summaryrefslogtreecommitdiffstats
path: root/drivers/platform
Commit message (Collapse)AuthorAgeFilesLines
...
* | | platform/x86: touchscreen_dmi: Add info for the Viglen Connect 10 tabletMark Stamp2021-10-281-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | Add touchscreen info for the Viglen Connect 10 tablet. Signed-off-by: Mark Stamp <stamp497@googlemail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211028094824.84292-1-hdegoede@redhat.com
* | | platform/surface: aggregator_registry: Add initial support for Surface Pro 8Maximilian Luz2021-10-281-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add preliminary support for the Surface Pro 8 to the Surface Aggregator registry. This includes battery/charger status and platform profile support. In contrast to earlier Surface Pro generations, the keyboard cover is now also connected via the Surface Aggregator Module (whereas it was previously connected via USB or HID-over-I2C). To properly support the HID devices of that cover, however, more changes regarding hot-removal of Surface Aggregator client devices as well as a new device hub driver are required. We will address those things in a follow-up series, so do not add any HID device IDs just yet. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20211028012845.1887219-1-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: mlx-platform: Add support for new system SGN2410Vadim Pasternak2021-10-271-0/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for new system type, which is a water-cooling flavor of the VMOD001 system class, equipped with 48xSFP28 and 8xQSFP28 100G Ethernet ports. System is recognized by "DMI_BOARD_NAME" and " DMI_PRODUCT_SKU" matches, when these fields are set respectively to "VMOD001" and "HI138". Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Oleksandr Shamray <oleksandrs@nvidia.com> Link: https://lore.kernel.org/r/20211023094022.4193813-4-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: mlx-platform: Add BIOS attributes for CoffeeLake COMEx based ↵Vadim Pasternak2021-10-271-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | systems Extend systems of class VMOD0010 equipped with CoffeeLake COMEx module with BIOS related attributes to represent various BIOS statuses. These attributes "bios_active_image", "bios_auth_fail", "bios_upgrade_fail", "bios_safe_mode" has been already added to modular system. This all of them are already documented. - "bios_active_image" - location of current active BIOS image (0: Top, 1: Bottom. The reported value should correspond to value expected by OS in case of BIOS safe mode is 0. This bit is related to Intel top-swap feature of DualBios on the same flash. - "bios_auth_fail": BIOS upgrade is failed because provided BIOS image is not signed correctly. - "bios_upgrade_fail" BIOS upgrade is failed by some reason not related to authentication. For example, due to physical SPI flash problem. - "bios_safe_mod": - 0 : if BIOS is booted from a supposed active image; 1 : BIOS safe mechanism was enforced by hardware (CPLD). Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Oleksandr Shamray <oleksandrs@nvidia.com> Link: https://lore.kernel.org/r/20211023094022.4193813-3-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: mlx-platform: Extend FAN and LED configuration to support new ↵Vadim Pasternak2021-10-271-1/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MQM97xx systems Add support for new system types "MQM97xx", which is based on Mellanox Quantum-2 ASIC. It provides up to 64x400GB/s (IB) full bidirectional bandwidth per port using PAM-4 modulation. The system support 32 OSFP cages that can provide 64x400GB/s per port (two ports/cage). The system fits standard 1U racks. System is equipped with seven fan drawers and with per fan drawer LED on backport panel and uses two-bytes for exposing CPLD Part Number versions. System is recognized by "DMI_BOARD_NAME" match, when this field is set to "VMOD0010". Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Oleksandr Shamray <oleksandrs@nvidia.com> Link: https://lore.kernel.org/r/20211023094022.4193813-2-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: asus-wmi: rename platform_profile_* function symbolsMario Limonciello2021-10-271-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An upcoming change to platform profiles will export `platform_profile_get` as a symbol that can be used by other drivers. Avoid the collision. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211026190835.10697-3-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: hp-wmi: rename platform_profile_* function symbolsMario Limonciello2021-10-271-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An upcoming change to platform profiles will export `platform_profile_get` as a symbol that can be used by other drivers. Avoid the collision. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211026190835.10697-2-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: amd-pmc: Drop check for valid alarm timeMario Limonciello2021-10-271-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is already checked when calling rtc_read_alarm. Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211026171443.289-3-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: amd-pmc: Downgrade dev_info message to dev_dbgMario Limonciello2021-10-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the majority of users this information will not be informative as they've chosen to program the RTC before going to sleep. Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211026171443.289-2-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: amd-pmc: fix compilation without CONFIG_RTC_SYSTOHC_DEVICEMario Limonciello2021-10-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just hardcode the RTC to "rtc0" which is the default for CONFIG_RTC_SYSTOHC_DEVICE and used by all standard x86 distros. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Suggested-by: Hans de Goede <hdegoede@redhat.com> Fixes: 59348401ebed ("platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeup") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211026171443.289-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: system76_acpi: fix Kconfig dependenciesArnd Bergmann2021-10-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When CONFIG_INPUT is disabled, this driver now fails to link: ld.lld: error: undefined symbol: devm_input_allocate_device >>> referenced by system76_acpi.c >>> platform/x86/system76_acpi.o:(system76_add) in archive drivers/built-in.a ld.lld: error: undefined symbol: input_set_capability >>> referenced by system76_acpi.c >>> platform/x86/system76_acpi.o:(system76_add) in archive drivers/built-in.a ld.lld: error: undefined symbol: devm_hwmon_device_register_with_info >>> referenced by system76_acpi.c >>> platform/x86/system76_acpi.o:(system76_add) in archive drivers/built-in.a ld.lld: error: undefined symbol: battery_hook_unregister >>> referenced by system76_acpi.c >>> platform/x86/system76_acpi.o:(system76_remove) in archive drivers/built-in.a Add Kconfig dependencies for each of these three. Fixes: 0de30fc684b3 ("platform/x86: system76_acpi: Replace Fn+F2 function for OLED models") Fixes: 95563d45b5da ("platform/x86: system76_acpi: Report temperature and fan speed") Fixes: 76f7eba3e0a2 ("platform/x86: system76_acpi: Add battery charging thresholds") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20211022154901.904984-1-arnd@kernel.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: barco-p50-gpio: use KEY_VENDOR for button instead of KEY_RESTARTPeter Korsgaard2021-10-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that systemd-logind by default listens for KEY_RESTART input events and reboots the machine, which isn't great - So use KEY_VENDOR for the vendor specific identify button instead to not conflict. Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com> Link: https://lore.kernel.org/r/20211022124612.19780-1-peter@korsgaard.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: sony-laptop: replace snprintf in show functions with sysfs_emitYe Guojin2021-10-221-28/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | coccicheck complains about the use of snprintf() in sysfs show functions: WARNING use scnprintf or sprintf Use sysfs_emit instead of scnprintf or sprintf makes more sense. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn> Link: https://lore.kernel.org/r/20211022090851.1065538-1-ye.guojin@zte.com.cn Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: lg-laptop: replace snprintf in show functions with sysfs_emitYe Guojin2021-10-221-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | coccicheck complains about the use of snprintf() in sysfs show functions: WARNING use scnprintf or sprintf Use sysfs_emit instead of scnprintf or sprintf makes more sense. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn> Link: https://lore.kernel.org/r/20211022090722.1065457-1-ye.guojin@zte.com.cn Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: wmi: change notification handler typeMikalai Ramanovich2021-10-221-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since AML code on some Xiaomi laptops notifies the WMI hotkey with 0x20 event, we need ACPI_ALL_NOTIFY here to be able to handle it. Signed-off-by: Mikalai Ramanovich <nikolay.romanovich.00@gmail.com> Link: https://lore.kernel.org/r/20211015191322.73388-1-nikolay.romanovich.00@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/surface: aggregator_registry: Add support for Surface Laptop StudioMaximilian Luz2021-10-211-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the Surface Laptop Studio. In contrast to previous Surface Laptop models, this one has its HID devices attached to target ID 1 (instead of 2). It also has a couple more of them, including a new notifier for when the pen is stashed / taken out of its place, a "Sys Control" device, and two other unidentified HID devices with unknown usages. Battery and performance profile interfaces remain the same. Cc: stable@vger.kernel.org # 5.14+ Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20211021130904.862610-2-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/surface: gpe: Add support for Surface Laptop StudioMaximilian Luz2021-10-211-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new Surface Laptop Studio uses GPEs for lid events as well. Add an entry for that so that the lid can be used to wake the device. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20211021111053.564133-1-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeupMario Limonciello2021-10-211-1/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RTC based wakeup from s0i3 doesn't work properly on some Green Sardine platforms. Because of this, a newer SMU for Green Sardine has the ability to pass wakeup time as argument of the upper 16 bits of OS_HINT message. With older firmware setting the timer value in OS_HINT will cause firmware to reject the hint, so only run this path on: 1) Green Sardine 2) Minimum SMU FW 3) RTC alarm armed during s0i3 entry Using this method has some limitations that the s0i3 wakeup will need to be between 4 seconds and 18 hours, so check those boundary conditions as well and abort the suspend if RTC is armed for too short or too long of a duration. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211020162946.10537-2-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: amd-pmc: adjust arguments for `amd_pmc_send_cmd`Mario Limonciello2021-10-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the "argument" for the "message" is listed as a boolean value. This works well for the commands used currently, but an additional upcoming command will pass more data in the message. Expand it to be a full 32 bit value. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211020162946.10537-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: Support for EC-connected GPIOs for identify LED/button on ↵Santosh Kumar Yadav2021-10-203-0/+449
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Barco P50 board Add a driver providing access to the GPIOs for the identify button and led present on Barco P50 board, based on the pcengines-apuv2.c driver. There is unfortunately no suitable ACPI entry for the EC communication interface, so instead bind to boards with "P50" as their DMI product family and hard code the I/O port number (0x299). The driver also hooks up the leds-gpio and gpio-keys-polled drivers to the GPIOs, so they are finally exposed as: LED: /sys/class/leds/identify Button: (/proc/bus/input/devices) I: Bus=0019 Vendor=0001 Product=0001 Version=0100 N: Name="identify" P: Phys=gpio-keys-polled/input0 S: Sysfs=/devices/platform/barco-p50-gpio/gpio-keys-polled/input/input10 U: Uniq= H: Handlers=event10 B: PROP=0 B: EV=3 B: KEY=1000000 0 0 0 0 0 0 Signed-off-by: Santosh Kumar Yadav <santoshkumar.yadav@barco.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Link: https://lore.kernel.org/r/20211020123634.2638-1-peter@korsgaard.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: intel_int0002_vgpio: Use the new soc_intel_is_byt()/_cht() helpersHans de Goede2021-10-191-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | Use the new soc_intel_is_byt()/_cht() helpers to clean things up a bit. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211018143324.296961-3-hdegoede@redhat.com
* | | platform/x86: thinkpad_acpi: Fix bitwise vs. logical warningNathan Chancellor2021-10-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A new warning in clang points out a use of bitwise OR with boolean expressions in this driver: drivers/platform/x86/thinkpad_acpi.c:9061:11: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] else if ((strlencmp(cmd, "level disengaged") == 0) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || drivers/platform/x86/thinkpad_acpi.c:9061:11: note: cast one or both operands to int to silence this warning 1 error generated. This should clearly be a logical OR so change it to fix the warning. Fixes: fe98a52ce754 ("ACPI: thinkpad-acpi: add sysfs support to fan subdriver") Link: https://github.com/ClangBuiltLinux/linux/issues/1476 Reported-by: Tor Vic <torvic9@mailbox.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20211018182537.2316800-1-nathan@kernel.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: thinkpad_acpi: Fix coccinelle warningsYe Guojin2021-10-191-27/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | coccicheck complains about the use of snprintf() in sysfs show functions: WARNING use scnprintf or sprintf Use sysfs_emit instead of scnprintf or sprintf makes more sense. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn> Link: https://lore.kernel.org/r/20211018091750.858826-1-ye.guojin@zte.com.cn Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: panasonic-laptop: Replace snprintf in show functions with ↵Qing Wang2021-10-191-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sysfs_emit show() must not use snprintf() when formatting the value to be returned to user space. Fix the coccicheck warnings: WARNING: use scnprintf or sprintf. Use sysfs_emit instead of scnprintf or sprintf makes more sense. Signed-off-by: Qing Wang <wangqing@vivo.com> Link: https://lore.kernel.org/r/1634280641-4862-1-git-send-email-wangqing@vivo.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform: x86: ideapad-laptop: Use ACPI_COMPANION() directlyRafael J. Wysocki2021-10-191-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION() macro and the ACPI handle produced by the former comes from the ACPI device object produced by the latter, so it is way more straightforward to evaluate the latter directly instead of passing the handle produced by the former to acpi_bus_get_device(). Modify ideapad_acpi_add() accordingly (no intentional functional impact). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/8000884.T7Z3S40VBb@kreacher Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | surface: surface3_power: Drop redundant acpi_bus_get_device() callRafael J. Wysocki2021-10-191-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the ACPI companion of a given device is not present, the result of the ACPI_HANDLE() evaluation for it will be NULL, so calling acpi_bus_get_device() on ACPI_HANDLE() result in order to validate it is redundant. Drop the redundant acpi_bus_get_device() call from mshw0011_notify() along with a local variable related to it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/3160001.aeNJFYEL58@kreacher Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | surface: surface3-wmi: Use ACPI_COMPANION() directlyRafael J. Wysocki2021-10-191-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION() macro and the ACPI handle produced by the former comes from the ACPI device object produced by the latter, so it is way more straightforward to evaluate the latter directly instead of passing the handle produced by the former to acpi_bus_get_device(). Modify s3_wmi_check_platform_device() accordingly (no intentional functional impact). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/12896717.uLZWGnKmhe@kreacher Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: system76_acpi: Add attribute group for kb_led_colorTim Crawford2021-10-191-14/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create the attribute groups for kb_led_color and set the `groups` field in kb_led. While touching it, also change its show method to use sysfs_emit() instead of sprintf(). Signed-off-by: Tim Crawford <tcrawford@system76.com> Link: https://lore.kernel.org/r/20211006202202.7479-5-tcrawford@system76.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: system76_acpi: Add battery charging thresholdsTim Crawford2021-10-191-0/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | System76 laptops running open source EC firmware support configuring charging thresholds through ACPI methods. Expose this functionality through the standard sysfs entries charge_control_{start,end}_threshold. Signed-off-by: Tim Crawford <tcrawford@system76.com> Link: https://lore.kernel.org/r/20211006202202.7479-4-tcrawford@system76.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: system76_acpi: Replace Fn+F2 function for OLED modelsJeremy Soller2021-10-191-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | System76 laptops models with OLED displays do not support the default Fn+F2 behavior of turning the embedded display on and off. Some models instead introduce a new notify event that is used to lock the screen so the OS will put the display in a low power state. Signed-off-by: Jeremy Soller <jeremy@system76.com> Signed-off-by: Tim Crawford <tcrawford@system76.com> Link: https://lore.kernel.org/r/20211006202202.7479-3-tcrawford@system76.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: system76_acpi: Report temperature and fan speedJeremy Soller2021-10-191-4/+218
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a hwmon interface to report CPU/GPU temperature and fan speed. sensors now reports an ACPI interface with the entries: system76_acpi-acpi-0 Adapter: ACPI interface CPU fan: 0 RPM GPU fan: 0 RPM CPU temp: +47.0°C GPU temp: +0.0°C Signed-off-by: Jeremy Soller <jeremy@system76.com> Signed-off-by: Tim Crawford <tcrawford@system76.com> Link: https://lore.kernel.org/r/20211006202202.7479-2-tcrawford@system76.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: mlx-platform: Add support for multiply cooling devicesVadim Pasternak2021-10-191-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add new registers to support systems with multiply cooling devices. Modular systems support up-to four cooling devices. This capability is detected according to the registers initial setting. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20211002093609.3771576-1-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/mellanox: mlxreg-lc: Add initial support for Nvidia line card devicesVadim Pasternak2021-10-193-0/+919
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide support for the Nvidia MSN4800-XX line cards for MSN4800 Ethernet modular switch system, providing a high performance switching solution for Enterprise Data Centers (EDC) for building Ethernet based clusters, High-Performance Computing (HPC) and embedded environments. Initial version provides support for line card type MSN4800-C16. This type of line card is equipped with: - Lattice CPLD device, used for system and ports control. - four Nvidia gearbox devices, used for port splitting. - FPGA device, used for gearboxes management. - 16x100G QSFP28 ports. - hotpswap controllers, voltage regulators, analog-to-digital convertors, nvram devices. - status LED. During initialization driver creates: - line card's I2C tree through "i2c-mux-mlxcpd" driver. - line card's LED objects through "leds-mlxreg" driver. - line card's CPLD register space input / output "hwmon" attributes for line control and monitoring through "mlxreg-io" driver. These attributes provide CPLD and FPAG versioning, control for upgradable components burning, NVRAM devices write protection, line card revision, line card power consuming, line card reset cause indication, etcetera. Lattice CPLD device and nvram devices are feeding from auxiliary power domain and accessible, when line card is powered off. These devices are connected by line card driver probing routine, invoked after line card security verification is done by hardware and event lc#n_verified is received for line card located in slot #n. Gearboxes, FPGA, hotpswap controllers, voltage regulators, analog-to-digital convertors are feeding from main power domain. These devices are connected after power good event "lc#n_powered" is received for line card located in slot #n. The driver 'mlxreg-lc' is driven by 'mlxreg-hotplug' driver following relevant "hotplug" events. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20211002093238.3771419-8-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/mellanox: mlxreg-io: Extend number of hwmon attributesVadim Pasternak2021-10-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend maximum number of the attributes, exposed to 'sysfs'. It is requires in order to support modular systems, which provide more attributes for system control, statuses and info. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20211002093238.3771419-6-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: mlx-platform: Configure notifier callbacks for modular systemVadim Pasternak2021-10-191-0/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add event notifier callbacks for modular system line cards. These callbacks are to be passed to "mlxreg-hotplug" driver by line card driver during probing. Then, when any line card related hotplug event is received (insertion ,power, synch, ready), hotplug driver will invoke callback for the relevant line card. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20211002093238.3771419-5-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/mellanox: mlxreg-hotplug: Extend logic for hotplug devices operationsVadim Pasternak2021-10-191-35/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the structure 'mlxreg_hotplug_device" with platform device field to allow transition of the register map and system interrupt line number to underlying hotplug devices, sharing the same register map and same interrupt line with 'mlxreg-hotplug' driver. Extend logic for hotplug devices creation and removing according to the action associated with the hotplug device description. Previously hotplug driver was capable to attach / de-attach upon hotplug events only I2C devices handled by simple I2C drivers. Now it should be able to attach also devices handled by the platform drivers. The motivation is to allow transition of platform data like: - system interrupt line number, sharing with 'mlxreg-hotplug' to underlying hotplug devices. - shared register map of programmable devices on main board to underlying hotplug devices. Additioanlly the number of 'sysfs' attributes is increased, since modular system defines more 'sysfs' attributes. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20211002093238.3771419-4-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: mlx-platform: Add initial support for new modular systemVadim Pasternak2021-10-191-2/+1653
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add initial chassis management support for Nvidia modular Ethernet switch systems MSN4800, providing a high performance switching solution for Enterprise Data Centers (EDC) for building Ethernet based clusters, High-Performance Computing (HPC) and embedded environments. This system could be equipped with the different types of replaceable line cards and management board. The first system flavor will support the line card type MSN4800-C16 equipped with Lattice CPLD devices aimed for system and ASIC control, one Nvidia FPGA for gearboxes (PHYs) management, and four Nvidia gearboxes for the port control and with 16x100GbE QSFP28 ports and also with various devices for electrical control. The system is equipped with eight slots for line cards, four slots for power supplies and six slots for fans. It could be configured as fully populated or with even only one line card. The line cards are hot-pluggable. In the future when more line card flavors are to be available (for example line cards with 8x200Gb Eth port, with 4x400 Eth ports, or with some kind of smart cards for offloading purpose), any type of line card could be inserted at any slot. The system is based on Nvidia Spectrum-3 ASIC. The switch height is 4U and it fits standard rack size. System could be configured as fully populated or with even only one line card. The line cards are hot-pluggable. Line cards are connected to the chassis through I2C interface for the chassis management operations and through PCIe for the networking operations. Future line cards could be connected to the chassis through InfiniBand fabric, instead of PCIe. The first type of line card supports 16x100GbE QSFP28 Ethernet ports. Those line cards equipped with the programmable devices aimed for system control of Nvidia Ethernet switch ASIC control, Nvidia FPGA, Nvidia gearboxes (PHYs). The next coming card generations are supposed to support: - Line cards with 8x200Gbe QSFP28 Ethernet ports. - Line cards with 4x400Gbe QSFP-DD Ethernet ports. - Smart cards equipped with Nvidia ARM CPU for offloading and for fast access to the storage (EBoF). - Fabric cards for inter-connection. The basic system initialization flow with input signals from the programmable device to kernel hotplug driver and with OS response to some of these signals is depicted below. lc#n_prsnt *-> Input: line card presence in/out events. Informational event. Required action - 'udev' event generation for logging. lc#n_verified *-> Input: line card verification status events coming after line card security signature validation by hardware. Required action - connect line card driver and initialized line card devices feeding from system auxiliary power domain. lc#n_pwr <-* Output: line card power on / off from OS. Action should be performed by platform power management driver. lc#n_powered *-> Input: line card power on/off events coming after line card "power good" on/off events, mean that line card power up sequence has been successfully completed or line card "power good" status has been dropped. Required action - connect line card devices feeding from system main power domain. lc#n_synced *-> Input: line card synchronization events, coming after hardware-firmware synchronization handshake. Required action - to enable line card, in case lc#n_ready has been received before. lc#n_ready *-> Input: line card ready events, indicating line card PHYs ready / unready states. Required action - enable line card, in case lc#n_synced has been received before. lc#n_enable <-* Output: line card enable from OS - release FPGA and PHYs line card devices from reset state. Action should be performed by platform power management driver. lc#n_active *-> Input: when line card "active event" is received for particular line card, its network, hardware monitoring and thermal interfaces should be configured according to the configuration obtained from the firmware. When opposite "inactive event" is received all the above interfaces should be teared down. Required action - connect / disconnect the above line card interfaces through ASIC I2C chassis management driver. For initial support: - Define new system type 'VMOD0011' to support new modular system. - Provide initial platform configuration for new system type. - Extend the registers definitions. - Add support for modular system registers related to line card specific events - insertion/removal, power on/off, verification and activation. - Add hotplug configuration for the above events. - Add configurations for hotplug actions for the modular system. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20211002093238.3771419-3-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: int1092: Fix non sequential device mode handlingShravan S2021-10-111-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SAR information from BIOS may come in non sequential pattern. To overcome the issue, a check is made to extract the right SAR information using the device mode which is currently being used. Remove .owner field if calls are used which set it automatically. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by: Shravan S <s.shravan@intel.com> Link: https://lore.kernel.org/r/20211006073525.1332925-1-s.shravan@intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: intel_skl_int3472: Correct null checkDaniel Scally2021-10-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The int3472-discrete driver can enter an error path after initialising int3472->clock.ena_gpio, but before it has registered the clock. This will cause a NULL pointer dereference, because clkdev_drop() is not null aware. Instead of guarding the call to skl_int3472_unregister_clock() by checking for .ena_gpio, check specifically for the presence of the clk_lookup, which will guarantee clkdev_create() has already been called. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214453 Fixes: 7540599a5ef1 ("platform/x86: intel_skl_int3472: Provide skl_int3472_unregister_clock()") Signed-off-by: Daniel Scally <djrscally@gmail.com> Link: https://lore.kernel.org/r/20211008224608.415949-1-djrscally@gmail.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: gigabyte-wmi: add support for B550 AORUS ELITE AX V2Zephaniah E. Loss-Cutler-Hull2021-10-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | This works just fine on my system. Signed-off-by: Zephaniah E. Loss-Cutler-Hull <zephaniah@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211005044855.1429724-1-zephaniah@gmail.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: amd-pmc: Add alternative acpi id for PMC controllerSachi King2021-10-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Surface Laptop 4 AMD has used the AMD0005 to identify this controller instead of using the appropriate ACPI ID AMDI0005. Include AMD0005 in the acpi id list. Link: https://github.com/linux-surface/acpidumps/tree/master/surface_laptop_4_amd Link: https://gist.github.com/nakato/2a1a7df1a45fe680d7a08c583e1bf863 Cc: <stable@vger.kernel.org> # 5.14+ Signed-off-by: Sachi King <nakato@nakato.io> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211002041840.2058647-1-nakato@nakato.io Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: intel_scu_ipc: Update timeout value in commentPrashant Malani2021-10-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The comment decribing the IPC timeout hadn't been updated when the actual timeout was changed from 3 to 5 seconds in commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual timeout from 3 to 5 seconds") . Since the value is anyway updated to 10s now, take this opportunity to update the value in the comment too. Signed-off-by: Prashant Malani <pmalani@chromium.org> Cc: Benson Leung <bleung@chromium.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20210928101932.2543937-4-pmalani@chromium.org Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: intel_scu_ipc: Increase virtual timeout to 10sPrashant Malani2021-10-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual timeout from 3 to 5 seconds") states that the recommended timeout range is 5-10 seconds. Adjust the timeout value to the higher of those i.e 10 seconds, to account for situations where the 5 seconds is insufficient for disconnect command success. Signed-off-by: Prashant Malani <pmalani@chromium.org> Cc: Benson Leung <bleung@chromium.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20210928101932.2543937-3-pmalani@chromium.org Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: intel_scu_ipc: Fix busy loop expiry timePrashant Malani2021-10-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The macro IPC_TIMEOUT is already in jiffies (it is also used like that elsewhere in the file when calling wait_for_completion_timeout()). Don’t convert it using helper functions for the purposes of calculating the busy loop expiry time. Fixes: e7b7ab3847c9 (“platform/x86: intel_scu_ipc: Sleeping is fine when polling”) Signed-off-by: Prashant Malani <pmalani@chromium.org> Cc: Benson Leung <bleung@chromium.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20210928101932.2543937-2-pmalani@chromium.org Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: dell: Make DELL_WMI_PRIVACY depend on DELL_WMIHans de Goede2021-10-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DELL_WMI_PRIVACY is a feature toggle for the main dell-wmi driver, so it must depend on the Kconfig option which enables the main dell-wmi driver. Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211011132338.407571-1-hdegoede@redhat.com
* | | platform/x86: Rename wmaa-backlight-wmi to nvidia-wmi-ec-backlightDaniel Dadap2021-10-113-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename the wmaa-backlight-wmi driver and associated KConfig option to remove the remaining references to the "WMAA" ACPI handle which was used in the previous name. The driver has already been updated to remove internal references to "WMAA". As part of the renaming, the components in the name have been rearranged to reflect the standard vendor_wmi_feature pattern. Signed-off-by: Daniel Dadap <ddadap@nvidia.com> Link: https://lore.kernel.org/r/20210927202359.13684-2-ddadap@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: Remove "WMAA" from identifier names in wmaa-backlight-wmi.cDaniel Dadap2021-10-111-83/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "wmaa" in the name of the wmaa-backlight-wmi driver was named after the ACPI method handle for EC-based backlight control on the systems this driver was tested on during development. However, this "WMAA" handle is generated by the WMI compilation process, and isn't actually a part of the backlight control mechanism which this driver supports. Since the "WMAA" handle isn't actually a part of the firmware backlight interface, the various identifiers in this driver using "WMAA" or "wmaa" aren't actually appropriate. As a common denominator across the systems supported by this driver is that they are hybrid graphics systems with NVIDIA GPUs, using "nvidia" in the driver name seems more appropriate than "wmaa". Update the driver to remove "wmaa" and "WMAA" in identifier names where they appear. The kerneldoc comments for the enum wmi_brightness_method values are replaced with the verbatim text from the decompiled BMF code for this WMI class. Signed-off-by: Daniel Dadap <ddadap@nvidia.com> Link: https://lore.kernel.org/r/20210927202359.13684-1-ddadap@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/mellanox: mlxreg-io: Fix read access of n-bytes size attributesVadim Pasternak2021-10-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix shift argument for function rol32(). It should be provided in bits, while was provided in bytes. Fixes: 86148190a7db ("platform/mellanox: mlxreg-io: Add support for complex attributes") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20210927142214.2613929-3-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/mellanox: mlxreg-io: Fix argument base in kstrtou32() callVadim Pasternak2021-10-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change kstrtou32() argument 'base' to be zero instead of 'len'. It works by chance for setting one bit value, but it is not supposed to work in case value passed to mlxreg_io_attr_store() is greater than 1. It works for example, for: echo 1 > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable But it will fail for: echo n > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable, where n > 1. The flow for input buffer conversion is as below: _kstrtoull(const char *s, unsigned int base, unsigned long long *res) calls: rv = _parse_integer(s, base, &_res); For the second case, where n > 1: - _parse_integer() converts 's' to 'val'. For n=2, 'len' is set to 2 (string buffer is 0x32 0x0a), for n=3 'len' is set to 3 (string buffer 0x33 0x0a), etcetera. - 'base' is equal or greater then '2' (length of input buffer). As a result, _parse_integer() exits with result zero (rv): rv = 0; while (1) { ... if (val >= base)-> (2 >= 2) break; ... rv++; ... } And _kstrtoull() in their turn will fail: if (rv == 0) return -EINVAL; Fixes: 5ec4a8ace06c ("platform/mellanox: Introduce support for Mellanox register access driver") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20210927142214.2613929-2-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | | platform/x86: thinkpad_acpi: Switch to common use of attributesLen Baker2021-09-281-113/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As noted in the "Deprecated Interfaces, Language Features, Attributes, and Conventions" documentation [1], size calculations (especially multiplication) should not be performed in memory allocator (or similar) function arguments due to the risk of them overflowing. This could lead to values wrapping around and a smaller allocation being made than the caller was expecting. Using those allocations could lead to linear overflows of heap memory and other misbehaviors. So, to avoid open-coded arithmetic in the kzalloc() call inside the create_attr_set() function the code must be refactored. Using the struct_size() helper is the fast solution but it is better to switch this code to common use of attributes. Then, remove all the custom code to manage hotkey attributes and use the attribute_group structure instead, refactoring the code accordingly. Also, to manage the optional hotkey attributes (hotkey_tablet_mode and hotkey_radio_sw) use the is_visible callback from the same structure. Moreover, now the hotkey_init_tablet_mode() function never returns a negative number. So, the check after the call can be safely removed. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Len Baker <len.baker@gmx.com> Link: https://lore.kernel.org/r/20210926111908.6950-1-len.baker@gmx.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-10 01:42:12 +0000