- 19 Oct, 2021 4 commits
-
-
Vadim Pasternak authored
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.comSigned-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Vadim Pasternak authored
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 authored
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 authored
Add new types for the Nvidia modular systems MSN4800 which could be equipped with the different types of replaceable line cards. Add new type to specify the kind of hotplug events for the line cards. The line card events are generated by the programmable device located on the main board. This device implements interrupt controller logic. Line card interrupts are associated with different line cards states during its initialization: insertion, security signature validation, power good state, security validation, hardware-firmware synchronization state, line card PHYs readiness state, firmware availability for line card ports. Also under some circumstances hardware can generate thermal shutdown for particular line card. Add new type specifying the action, which should be performed when particular hotplug event is received. This action defines in which way hotplug event should be handled by hotplug driver. There are the next actions types: - Connect I2C device with empty 'platform_data' field according to the platform topology, if device is configured (for example, power unit micro-controller driver, when power unit is connected to power source (this is what is currently supported). - Connect device with 'platform_data' field set according to the platform topology. The purpose is to pass 'platform_data' through hotplug driver to underlying device (for example line card driver). - No device is associated with hotplug event - just send "udev" event (this is what is currently supported). Extend structure 'mlxreg_hotplug_device' with hotplug action field. Extend structure 'mlxreg_core_data' with: - Registers for line card power and enabling control. - Slot number field, to indicate at which physical slot replaceable line card device is located. Signed-off-by:
-
- 11 Oct, 2021 14 commits
-
-
Shravan S authored
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.comSigned-off-by:
-
Daniel Scally authored
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: 7540599a ("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.comSigned-off-by:
-
Zephaniah E. Loss-Cutler-Hull authored
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.comSigned-off-by:
-
Sachi King authored
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.ioSigned-off-by:
-
Prashant Malani authored
The comment decribing the IPC timeout hadn't been updated when the actual timeout was changed from 3 to 5 seconds in commit a7d53dbb ("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.orgSigned-off-by:
-
Prashant Malani authored
Commit a7d53dbb ("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 authored
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: e7b7ab38 (“platform/x86: intel_scu_ipc: Sleeping is fine when polling”) Signed-off-by:
-
Hans de Goede authored
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: 8af9fa37 ("platform/x86: dell-privacy: Add support for Dell hardware privacy") Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Daniel Dadap authored
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.comSigned-off-by:
-
Daniel Dadap authored
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:
-
Vadim Pasternak authored
Fix shift argument for function rol32(). It should be provided in bits, while was provided in bytes. Fixes: 86148190 ("platform/mellanox: mlxreg-io: Add support for complex attributes") Signed-off-by:
-
Vadim Pasternak authored
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: 5ec4a8ac ("platform/mellanox: Introduce support for Mellanox register access driver") Signed-off-by: -
Mauro Carvalho Chehab authored
The ReST format requires blank lines before/after identation changes, for it to properly detect lists. Fixes: ee7abc10 ("platform/x86: intel_pmc_core: export platform global reset bits via etr3 sysfs file") Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/3673e1a255ad4100c933af215b60d68ba126f820.1632740376.git.mchehab+huawei@kernel.orgSigned-off-by:
-
Mauro Carvalho Chehab authored
As described at Documentation/ABI/README doesn't contain an Attribute: field. The way sysfs ABI is supposed to work is that each different attribute would have a separate file. So, the right way to map this would be like: /sys/.../dell_privacy_supported_type/mic_mute /sys/.../dell_privacy_supported_type/camera_shutter /sys/.../dell_privacy_current_state/mic_mute /sys/.../dell_privacy_current_state/camera_shutter However, it seems to late to fix that, as this was merged already on Kernel 5.13, and a change right now would be a regression. So, instead, let's at least fix the entry to match the expected format. While here, fix the format of the contact, which is not a valid e-mail URL. This should also fix the current warnings produced when building the docs: Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi:35: WARNING: Unexpected indentation. Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi:2: WARNING: Unexpected indentation. Fixes: 8af9fa37 ("platform/x86: dell-privacy: Add support for Dell hardware privacy") Signed-off-by:
-
- 28 Sep, 2021 6 commits
-
-
Len Baker authored
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-argumentsSuggested-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.comReviewed-by:
-
Kelly Anderson authored
Adding support specifically for Ideapad 5 Pro 16ACH6-82L5 by adding a allow list that can validate notebooks for which dytc_version is less than 5, and seem to work fine at dytc_version 4. This code has been tested to work properly on the specified system. Signed-off-by:
Kelly Anderson <kelly@xilka.com> Link: https://lore.kernel.org/r/11840239.O9o76ZdvQC@comer.internalReviewed-by:
-
Mark Gross authored
Signed-off-by: Mark Gross<markgross@kernel.org> Link: https://lore.kernel.org/r/20210921135358.85143-1-markgross@kernel.orgSigned-off-by:
-
Sanket Goswami authored
Add a message to print the resume time information obtained from the smu_metrics structure. Signed-off-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by:
Sanket Goswami <Sanket.Goswami@amd.com> Link: https://lore.kernel.org/r/20210921120020.19454-1-Sanket.Goswami@amd.comReviewed-by:
-
Sanket Goswami authored
It was reported that the resume stats received from the firmware are always zero. This happens because the SMU expects the driver to send the command to dump the log data after clearing the OS_HINT. Adjust the order of the commands sent to SMU. Signed-off-by:
-
Hans de Goede authored
The amd_pmc_get_smu_version() and amd_pmc_idlemask_read() functions are used in the probe / suspend/resume code, so they are also used when CONFIG_DEBUGFS is disabled, move them outside of the #ifdef CONFIG_DEBUGFS block. Note this purely moves the code to above the #ifdef CONFIG_DEBUGFS, the code is completely unchanged. Fixes: f6045de1 ("platform/x86: amd-pmc: Export Idlemask values based on the APU") Cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Cc: Sanket Goswami <Sanket.Goswami@amd.com> Reported-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
- 21 Sep, 2021 5 commits
-
-
Troy Rollo authored
Adds support for: - Dell Inspiron 2in1 tablet mode switch notifications. These are delivered by a type 0x0011 message with code 0xe070, followed by a flag (1 for laptop mode, 0 for tablet mode). - Recognising (but not otherwise processing) the Dell Ultra Performance mode request switch. This is delivered by a type 0x0012 message with code 0x000d, followed by a parameter that is either 1 or 2. It is not clear what (if anything) should be done with this notification, so it is ignored. Signed-off-by:
Troy Rollo <linux2021@troy.rollo.name> Link: https://lore.kernel.org/r/20210918073131.2966942-1-linux2021@troy.rollo.nameReviewed-by:
-
Tobias Jakobi authored
Tested with a AMD Ryzen 7 5800X. Signed-off-by:
Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Acked-by:
Thomas Weißschuh <thomas@weissschuh.net> Link: https://lore.kernel.org/r/20210921100702.3838-1-tjakobi@math.uni-bielefeld.deSigned-off-by:
-
José Expósito authored
Some devices, even non convertible ones, can send incorrect SW_TABLET_MODE reports. Add an allow list and accept such reports only from devices in it. Bug reported for Dell XPS 17 9710 on: https://gitlab.freedesktop.org/libinput/libinput/-/issues/662Reported-by:
Tobias Gurtzick <magic@wizardtales.com> Suggested-by:
José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20210920160312.9787-1-jose.exposito89@gmail.com [hdegoede@redhat.com: Check dmi_switches_auto_add_allow_list only once] Signed-off-by:
-
Randy Dunlap authored
When DELL_WMI=y, DELL_WMI_PRIVACY=y, and LEDS_TRIGGER_AUDIO=m, there is a linker error since the LEDS trigger code is built as a loadable module. This happens because DELL_WMI_PRIVACY is a bool that depends on a tristate (LEDS_TRIGGER_AUDIO=m), which can be dangerous. ld: drivers/platform/x86/dell/dell-wmi-privacy.o: in function `dell_privacy_wmi_probe': dell-wmi-privacy.c:(.text+0x3df): undefined reference to `ledtrig_audio_get' Fixes: 8af9fa37 ("platform/x86: dell-privacy: Add support for Dell hardware privacy") Signed-off-by:
-
Krzysztof Kozlowski authored
The MODULE_DEVICE_TABLE already creates proper alias for ACPI driver. Having another MODULE_ALIAS causes the alias to be duplicated. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210916170054.136790-1-krzysztof.kozlowski@canonical.comReviewed-by:
-
- 16 Sep, 2021 3 commits
-
-
Sanket Goswami authored
IdleMask is the metric used by the PM firmware to know the status of each of the Hardware IP blocks monitored by the PM firmware. Knowing this value is key to get the information of s2idle suspend/resume status. This value is mapped to PMC scratch registers, retrieve them accordingly based on the CPU family and the underlying firmware support. Co-developed-by:
-
Sanket Goswami authored
As the PM firmware returns the status of the last s0i3 in the smu_metrics structure, the existing name "s0i3_cyclecount" seems to be a misnomer. Change it accordingly to "s0i3_last_entry_status". Signed-off-by:
-
K Naduvalath, Sumesh authored
This driver is for accessing the PSE (Programmable Service Engine) - an Embedded Controller like IP - using ISHTP (Integratd Sensor Hub Transport Protocol) to get battery, thermal and UCSI (USB Type-C Connector System Software Interface) related data from the platform. Signed-off-by:
K Naduvalath, Sumesh <sumesh.k.naduvalath@intel.com> Reviewed-by:
Mark Gross <mgross@linux.intel.com> Link: https://lore.kernel.org/r/20210913051056.28736-1-sumesh.k.naduvalath@intel.comReviewed-by:
-
- 14 Sep, 2021 8 commits
-
-
Jules Irenge authored
checkpatch.pl tool warns about using __attribute__((packed)) "WARNING: __packed is preferred over __attribute__((packed))" To fix this __attribute__((packed)) is replaced by __packed Signed-off-by:
Jules Irenge <jbi.octave@gmail.com> Link: https://lore.kernel.org/r/20210912011741.30495-1-jbi.octave@gmail.comReviewed-by:
-
Barnabás Pőcze authored
Make `find_guid()` return an acpi_status, and make it handle NULL pointer GUID strings; and adapt users accordingly. Signed-off-by:
Barnabás Pőcze <pobrn@protonmail.com> Link: https://lore.kernel.org/r/20210904175450.156801-31-pobrn@protonmail.comReviewed-by:
-
Barnabás Pőcze authored
Previously, `acpi_wmi_notify_handler()` and `wmi_get_event_data()` shared more or less the exact same code to query the data for a particular event. Introduce a function to get rid of the duplication, and use it from `acpi_wmi_notify_handler()` and `wmi_get_event_data()`. Signed-off-by:
-
Barnabás Pőcze authored
Introduce helper function to determine the appropriate ACPI type for the input parameter. This also fixes the following checkpatch warning: "braces {} are not necessary for any arm of this statement". Signed-off-by: -
Barnabás Pőcze authored
Instead of "manually" constructing the ACPI method name and hard-coding sizes in WMI functions, introduce a helper method which generates the method name for an arbitrary WMI block. Furthermore, save the appropriate buffer size into a macro. Signed-off-by:
-
Barnabás Pőcze authored
Introduce a helper function which wraps the appropriate `container_of()` macro invocation to convert a `struct device_driver` to `struct wmi_driver`. Signed-off-by:
-
Barnabás Pőcze authored
The current code carries out the following ACPI status mapping: AE_NOT_FOUND -> AE_OK AE_OK -> AE_OK AE_$X -> AE_$X That is, everything is mapped to itself, except AE_NOT_FOUND. The current code does not do it in the most straighforward way. Simplify the logic. Signed-off-by:
-
Barnabás Pőcze authored
Previously, `__query_block()` would fail if the second WCxx method call failed. However, the WQxx method might have succeeded, and potentially allocated memory for the result. Instead of throwing away the result and potentially leaking memory, ignore the result of the second WCxx call. Signed-off-by:
-
