aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2024-05-14Bluetooth: hci_bcm: Limit bcm43455 baudrate to 2000000Hans de Goede1-1/+1
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 <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-05-14Bluetooth: hci_intel: Fix multiple issues reported by checkpatch.plUri Arev1-9/+10
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 <[email protected]> Suggested-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-05-14Bluetooth: hci_intel: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
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 <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-05-14Bluetooth: hci_bcm: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
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 <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-05-14Bluetooth: btqcomsmd: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
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 <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-05-14Bluetooth: Add support for MediaTek MT7922 deviceIan W MORRISON1-0/+5
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 <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-05-14Bluetooth: btintel: Add support to download intermediate loaderKiran K2-1/+40
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 <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-05-14Bluetooth: btintel: Define macros for image typesKiran K2-6/+9
Use macro for image type instead of using hard code number. Signed-off-by: Kiran K <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-05-14rapidio: remove choice for enumerationMasahiro Yamada1-15/+2
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 <[email protected]>
2024-05-14Makefile: remove redundant tool coverage variablesMasahiro Yamada2-15/+0
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 <[email protected]> Reviewed-by: Kees Cook <[email protected]> Tested-by: Roberto Sassu <[email protected]>
2024-05-14net: micrel: Fix receiving the timestamp in the frame for lan8841Horatiu Vultur1-1/+2
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 <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-05-14Merge branch 'for-6.10/winwing' into for-linusJiri Kosina3-0/+243
- implement full support for WinWing Orion2 (Ivan Gorinov)
2024-05-14Merge branch 'for-6.10/uclogic' into for-linusJiri Kosina1-0/+3
2024-05-14Merge branch 'for-6.10/steam' into for-linusJiri Kosina1-8/+147
- support for Deck IMU in hid-steam (Max Maisel)
2024-05-14Merge branch 'for-6.10/sony' into for-linusJiri Kosina1-5/+2
2024-05-14Merge branch 'for-6.10/playstation' into for-linusJiri Kosina1-45/+93
- 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 Kosina3-11/+7
- 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 Kosina1-24/+33
2024-05-14Merge branch 'for-6.10/kye' into for-linusJiri Kosina1-31/+44
2024-05-14Merge branch 'for-6.10/intel-ish' into for-linusJiri Kosina9-61/+639
- 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 Kosina1-17/+27
- PM fixes for STM and Weida Tech devices (Kenny Levinsen)
2024-05-14Merge branch 'for-6.10/hid-sysfs-emit' into for-linusJiri Kosina10-45/+39
- conversion from sprintf() to sysfs_emit() (Li Zhijian)
2024-05-14Merge branch 'for-6.10/hid-debug' into for-linusJiri Kosina1-442/+2995
- 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 Irenge1-6/+3
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 <[email protected]> Reviewed-by: Holger Dengler <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]>
2024-05-14Merge branch 'for-6.10/hid-bpf' into for-linusJiri Kosina14-71/+1934
- 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 Kosina2-80/+54
- 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 Kosina3-8/+16
- PM fix and assorted other code cleanups for amd-sfh (Basavaraj Natikar)
2024-05-14platform/x86: Add new Dell UART backlight driverHans de Goede3-0/+414
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 <[email protected]> Tested-by: Roman Bogoyev <[email protected]> Tested-by: Kai-Heng Feng <[email protected]> Co-developed-by: AceLan Kao <[email protected]> Signed-off-by: AceLan Kao <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-05-14platform/x86: x86-android-tablets: Create LED device for Xiaomi Pad 2 bottom ↵Hans de Goede1-0/+47
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 <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-05-14platform/x86: x86-android-tablets: Xiaomi pad2 RGB LED fwnode updatesKate Hsuan1-3/+3
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 <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Co-developed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-05-14platform/x86: x86-android-tablets: Pass struct device to init()Hans de Goede4-10/+10
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 <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-05-14platform/x86/amd: pmc: Add new ACPI ID AMDI000BShyam Sundar S K1-0/+1
Add new ACPI ID AMDI000B used by upcoming AMD platform to the PMC supported list of devices. Signed-off-by: Shyam Sundar S K <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-05-14platform/x86/amd: pmf: Add new ACPI ID AMDI0105Shyam Sundar S K1-0/+1
Add new ACPI ID AMDI0105 used by upcoming AMD platform to the PMF supported list of devices. Signed-off-by: Shyam Sundar S K <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-05-14platform/x86: p2sb: Don't init until unassigned resources have been assignedBen Fradella1-14/+15
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 <[email protected]> Acked-by: Andy Shevchenko <[email protected]> Tested-by: Klara Modin <[email protected]> Reviewed-by: Shin'ichiro Kawasaki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-05-14platform/surface: aggregator: Log critical errors during SAM probingWeifeng Liu1-14/+28
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 <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Weifeng Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-05-14firmware: dmi: Add info message for number of populated and total memory slotsHeiner Kallweit1-0/+6
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 <[email protected]> Signed-off-by: Jean Delvare <[email protected]>
2024-05-14power: supply: sbs-manager: Remove class argument from i2c_mux_add_adapter()Wolfram Sang1-1/+1
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 <[email protected]> Acked-by: Sebastian Reichel <[email protected]>
2024-05-14media: bcm2835-unicam: Depend on COMMON_CLKLaurent Pinchart1-1/+1
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 <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Signed-off-by: Hans Verkuil <[email protected]>
2024-05-13Merge tag 'idxd-for-linus-may2024' of git bundle from ArjanLinus Torvalds6-5/+111
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 Kicinski10-186/+4
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/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-05-13net: stmmac: move the EST structure to struct stmmac_privXiaolei Wang4-41/+54
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 <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Serge Semin <[email protected]> Reviewed-by: Andrew Halaney <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-05-13net: stmmac: move the EST lock to struct stmmac_privXiaolei Wang3-12/+16
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 <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Serge Semin <[email protected]> Reviewed-by: Andrew Halaney <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-05-13net: mana: Enable MANA driver on ARM64 with 4K page sizeHaiyang Zhang1-1/+2
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-05-13net: prestera: Add flex arrays to some structsErick Archer1-46/+37
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 <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/AS8PR02MB7237E8469568A59795F1F0408BE12@AS8PR02MB7237.eurprd02.prod.outlook.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-05-13net: fec: remove .ndo_poll_controller to avoid deadlocksWei Fang1-26/+0
There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed. Fixes: 7f5c6addcdc0 ("net/fec: add poll controller function for fec nic") Signed-off-by: Wei Fang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-05-13net: stmmac: add support for RZ/N1 GMACClément Léger3-0/+99
Add support for the Renesas RZ/N1 GMAC. This support can make use of a custom RZ/N1 PCS which is fetched by parsing the pcs-handle device tree property. Signed-off-by: Clément Léger <[email protected]> Co-developed-by: Romain Gantois <[email protected]> Signed-off-by: Romain Gantois <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Reviewed-by: Hariprasad Kelam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-05-13net: stmmac: dwmac-socfpga: use pcs_init/pcs_exitRussell King (Oracle)1-54/+53
Use the newly introduced pcs_init() and pcs_exit() operations to create and destroy the PCS instance at a more appropriate moment during the driver lifecycle, thereby avoiding publishing a network device to userspace that has not yet finished its PCS initialisation. There are other similar issues with this driver which remain unaddressed, but these are out of scope for this patch. Signed-off-by: Russell King (Oracle) <[email protected]> Reviewed-by: Maxime Chevallier <[email protected]> [rgantois: removed second parameters of new callbacks] Signed-off-by: Romain Gantois <[email protected]> Reviewed-by: Hariprasad Kelam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-05-13net: stmmac: introduce pcs_init/pcs_exit stmmac operationsRussell King (Oracle)1-1/+7
Introduce a mechanism whereby platforms can create their PCS instances prior to the network device being published to userspace, but after some of the core stmmac initialisation has been completed. This means that the data structures that platforms need will be available. Signed-off-by: Russell King (Oracle) <[email protected]> Reviewed-by: Maxime Chevallier <[email protected]> Reviewed-by: Serge Semin <[email protected]> Co-developed-by: Romain Gantois <[email protected]> Signed-off-by: Romain Gantois <[email protected]> Reviewed-by: Hariprasad Kelam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-05-13net: stmmac: Make stmmac_xpcs_setup() generic to all PCS devicesSerge Semin3-19/+23
A pcs_init() callback will be introduced to stmmac in a future patch. This new function will be called during the hardware initialization phase. Instead of separately initializing XPCS and PCS components, let's group all PCS-related hardware initialization logic in the current stmmac_xpcs_setup() function. Rename stmmac_xpcs_setup() to stmmac_pcs_setup() and move the conditional call to stmmac_xpcs_setup() inside the function itself. Signed-off-by: Serge Semin <[email protected]> Co-developed-by: Romain Gantois <[email protected]> Signed-off-by: Romain Gantois <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Reviewed-by: Hariprasad Kelam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-05-13net: stmmac: Add dedicated XPCS cleanup methodSerge Semin3-4/+17
Currently the XPCS handler destruction is performed in the stmmac_mdio_unregister() method. It doesn't look good because the handler isn't originally created in the corresponding protagonist stmmac_mdio_unregister(), but in the stmmac_xpcs_setup() function. In order to have more coherent MDIO and XPCS setup/cleanup procedures, let's move the DW XPCS destruction to the dedicated stmmac_pcs_clean() method. This method will also be used to cleanup PCS hardware using the pcs_exit() callback that will be introduced to stmmac in a subsequent patch. Signed-off-by: Serge Semin <[email protected]> Co-developed-by: Romain Gantois <[email protected]> Signed-off-by: Romain Gantois <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Reviewed-by: Hariprasad Kelam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.