- 28 Oct, 2021 1 commit
-
-
Maximilian Luz authored
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.comReviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 27 Oct, 2021 8 commits
-
-
Vadim Pasternak authored
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.comSigned-off-by:
-
Vadim Pasternak authored
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 authored
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:
-
Mario Limonciello authored
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.comReviewed-by:
-
Mario Limonciello authored
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 authored
This is already checked when calling rtc_read_alarm. Suggested-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Mario Limonciello authored
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:
-
Mario Limonciello authored
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:
-
- 24 Oct, 2021 2 commits
-
-
Arnd Bergmann authored
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: 0de30fc6 ("platform/x86: system76_acpi: Replace Fn+F2 function for OLED models") Fixes: 95563d45 ("platform/x86: system76_acpi: Report temperature and fan speed") Fixes: 76f7eba3 ("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.orgReviewed-by:
-
Peter Korsgaard authored
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.comSigned-off-by:
-
- 22 Oct, 2021 6 commits
-
-
Ye Guojin authored
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.cnReviewed-by:
-
Ye Guojin authored
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:
-
Jonathan Corbet authored
The use of a Sphinx list within this ABI file caused the following warning: Documentation/ABI/stable/sysfs-driver-mlxreg-io:230: WARNING: Unexpected indentation. Documentation/ABI/stable/sysfs-driver-mlxreg-io:230: WARNING: Block quote ends without a blank line; unexpected unindent. Remove the bullets to make the warning go away and get proper formatting. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Mikalai Ramanovich authored
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.comReviewed-by:
-
Maximilian Luz authored
Until now we have only ever seen HID devices with target ID 2. The new Surface Laptop Studio however uses HID devices with target ID 1. Allow matching this driver to those as well. Cc: stable@vger.kernel.org # 5.14+ Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211021130904.862610-4-luzmaximilian@gmail.comReviewed-by:
-
Maximilian Luz authored
Until now, we have only ever seen the REG-category registry being used on devices addressed with target ID 2. In fact, we have only ever seen Surface Aggregator Module (SAM) HID devices with target ID 2. For those devices, the registry also has to be addressed with target ID 2. Some devices, like the new Surface Laptop Studio, however, address their HID devices on target ID 1. As a result of this, any target ID 2 commands time out. This includes event management commands addressed to the target ID 2 REG-category registry. For these devices, the registry has to be addressed via target ID 1 instead. We therefore assume that the target ID of the registry to be used depends on the target ID of the respective device. Implement this accordingly. Note that we currently allow the surface HID driver to only load against devices with target ID 2, so these timeouts are not happening (yet). This is just a preparation step before we allow the driver to load against all target IDs. Cc: stable@vger.kernel.org # 5.14+ Signed-off-by:
-
- 21 Oct, 2021 4 commits
-
-
Maximilian Luz authored
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 authored
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:
-
Mario Limonciello authored
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 authored
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:
-
- 20 Oct, 2021 1 commit
-
-
Santosh Kumar Yadav authored
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.comReviewed-by:
-
- 19 Oct, 2021 18 commits
-
-
Hans de Goede authored
Use the new soc_intel_is_cht() helper to find out if we are running on a CHT device rather then checking the ACPI _HRV field. This is more reliable (some CHT devices have been found where the _HRV for the PMIC is 2 rather then 3) and leads to a nice cleanup. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Hans de Goede authored
Use the new soc_intel_is_byt()/_cht() helpers to clean things up a bit. Reviewed-by:
-
Hans de Goede authored
The soc_intel_is_foo() helpers from sound/soc/intel/common/soc-intel-quirks.h are useful outside of the sound subsystem too. Move these to include/linux/platform_data/x86/soc.h, so that other code can use them too. Suggested-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Nathan Chancellor authored
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: fe98a52c ("ACPI: thinkpad-acpi: add sysfs support to fan subdriver") Link: https://github.com/ClangBuiltLinux/linux/issues/1476Reported-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.orgReviewed-by:
-
Ye Guojin authored
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:
-
Qing Wang authored
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.comReviewed-by:
-
Rafael J. Wysocki authored
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@kreacherReviewed-by:
-
Rafael J. Wysocki authored
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 authored
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:
-
Tim Crawford authored
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.comReviewed-by:
-
Tim Crawford authored
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: -
Jeremy Soller authored
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:
-
Jeremy Soller authored
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:
-
Vadim Pasternak authored
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:
Michael <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20211002093609.3771576-1-vadimp@nvidia.comSigned-off-by:
-
Vadim Pasternak authored
Add documentation for the new attributes for line cards: - CPLDs versioning. - Write protection control for 'nvram' devices. - Line card reset reasons. - Enabling burning of FPGA and CPLDs. - Enabling burning of FPGA and gearbox SPI flashes, - Enabling power of whole line card. - Enabling power of QSFP ports equipped on line card. - The maximum powered required for line card feeding. - Line card configuration Id. Signed-off-by:
-
Vadim Pasternak authored
Add documentation for the new attributes: - "bios_active_image"; "bios_auth_fail"; "bios_upgrade_fail"; "bios_safe_mode" to represent various BIOS statuses. - "lc{n}_enable" - for put/release the line card to/from enable state. - "lc{n}_pwr" - for power on/off the line card. - "lc{n}_rst_mask" - for line card reset state enforced by ASIC, when it sets it due to some abnormal ASIC behavior. - "psu3_on"; "psu4_on" - for connection/disconnection power supply unit to/from the power source. - "pm_mgmt_en" - for setting power management control ownership. When power management control is provided by hardware, it means that hardware will automatically power off one or more line cards in case system power budget is under power required for feeding all powered on line cards. It could be a case, when some of power units lost power good state. - "shutdown_unlock" - for unlocking system after hardware or firmware thermal shutdown, which causes locking of the all interfaces to ASIC. Signed-off-by: -
Vadim Pasternak authored
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 authored
Extend structure 'mlxreg_core_data' with the field "secured". The purpose of this field is to restrict access to some attributes, if kernel is configured with security options, like: LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY. Access to some attributes, which for example, allow burning of some hardware components, like FPGA, CPLD, SPI, etcetera can break the system. In case user does not want to allow such access, it can disable it by setting security options. Signed-off-by:
-
