summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-05-14Bluetooth: ath3k: Fix multiple issues reported by checkpatch.plUri Arev
This fixes some CHECKs reported by the checkpatch script. Issues reported in ath3k.c: ------- ath3k.c ------- CHECK: Please don't use multiple blank lines + + CHECK: Blank lines aren't necessary after an open brace '{' +static const struct usb_device_id ath3k_blist_tbl[] = { + CHECK: Alignment should match open parenthesis +static int ath3k_load_firmware(struct usb_device *udev, + const struct firmware *firmware) CHECK: Alignment should match open parenthesis + err = usb_bulk_msg(udev, pipe, send_buf, size, + &len, 3000); CHECK: Unnecessary parentheses around 'len != size' + if (err || (len != size)) { CHECK: Alignment should match open parenthesis +static int ath3k_get_version(struct usb_device *udev, + struct ath3k_version *version) CHECK: Alignment should match open parenthesis +static int ath3k_load_fwfile(struct usb_device *udev, + const struct firmware *firmware) CHECK: Alignment should match open parenthesis + err = usb_bulk_msg(udev, pipe, send_buf, size, + &len, 3000); CHECK: Unnecessary parentheses around 'len != size' + if (err || (len != size)) { CHECK: Blank lines aren't necessary after an open brace '{' + switch (fw_version.ref_clock) { + CHECK: Alignment should match open parenthesis + snprintf(filename, ATH3K_NAME_LEN, "ar3k/ramps_0x%08x_%d%s", + le32_to_cpu(fw_version.rom_version), clk_value, ".dfu"); CHECK: Alignment should match open parenthesis +static int ath3k_probe(struct usb_interface *intf, + const struct usb_device_id *id) CHECK: Alignment should match open parenthesis + BT_ERR("Firmware file \"%s\" not found", + ATH3K_FIRMWARE); CHECK: Alignment should match open parenthesis + BT_ERR("Firmware file \"%s\" request failed (err=%d)", + ATH3K_FIRMWARE, ret); total: 0 errors, 0 warnings, 14 checks, 540 lines checked Signed-off-by: Uri Arev <me@wantyapps.xyz> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2024-05-14Bluetooth: hci_bcm: Limit bcm43455 baudrate to 2000000Hans de Goede
Like the bcm43430a0 the bcm43455 BT does not support the 0xfc45 command to set the UART clock to 48 MHz and because of this it does not work at 4000000 baud. These chips are found on ACPI/x86 devices where the operating baudrate does not come from the firmware but is hardcoded at 4000000, which does not work. Make the driver_data for the "BCM2EA4" ACPI HID which is used for the bcm43455 BT point to bcm43430_device_data which limits the baudrate to 2000000. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2024-05-14Bluetooth: hci_intel: Fix multiple issues reported by checkpatch.plUri Arev
This fixes the following CHECKs, WARNINGs, and ERRORs reported in hci_intel.c Reported by checkpatch.pl: ----------- hci_intel.c ----------- WARNING: Prefer using '"%s...", __func__' to using 'intel_setup', this function's name, in a string + bt_dev_dbg(hdev, "start intel_setup"); ERROR: code indent should use tabs where possible + /* Check for supported iBT hardware variants of this firmware$ ERROR: code indent should use tabs where possible + * loading method.$ ERROR: code indent should use tabs where possible + *$ ERROR: code indent should use tabs where possible + * This check has been put in place to ensure correct forward$ ERROR: code indent should use tabs where possible + * compatibility options when newer hardware variants come along.$ ERROR: code indent should use tabs where possible + */$ CHECK: No space is necessary after a cast + duration = (unsigned long long) ktime_to_ns(delta) >> 10; CHECK: No space is necessary after a cast + duration = (unsigned long long) ktime_to_ns(delta) >> 10; WARNING: Missing a blank line after declarations + int err = PTR_ERR(intel->rx_skb); + bt_dev_err(hu->hdev, "Frame reassembly failed (%d)", err); Signed-off-by: Uri Arev <me@wantyapps.xyz> Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2024-05-14Bluetooth: hci_intel: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2024-05-14Bluetooth: hci_bcm: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2024-05-14Bluetooth: btqcomsmd: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2024-05-14Bluetooth: Add support for MediaTek MT7922 deviceIan W MORRISON
This patch adds support for the MediaTek MT7922 Bluetooth device. The information in /sys/kernel/debug/usb/devices about the MT7922 is as follows: T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3585 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Signed-off-by: Ian W MORRISON <ianwmorrison@live.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2024-05-14Bluetooth: btintel: Add support to download intermediate loaderKiran K
Some variants of Intel controllers like BlazarI supports downloading of Intermediate bootloader (IML) image. IML gives flexibility to fix issues as its not possible to fix issue in Primary bootloader once flashed to ROM. This patch adds the support to download IML before downloading operational firmware image. dmesg logs: [13.399003] Bluetooth: Core ver 2.22 [13.399006] Bluetooth: Starting self testing [13.401194] Bluetooth: ECDH test passed in 2135 usecs [13.421175] Bluetooth: SMP test passed in 597 usecs [13.421184] Bluetooth: Finished self testing [13.422919] Bluetooth: HCI device and connection manager initialized [13.422923] Bluetooth: HCI socket layer initialized [13.422925] Bluetooth: L2CAP socket layer initialized [13.422930] Bluetooth: SCO socket layer initialized [13.458065] Bluetooth: hci0: Device revision is 0 [13.458071] Bluetooth: hci0: Secure boot is disabled [13.458072] Bluetooth: hci0: OTP lock is disabled [13.458072] Bluetooth: hci0: API lock is enabled [13.458073] Bluetooth: hci0: Debug lock is disabled [13.458073] Bluetooth: hci0: Minimum firmware build 1 week 10 2014 [13.458075] Bluetooth: hci0: Bootloader timestamp 2022.46 buildtype 1 build 26590 [13.458324] Bluetooth: hci0: DSM reset method type: 0x00 [13.460678] Bluetooth: hci0: Found device firmware: intel/ibt-0090-0291-iml.sfi [13.460684] Bluetooth: hci0: Boot Address: 0x30099000 [13.460685] Bluetooth: hci0: Firmware Version: 227-11.24 [13.562554] Bluetooth: hci0: Waiting for firmware download to complete [13.563023] Bluetooth: hci0: Firmware loaded in 99941 usecs [13.563057] Bluetooth: hci0: Waiting for device to boot [13.565029] Bluetooth: hci0: Malformed MSFT vendor event: 0x02 [13.565148] Bluetooth: hci0: Device booted in 2064 usecs [13.567065] Bluetooth: hci0: No device address configured [13.569010] Bluetooth: hci0: Found device firmware: intel/ibt-0090-0291.sfi [13.569061] Bluetooth: hci0: Boot Address: 0x10000800 [13.569062] Bluetooth: hci0: Firmware Version: 227-11.24 [13.788891] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [13.788897] Bluetooth: BNEP filters: protocol multicast [13.788902] Bluetooth: BNEP socket layer initialized [15.435905] Bluetooth: hci0: Waiting for firmware download to complete [15.436016] Bluetooth: hci0: Firmware loaded in 1823233 usecs [15.436258] Bluetooth: hci0: Waiting for device to boot [15.471140] Bluetooth: hci0: Device booted in 34277 usecs [15.471201] Bluetooth: hci0: Malformed MSFT vendor event: 0x02 [15.471487] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-0090-0291.ddc [15.474353] Bluetooth: hci0: Applying Intel DDC parameters completed [15.474486] Bluetooth: hci0: Found Intel DDC parameters: intel/bdaddress.cfg [15.475299] Bluetooth: hci0: Applying Intel DDC parameters completed [15.479381] Bluetooth: hci0: Firmware timestamp 2024.10 buildtype 3 build 58595 [15.479385] Bluetooth: hci0: Firmware SHA1: 0xb4f3cc46 [15.483243] Bluetooth: hci0: Fseq status: Success (0x00) [15.483246] Bluetooth: hci0: Fseq executed: 00.00.00.00 [15.483247] Bluetooth: hci0: Fseq BT Top: 00.00.00.00 [15.578712] Bluetooth: MGMT ver 1.22 [15.822682] Bluetooth: RFCOMM TTY layer initialized [15.822690] Bluetooth: RFCOMM socket layer initialized [15.822695] Bluetooth: RFCOMM ver 1.11 Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2024-05-14Bluetooth: btintel: Define macros for image typesKiran K
Use macro for image type instead of using hard code number. Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2024-05-14rapidio: remove choice for enumerationMasahiro Yamada
This is the last use of the tristate choice. This choice was introduced a decade ago by commit a11650e11093 ("rapidio: make enumeration/discovery configurable"). Since then, RAPIDIO_ENUM_BASIC has always been the sole member. There was no need to have this choice block. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-05-14Makefile: remove redundant tool coverage variablesMasahiro Yamada
Now Kbuild provides reasonable defaults for objtool, sanitizers, and profilers. Remove redundant variables. Note: This commit changes the coverage for some objects: - include arch/mips/vdso/vdso-image.o into UBSAN, GCOV, KCOV - include arch/sparc/vdso/vdso-image-*.o into UBSAN - include arch/sparc/vdso/vma.o into UBSAN - include arch/x86/entry/vdso/extable.o into KASAN, KCSAN, UBSAN, GCOV, KCOV - include arch/x86/entry/vdso/vdso-image-*.o into KASAN, KCSAN, UBSAN, GCOV, KCOV - include arch/x86/entry/vdso/vdso32-setup.o into KASAN, KCSAN, UBSAN, GCOV, KCOV - include arch/x86/entry/vdso/vma.o into GCOV, KCOV - include arch/x86/um/vdso/vma.o into KASAN, GCOV, KCOV I believe these are positive effects because all of them are kernel space objects. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Roberto Sassu <roberto.sassu@huawei.com>
2024-05-14nbd: Fix signal handlingBart Van Assche
Both nbd_send_cmd() and nbd_handle_cmd() return either a negative error number or a positive blk_status_t value. nbd_queue_rq() converts these return values into a blk_status_t value. There is a bug in the conversion code: if nbd_send_cmd() returns BLK_STS_RESOURCE, nbd_queue_rq() should return BLK_STS_RESOURCE instead of BLK_STS_OK. Fix this, move the conversion code into nbd_handle_cmd() and fix the remaining sparse warnings. This patch fixes the following sparse warnings: drivers/block/nbd.c:673:32: warning: incorrect type in return expression (different base types) drivers/block/nbd.c:673:32: expected int drivers/block/nbd.c:673:32: got restricted blk_status_t [usertype] drivers/block/nbd.c:714:48: warning: incorrect type in return expression (different base types) drivers/block/nbd.c:714:48: expected int drivers/block/nbd.c:714:48: got restricted blk_status_t [usertype] drivers/block/nbd.c:1120:21: warning: incorrect type in assignment (different base types) drivers/block/nbd.c:1120:21: expected int [assigned] ret drivers/block/nbd.c:1120:21: got restricted blk_status_t [usertype] drivers/block/nbd.c:1125:16: warning: incorrect type in return expression (different base types) drivers/block/nbd.c:1125:16: expected restricted blk_status_t drivers/block/nbd.c:1125:16: got int [assigned] ret Cc: Christoph Hellwig <hch@lst.de> Cc: Josef Bacik <jbacik@fb.com> Cc: Yu Kuai <yukuai3@huawei.com> Cc: Markus Pargmann <mpa@pengutronix.de> Fixes: fc17b6534eb8 ("blk-mq: switch ->queue_rq return value to blk_status_t") Cc: stable@vger.kernel.org Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20240510202313.25209-6-bvanassche@acm.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-05-14nbd: Remove a local variable from nbd_send_cmd()Bart Van Assche
blk_rq_bytes() returns an unsigned int while 'size' has type unsigned long. This is confusing. Improve code readability by removing the local variable 'size'. Cc: Christoph Hellwig <hch@lst.de> Cc: Josef Bacik <jbacik@fb.com> Cc: Yu Kuai <yukuai3@huawei.com> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20240510202313.25209-5-bvanassche@acm.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-05-14nbd: Improve the documentation of the locking assumptionsBart Van Assche
Document locking assumptions with lockdep_assert_held() instead of source code comments. The advantage of lockdep_assert_held() is that it is verified at runtime if lockdep is enabled in the kernel config. Cc: Christoph Hellwig <hch@lst.de> Cc: Josef Bacik <jbacik@fb.com> Cc: Yu Kuai <yukuai3@huawei.com> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20240510202313.25209-4-bvanassche@acm.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-05-14nbd: Remove superfluous castsBart Van Assche
In Linux kernel code it is preferred not to use a cast when converting a void pointer to another pointer type. Cc: Christoph Hellwig <hch@lst.de> Cc: Josef Bacik <jbacik@fb.com> Cc: Yu Kuai <yukuai3@huawei.com> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20240510202313.25209-3-bvanassche@acm.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-05-14net: micrel: Fix receiving the timestamp in the frame for lan8841Horatiu Vultur
The blamed commit started to use the ptp workqueue to get the second part of the timestamp. And when the port was set down, then this workqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING is not enabled, then the ptp_clock is not initialized so then it would crash when it would try to access the delayed work. So then basically by setting up and then down the port, it would crash. The fix consists in checking if the ptp_clock is initialized and only then cancel the delayed work. Fixes: cc7554954848 ("net: micrel: Change to receive timestamp in the frame for lan8841") Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-05-14Merge branch 'for-6.10/winwing' into for-linusJiri Kosina
- implement full support for WinWing Orion2 (Ivan Gorinov)
2024-05-14Merge branch 'for-6.10/uclogic' into for-linusJiri Kosina
2024-05-14Merge branch 'for-6.10/steam' into for-linusJiri Kosina
- support for Deck IMU in hid-steam (Max Maisel)
2024-05-14Merge branch 'for-6.10/sony' into for-linusJiri Kosina
2024-05-14Merge branch 'for-6.10/playstation' into for-linusJiri Kosina
- fixes for better support of 3rd party playstation DS4 controllers (Max Staudt)
2024-05-14Merge branch 'for-6.10/plarform-driver-remove-new' into for-linusJiri Kosina
- conversion of HID device drivers from platform_driver->remove() to platform_driver->remove_new() (Uwe Kleine-König)
2024-05-14Merge branch 'for-6.10/nintendo' into for-linusJiri Kosina
2024-05-14Merge branch 'for-6.10/kye' into for-linusJiri Kosina
2024-05-14Merge branch 'for-6.10/intel-ish' into for-linusJiri Kosina
- Implement loading firmware from host in intel-ish driver, needed to support Lunar Lake and later (Zhang Lixu)
2024-05-14Merge branch 'for-6.10/i2c-hid' into for-linusJiri Kosina
- PM fixes for STM and Weida Tech devices (Kenny Levinsen)
2024-05-14Merge branch 'for-6.10/hid-sysfs-emit' into for-linusJiri Kosina
- conversion from sprintf() to sysfs_emit() (Li Zhijian)
2024-05-14Merge branch 'for-6.10/hid-debug' into for-linusJiri Kosina
- support for missing mappings and codes from HUT 1.5 in hid-debug (Thomas Kuehne)
2024-05-14s390/pkey: Use kfree_sensitive() to fix Coccinelle warningsJules Irenge
Replace memzero_explicit() and kfree() with kfree_sensitive() to fix warnings reported by Coccinelle: WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506) WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643) WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770) Signed-off-by: Jules Irenge <jbi.octave@gmail.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Link: https://lore.kernel.org/r/ZjqZkNi_JUJu73Rg@octinomon.home Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2024-05-14Merge branch 'for-6.10/hid-bpf' into for-linusJiri Kosina
- updates to HID-BPF infrastructure, with some of the specific fixes (e.g. rdesc fixups) abstracted into separate BPF programs for consumption by libevdev/udev-hid-bpf (Benjamin Tissoires)
2024-05-14Merge branch 'for-6.10/asus' into for-linusJiri Kosina
- initial support for ROG Ally and ROG X13 devices (Luke D. Jones) - other small assorted cleanups of hid-asus driver (Luke D. Jones)
2024-05-14Merge branch 'for-6.10/amd-sfh' into for-linusJiri Kosina
- PM fix and assorted other code cleanups for amd-sfh (Basavaraj Natikar)
2024-05-14platform/x86: Add new Dell UART backlight driverHans de Goede
Dell All In One (AIO) models released after 2017 use a backlight controller board connected to an UART. In DSDT this uart port will be defined as: Name (_HID, "DELL0501") Name (_CID, EisaId ("PNP0501") Instead of having a separate ACPI device with an UartSerialBusV2() resource to model the backlight-controller, which would be the standard way to do this. The acpi_quirk_skip_serdev_enumeration() has special handling for this and it will make the serial port code create a serdev controller device for the UART instead of a /dev/ttyS0 char-dev. It will also create a dell-uart-backlight driver platform device for this driver to bind too. This new kernel module contains 2 drivers for this: 1. A simple platform driver which creates the actual serdev device (with the serdev controller device as parent) 2. A serdev driver for the created serdev device which exports the backlight functionality uses a standard backlight class device. Reported-by: Roman Bogoyev <roman@computercheck.com.au> Tested-by: Roman Bogoyev <roman@computercheck.com.au> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Co-developed-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240513144603.93874-2-hdegoede@redhat.com
2024-05-14platform/x86: x86-android-tablets: Create LED device for Xiaomi Pad 2 bottom ↵Hans de Goede
bezel touch buttons The Xiaomi [Mi]Pad 2 has 3 menu / home / back capacitive touch-buttons on its bottom bezel. These are backlit by LEDs attached to a TPS61158 LED controller which is controlled by the "pwm_soc_lpss_2" PWM output. Create a LED class device for this, using the new input-events trigger as default trigger so that the buttons automatically light up on any input activity. Note alternatively a "leds_pwm" platform device could be created together with the necessary fwnode_s_ and a fwnode link to the PWM controller. There are 2 downsides to this approach: 1. The code would still need to pwm_get() the PWM controller to get/attach a fwnode for the PWM controller fwnode link and setting up the necessary fwnodes is non-trivial. So this would likely require more code then simply registering the LED class device directly. 2. Currently the leds_pwm driver and its devicetree bindings do not support limiting the maximum dutycycle to less then 100% which is required in this case (the leds_pwm driver can probably be extended to allow this). Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240509141207.63570-2-hdegoede@redhat.com
2024-05-14platform/x86: x86-android-tablets: Xiaomi pad2 RGB LED fwnode updatesKate Hsuan
Xiaomi pad2 RGB LED fwnode updates: 1. Set "label" instead "function" to change the LED classdev name from "rgb:indicator" to "mipad2:rgb:indicator" to match the usual triplet name format for LED classdevs. 2. Set the trigger to the new "bq27520-0-charging-orange-full-green" powersupply trigger type for multi-color LEDs. 3. Put the fwnode link for red before green in ktd2026_node_group[] so that multi_index becomes "red green blue". Signed-off-by: Kate Hsuan <hpa@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Co-developed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240504164105.114017-8-hdegoede@redhat.com
2024-05-14platform/x86: x86-android-tablets: Pass struct device to init()Hans de Goede
Pass a struct device pointer for x86_android_tablet_device to the board specific init() functions, so that these functions can use this for e.g. devm_*() functions. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240509141207.63570-1-hdegoede@redhat.com
2024-05-14platform/x86/amd: pmc: Add new ACPI ID AMDI000BShyam Sundar S K
Add new ACPI ID AMDI000B used by upcoming AMD platform to the PMC supported list of devices. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20240510103946.877307-1-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-05-14platform/x86/amd: pmf: Add new ACPI ID AMDI0105Shyam Sundar S K
Add new ACPI ID AMDI0105 used by upcoming AMD platform to the PMF supported list of devices. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20240510103519.876646-1-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-05-14platform/x86: p2sb: Don't init until unassigned resources have been assignedBen Fradella
The P2SB could get an invalid BAR from the BIOS, and that won't be fixed up until pcibios_assign_resources(), which is an fs_initcall(). - Move p2sb_fs_init() to an fs_initcall_sync(). This is still early enough to avoid a race with any dependent drivers. - Add a check for IORESOURCE_UNSET in p2sb_valid_resource() to catch unset BARs going forward. - Return error values from p2sb_fs_init() so that the 'initcall_debug' cmdline arg provides useful data. Signed-off-by: Ben Fradella <bfradell@netapp.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Klara Modin <klarasmodin@gmail.com> Reviewed-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Link: https://lore.kernel.org/r/20240509164905.41016-1-bcfradella@proton.me Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-05-14platform/surface: aggregator: Log critical errors during SAM probingWeifeng Liu
Emits messages upon errors during probing of SAM. Hopefully this could provide useful context to user for the purpose of diagnosis when something miserable happen. Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Weifeng Liu <weifeng.liu.z@gmail.com> Link: https://lore.kernel.org/r/20240505130800.2546640-3-weifeng.liu.z@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-05-14firmware: dmi: Add info message for number of populated and total memory slotsHeiner Kallweit
As part of adding support for calling i2c_register_spd() on muxed SMBUS segments the same message has been removed from i2c_register_spd(). However users may find it useful, therefore reintroduce it as part of the DMI scan code. [JD: Static variable dmi_memdev_populated_nr is only used in __init functions, so it can be marked __initdata.] Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
2024-05-14power: supply: sbs-manager: Remove class argument from i2c_mux_add_adapter()Wolfram Sang
Commit 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device instantiation") removed the last call to i2c_mux_add_adapter() with a non-null class argument. Therefore the class argument can be removed. Note: Class-based device instantiation is a legacy mechanism which shouldn't be used in new code, so we can rule out that this argument may be needed again in the future. This driver was forgotten by the patch in the Fixes tag. Fixes: fec1982d7072 ("i2c: mux: Remove class argument from i2c_mux_add_adapter()") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-05-14media: bcm2835-unicam: Depend on COMMON_CLKLaurent Pinchart
The bcm2835-unicam driver calls the clk_set_min_rate() function, which is declared but not implemented on platforms that don't provide COMMON_CLK. This causes linkage failures with some configurations. Fix it by depending on COMMON_CLK. This only slightly restricts compilation testing, but not usage of the driver as all platforms on which the hardware can be found provide COMMON_CLK. Fixes: 392cd78d495f ("media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202405112243.2MLRT7li-lkp@intel.com/ Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2024-05-13brd: implement discard supportKeith Busch
The ramdisk memory utilization can only go up when data is written to new pages. Implement discard to provide the possibility to reduce memory usage for pages no longer in use. Aligned discards will free the associated pages, if any, and determinisitically return zeroed data until written again. Signed-off-by: Keith Busch <kbusch@kernel.org> Link: https://lore.kernel.org/r/20240429102308.147627-1-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-05-13Merge tag 'idxd-for-linus-may2024' of git bundle from ArjanLinus Torvalds
Pull DSA and IAA accelerator mis-alignment fix from Arjan van de Ven: "The DSA (memory copy/zero/etc) and IAA (compression) accelerators in the Sapphire Rapids and Emerald Rapids SOCs turn out to have a bug that has security implications. Both of these accelerators work by the application submitting a 64 byte command to the device; this command contains an opcode as well as the virtual address of the return value that the device will update on completion... and a set of opcode specific values. In a typical scenario a ring 3 application mmaps the device file and uses the ENQCMD or MOVDIR64 instructions (which are variations of a 64 byte atomic write) on this mmap'd memory region to directly submit commands to a device hardware. The return value as specified in the command, is supposed to be 32 (or 64) bytes aligned in memory, and generally the hardware checks and enforces this alignment. However in testing it has been found that there are conditions (controlled by the submitter) where this enforcement does not happen... which makes it possible for the return value to span a page boundary. And this is where it goes wrong - the accelerators will perform the virtual to physical address lookup on the first of the two pages, but end up continue writing to the next consecutive physical (host) page rather than the consecutive virtual page. In addition, the device will end up in a hung state on such unaligned write of the return value. This patch series has the proposed software side solution consisting of three parts: - Don't allow these two PCI devices to be assigned to VM guests (we cannot trust a VM guest to behave correctly and not cause this condition) - Don't allow ring 3 applications to set up the mmap unless they have CAP_SYS_RAWIO permissions. This makes it no longer possible for non-root applications to directly submit commands to the accelerator - Add a write() method to the device so that an application can submit its commands to the kernel driver, which performs the needed sanity checks before submitting it to the hardware. This switch from mmap to write is an incompatible interface change to non-root userspace, but we have not found a way to avoid this. All software we know of uses a small set of accessor libraries for these accelerators, for which libqpl and libdml (on github) are the most common. As part of the security release, updated versions of these libraries will be released that transparently fall back to write(). Intel has assigned CVE-2024-21823 to this hardware issue" * tag 'idxd-for-linus-may2024' of git bundle from Arjan: dmaengine: idxd: add a write() method for applications to submit work dmaengine: idxd: add a new security check to deal with a hardware erratum VFIO: Add the SPR_DSA and SPR_IAX devices to the denylist
2024-05-13net: revert partially applied PHY topology seriesJakub Kicinski
The series is causing issues with PHY drivers built as modules. Since it was only partially applied and the merge window has opened let's revert and try again for v6.11. Revert 6916e461e793 ("net: phy: Introduce ethernet link topology representation") Revert 0ec5ed6c130e ("net: sfp: pass the phy_device when disconnecting an sfp module's PHY") Revert e75e4e074c44 ("net: phy: add helpers to handle sfp phy connect/disconnect") Revert fdd353965b52 ("net: sfp: Add helper to return the SFP bus name") Revert 841942bc6212 ("net: ethtool: Allow passing a phy index for some commands") Link: https://lore.kernel.org/all/171242462917.4000.9759453824684907063.git-patchwork-notify@kernel.org/ Link: https://lore.kernel.org/all/20240507102822.2023826-1-maxime.chevallier@bootlin.com/ Link: https://lore.kernel.org/r/20240513154156.104281-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-05-13net: stmmac: move the EST structure to struct stmmac_privXiaolei Wang
Move the EST structure to struct stmmac_priv, because the EST configs don't look like platform config, but EST is enabled in runtime with the settings retrieved for the TC TAPRIO feature also in runtime. So it's better to have the EST-data preserved in the driver private data instead of the platform data storage. Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Link: https://lore.kernel.org/r/20240513014346.1718740-3-xiaolei.wang@windriver.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-05-13net: stmmac: move the EST lock to struct stmmac_privXiaolei Wang
Reinitialize the whole EST structure would also reset the mutex lock which is embedded in the EST structure, and then trigger the following warning. To address this, move the lock to struct stmmac_priv. We also need to reacquire the mutex lock when doing this initialization. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068 Modules linked in: CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mutex_lock+0xd84/0x1068 lr : __mutex_lock+0xd84/0x1068 sp : ffffffc0864e3570 x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003 x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000 x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8 x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698 x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027 x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: __mutex_lock+0xd84/0x1068 mutex_lock_nested+0x28/0x34 tc_setup_taprio+0x118/0x68c stmmac_setup_tc+0x50/0xf0 taprio_change+0x868/0xc9c Fixes: b2aae654a479 ("net: stmmac: add mutex lock to protect est parameters") Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Link: https://lore.kernel.org/r/20240513014346.1718740-2-xiaolei.wang@windriver.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-05-13net: mana: Enable MANA driver on ARM64 with 4K page sizeHaiyang Zhang
Change the Kconfig dependency, so this driver can be built and run on ARM64 with 4K page size. 16/64K page sizes are not supported yet. Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Link: https://lore.kernel.org/r/1715632141-8089-1-git-send-email-haiyangz@microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-05-13net: prestera: Add flex arrays to some structsErick Archer
The "struct prestera_msg_vtcam_rule_add_req" uses a dynamically sized set of trailing elements. Specifically, it uses an array of structures of type "prestera_msg_acl_action actions_msg". The "struct prestera_msg_flood_domain_ports_set_req" also uses a dynamically sized set of trailing elements. Specifically, it uses an array of structures of type "prestera_msg_acl_action actions_msg". So, use the preferred way in the kernel declaring flexible arrays [1]. At the same time, prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). In this case, it is important to note that the attribute used is specifically __counted_by_le since the counters are of type __le32. The logic does not need to change since the counters for the flexible arrays are asigned before any access to the arrays. The order in which the structure prestera_msg_vtcam_rule_add_req and the structure prestera_msg_flood_domain_ports_set_req are defined must be changed to avoid incomplete type errors. Also, avoid the open-coded arithmetic in memory allocator functions [2] using the "struct_size" macro. Moreover, the new structure members also allow us to avoid the open- coded arithmetic on pointers. So, take advantage of this refactoring accordingly. This code was detected with the help of Coccinelle, and audited and modified manually. Link: https://www.kernel.org/doc/html/next/process/deprecated.html#zero-length-and-one-element-arrays [1] Link: https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [2] Signed-off-by: Erick Archer <erick.archer@outlook.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/AS8PR02MB7237E8469568A59795F1F0408BE12@AS8PR02MB7237.eurprd02.prod.outlook.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-19 15:28:49 +0000