summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-07-10clone3: drop __ARCH_WANT_SYS_CLONE3 macroArnd Bergmann
When clone3() was introduced, it was not obvious how each architecture deals with setting up the stack and keeping the register contents in a fork()-like system call, so this was left for the architecture maintainers to implement, with __ARCH_WANT_SYS_CLONE3 defined by those that already implement it. Five years later, we still have a few architectures left that are missing clone3(), and the macro keeps getting in the way as it's fundamentally different from all the other __ARCH_WANT_SYS_* macros that are meant to provide backwards-compatibility with applications using older syscalls that are no longer provided by default. Address this by reversing the polarity of the macro, adding an __ARCH_BROKEN_SYS_CLONE3 macro to all architectures that don't already provide the syscall, and remove __ARCH_WANT_SYS_CLONE3 from all the other ones. Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-10kbuild: add syscall table generation to scripts/Makefile.asm-headersArnd Bergmann
There are 11 copies of arch/*/kernel/syscalls/Makefile that all implement the same basic logic in a somewhat awkward way. I tried out various ways of unifying the existing copies and ended up with something that hooks into the logic for generating the redirections to asm-generic headers. This gives a nicer syntax of being able to list the generated files in $(syscall-y) inside of arch/*/include/asm/Kbuild instead of both $(generated-y) in that place and also in another Makefile. The configuration for which syscall.tbl file to use and which ABIs to enable is now done in arch/*/kernel/Makefile.syscalls. I have done patches for all architectures and made sure that the new generic rules implement a superset of all the architecture specific corner cases. ince the header file is not specific to asm-generic/*.h redirects now, I ended up renaming the file to scripts/Makefile.asm-headers. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-10kbuild: verify asm-generic header listArnd Bergmann
In order to integrate the system call header generation with generating the asm-generic wrappers, restrict the generated headers to those that actually exist in include/asm-generic/. The path is already known, so add these as a dependency. The asm-generic/bugs.h header was removed in commit 61235b24b9cb ("init: Remove check_bugs() leftovers"), which now causes a build failure, so drop it from the list. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-10loongarch: avoid generating extra header filesArnd Bergmann
The list of generated headers is rather outdated, some of these no longer exist, while others are already listed in include/asm-generic/Kbuild so there is no need to list them here. As we start validating the list of headers against the files that exist, the outdated ones now cause a warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-10um: don't generate asm/bpf_perf_event.hArnd Bergmann
If we start validating the existence of the asm-generic side of generated headers, this one causes a warning: make[3]: *** No rule to make target 'arch/um/include/generated/asm/bpf_perf_event.h', needed by 'all'. Stop. The problem is that the asm-generic header only exists for the uapi variant, but arch/um has no uapi headers and instead uses the x86 userspace API. Add a custom file with an explicit redirect to avoid this. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-10csky: drop asm/gpio.h wrapperArnd Bergmann
The asm/gpio.h header is gone now that all architectures just use gpiolib, and so the redirect is no longer valid. Acked-by: Guo Ren <guoren@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-10gpio: virtuser: actually use the "trimmed" local variableBartosz Golaszewski
This variable is set with the intention of being passed to the subsequent strcmp() but something went wrong and it was left unused. Use it now. Fixes: 91581c4b3f29 ("gpio: virtuser: new virtual testing driver for the GPIO API") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202407092245.BPnW2mr6-lkp@intel.com/ Link: https://lore.kernel.org/r/20240709151235.90523-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-07-10dt-bindings: iommu: Convert msm,iommu-v0 to yamlDavid Heidelberg
Convert Qualcomm IOMMU v0 implementation to yaml format. iommus part being ommited for the other bindings, as mdp4 one. Signed-off-by: David Heidelberg <david@ixit.cz> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20240705221520.109540-1-david@ixit.cz Signed-off-by: Will Deacon <will@kernel.org>
2024-07-10iommu/vt-d: Fix aligned pages in calculate_psi_aligned_address()Lu Baolu
The helper calculate_psi_aligned_address() is used to convert an arbitrary range into a size-aligned one. The aligned_pages variable is calculated from input start and end, but is not adjusted when the start pfn is not aligned and the mask is adjusted, which results in an incorrect number of pages returned. The number of pages is used by qi_flush_piotlb() to flush caches for the first-stage translation. With the wrong number of pages, the cache is not synchronized, leading to inconsistencies in some cases. Fixes: c4d27ffaa8eb ("iommu/vt-d: Add cache tag invalidation helpers") Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20240709152643.28109-3-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2024-07-10iommu/vt-d: Limit max address mask to MAX_AGAW_PFN_WIDTHLu Baolu
Address mask specifies the number of low order bits of the address field that must be masked for the invalidation operation. Since address bits masked start from bit 12, the max address mask should be MAX_AGAW_PFN_WIDTH, as defined in Table 19 ("Invalidate Descriptor Address Mask Encodings") of the spec. Limit the max address mask returned from calculate_psi_aligned_address() to MAX_AGAW_PFN_WIDTH to prevent potential integer overflow in the following code: qi_flush_dev_iotlb(): ... addr |= (1ULL << (VTD_PAGE_SHIFT + mask - 1)) - 1; ... Fixes: c4d27ffaa8eb ("iommu/vt-d: Add cache tag invalidation helpers") Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20240709152643.28109-2-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2024-07-10perf: add missing MODULE_DESCRIPTION() macrosJeff Johnson
With ARCH=x86, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/perf/arm-ccn.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/perf/fsl_imx8_ddr_perf.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/perf/marvell_cn10k_ddr_pmu.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/perf/arm_cspmu/arm_cspmu_module.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/perf/arm_cspmu/nvidia_cspmu.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/perf/arm_cspmu/ampere_cspmu.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/perf/cxl_pmu.o Add the missing invocation of the MODULE_DESCRIPTION() macro to all files which have a MODULE_LICENSE(). This includes drivers/perf/hisilicon/hisi_uncore_pmu.c which, although it did not produce a warning with the x86 allmodconfig configuration, may cause this warning with arm64 configurations. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240709-md-drivers-perf-v3-1-513275b75ed0@quicinc.com Signed-off-by: Will Deacon <will@kernel.org>
2024-07-10USB: uas: Implement the new shutdown callbackKerem Karabay
A standard implementation of shutdown callback has been implemented for USB drivers. Since the UAS driver implements a shutdown callback this patch enables it to use the new standard implementation. Signed-off-by: Kerem Karabay <kekrby@gmail.com> Signed-off-by: Aditya Garg <gargaditya08@live.com> Link: https://lore.kernel.org/r/E3A502A9-6572-4F1B-9EB2-2F6F0C4E6EA8@live.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-10USB: core: add 'shutdown' callback to usb_driverKerem Karabay
Currently there is no standardized method for USB drivers to handle shutdown events. This patch simplifies running code on shutdown for USB devices by adding a shutdown callback to usb_driver. Signed-off-by: Kerem Karabay <kekrby@gmail.com> Signed-off-by: Aditya Garg <gargaditya08@live.com> Link: https://lore.kernel.org/r/7AAC1BF4-8B60-448D-A3C1-B7E80330BE42@live.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-10usb: typec: Drop explicit initialization of struct ↵Uwe Kleine-König
i2c_device_id::driver_data to 0 These driver don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20240710073050.192806-2-u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-10usb: dwc3: enable CCI support for AMD-xilinx DWC3 controllerRadhey Shyam Pandey
The GSBUSCFG0 register bits [31:16] are used to configure the cache type settings of the descriptor and data write/read transfers (Cacheable, Bufferable/Posted). When CCI is enabled in the design, DWC3 core GSBUSCFG0 cache bits must be updated to support CCI enabled transfers in USB. To program GSBUSCFG0 cache bits create a software node property in AMD-xilinx dwc3 glue driver and pass it to dwc3 core. The core then reads this property value and configures it in dwc3_core_init() sequence. Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/1720548651-726412-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-10usb: dwc2: add support for other Lantiq SoCsHauke Mehrtens
The size of the internal RAM of the DesignWare USB controller changed between the different Lantiq SoCs. We have the following sizes: Amazon + Danube: 8 KByte Amazon SE + arx100: 2 KByte xrx200 + xrx300: 2.5 KByte For Danube SoC we do not provide the params and let the driver decide to use sane defaults, for the Amazon SE and arx100 we use small fifos and for the xrx200 and xrx300 SCs a little bit bigger periodic fifo. The auto detection of max_transfer_size and max_packet_count should work, so remove it. This patch is included in OpenWrt for many years. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Minas Harutyunyan <hminas@synopsys.com> Link: https://lore.kernel.org/r/20240708222054.2727789-1-hauke@hauke-m.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-10usb: gadget: Use u16 types for 16-bit fieldsKees Cook
Since the beginning of time, struct usb_ep::maxpacket was a bitfield, and when new 16-bit members were added, the convention was followed: 1da177e4c3f41 (Linus Torvalds 2005-04-16 236) unsigned maxpacket:16; e117e742d3106 (Robert Baldyga 2013-12-13 237) unsigned maxpacket_limit:16; a59d6b91cbca5 (Tatyana Brokhman 2011-06-28 238) unsigned max_streams:16; However, there is no need for this as a simple u16 can be used instead, simplifying the struct and the resulting compiler binary output. Switch to u16 for all three, and rearrange struct slightly to minimize holes. No change in the final size of the struct results; the 2 byte gap is just moved to the end, as seen with pahole: - /* XXX 2 bytes hole, try to pack */ ... /* size: 72, cachelines: 2, members: 15 */ ... + /* padding: 2 */ Changing this simplifies future introspection[1] of maxpacket's type during allocations: drivers/usb/gadget/function/f_tcm.c:330:24: error: 'typeof' applied to a bit-field 330 | fu->cmd.buf = kmalloc(fu->ep_out->maxpacket, GFP_KERNEL); Link: https://lore.kernel.org/all/202407090928.6UaOAZAJ-lkp@intel.com [1] Signed-off-by: Kees Cook <kees@kernel.org> Link: https://lore.kernel.org/r/20240709154953.work.953-kees@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-10usb: gadget: midi2: Fix incorrect default MIDI2 protocol setupTakashi Iwai
The MIDI2 gadget driver handled the default MIDI protocol version incorrectly due to the confusion of the protocol version passed via configfs (either 1 or 2) and UMP protocol bits (0x100 / 0x200). As a consequence, the default protocol always resulted in MIDI1. This patch addresses the misunderstanding of the protocol handling. Fixes: 29ee7a4dddd5 ("usb: gadget: midi2: Add configfs support") Cc: stable <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240708095719.25627-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-10Merge tag 'mt76-for-kvalo-2024-07-08' of https://github.com/nbd168/wirelessKalle Valo
mt76 patches for 6.11 - mt7925 MLO support - mt7925 fix
2024-07-10thermal: imx: Drop critical trip check from imx_set_trip_temp()Rafael J. Wysocki
Because the IMX thermal driver does not flag its critical trip as writable, imx_set_trip_temp() will never be invoked for it and so the critical trip check can be dropped from there. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2272035.iZASKD2KPV@rjwysocki.net
2024-07-10dm raid: fix stripes adding reshape size issuesHeinz Mauelshagen
Adding stripes to an existing raid4/5/6/10 mapped device grows its capacity though it'll be only made available _after_ the respective reshape finished as of MD kernel reshape semantics. Such reshaping involves moving a window forward starting at BOD reading content from previous lesser stripes and writing them back in the new layout with more stripes. Once that process finishes at end of previous data, the grown size may be announced and used. In order to avoid writing over any existing data in place, out-of-place space is added to the beginning of each data device by lvm2 before starting the reshape process. That reshape space wasn't taken into acount for data device size calculation. Fixes resulting from above: - correct event handling conditions in do_table_event() to set the device's capacity after the stripe adding reshape ended - subtract mentioned out-of-place space doing data device and array size calculations - conditionally set capacity as of superblock in preresume Testing: - passes all LVM2 RAID tests including new lvconvert-raid-reshape-size.sh one Tested-by: Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-10dm raid: move _get_reshape_sectors() as prerequisite to fixing reshape size ↵Heinz Mauelshagen
issues rs_set_dev_and_array_sectors() needs this function to calculate device and array size properly in case leg data devices have out-of-place reshape space allocated. Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-10dm-crypt: support for per-sector NVMe metadataMikulas Patocka
Support per-sector NVMe metadata in dm-crypt. This commit changes dm-crypt, so that it can use NVMe metadata to store authentication information. We can put dm-crypt directly on the top of NVMe device, without using dm-integrity. This commit improves write throughput twice, becase the will be no writes to the dm-integrity journal. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-10dm mpath: don't call dm_get_device in multipath_messageBenjamin Marzinski
When mutipath_message is called with an action and a device, it needs to find the pgpath that matches that device. dm_get_device() is not the right function for this. dm_get_device() will look for a table_device matching the requested path in use by either the live or inactive table. If it doesn't find the device, dm_get_device() will open it and add it to the table. Means that multipath_message will accept any block device, add it to the table if not present, and then look through the pgpaths to see if it finds a match. Afterwards it will remove the device if it was not previously in the table devices list. This is the only function that can modify the device list of a table besides the constructors and destructors, and it can only do this when it was passed an invalid message. Instead, multipath_message() should call dm_devt_from_path() to get the device dev_t, and match that against its pgpaths. Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-10dm: factor out helper function from dm_get_deviceBenjamin Marzinski
Factor out a helper function, dm_devt_from_path(), from dm_get_device() for use in dm targets. Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-10dm-verity: fix dm_is_verity_target() when dm-verity is builtinEric Biggers
When CONFIG_DM_VERITY=y, dm_is_verity_target() returned true for any builtin dm target, not just dm-verity. Fix this by checking for verity_target instead of THIS_MODULE (which is NULL for builtin code). Fixes: b6c1c5745ccc ("dm: Add verity helpers for LoadPin") Cc: stable@vger.kernel.org Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-10dm: Remove max_secure_erase_granularityDamien Le Moal
The max_secure_erase_granularity boolean of struct dm_target is used in __process_abnormal_io() but never set by any target. Remove this field and the dead code using it. Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-10dm: Remove max_write_zeroes_granularityDamien Le Moal
The max_write_zeroes_granularity boolean of struct dm_target is used in __process_abnormal_io() but never set by any target. Remove this field and the dead code using it. Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-10dm vdo indexer: use swap() instead of open coding itJiapeng Chong
Use existing swap() macro rather than duplicating its implementation. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9173 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-10dm vdo: remove unused struct 'uds_attribute'Dr. David Alan Gilbert
'uds_attribute' is unused since commit a9da0fb6d8c6 ("dm vdo: remove all sysfs interfaces"). Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-10dm: stop using blk_limits_io_{min,opt}Christoph Hellwig
Remove use of the blk_limits_io_{min,opt} and assign the values directly to the queue_limits structure. For the io_opt this is a completely mechanical change, for io_min it removes flooring the limit to the physical and logical block size in the particular caller. But as blk_validate_limits will do the same later when actually applying the limits, there still is no change in overall behavior. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-10dm-crypt: limit the size of encryption requestsMikulas Patocka
There was a performance regression reported where dm-crypt would perform worse on new kernels than on old kernels. The reason is that the old kernels split the bios to NVMe request size (that is usually 65536 or 131072 bytes) and the new kernels pass the big bios through dm-crypt and split them underneath. If a big 1MiB bio is passed to dm-crypt, dm-crypt processes it on a single core without parallelization and this is what causes the performance degradation. This commit introduces new tunable variables /sys/module/dm_crypt/parameters/max_read_size and /sys/module/dm_crypt/parameters/max_write_size that specify the maximum bio size for dm-crypt. Bios larger than this value are split, so that they can be encrypted in parallel by multiple cores. If these variables are '0', a default 131072 is used. Splitting bios may cause performance regressions in other workloads - if this happens, the user should increase the value in max_read_size and max_write_size variables. max_read_size: 128k 2399MiB/s 256k 2368MiB/s 512k 1986MiB/s 1024 1790MiB/s max_write_size: 128k 1712MiB/s 256k 1651MiB/s 512k 1537MiB/s 1024k 1332MiB/s Note that if you run dm-crypt inside a virtual machine, you may need to do "echo numa >/sys/module/workqueue/parameters/default_affinity_scope" to improve performance. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Tested-by: Laurence Oberman <loberman@redhat.com>
2024-07-10Merge back ACPI processor driver material for 6.11.Rafael J. Wysocki
2024-07-10Merge back cpufreq material for 6.11.Rafael J. Wysocki
2024-07-10Merge back thermal control material for 6.11.Rafael J. Wysocki
2024-07-10erofs: get rid of z_erofs_map_blocks_iter_* tracepointsHongzhen Luo
Consolidate them under erofs_map_blocks_* for simplicity since we have many other ways to know if a given inode is compressed or not. Signed-off-by: Hongzhen Luo <hongzhen@linux.alibaba.com> Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/20240710083459.208362-1-hongzhen@linux.alibaba.com Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2024-07-10wifi: mac80211: fix AP chandef capturing in CSAJohannes Berg
When the CSA is announced with only HT elements, the AP chandef isn't captured correctly, leading to crashes in the later code that checks for TPE changes during CSA. Capture the AP chandef correctly in both cases to fix this. Reported-by: Jouni Malinen <j@w1.fi> Fixes: 4540568136fe ("wifi: mac80211: handle TPE element during CSA") Link: https://patch.msgid.link/20240709160851.47805f24624d.I024091f701447f7921e93bb23b46e01c2f46347d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-10wifi: iwlwifi: correctly reference TSO page informationBenjamin Berg
The code got copied from get_workaround_page, but here p->page is the correct way to reference the page. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Fixes: adc902ceada2 ("wifi: iwlwifi: keep the TSO and workaround pages mapped") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202407062135.NNjnmMdR-lkp@intel.com/ Link: https://patch.msgid.link/20240709123149.1848315-1-benjamin@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-10arm64/efistub: Clean up KASLR logicArd Biesheuvel
Clean up some redundant code in the KASLR placement handling logic. No functional change intended. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-07-10Merge branch 'aquantia-phy-aqr115c' into mainDavid S. Miller
Bartosz Golaszewski says: ==================== net: phy: aquantia: enable support for aqr115c This series addesses two issues with the aqr115c PHY on Qualcomm sa8775p-ride-r3 board and adds support for this PHY to the aquantia driver. While the manufacturer calls the 2.5G PHY mode OCSGMII, we reuse the existing 2500BASEX mode in the kernel to avoid extending the uAPI. It took me a while to resend because I noticed an issue with the PHY coming out of suspend with no possible interfaces listed and tracked it to the GLOBAL_CFG registers for different modes returning 0. A workaround has been added to the series. Unfortunately the HPG doesn't mention a proper way of doing it or even mention any such issue at all. Changes since v2: - add a patch that addresses an issue with GLOBAL_CFG registers returning 0 - reuse aqr113c_config_init() for aqr115c - improve commit messages, give more details on the 2500BASEX mode reuse Link to v2: https://lore.kernel.org/lkml/Zn4Nq1QvhjAUaogb@makrotopia.org/T/ Changes since v1: - split out the PHY patches into their own series - don't introduce new mode (OCSGMII) but use existing 2500BASEX instead - split the wait-for-FW patch into two: one renaming and exporting the relevant function and the second using it before checking the FW ID Link to v1: https://lore.kernel.org/linux-arm-kernel/20240619184550.34524-1-brgl@bgdev.pl/T/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2024-07-10dt-bindings: fsl-qdma: fix interrupts 'if' check logicFrank Li
All compatible string include 'fsl,ls1021a-qdma'. Previous if check are always true. if: properties: compatible: contains: enum: - fsl,ls1021a-qdma Change to check other compatible strings to get correct logic and fix below CHECK_DTB warnings. arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dtb: dma-controller@8380000: interrupts: [[0, 43, 4], [0, 251, 4], [0, 252, 4], [0, 253, 4], [0, 254, 4]] is too long Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20240701195717.1843041-1-Frank.Li@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2024-07-10dt-bindings: dma: sprd,sc9860-dma: convert to YAMLStanislav Jakubek
Convert the Spreadtrum SC9860 DMA bindings to DT schema. Changes during conversion: - rename file to match compatible - make interrupts optional, the AGCP DMA controller doesn't need it - describe the optional ashb_eb clock for the AGCP DMA controller Signed-off-by: Stanislav Jakubek <stano.jakubek@gmail.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/Zob1+kGW1xeBKehA@standask-GA-A55M-S2HP Signed-off-by: Vinod Koul <vkoul@kernel.org>
2024-07-10perf kvm: Add kvm-stat for loongarch64Bibo Mao
Add support for 'perf kvm stat' on loongarch64 platform, now only kvm exit event is supported. Here is example output about "perf kvm --host stat report" command Event name Samples Sample% Time (ns) Time% Mean Time (ns) Mem Store 83969 51.00% 625697070 8.00% 7451 Mem Read 37641 22.00% 112485730 1.00% 2988 Interrupt 15542 9.00% 20620190 0.00% 1326 IOCSR 15207 9.00% 94296190 1.00% 6200 Hypercall 4873 2.00% 12265280 0.00% 2516 Idle 3713 2.00% 6322055860 87.00% 1702681 FPU 1819 1.00% 2750300 0.00% 1511 Inst Fetch 502 0.00% 1341740 0.00% 2672 Mem Modify 324 0.00% 602240 0.00% 1858 CPUCFG 55 0.00% 77610 0.00% 1411 CSR 12 0.00% 19690 0.00% 1640 LASX 3 0.00% 4870 0.00% 1623 LSX 2 0.00% 2100 0.00% 1050 Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2024-07-10Merge tag 'drm-intel-next-2024-06-28' of ↵Daniel Vetter
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next drm/i915 feature pull #2 for v6.11: Features and functionality: - More eDP Panel Replay enabling (Jouni) - Add async flip and flip done tracepoints (Ville) Refactoring and cleanups: - Clean up BDW+ pipe interrupt register definitions (Ville) - Prep work for DSB based plane programming (Ville) - Relocate encoder suspend/shutdown helpers (Imre) - Polish plane surface alignment handling (Ville) Fixes: - Enable more fault interrupts on TGL+/MTL+ (Ville) - Fix CMRR 32-bit build (Mitul) - Fix PSR Selective Update Region Scan Line Capture Indication (Jouni) - Fix cursor fb unpinning (Maarten, Ville) - Fix Cx0 PHY PLL state verification in TBT mode (Imre) - Fix unnecessary MG DP programming on MTL+ Type-C (Imre) DRM changes: - Rename drm_plane_check_pixel_format() to drm_plane_has_format() and export (Ville) - Add drm_vblank_work_flush_all() (Maarten) Xe driver changes: - Call encoder .suspend_complete() hook also on Xe (Imre) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/875xttazx2.fsf@intel.com
2024-07-10docs: rust: quick-start: add section on Linux distributionsMiguel Ojeda
Now that we are starting to support several Rust compiler and `bindgen` versions, there is a good chance some Linux distributions work out of the box. Thus, provide some instructions on how to set the toolchain up for a few major Linux distributions. This simplifies the setup users need to build the kernel. In addition, add an introduction to the document so that it is easier to understand its structure and move the LLVM+Rust kernel.org toolchains paragraph there (removing "depending on the Linux version"). We may want to reorganize the document or split it in the future, but I wanted to focus this commit on the new information added about each particular distribution. Finally, remove the `rustup`'s components mention in `changes.rst` since users do not need it if they install the toolchain via the distributions (and anyway it was too detailed for that main document). Cc: Jan Alexander Steffens <heftig@archlinux.org> Cc: Johannes Löthberg <johannes@kyriasis.com> Cc: Fabian Grünbichler <debian@fabian.gruenbichler.email> Cc: Josh Stone <jistone@redhat.com> Cc: Randy Barlow <randy@electronsweatshop.com> Cc: Anna (navi) Figueiredo Gomes <navi@vlhl.dev> Cc: Matoro Mahri <matoro_gentoo@matoro.tk> Cc: Ryan Scheel <ryan.havvy@gmail.com> Cc: figsoda <figsoda@pm.me> Cc: Jörg Thalheim <joerg@thalheim.io> Cc: Theodore Ni <43ngvg@masqt.com> Cc: Winter <nixos@winter.cafe> Cc: William Brown <wbrown@suse.de> Cc: Xiaoguang Wang <xiaoguang.wang@suse.com> Cc: Andrea Righi <andrea.righi@canonical.com> Cc: Zixing Liu <zixing.liu@canonical.com> Cc: Nathan Chancellor <nathan@kernel.org> Tested-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@samsung.com> Link: https://lore.kernel.org/r/20240709160615.998336-14-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-10rust: warn about `bindgen` versions 0.66.0 and 0.66.1Miguel Ojeda
`bindgen` versions 0.66.0 and 0.66.1 panic due to C string literals with NUL characters [1]: panicked at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bindgen-0.66.0/codegen/mod.rs:717:71: called `Result::unwrap()` on an `Err` value: FromBytesWithNulError { kind: InteriorNul(4) } Thus, in preparation for supporting several `bindgen` versions, add a version check to warn the user about it. Since some distributions may have patched it (e.g. Debian did [2]), check if that seems to be the case (after the version check matches), in order to avoid printing a warning in that case. We could make it an error, but 1) it is going to fail anyway later in the build, 2) we would disable `RUST`, which is also painful, 3) someone could have patched it in a way that still makes our extra check fail (however unlikely), 4) the interior NUL may go away in the headers (however unlikely). Thus just warn about it so that users know why it is failing. In addition, add a couple tests for the new cases. Link: https://github.com/rust-lang/rust-bindgen/pull/2567 [1] Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069047 [2] Link: https://lore.kernel.org/r/20240709160615.998336-11-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-10rust: start supporting several `bindgen` versionsMiguel Ojeda
With both the workaround for `bindgen` 0.69.0 and the warning about 0.66.0 and 0.66.1 in place, start supporting several `bindgen` versions, like it was done for the Rust compiler in a previous patch. All other versions, including the latest 0.69.4, build without errors. The `bindgen` project, like Rust, has also agreed to have the kernel in their CI [1] -- thanks! This should help both projects: `bindgen` will be able to detect early issues like those mentioned above, and the kernel will be very likely build with new releases (at least for the basic configuration being tested). Link: https://github.com/rust-lang/rust-bindgen/pull/2851 [1] Tested-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@samsung.com> Link: https://lore.kernel.org/r/20240709160615.998336-10-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-10rust: work around `bindgen` 0.69.0 issueMiguel Ojeda
`bindgen` 0.69.0 contains a bug: `--version` does not work without providing a header [1]: error: the following required arguments were not provided: <HEADER> Usage: bindgen <FLAGS> <OPTIONS> <HEADER> -- <CLANG_ARGS>... Thus, in preparation for supporting several `bindgen` versions, work around the issue by passing a dummy argument. Include a comment so that we can remove the workaround in the future. Link: https://github.com/rust-lang/rust-bindgen/pull/2678 [1] Reviewed-by: Finn Behrens <me@kloenk.dev> Tested-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@samsung.com> Link: https://lore.kernel.org/r/20240709160615.998336-9-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-10rust: avoid assuming a particular `bindgen` buildMiguel Ojeda
`bindgen`'s logic to find `libclang` (via `clang-sys`) may change over time, and depends on how it was built (e.g. Linux distributions may decide to build it differently, and we are going to provide documentation on installing it via distributions later in this series). Therefore, clarify that `bindgen` may be built in several ways and simplify the documentation by only mentioning the most prominent environment variable (`LIBCLANG_PATH`) as an example on how to tweak the search of the library at runtime (i.e. when `bindgen` is built as our documentation explains). This also avoids duplicating the documentation, like `bindgen` itself does (i.e. it refers to `clang-sys`). Similarly, replace the test we had for this (which used the real program) with a mocked one, to avoid depending on the particular build as well. Tested-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@samsung.com> Link: https://lore.kernel.org/r/20240709160615.998336-8-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-10rust: start supporting several compiler versionsMiguel Ojeda
It is time to start supporting several Rust compiler versions and thus establish a minimum Rust version. We may still want to upgrade the minimum sometimes in the beginning since there may be important features coming into the language that improve how we write code (e.g. field projections), which may or may not make sense to support conditionally. We will start with a window of two stable releases, and widen it over time. Thus this patch does not move the current minimum (1.78.0), but instead adds support for the recently released 1.79.0. This should already be enough for kernel developers in distributions that provide recent Rust compiler versions routinely, such as Arch Linux, Debian Unstable (outside the freeze period), Fedora Linux, Gentoo Linux (especially the testing channel), Nix (unstable) and openSUSE Tumbleweed. See the documentation patch about it later in this series. In addition, Rust for Linux is now being built-tested in Rust's pre-merge CI [1]. That is, every change that is attempting to land into the Rust compiler is tested against the kernel, and it is merged only if it passes -- thanks to the Rust project for that! Thus, with the pre-merge CI in place, both projects hope to avoid unintentional changes to Rust that break the kernel. This means that, in general, apart from intentional changes on their side (that we will need to workaround conditionally on our side), the upcoming Rust compiler versions should generally work. For instance, currently, the beta (1.80.0) and nightly (1.81.0) branches work as well. Of course, the Rust for Linux CI job in the Rust toolchain may still need to be temporarily disabled for different reasons, but the intention is to help bring Rust for Linux into stable Rust. Link: https://github.com/rust-lang/rust/pull/125209 [1] Reviewed-by: Finn Behrens <me@kloenk.dev> Tested-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@samsung.com> Link: https://lore.kernel.org/r/20240709160615.998336-7-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>