summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-07-01Merge tag 'renesas-dts-for-v6.11-tag2-v2' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt * tag 'renesas-dts-for-v6.11-tag2-v2' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: arm64: dts: renesas: r8a779h0: R-Car Sound support arm64: dts: renesas: r8a779g0: Tidy up sound DT settings arm64: dts: renesas: Add interrupt-names to arch timer nodes ARM: dts: renesas: Add interrupt-names to arch timer nodes arm64: dts: renesas: r9a08g045: Add missing hypervisor virtual timer IRQ arm64: dts: renesas: r9a07g054: Add missing hypervisor virtual timer IRQ arm64: dts: renesas: r9a07g044: Add missing hypervisor virtual timer IRQ arm64: dts: renesas: r9a07g043u: Add missing hypervisor virtual timer IRQ arm64: dts: renesas: r8a779g0: Add missing hypervisor virtual timer IRQ arm64: dts: renesas: r8a779f0: Add missing hypervisor virtual timer IRQ arm64: dts: renesas: r8a779a0: Add missing hypervisor virtual timer IRQ arm64: dts: renesas: r8a779h0: Drop "opp-shared" from opp-table-0 Link: https://lore.kernel.org/r/cover.1719837594.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-01power: supply: cros_charge-control: don't load if Framework control is presentThomas Weißschuh
Framework laptops implement a custom charge control EC command. The upstream CrOS EC command is also present and functional but can get overridden by the custom one. Until Framework make both commands compatible or remove their custom one, don't load the driver on those machines. If the user knows they are not going to use the custom command they can use a module parameter to load cros_charge-control anyways. Note that the UEFI setup configuration for battery control also uses their custom command. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240630-cros_ec-charge-control-v5-5-8f649d018c52@weissschuh.net Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-07-01power: supply: add ChromeOS EC based charge control driverThomas Weißschuh
The ChromeOS Embedded Controller implements a command to control charge thresholds and behaviour. Use it to implement the standard Linux charge_control_start_threshold, charge_control_end_threshold and charge_behaviour sysfs UAPIs. The driver is designed to be probed via the cros_ec mfd device. Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240630-cros_ec-charge-control-v5-4-8f649d018c52@weissschuh.net Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-07-01platform/chrome: cros_ec_proto: Introduce cros_ec_get_cmd_versions()Thomas Weißschuh
Retrieving the supported versions of a command is a fairly common operation. Provide a helper for it. If the command is not supported at all the EC returns -EINVAL/EC_RES_INVALID_PARAMS. This error is translated into an empty version mask as that is easier to handle for callers and they don't need to know about the error details. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240630-cros_ec-charge-control-v5-3-8f649d018c52@weissschuh.net Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-07-01platform/chrome: Update binary interface for EC-based charge controlThomas Weißschuh
The charge-control command v2/v3 is more featureful than v1, it additionally supports charge thresholds. The definitions were imported from ChromeOS EC commit 32870d602317 ("squirtle: modify motionsense rotation matrix") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240630-cros_ec-charge-control-v5-2-8f649d018c52@weissschuh.net Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-07-01ACPI: battery: add devm_battery_hook_register()Thomas Weißschuh
Add a utility function for device-managed registration of battery hooks. The function makes it easier to manage the lifecycle of a hook. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240630-cros_ec-charge-control-v5-1-8f649d018c52@weissschuh.net Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-07-01firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headersRichard Fitzgerald
Check that all fields of a V2 algorithm header fit into the available firmware data buffer. The wmfw V2 format introduced variable-length strings in the algorithm block header. This means the overall header length is variable, and the position of most fields varies depending on the length of the string fields. Each field must be checked to ensure that it does not overflow the firmware data buffer. As this ia bugfix patch, the fixes avoid making any significant change to the existing code. This makes it easier to review and less likely to introduce new bugs. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/20240627141432.93056-5-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-01firmware: cs_dsp: Validate payload length before processing blockRichard Fitzgerald
Move the payload length check in cs_dsp_load() and cs_dsp_coeff_load() to be done before the block is processed. The check that the length of a block payload does not exceed the number of remaining bytes in the firwmware file buffer was being done near the end of the loop iteration. However, some code before that check used the length field without validating it. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/20240627141432.93056-4-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-01firmware: cs_dsp: Return error if block header overflows fileRichard Fitzgerald
Return an error from cs_dsp_power_up() if a block header is longer than the amount of data left in the file. The previous code in cs_dsp_load() and cs_dsp_load_coeff() would loop while there was enough data left in the file for a valid region. This protected against overrunning the end of the file data, but it didn't abort the file processing with an error. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/20240627141432.93056-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-01firmware: cs_dsp: Fix overflow checking of wmfw headerRichard Fitzgerald
Fix the checking that firmware file buffer is large enough for the wmfw header, to prevent overrunning the buffer. The original code tested that the firmware data buffer contained enough bytes for the sums of the size of the structs wmfw_header + wmfw_adsp1_sizes + wmfw_footer But wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 and Halo Core the equivalent struct is wmfw_adsp2_sizes, which is 4 bytes longer. So the length check didn't guarantee that there are enough bytes in the firmware buffer for a header with wmfw_adsp2_sizes. This patch splits the length check into three separate parts. Each of the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checked separately before they are used. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/20240627141432.93056-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-01dt-bindings: soc: ti: Move ti,j721e-system-controller.yaml to soc/tiRoger Quadros
soc/ti is the more appropriate location for the system controller device tree binding documentation so move there. Update Kishon's email address to a working one. Signed-off-by: Roger Quadros <rogerq@kernel.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20240520-for-v6-11-j721e-syscon-v1-1-f57a93e12cad@kernel.org Signed-off-by: Nishanth Menon <nm@ti.com>
2024-07-01nvme: don't set io_opt if NOWS is zeroChristoph Hellwig
NOWS is one of the annoying "0's based values" in NVMe, where 0 means one and we thus can't detect if it isn't set. Thus a NOWS value of 0 means that the Namespace Optimal Write Size is a single LBA, which is clearly bogus. Ignore the value in that case and don't propagate an io_opt value to the block layer. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Nitesh Shetty <nj.shetty@samsung.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Link: https://lore.kernel.org/r/20240701051800.1245240-4-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-07-01block: don't reduce max_sectors based on io_optChristoph Hellwig
Don't reduce the max_sectors value below the normal cap when the driver advertsizes a very low io_opt. This restores the behavior we had before the recent changes to the max_sectors calculation. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Nitesh Shetty <nj.shetty@samsung.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Link: https://lore.kernel.org/r/20240701051800.1245240-3-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-07-01block: remove a duplicate io_min check in blk_validate_limitsChristoph Hellwig
If io_min is larger than the cap, it must by definition be non-zero. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Nitesh Shetty <nj.shetty@samsung.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Link: https://lore.kernel.org/r/20240701051800.1245240-2-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-07-01syscalls: fix sys_fanotify_mark prototypeArnd Bergmann
My earlier fix missed an incorrect function prototype that shows up on native 32-bit builds: In file included from fs/notify/fanotify/fanotify_user.c:14: include/linux/syscalls.h:248:25: error: conflicting types for 'sys_fanotify_mark'; have 'long int(int, unsigned int, u32, u32, int, const char *)' {aka 'long int(int, unsigned int, unsigned int, unsigned int, int, const char *)'} 1924 | SYSCALL32_DEFINE6(fanotify_mark, | ^~~~~~~~~~~~~~~~~ include/linux/syscalls.h:862:17: note: previous declaration of 'sys_fanotify_mark' with type 'long int(int, unsigned int, u64, int, const char *)' {aka 'long int(int, unsigned int, long long unsigned int, int, const char *)'} On x86 and powerpc, the prototype is also wrong but hidden in an #ifdef, so it never caused problems. Add another alternative declaration that matches the conditional function definition. Fixes: 403f17a33073 ("parisc: use generic sys_fanotify_mark implementation") Cc: stable@vger.kernel.org Reported-by: Guenter Roeck <linux@roeck-us.net> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-01blk-wbt: don't throttle swap writes in direct reclaimBaokun Li
Now we avoid throttling swap writes by determining whether the current process is kswapd (aka current_is_kswapd()), but swap writes can come from either kswapd or direct reclaim, so the swap writes from direct reclaim will still be throttled. When a process holds a lock to allocate a free page, and enters direct reclaim because there is no free memory, then it might trigger a hung due to the wbt throttling that causes other processes to fail to get the lock. Both kswapd and direct reclaim set the REQ_SWAP flag, so use REQ_SWAP instead of current_is_kswapd() to avoid throttling swap writes. Also renamed WBT_KSWAPD to WBT_SWAP and WBT_RWQ_KSWAPD to WBT_RWQ_SWAP. Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20240604030522.3686177-1-libaokun@huaweicloud.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-07-01HID: bpf: Thrustmaster TCA Yoke Boeing joystick fixBenjamin Tissoires
This joystick's original HID descriptor is wrong & it shows a ABS_MISC axis in Linux that doesn't exist on the hardware. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/82 Signed-off-by: K S Iyer <kumar.s.iyer65@gmail.com> Link: https://patch.msgid.link/20240627-import-bpf-v1-6-0dbcda4a5b1f@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-07-01HID: bpf: Add Huion Dial 2 bpf fixupBenjamin Tissoires
Pretty much similar to the Inspiroy 2, but with 2 wheels and 8 buttons. This bpf also works in both normal and vendor mode. If the device is switched into vendor mode by huion-switcher, a udev property is set which is then retrieved by this bpf object. This allows to hide the now unused normal collections. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/103 Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/104 Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/111 Link: https://patch.msgid.link/20240627-import-bpf-v1-5-0dbcda4a5b1f@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-07-01HID: bpf: Add support for the XP-PEN Deco Mini 4Benjamin Tissoires
The XP-PEN Deco Mini 4 is a UGEE device with a frame with 6 buttons. Its pen has 2 buttons and supports pressure reporting. Fix their report descriptors and transform the frame button events to support it. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/88 Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://patch.msgid.link/20240627-import-bpf-v1-4-0dbcda4a5b1f@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-07-01HID: bpf: move the BIT() macro to hid_bpf_helpers.hBenjamin Tissoires
This macro can be useful in mopre than one place Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/commit/7970a9c17aa0756bad63e89fccb6ee4f2ec83ccc Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://patch.msgid.link/20240627-import-bpf-v1-3-0dbcda4a5b1f@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-07-01HID: bpf: add a driver for the Huion Inspiroy 2S (H641P)Benjamin Tissoires
This is a a driver for the Huion Inspiroy 2S in both modes (firmware mode and tablet mode). This device has 6 buttons and a wheel, all of which send key combinations (see the comments for the defaults). Luckily the device is quite limited in that it only supports one button down at a time, so with this BPF we can simply remap the 8 possible report IDs to our own custom-built report descriptor. If the device is in tablet mode (e.g. using huion-switcher it sends everything through the vendor report instead). This BPF program converts both, depending which devices you attach to you get both. Or if you attach to all hid devices you get a duplicate device but it'll work either way. This BPF should be mostly compatible for the M and L as well though they have more buttons so the rdescs will need some minor rework. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/85 Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/109 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Link: https://patch.msgid.link/20240627-import-bpf-v1-2-0dbcda4a5b1f@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-07-01HID: bpf: Add a HID report composition helper macrosBenjamin Tissoires
These macros make it slightly easier and more modular to create a HID report descriptor from scratch. Since they carry the annotation we don't need to comment it and they cannot get stale. For comparison, before we had this: 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x95, 0x04, // Report Count (4) 0x75, 0x01, // Report Size (1) Now we can write this as: LogicalRange_i8(0, 1) ReportCount(4) ReportSize(1) Because these macros are for creating new report descriptors, some bits aren't directly exposed. e.g in the example above: there is a logical range as one macro that sets both min and max. There is seldom a good use case for skipping either anyway. These macros will need to be expanded over time. For Usage Pages and Usage IDs, we use a tool to parse the HUT JSON (attached to the HUT 1.5 PDF [1]) and generate all #defines for all usage pages and usages in the form: #define UsagePage_Foo_Bar #define Usage_FB_SomeOrOther Where the FB is simply the acronym based on the capital letters in the Usage Page name or the first three letters, whichever makes slightly more sense. [1] https://usb.org/document-library/hid-usage-tables-15 Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/92 Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/96 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Link: https://patch.msgid.link/20240627-import-bpf-v1-1-0dbcda4a5b1f@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-07-01HID: bpf: doc fixes for hid_hw_request() hooksBenjamin Tissoires
We had the following errors while doing make htmldocs: Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:167: ERROR: Unexpected indentation. Also ensure consistency with the rest of the __u64 vs u64. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 9286675a2aed ("HID: bpf: add HID-BPF hooks for hid_hw_output_report") Link: https://patch.msgid.link/20240701-fix-cki-v2-4-20564e2e1393@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-07-01HID: bpf: doc fixes for hid_hw_request() hooksBenjamin Tissoires
We had the following errors while doing make htmldocs: Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:144: ERROR: Unexpected indentation. Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:145: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/hid/hid-bpf:185: include/linux/hid_bpf.h:147: ERROR: Unexpected indentation. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 8bd0488b5ea5 ("HID: bpf: add HID-BPF hooks for hid_hw_raw_requests") Link: https://patch.msgid.link/20240701-fix-cki-v2-3-20564e2e1393@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-07-01HID: bpf: fix gcc warning and unify __u64 into u64Benjamin Tissoires
I've got multiple reports of: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]. Let's use the same trick than kernel/bpf/helpers.c to shut up that warning. Even if we were on an architecture with addresses on more than 64 bits, this isn't much of an issue as the address is not used as a pointer, but as an hash and the caller is not supposed to go back to the kernel address ever. And while we change those, make sure we use u64 instead of __u64 for consistency Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406280633.OPB5uIFj-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202406282304.UydSVncq-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202406282242.Fk738zzy-lkp@intel.com/ Reported-by: Mirsad Todorovac <mtodorovac69@gmail.com> Fixes: 67eccf151d76 ("HID: add source argument to HID low level functions") Link: https://patch.msgid.link/20240701-fix-cki-v2-2-20564e2e1393@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-07-01selftests/hid: ensure CKI can compile our new tests on old kernelsBenjamin Tissoires
In the same way than commit ae7487d112cf ("selftests/hid: ensure we can compile the tests on kernels pre-6.3") we should expose struct hid_bpf_ops when it's not available in vmlinux.h. So unexpose an eventual struct hid_bpf_ops, include vmlinux.h, and re-export struct hid_bpf_ops. Fixes: d7696738d66b ("selftests/hid: convert the hid_bpf selftests with struct_ops") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202406270328.bscLN1IF-lkp@intel.com/ Link: https://patch.msgid.link/20240701-fix-cki-v2-1-20564e2e1393@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-07-01net: ethtool: Fix the panic caused by dev being null when dumping coalesceHeng Qi
syzbot reported a general protection fault caused by a null pointer dereference in coalesce_fill_reply(). The issue occurs when req_base->dev is null, leading to an invalid memory access. This panic occurs if dumping coalesce when no device name is specified. Fixes: f750dfe825b9 ("ethtool: provide customized dim profile management") Reported-by: syzbot+e77327e34cdc8c36b7d3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e77327e34cdc8c36b7d3 Signed-off-by: Heng Qi <hengqi@linux.alibaba.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-07-01Merge tag 'v6.10-rockchip-dtsfixes1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes Apart from the regular dts fixes for wrong addresses, missing or wrong properties, this reverts the previous move away from cd-gpios to the mmc-controller's internal card-detect. With this change applied, it was reported that boards could not detect card anymore, so this go reverted of course. * tag 'v6.10-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: arm64: dts: rockchip: Add sound-dai-cells for RK3368 arm64: dts: rockchip: Fix the i2c address of es8316 on Cool Pi 4B arm64: dts: rockchip: fix PMIC interrupt pin on ROCK Pi E arm64: dts: rockchip: make poweroff(8) work on Radxa ROCK 5A Revert "arm64: dts: rockchip: remove redundant cd-gpios from rk3588 sdmmc nodes" ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node arm64: dts: rockchip: Fix the value of `dlg,jack-det-rate` mismatch on rk3399-gru arm64: dts: rockchip: set correct pwm0 pinctrl on rk3588-tiger arm64: dts: rockchip: Rename LED related pinctrl nodes on rk3308-rock-pi-s arm64: dts: rockchip: Fix SD NAND and eMMC init on rk3308-rock-pi-s arm64: dts: rockchip: Fix rk3308 codec@ff560000 reset-names arm64: dts: rockchip: Fix the DCDC_REG2 minimum voltage on Quartz64 Model B Link: https://lore.kernel.org/r/10237789.nnTZe4vzsl@diego Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-01KVM: s390: fix LPSWEY handlingChristian Borntraeger
in rare cases, e.g. for injecting a machine check we do intercept all load PSW instructions via ICTL_LPSW. With facility 193 a new variant LPSWEY was added. KVM needs to handle that as well. Fixes: a3efa8429266 ("KVM: s390: gen_facilities: allow facilities 165, 193, 194 and 196") Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20240628163547.2314-1-borntraeger@linux.ibm.com>
2024-07-01arm64: dts: exynos850: Enable TRNGSam Protsenko
Add True Random Number Generator (TRNG) node to Exynos850 SoC dtsi. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240618204523.9563-8-semen.protsenko@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-07-01m68k: defconfig: Update defconfigs for v6.10-rc1Geert Uytterhoeven
- Enable modular build of the new Packet Forwarding Control Protocol (PFCP). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/442176a8cd763e366ab9199b297919486c7f75f4.1716805119.git.geert@linux-m68k.org
2024-07-01m68k: atari: Fix TT bootup freeze / unexpected (SCU) interrupt messagesEero Tamminen
Avoid freeze on Atari TT / MegaSTe boot with continuous messages of: unexpected interrupt from 112 Which was due to VBL interrupt being enabled in SCU sys mask, but there being no handler for that any more. (Bug and fix were first verified on real Atari TT HW by Christian, this patch later on in Hatari emulator.) Fixes: 1fa0b29f3a43f9dd ("fbdev: Kill Atari vblank cursor blinking") Reported-by: Nicolas Pomarède <npomarede@corp.free.fr> Closes: https://listengine.tuxfamily.org/lists.tuxfamily.org/hatari-devel/2024/06/msg00016.html Closes: https://lore.kernel.org/all/9aa793d7-82ed-4fbd-bce5-60810d8a9119@helsinkinet.fi Tested-by: Christian Zietz <czietz@gmx.net> Signed-off-by: Eero Tamminen <oak@helsinkinet.fi> Reviewed-by: Michael Schmitz <schmitzmic@gmail.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/20240624144901.5236-1-oak@helsinkinet.fi Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2024-07-01riscv: dts: starfive: add PCIe dts configuration for JH7110Minda Chen
Add PCIe dts configuraion for JH7110 SoC platform. The Star64 only has one exposed PCIe port, so only the Mars and VisionFive 2 get two enabled. Signed-off-by: Minda Chen <minda.chen@starfivetech.com> Reviewed-by: Hal Feng <hal.feng@starfivetech.com> [conor: squash in star64's single exposed port] Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2024-07-01spi: dt-bindings: fsl-dspi: Convert to yaml formatFrank Li
Convert dt-binding spi-fsl-dspi.txt to yaml format. Use part Vladimir Oltean's work at of https://lore.kernel.org/linux-spi/20221111224651.577729-1-vladimir.oltean@nxp.com/ Additional changes during convert: - compatible string "fsl,ls1028a-dspi" can be followed by fsl,ls1021a-v1.0-dspi. - Change "dspi0@4002c000" to "spi@4002c000" in example. - Reorder properties in example. - Use GIC include in example. - Deprecated fsl,spi-cs-sck-delay and fsl,spi-sck-cs-delay by use common SPI property. - Use compatible string 'jedec,spi-nor' in example. - Split peripheral part to fsl,dspi-peripheral-props.yaml. - Remove 'interrupts' and 'pinctrl' from required list. - Update 'bus-num' description. - Update 'spi-num-chipselects' description by add "cs-gpios don't count against this number". - Remove 'big-endian' description. Co-developed-by: Kuldeep Singh <kuldeep.singh@nxp.com> Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com> Co-developed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20240624-ls_qspi-v4-2-3d1c6f5005bf@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-01spi: fsl-dspi: use common proptery 'spi-cs-setup(hold)-delay-ns'Frank Li
Use SPI common DT binding properties 'spi-cs-setup-delay-ns' and 'spi-cs-hold-delay-ns'. If these properties do not exist, fall back to legacy 'fsl,spi-cs-sck-delay' and 'fsl,spi-sck-cs-delay'. Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20240624-ls_qspi-v4-1-3d1c6f5005bf@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-01spi: davinci: Unset POWERDOWN bit when releasing resourcesBastien Curutchet
On the OMAPL138, the SPI reference clock is provided by the Power and Sleep Controller (PSC). The PSC's datasheet says that 'some peripherals have special programming requirements and additional recommended steps you must take before you can invoke the PSC module state transition'. I didn't find more details in documentation but it appears that PSC needs the SPI to clear the POWERDOWN bit before disabling the clock. Indeed, when this bit is set, the PSC gets stuck in transitions from enable to disable state. Clear the POWERDOWN bit when releasing driver's resources Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20240624071745.17409-1-bastien.curutchet@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-01Merge branch '100GbE' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue into main Tony nguyen says: ==================== Intel Wired LAN Driver Updates 2024-06-28 (MAINTAINERS, ice) This series contains updates to MAINTAINERS file and ice driver. Jesse replaces himself with Przemek in the maintainers file. Karthik Sundaravel adds support for VF get/set MAC address via devlink. Eric checks for errors from ice_vsi_rebuild() during queue reconfiguration. Paul adjusts FW API version check for E830 devices. Piotr adds differentiation of unload type when shutting down AdminQ. Przemek changes ice_adapter initialization to occur once per physical card. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2024-07-01Merge tag 'for-net-2024-06-28' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth into main bluetooth pull request for net: - Ignore too large handle values in BIG - L2CAP: sync sock recv cb and release - hci_bcm4377: Fix msgid release - ISO: Check socket flag instead of hcon - hci_event: Fix setting of unicast qos interval - hci: disallow setting handle bigger than HCI_CONN_HANDLE_MAX - Add quirk to ignore reserved PHY bits in LE Extended Adv Report - hci_core: cancel all works upon hci_unregister_dev - btintel_pcie: Fix REVERSE_INULL issue reported by coverity - qca: Fix BT enable failure again for QCA6390 after warm reboot Signed-off-by: David S. Miller <davem@davemloft.net>
2024-07-01drm: panel-orientation-quirks: Add labels for both Valve Steam Deck revisionsMatthew Schwartz
This accounts for the existence of two Steam Deck revisions instead of a single revision Signed-off-by: Matthew Schwartz <mattschwartz@gwu.edu> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240628205822.348402-3-mattschwartz@gwu.edu
2024-07-01drm: panel-orientation-quirks: Add quirk for Valve GalileoJohn Schoenick
Valve's Steam Deck Galileo revision has a 800x1280 OLED panel Cc: stable@vger.kernel.org # 6.1+ Signed-off-by: John Schoenick <johns@valvesoftware.com> Signed-off-by: Matthew Schwartz <mattschwartz@gwu.edu> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240628205822.348402-2-mattschwartz@gwu.edu
2024-07-01sched: Move psi_account_irqtime() out of update_rq_clock_task() hotpathJohn Stultz
It was reported that in moving to 6.1, a larger then 10% regression was seen in the performance of clock_gettime(CLOCK_THREAD_CPUTIME_ID,...). Using a simple reproducer, I found: 5.10: 100000000 calls in 24345994193 ns => 243.460 ns per call 100000000 calls in 24288172050 ns => 242.882 ns per call 100000000 calls in 24289135225 ns => 242.891 ns per call 6.1: 100000000 calls in 28248646742 ns => 282.486 ns per call 100000000 calls in 28227055067 ns => 282.271 ns per call 100000000 calls in 28177471287 ns => 281.775 ns per call The cause of this was finally narrowed down to the addition of psi_account_irqtime() in update_rq_clock_task(), in commit 52b1364ba0b1 ("sched/psi: Add PSI_IRQ to track IRQ/SOFTIRQ pressure"). In my initial attempt to resolve this, I leaned towards moving all accounting work out of the clock_gettime() call path, but it wasn't very pretty, so it will have to wait for a later deeper rework. Instead, Peter shared this approach: Rework psi_account_irqtime() to use its own psi_irq_time base for accounting, and move it out of the hotpath, calling it instead from sched_tick() and __schedule(). In testing this, we found the importance of ensuring psi_account_irqtime() is run under the rq_lock, which Johannes Weiner helpfully explained, so also add some lockdep annotations to make that requirement clear. With this change the performance is back in-line with 5.10: 6.1+fix: 100000000 calls in 24297324597 ns => 242.973 ns per call 100000000 calls in 24318869234 ns => 243.189 ns per call 100000000 calls in 24291564588 ns => 242.916 ns per call Reported-by: Jimmy Shiu <jimmyshiu@google.com> Originally-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: John Stultz <jstultz@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Chengming Zhou <chengming.zhou@linux.dev> Reviewed-by: Qais Yousef <qyousef@layalina.io> Link: https://lore.kernel.org/r/20240618215909.4099720-1-jstultz@google.com
2024-07-01sched/deadline: Fix task_struct reference leakWander Lairson Costa
During the execution of the following stress test with linux-rt: stress-ng --cyclic 30 --timeout 30 --minimize --quiet kmemleak frequently reported a memory leak concerning the task_struct: unreferenced object 0xffff8881305b8000 (size 16136): comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s) object hex dump (first 32 bytes): 02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .@.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ debug hex dump (first 16 bytes): 53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S............... backtrace: [<00000000046b6790>] dup_task_struct+0x30/0x540 [<00000000c5ca0f0b>] copy_process+0x3d9/0x50e0 [<00000000ced59777>] kernel_clone+0xb0/0x770 [<00000000a50befdc>] __do_sys_clone+0xb6/0xf0 [<000000001dbf2008>] do_syscall_64+0x5d/0xf0 [<00000000552900ff>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 The issue occurs in start_dl_timer(), which increments the task_struct reference count and sets a timer. The timer callback, dl_task_timer, is supposed to decrement the reference count upon expiration. However, if enqueue_task_dl() is called before the timer expires and cancels it, the reference count is not decremented, leading to the leak. This patch fixes the reference leak by ensuring the task_struct reference count is properly decremented when the timer is canceled. Fixes: feff2e65efd8 ("sched/deadline: Unthrottle PI boosted threads while enqueuing") Signed-off-by: Wander Lairson Costa <wander@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Juri Lelli <juri.lelli@redhat.com> Link: https://lore.kernel.org/r/20240620125618.11419-1-wander@redhat.com
2024-07-01Revert "sched/fair: Make sure to try to detach at least one movable task"Josh Don
This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06. b0defa7ae03ec changed the load balancing logic to ignore env.max_loop if all tasks examined to that point were pinned. The goal of the patch was to make it more likely to be able to detach a task buried in a long list of pinned tasks. However, this has the unfortunate side effect of creating an O(n) iteration in detach_tasks(), as we now must fully iterate every task on a cpu if all or most are pinned. Since this load balance code is done with rq lock held, and often in softirq context, it is very easy to trigger hard lockups. We observed such hard lockups with a user who affined O(10k) threads to a single cpu. When I discussed this with Vincent he initially suggested that we keep the limit on the number of tasks to detach, but increase the number of tasks we can search. However, after some back and forth on the mailing list, he recommended we instead revert the original patch, as it seems likely no one was actually getting hit by the original issue. Fixes: b0defa7ae03e ("sched/fair: Make sure to try to detach at least one movable task") Signed-off-by: Josh Don <joshdon@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20240620214450.316280-1-joshdon@google.com
2024-07-01x86/alternatives, kvm: Fix a couple of CALLs without a frame pointerBorislav Petkov (AMD)
objtool complains: arch/x86/kvm/kvm.o: warning: objtool: .altinstr_replacement+0xc5: call without frame pointer save/setup vmlinux.o: warning: objtool: .altinstr_replacement+0x2eb: call without frame pointer save/setup Make sure %rSP is an output operand to the respective asm() statements. The test_cc() hunk and ALT_OUTPUT_SP() courtesy of peterz. Also from him add some helpful debugging info to the documentation. Now on to the explanations: tl;dr: The alternatives macros are pretty fragile. If I do ALT_OUTPUT_SP(output) in order to be able to package in a %rsp reference for objtool so that a stack frame gets properly generated, the inline asm input operand with positional argument 0 in clear_page(): "0" (page) gets "renumbered" due to the added : "+r" (current_stack_pointer), "=D" (page) and then gcc says: ./arch/x86/include/asm/page_64.h:53:9: error: inconsistent operand constraints in an ‘asm’ The fix is to use an explicit "D" constraint which points to a singleton register class (gcc terminology) which ends up doing what is expected here: the page pointer - input and output - should be in the same %rdi register. Other register classes have more than one register in them - example: "r" and "=r" or "A": ‘A’ The ‘a’ and ‘d’ registers. This class is used for instructions that return double word results in the ‘ax:dx’ register pair. Single word values will be allocated either in ‘ax’ or ‘dx’. so using "D" and "=D" just works in this particular case. And yes, one would say, sure, why don't you do "+D" but then: : "+r" (current_stack_pointer), "+D" (page) : [old] "i" (clear_page_orig), [new1] "i" (clear_page_rep), [new2] "i" (clear_page_erms), : "cc", "memory", "rax", "rcx") now find the Waldo^Wcomma which throws a wrench into all this. Because that silly macro has an "input..." consume-all last macro arg and in it, one is supposed to supply input *and* clobbers, leading to silly syntax snafus. Yap, they need to be cleaned up, one fine day... Closes: https://lore.kernel.org/oe-kbuild-all/202406141648.jO9qNGLa-lkp@intel.com/ Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Sean Christopherson <seanjc@google.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20240625112056.GDZnqoGDXgYuWBDUwu@fat_crate.local
2024-07-01xfrm: Export symbol xfrm_dev_state_delete.Steffen Klassert
This fixes a build failure if xfrm_user is build as a module. Fixes: 07b87f9eea0c ("xfrm: Fix unregister netdevice hang on hardware offload.") Reported-by: Mark Brown <broonie@kernel.org> Tested-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2024-07-01Merge branch 'bnxt_en-ptp' into mainDavid S. Miller
Michael Chan says: ==================== bnxt_en: PTP updates for net-next The first 5 patches implement the PTP feature on the new BCM5760X chips. The main new hardware feature is the new TX timestamp completion which enables the driver to retrieve the TX timestamp in NAPI without deferring to the PTP worker. The last 5 patches increase the number of TX PTP packets in-flight from 1 to 4 on the older BCM5750X chips. On these older chips, we need to call firmware in the PTP worker to retrieve the timestamp. We use an arry to keep track of the in-flight TX PTP packets. v2: Patch #2: Fix the unwind of txr->is_ts_pkt when bnxt_start_xmit() aborts. Patch #4: Set the SKBTX_IN_PROGRESS flag for timestamp packets. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2024-07-01bnxt_en: Remove atomic operations on ptp->tx_availPavan Chebbi
Now that we require the spinlock to protect ptp->txts_prod, change ptp->tx_avail to non-atomic and protect it under the same spinlock. Add a new helper function bnxt_ptp_get_txts_prod() to decrement ptp->tx_avail under spinlock and return the producer. Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-07-01bnxt_en: Increase the max total outstanding PTP TX packets to 4Pavan Chebbi
Start accepting up to 4 TX TS requests on BCM5750X (P5) chips. These PTP TX packets will be queued in the ptp->txts_req[] array waiting for the TX timestamp to complete. The entries in the array will be managed by a producer and consumer index. The producer index is updated under spinlock since multiple TX rings can try to send PTP packets at the same time. Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-07-01bnxt_en: Let bnxt_stamp_tx_skb() return error codePavan Chebbi
Change the function bnxt_stamp_tx_skb() to return 0 for suceess or -EAGAIN if the timestamp is still pending in firmware. The calling PTP aux worker will reschedule based on the return code. Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-07-01bnxt_en: Remove an impossible condition check for PTP TX pending SKBPavan Chebbi
In the current 5750X PTP code paths, there is always at most one TX SKB requested for timestamp and we won't accept another one until we have retrieved the timestamp or it has timed out. Remove the unnecessary check in bnxt_get_tx_ts_p5() for a pending SKB and change the function to void. Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-10-01 07:22:01 +0000