aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-05-14Bluetooth: Add proper definitions for scan interval and windowLuiz Augusto von Dentz2-10/+24
This adds proper definitions for scan interval and window and then make use of them instead their values. 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-14kconfig: lxdialog: remove initialization with A_NORMALMasahiro Yamada1-9/+0
A_NORMAL is zero, so the attribute is set to the default A_NORMAL without explicit assignment. Signed-off-by: Masahiro Yamada <[email protected]>
2024-05-14kconfig: m/nconf: merge two item_add_str() callsMasahiro Yamada2-9/+4
Just trivial cleanups. Signed-off-by: Masahiro Yamada <[email protected]>
2024-05-14kconfig: m/nconf: remove dead code to display value of bool choiceMasahiro Yamada2-29/+14
Previously, optional bool choices met the following conditions simultaneously: - sym_is_choice(sym) - sym_is_changeable(sym) - type == S_BOOLEAN It no longer occurs since 6a1215888e23 ("kconfig: remove 'optional' property support"). Remove the dead code. Signed-off-by: Masahiro Yamada <[email protected]>
2024-05-14kconfig: m/nconf: remove dead code to display children of choice membersMasahiro Yamada2-95/+71
This code previously displayed child symbols of the selected choice member. Since commit 7e3465f63a0a ("kconfig: do not reparent the menu inside a choice block"), choice members never have child symbols, therefore this is dead code. Signed-off-by: Masahiro Yamada <[email protected]>
2024-05-14kconfig: gconf: show checkbox for choice correctlyMasahiro Yamada1-7/+5
Currently, bool choices have a checkbox, but tristate choices do not. It is opposite. Bool choices should not have a checkbox, as they are fixed to 'y' since commit 6a1215888e23 ("kconfig: remove 'optional' property support"). Tristate choices, however, should have a checkbox to allow users to toggle the value. Signed-off-by: Masahiro Yamada <[email protected]>
2024-05-14kbuild: use GCOV_PROFILE and KCSAN_SANITIZE in scripts/Makefile.modfinalMasahiro Yamada1-1/+3
Instead of filtering out the GCOV and KCSAN flags, let's set GCOV_PROFILE and KCSAN_SANITIZE to 'n', as in other Makefiles. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Kees Cook <[email protected]> Tested-by: Roberto Sassu <[email protected]>
2024-05-14Makefile: remove redundant tool coverage variablesMasahiro Yamada34-241/+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-14kbuild: provide reasonable defaults for tool coverageMasahiro Yamada2-9/+13
The objtool, sanitizers (KASAN, UBSAN, etc.), and profilers (GCOV, etc.) are intended only for kernel space objects. For instance, the following are not kernel objects, and therefore should opt out of coverage: - vDSO - purgatory - bootloader (arch/*/boot/) However, to exclude these from coverage, you need to explicitly set OBJECT_FILES_NON_STNDARD=y, KASAN_SANITIZE=n, etc. Kbuild can achieve this without relying on such variables because objects not directly linked to vmlinux or modules are considered "non-standard objects". Detecting standard objects is straightforward: - objects added to obj-y or lib-y are linked to vmlinux - objects added to obj-m are linked to modules There are some exceptional Makefiles (e.g., arch/s390/boot/Makefile, arch/xtensa/boot/lib/Makefile) that use obj-y or lib-y for non-kernel space objects, but they can be fixed later if necessary. Going forward, objects that are not listed in obj-y, lib-y, or obj-m will opt out of objtool, sanitizers, and profilers by default. You can still override the Kbuild decision by explicitly specifying OBJECT_FILES_NON_STANDARD, KASAN_SANITIZE, etc. but most of such Make variables can be removed. The next commit will clean up redundant variables. Note: This commit changes the coverage for some objects: - exclude .vmlinux.export.o from UBSAN, KCOV - exclude arch/csky/kernel/vdso/vgettimeofday.o from UBSAN - exclude arch/parisc/kernel/vdso32/vdso32.so from UBSAN - exclude arch/parisc/kernel/vdso64/vdso64.so from UBSAN - exclude arch/x86/um/vdso/um_vdso.o from UBSAN - exclude drivers/misc/lkdtm/rodata.o from UBSAN, KCOV - exclude init/version-timestamp.o from UBSAN, KCOV - exclude lib/test_fortify/*.o from all santizers and profilers I believe these are positive effects. 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 Kosina10-97/+740
- 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-14Merge branch 'for-6.10/hid-bpf' into for-linusJiri Kosina26-278/+3834
- 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-14devm-helpers: Fix a misspelled cancellation in the commentsAndy Shevchenko1-2/+2
Fix a misspelled cancellation in the comments. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-05-14tools arch x86: Add dell-uart-backlight-emulatorHans de Goede4-0/+229
Dell All In One (AIO) models released after 2017 use a backlight controller board connected to an UART. Add a small emulator to allow development and testing of the drivers/platform/x86/dell/dell-uart-backlight.c driver for this board, without requiring access to an actual Dell All In One. Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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-14bpf: remove CONFIG_BPF_JIT dependency on CONFIG_MODULES ofMike Rapoport (IBM)1-1/+1
BPF just-in-time compiler depended on CONFIG_MODULES because it used module_alloc() to allocate memory for the generated code. Since code allocations are now implemented with execmem, drop dependency of CONFIG_BPF_JIT on CONFIG_MODULES and make it select CONFIG_EXECMEM. Suggested-by: Björn Töpel <[email protected]> Signed-off-by: Mike Rapoport (IBM) <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]>
2024-05-14kprobes: remove dependency on CONFIG_MODULESMike Rapoport (IBM)4-23/+63
kprobes depended on CONFIG_MODULES because it has to allocate memory for code. Since code allocations are now implemented with execmem, kprobes can be enabled in non-modular kernels. Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes inside modules, make CONFIG_KPROBES select CONFIG_EXECMEM and drop the dependency of CONFIG_KPROBES on CONFIG_MODULES. Signed-off-by: Mike Rapoport (IBM) <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> [mcgrof: rebase in light of NEED_TASKS_RCU ] Signed-off-by: Luis Chamberlain <[email protected]>
2024-05-14powerpc: use CONFIG_EXECMEM instead of CONFIG_MODULES where appropriateMike Rapoport (IBM)6-9/+9
There are places where CONFIG_MODULES guards the code that depends on memory allocation being done with module_alloc(). Replace CONFIG_MODULES with CONFIG_EXECMEM in such places. Signed-off-by: Mike Rapoport (IBM) <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]>
2024-05-14x86/ftrace: enable dynamic ftrace without CONFIG_MODULESMike Rapoport (IBM)2-10/+1
Dynamic ftrace must allocate memory for code and this was impossible without CONFIG_MODULES. With execmem separated from the modules code, execmem_text_alloc() is available regardless of CONFIG_MODULES. Remove dependency of dynamic ftrace on CONFIG_MODULES and make CONFIG_DYNAMIC_FTRACE select CONFIG_EXECMEM in Kconfig. Signed-off-by: Mike Rapoport (IBM) <[email protected]> Reviewed-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]>
2024-05-14arch: make execmem setup available regardless of CONFIG_MODULESMike Rapoport (IBM)23-435/+453
execmem does not depend on modules, on the contrary modules use execmem. To make execmem available when CONFIG_MODULES=n, for instance for kprobes, split execmem_params initialization out from arch/*/kernel/module.c and compile it when CONFIG_EXECMEM=y Signed-off-by: Mike Rapoport (IBM) <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]>
2024-05-14powerpc: extend execmem_params for kprobes allocationsMike Rapoport (IBM)2-20/+7
powerpc overrides kprobes::alloc_insn_page() to remove writable permissions when STRICT_MODULE_RWX is on. Add definition of EXECMEM_KRPOBES to execmem_params to allow using the generic kprobes::alloc_insn_page() with the desired permissions. As powerpc uses breakpoint instructions to inject kprobes, it does not need to constrain kprobe allocations to the modules area and can use the entire vmalloc address space. Signed-off-by: Mike Rapoport (IBM) <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]>
2024-05-14arm64: extend execmem_info for generated code allocationsMike Rapoport (IBM)3-18/+12
The memory allocations for kprobes and BPF on arm64 can be placed anywhere in vmalloc address space and currently this is implemented with overrides of alloc_insn_page() and bpf_jit_alloc_exec() in arm64. Define EXECMEM_KPROBES and EXECMEM_BPF ranges in arm64::execmem_info and drop overrides of alloc_insn_page() and bpf_jit_alloc_exec(). Signed-off-by: Mike Rapoport (IBM) <[email protected]> Acked-by: Will Deacon <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.