summaryrefslogtreecommitdiff
path: root/drivers/platform
AgeCommit message (Collapse)AuthorFilesLines
2023-10-25platform/x86: wmi: Decouple WMI device removal from wmi_block_listArmin Wolf1-15/+14
Use device_for_each_child_reverse() to find and unregister WMI devices belonging to a WMI bus device instead of iterating thru the entire wmi_block_list. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231020211005.38216-6-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-25platform/x86: wmi: Fix opening of char deviceArmin Wolf1-14/+6
Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via file private data"), the miscdevice stores a pointer to itself inside filp->private_data, which means that private_data will not be NULL when wmi_char_open() is called. This might cause memory corruption should wmi_char_open() be unable to find its driver, something which can happen when the associated WMI device is deleted in wmi_free_devices(). Fix the problem by using the miscdevice pointer to retrieve the WMI device data associated with a char device using container_of(). This also avoids wmi_char_open() picking a wrong WMI device bound to a driver with the same name as the original driver. Fixes: 44b6b7661132 ("platform/x86: wmi: create userspace interface for drivers") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231020211005.38216-5-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-25platform/x86: wmi: Fix probe failure when failing to register WMI devicesArmin Wolf1-8/+8
When a WMI device besides the first one somehow fails to register, retval is returned while still containing a negative error code. This causes the ACPI device fail to probe, leaving behind zombie WMI devices leading to various errors later. Handle the single error path separately and return 0 unconditionally after trying to register all WMI devices to solve the issue. Also continue to register WMI devices even if some fail to allocate memory. Fixes: 6ee50aaa9a20 ("platform/x86: wmi: Instantiate all devices before adding them") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231020211005.38216-4-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-25platform/x86: wmi: Fix refcounting of WMI devices in legacy functionsArmin Wolf1-60/+107
Until now, legacy GUID-based functions where using find_guid() when searching for WMI devices, which did no refcounting on the returned WMI device. This meant that the WMI device could disappear at any moment, potentially leading to various errors. Fix this by using bus_find_device() which returns an actual reference to the found WMI device. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231020211005.38216-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-25platform/x86: wmi: Decouple probe deferring from wmi_block_listArmin Wolf1-13/+26
Many aggregate WMI drivers do not use -EPROBE_DEFER when they cannot find a WMI device during probe, instead they require all WMI devices associated with an platform device to become available at once. This is currently achieved by adding those WMI devices to the wmi_block_list before they are registered, which is then used by the deprecated GUID-based functions to search for WMI devices. Replace this approach with a device link which defers probing of the WMI device until the associated platform device has finished probing (and has registered all WMI devices). New aggregate WMI drivers should not rely on this behaviour. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231020211005.38216-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-25platform/x86/amd/hsmp: Fix iomem handlingArmin Wolf1-1/+1
Since the metrics table is marked as io memory, use memcpy_fromio() when copying its contents. Compile-tested only. Fixes: 5150542b8ec5 ("platform/x86/amd/hsmp: add support for metrics tbl") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231019135122.21774-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-25platform/x86: asus-wmi: Do not report brightness up/down keys when also ↵Hans de Goede1-0/+16
reported by acpi_video For a long time now the acpi_video driver reports evdev brightness up/down key events for the brightness hotkeys on most (non ancient) laptops. asus-wmi also reports evdev brightness up/down key events for these keys leading to each press being reported twice and e.g. GNOME increasing the brightness by 2 steps instead of 1 step. Use the acpi_video_handles_brightness_key_presses() helper to detect if acpi_video is reporting brightness key-presses and if it is then don't report the same events also from the asus-wmi driver. Note there is a chance that this may lead to regressions where the brightness hotkeys stop working because they are not actually reported by the acpi_video driver. Unfortunately the only way to find out if this is a problem is to try. To at least avoid regressions on old hw using the eeepc-wmi driver, implement this as a key filter in asus-nb-wmi so that the eeepc-wmi driver is not affected. Reported-by: James John <me@donjajo.com> Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231021094841.7419-1-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-24x86/microcode/intel: Rework intel_find_matching_signature()Thomas Gleixner1-1/+1
Take a cpu_signature argument and work from there. Move the match() helper next to the callsite as there is no point for having it in a header. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231002115902.797820205@linutronix.de
2023-10-24x86/microcode/intel: Rework intel_cpu_collect_info()Thomas Gleixner1-5/+3
Nothing needs struct ucode_cpu_info. Make it take struct cpu_signature, let it return a boolean and simplify the implementation. Rename it now that the silly name clash with collect_cpu_info() is gone. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231017211722.851573238@linutronix.de
2023-10-23platform/x86: thinkpad_acpi: replace deprecated strncpy with memcpyJustin Stitt1-2/+5
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous interfaces. We expect ec_fw_string to be NUL-terminated based on its use with format strings in thinkpad_acpi.c: 11241 | pr_notice("ThinkPad firmware release %s doesn't match the known patterns\n", 11242 | ec_fw_string); Moreover, NUL-padding is not required since ec_fw_string is explicitly zero-initialized: 11185 | char ec_fw_string[18] = {0}; When carefully copying bytes from one buffer to another in pre-determined blocks (like what's happening here with dmi_data): | static void find_new_ec_fwstr(const struct dmi_header *dm, void *private) | { | char *ec_fw_string = (char *) private; | const char *dmi_data = (const char *)dm; | /* | * ThinkPad Embedded Controller Program Table on newer models | * | * Offset | Name | Width | Description | * ---------------------------------------------------- | * 0x00 | Type | BYTE | 0x8C | * 0x01 | Length | BYTE | | * 0x02 | Handle | WORD | Varies | * 0x04 | Signature | BYTEx6 | ASCII for "LENOVO" | * 0x0A | OEM struct offset | BYTE | 0x0B | * 0x0B | OEM struct number | BYTE | 0x07, for this structure | * 0x0C | OEM struct revision | BYTE | 0x01, for this format | * 0x0D | ECP version ID | STR ID | | * 0x0E | ECP release date | STR ID | | */ | | /* Return if data structure not match */ | if (dm->type != 140 || dm->length < 0x0F || | memcmp(dmi_data + 4, "LENOVO", 6) != 0 || | dmi_data[0x0A] != 0x0B || dmi_data[0x0B] != 0x07 || | dmi_data[0x0C] != 0x01) | return; | | /* fwstr is the first 8byte string */ | strncpy(ec_fw_string, dmi_data + 0x0F, 8); ... we shouldn't be using a C string api. Let's instead use memcpy() as this more properly relays the intended behavior. Do note that ec_fw_string will still end up being NUL-terminated since we are memcpy'ing only 8 bytes into a buffer full of 18 zeroes. There's still some trailing NUL-bytes there. To ensure this behavior, let's add a BUILD_BUG_ON checking the length leaves space for at least one trailing NUL-byte. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20231020-strncpy-drivers-platform-x86-thinkpad_acpi-c-v1-1-312f2e33034f@google.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-18platform/mellanox: mlxbf-tmfifo: Fix a warning messageLiming Sun1-10/+11
This commit fixes the smatch static checker warning in function mlxbf_tmfifo_rxtx_word() which complains data not initialized at line 634 when IS_VRING_DROP() is TRUE. Signed-off-by: Liming Sun <limings@nvidia.com> Link: https://lore.kernel.org/r/20231012230235.219861-1-limings@nvidia.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-10-18apple-gmux: Hard Code max brightness for MMIO gmuxOrlando Chamberlain1-1/+13
The data in the max brightness port for iMacs with MMIO gmux incorrectly reports 0x03ff, but it should be 0xffff. As all other MMIO gmux models have 0xffff, hard code this for all MMIO gmux's so they all have the proper brightness range accessible. Fixes: 0c18184de990 ("platform/x86: apple-gmux: support MMIO gmux on T2 Macs") Reported-by: Karsten Leipold <poldi@dfn.de> Signed-off-by: Orlando Chamberlain <orlandoch.dev@gmail.com> Link: https://lore.kernel.org/r/20231017111444.19304-2-orlandoch.dev@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-10-18platform/surface: platform_profile: Propagate error if profile registration ↵Armin Wolf1-2/+1
fails If platform_profile_register() fails, the driver does not propagate the error, but instead probes successfully. This means when the driver unbinds, the a warning might be issued by platform_profile_remove(). Fix this by propagating the error back to the caller of surface_platform_profile_probe(). Compile-tested only. Fixes: b78b4982d763 ("platform/surface: Add platform profile driver") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> Tested-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20231014235449.288702-1-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-10-18x86: convert to new timestamp accessorsJeff Layton1-1/+1
Convert to using the new inode timestamp accessor functions. Signed-off-by: Jeff Layton <jlayton@kernel.org> Link: https://lore.kernel.org/r/20231004185347.80880-8-jlayton@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-10-18platform/x86: asus-wmi: Map 0x2a code, Ignore 0x2b and 0x2c eventsHans de Goede1-0/+3
Newer Asus laptops send the following new WMI event codes when some of the F1 - F12 "media" hotkeys are pressed: 0x2a Screen Capture 0x2b PrintScreen 0x2c CapsLock Map 0x2a to KEY_SELECTIVE_SCREENSHOT mirroring how similar hotkeys are mapped on other laptops. PrintScreem and CapsLock are also reported as normal PS/2 keyboard events, map these event codes to KE_IGNORE to avoid "Unknown key code 0x%x\n" log messages. Reported-by: James John <me@donjajo.com> Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/ Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231017090725.38163-4-hdegoede@redhat.com
2023-10-18platform/x86: asus-wmi: Only map brightness codes when using asus-wmi ↵Hans de Goede1-11/+4
backlight control Older Asus laptops change the backlight level themselves and then send WMI events with different codes for different backlight levels. The asus-wmi.c code maps the entire range of codes reported on brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code: define NOTIFY_BRNUP_MIN 0x11 define NOTIFY_BRNUP_MAX 0x1f define NOTIFY_BRNDOWN_MIN 0x20 define NOTIFY_BRNDOWN_MAX 0x2e if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX) code = ASUS_WMI_BRN_UP; else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX) code = ASUS_WMI_BRN_DOWN; This mapping is causing issues on new laptop models which actually send 0x2b events for printscreen presses and 0x2c events for capslock presses, which get translated into spurious brightness-down presses. This mapping is really only necessary when asus-wmi has registered a backlight-device for backlight control. In this case the mapping was used to decide to filter out the keypresss since in this case the firmware has already modified the brightness itself and instead of reporting a keypress asus-wmi will just report the new brightness value to userspace. OTOH when the firmware does not adjust the brightness itself then it seems to always report 0x2e for brightness-down presses and 0x2f for brightness up presses independent of the actual brightness level. So in this case the mapping of the code is not necessary and this translation actually leads to spurious brightness-down presses being send to userspace when pressing printscreen or capslock. Modify asus_wmi_handle_event_code() to only do the mapping when using asus-wmi backlight control to fix the spurious brightness-down presses. Reported-by: James John <me@donjajo.com> Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/ Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231017090725.38163-3-hdegoede@redhat.com
2023-10-18platform/x86: asus-wmi: Change ASUS_WMI_BRN_DOWN code from 0x20 to 0x2eHans de Goede1-1/+1
Older Asus laptops change the backlight level themselves and then send WMI events with different codes for different backlight levels. The asus-wmi.c code maps the entire range of codes reported on brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code: define NOTIFY_BRNUP_MIN 0x11 define NOTIFY_BRNUP_MAX 0x1f define NOTIFY_BRNDOWN_MIN 0x20 define NOTIFY_BRNDOWN_MAX 0x2e if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX) code = ASUS_WMI_BRN_UP; else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX) code = ASUS_WMI_BRN_DOWN; Before this commit all the NOTIFY_BRNDOWN_MIN - NOTIFY_BRNDOWN_MAX aka 0x20 - 0x2e events were mapped to 0x20. This mapping is causing issues on new laptop models which actually send 0x2b events for printscreen presses and 0x2c events for capslock presses, which get translated into spurious brightness-down presses. The plan is disable the 0x11-0x2e special mapping on laptops where asus-wmi does not register a backlight-device to avoid the spurious brightness-down keypresses. New laptops always send 0x2e for brightness-down presses, change the special internal ASUS_WMI_BRN_DOWN value from 0x20 to 0x2e to match this in preparation for fixing the spurious brightness-down presses. This change does not have any functional impact since all of 0x20 - 0x2e is mapped to ASUS_WMI_BRN_DOWN first and only then checked against the keymap code and the new 0x2e value is still in the 0x20 - 0x2e range. Reported-by: James John <me@donjajo.com> Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/ Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231017090725.38163-2-hdegoede@redhat.com
2023-10-17platform/x86: acer-wmi: Remove void function returnEdson Juliano Drosdeck1-2/+0
Adhere to Linux kernel coding style. Reported by checkpatch: WARNING: void function return statements are not generally useful Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com> Link: https://lore.kernel.org/r/20231016182910.3344-1-edson.drosdeck@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-16Merge 6.6-rc6 into usb-nextGreg Kroah-Hartman6-18/+94
We need the USB and Thunderbolt fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-12platform/x86/amd/pmc: Add dump_custom_stb module parameterShyam Sundar S K1-0/+32
There have been instances when the default size (1M) of the STB is not sufficient to get the complete traces of the failure. In such scenarios we can use a module_param to enable full trace that shall contain more debugging data. This is not a regular case and hence not enabling this capability by default. With this change, there will be two cases on how the driver fetches the stb data: 1) A special case (proposed now) - which is required only for certain platforms. Here, a new module param will be supplied to the driver that will have a special PMFW supporting enhanced dram sizes for getting the stb data. Without the special PMFW support, just setting the module param will not help to get the enhanced stb data. To adapt to this change, we will have a new amd_pmc_stb_handle_efr() to handle enhanced firmware reporting mechanism. Note that, since num_samples based r/w pointer offset calculation is not required for enhanced firmware reporting we will have this mailbox command sent only in case of regular STB cases. 2) Current code branch which fetches the stb data based on the parameters like the num_samples, fsize and the r/w pointer. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Co-developed-by: Harsh Jain <Harsh.Jain@amd.com> Signed-off-by: Harsh Jain <Harsh.Jain@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20231010145003.139932-3-Shyam-sundar.S-k@amd.com [ij: Renamed flex_arr -> stb_data_arr] Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-12platform/x86/amd/pmc: Handle overflow cases where the num_samples range is ↵Shyam Sundar S K1-6/+13
higher In amd_pmc_stb_debugfs_open_v2(), the stb buffer is created based on the num_samples and the read/write pointer offset. This holds good when the num_samples reported by PMFW is less than S2D_TELEMETRY_BYTES_MAX; where the stb buffer gets filled from 0th position until S2D_TELEMETRY_BYTES_MAX - 1 based on the read/write pointer offset. But when the num_samples exceeds the S2D_TELEMETRY_BYTES_MAX, the current code does not handle it well as it does not account for the cases where the stb buffer has to filled up as a circular buffer. Handle this scenario into two cases, where first memcpy will have the samples from location: (num_samples % S2D_TELEMETRY_BYTES_MAX) - (S2D_TELEMETRY_BYTES_MAX - 1) and next memcpy will have the newest ones i.e. 0 - (num_samples % S2D_TELEMETRY_BYTES_MAX - 1) Suggested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20231010145003.139932-2-Shyam-sundar.S-k@amd.com [ij: renamed flex_arr -> stb_data_arr] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-12platform/x86/amd/pmc: Use flex array when calling amd_pmc_stb_debugfs_open_v2()Shyam Sundar S K1-13/+19
Currently in amd_pmc_stb_debugfs_open_v2() the buffer size is assumed to be fixed and a second call to amd_pmc_stb_debugfs_open_v2() may race with a process holding open another fd. This could change "fsize" to a bigger size causing an out of bounds read. Instead create a struct with a flexarray to solve this. Suggested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20231010145003.139932-1-Shyam-sundar.S-k@amd.com [ij: renamed flex_arr -> stb_data_arr] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-12platform/x86: asus-wireless: Replace open coded acpi_match_acpi_device()Andy Shevchenko1-8/+4
Replace open coded acpi_match_acpi_device() in asus_wireless_add(). Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231010134019.3892062-1-andriy.shevchenko@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-12platform/x86: xo15-ebook: Replace open coded acpi_match_acpi_device()Andy Shevchenko1-4/+5
Replace open coded acpi_match_acpi_device() in ebook_switch_add(). Note, while it is a bit longer it is more robust in case more IDs will be added. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231010133936.3891996-1-andriy.shevchenko@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-12platform/x86/amd/hsmp: improve the error logSuma Hegde1-3/+3
1. Change print message during platform init to a more meaningful clear message. 2. Return the error code returned by hsmp_test() itself, rather then returning a common EOPNOTSUPP error. Signed-off-by: Suma Hegde <suma.hegde@amd.com> Reviewed-by: Naveen Krishna Chatradhi <nchatrad@amd.com> Link: https://lore.kernel.org/r/20231010120310.3464066-3-suma.hegde@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-12platform/x86/amd/hsmp: add support for metrics tblSuma Hegde1-2/+172
AMD MI300 MCM provides GET_METRICS_TABLE message to retrieve all the system management information from SMU. The metrics table is made available as hexadecimal sysfs binary file under per socket sysfs directory created at /sys/devices/platform/amd_hsmp/socket%d/metrics_bin Metrics table definitions will be documented as part of Public PPR. The same is defined in the amd_hsmp.h header. Signed-off-by: Suma Hegde <suma.hegde@amd.com> Reviewed-by: Naveen Krishna Chatradhi <nchatrad@amd.com> Link: https://lore.kernel.org/r/20231010120310.3464066-2-suma.hegde@amd.com [ij: lseek -> lseek(), dram -> DRAM in dev_err()] [ij: added period to terminate a documentation sentence] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-12platform/x86/amd/hsmp: create plat specific structSuma Hegde1-23/+38
Having a separate platform device structure helps in future, to contain platform specific variables and other data. Also, define macros for dev nodes Signed-off-by: Suma Hegde <suma.hegde@amd.com> Reviewed-by: Naveen Krishna Chatradhi <nchatrad@amd.com> Link: https://lore.kernel.org/r/20231010120310.3464066-1-suma.hegde@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-11platform/x86: msi-ec: Fix the 3rd configNikita Kravets1-2/+1
Fix the charge control address of CONF3 and remove an incorrect firmware version which turned out to be a BIOS firmware and not an EC firmware. Fixes: 392cacf2aa10 ("platform/x86: Add new msi-ec driver") Cc: Aakash Singh <mail@singhaakash.dev> Cc: Jose Angel Pastrana <japp0005@red.ujaen.es> Signed-off-by: Nikita Kravets <teackot@gmail.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20231006175352.1753017-5-teackot@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-10-11platform/x86: intel-uncore-freq: Conditionally create attribute for read ↵Srinivas Pandruvada1-2/+6
frequency When the current uncore frequency can't be read, don't create attribute "current_freq_khz" as any read will fail later. Some user space applications like turbostat fail to continue with the failure. So, check error during attribute creation. Fixes: 414eef27283a ("platform/x86/intel/uncore-freq: Display uncore current frequency") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20231004181915.1887913-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-10-11Merge tag 'platform-drivers-x86-mellanox-init-v6.6' into fixesHans de Goede1-2/+3
Fixes in the mellanox init branch due for v6.6. platform-drivers-x86-mellanox-init-v6.6: v6.6-rc1 + fixes in the platform-drivers-x86-mellanox-init branch to avoid a feature conflict during the v6.7 merge window.
2023-10-09platform/x86: msi-ec: Add more EC configsNikita Kravets1-0/+467
This patch adds configurations for new EC firmware from the downstream version of the driver. Cc: Aakash Singh <mail@singhaakash.dev> Cc: Jose Angel Pastrana <japp0005@red.ujaen.es> Signed-off-by: Nikita Kravets <teackot@gmail.com> Link: https://lore.kernel.org/r/20231006175352.1753017-9-teackot@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-09Merge tag 'platform-drivers-x86-ib-int3472-v6.7' of ↵Bartosz Golaszewski4-94/+94
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 into gpio/for-next Immutable branch between pdx86 int3472 branch and GPIO due for the v6.7 merge window. platform-drivers-x86-ib-int3472-v6.7: v6.6-rc1 + platform-drivers-x86-int3472 for merging into the GPIO subsystem for v6.7.
2023-10-09platform/x86: msi-ec: rename fn_super_swapNikita Kravets2-10/+10
This patch renames fn_super_swap to fn_win_swap for consistency with the downstream version of the driver. Renaming the field to fn_super_swap in the downstream driver would require modifying several branches that are yet to be merged into the main branch, so I decided to do it here instead. Cc: Aakash Singh <mail@singhaakash.dev> Cc: Jose Angel Pastrana <japp0005@red.ujaen.es> Signed-off-by: Nikita Kravets <teackot@gmail.com> Link: https://lore.kernel.org/r/20231006175352.1753017-7-teackot@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06Merge branch 'pdx86/platform-drivers-x86-mellanox-init' into review-ilpoIlpo Järvinen1-14/+15
2023-10-06platform: mellanox: Fix misspelling error in routine nameVadim Pasternak1-4/+4
Change mlxplat_i2c_main_complition_notify() to mlxplat_i2c_main_completion_notify(). Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20231005075616.42777-3-vadimp@nvidia.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform: mellanox: Rename some init()/exit() functions for consistent namingVadim Pasternak1-9/+9
Currently some names of init()/exit() pairing function are not consistent. Rename pair mlxplat_pre_init()/mlxplat_post_exit() to respectively mlxplat_logicdev_init()/mlxplat_logicdev_exit(). Rename pair mlxplat_post_init()/mlxplat_pre_exit() to respectively mlxplat_platdevs_init()/mlxplat_platdevs_exit(). Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20231005075616.42777-4-vadimp@nvidia.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform: mellanox: Fix a resource leak in an error handling path in probing ↵Vadim Pasternak1-2/+3
flow Fix missed resource deallocation in rollback flows. Currently if an error occurs after a successful mlxplat_i2c_main_init(), mlxplat_i2c_main_exit() call is missed in rollback flow. Thus, some resources are not de-allocated. Move mlxplat_pre_exit() call from mlxplat_remove() into mlxplat_i2c_main_exit(). Call mlxplat_i2c_main_exit() instead of calling mlxplat_pre_exit() in mlxplat_probe() error handling flow. Unregister 'priv->pdev_i2c' device in mlxplat_i2c_main_init() cleanup flow if this device was successfully registered. Fixes: 158cd8320776 ("platform: mellanox: Split logic in init and exit flow") Reported-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Closes: https://lore.kernel.org/lkml/70165032-796e-6f5c-6748-f514e3b9d08c@linux.intel.com/T/ Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20231005075616.42777-2-vadimp@nvidia.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86: hp-wmi:: Mark driver struct with __refdata to prevent section ↵Uwe Kleine-König1-1/+7
mismatch warning As described in the added code comment, a reference to .exit.text is ok for drivers registered via module_platform_driver_probe(). Make this explicit to prevent a section mismatch warning: WARNING: modpost: drivers/platform/x86/hp/hp-wmi: section mismatch in reference: hp_wmi_driver+0x8 (section: .data) -> hp_wmi_bios_remove (section: .exit.text) Fixes: c165b80cfecc ("hp-wmi: fix handling of platform device") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231004111624.2667753-1-u.kleine-koenig@pengutronix.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-10-06Merge branch 'pdx86/platform-drivers-x86-int3472' into review-ilpoIlpo Järvinen4-94/+94
2023-10-06platform/x86: int3472: Switch to devm_get_gpiod()Hans de Goede3-26/+6
Switch to devm_get_gpiod() for discrete GPIOs for clks / regulators / LEDs and let devm do the cleanup for us. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20231004162317.163488-5-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86: int3472: Stop using gpiod_toggle_active_low()Hans de Goede4-59/+41
Use the new skl_int3472_gpiod_get_from_temp_lookup() helper to get a gpio to pass to register_gpio_clock(), skl_int3472_register_regulator() and skl_int3472_register_pled(). This removes all use of the deprecated gpiod_toggle_active_low() and acpi_get_and_request_gpiod() functions. Suggested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20231004162317.163488-4-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86: int3472: Add new skl_int3472_gpiod_get_from_temp_lookup() helperBartosz Golaszewski1-0/+26
Add a new skl_int3472_gpiod_get_from_temp_lookup() helper. This is a preparation patch for removing usage of the deprecated gpiod_toggle_active_low() and acpi_get_and_request_gpiod() functions. [hdegoede@redhat.com] use the new skl_int3472_fill_gpiod_lookup() helper Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Co-developed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231004162317.163488-3-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86: int3472: Add new skl_int3472_fill_gpiod_lookup() helperHans de Goede1-10/+22
Add a new skl_int3472_fill_gpiod_lookup() helper. This is a preparation patch for removing usage of the deprecated gpiod_toggle_active_low() and acpi_get_and_request_gpiod() functions. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20231004162317.163488-2-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86/intel/ifs: ARRAY BIST for Sierra ForestJithu Joseph3-8/+51
Array BIST MSR addresses, bit definition and semantics are different for Sierra Forest. Branch into a separate Array BIST flow on Sierra Forest when user invokes Array Test. Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Tested-by: Pengfei Xu <pengfei.xu@intel.com> Link: https://lore.kernel.org/r/20231005195137.3117166-10-jithu.joseph@intel.com [ij: ARRAY_GEN_* -> ARRAY_GEN* for consistency] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86/intel/ifs: Add new error codeJithu Joseph1-0/+6
Make driver aware of a newly added error code so that it can provide a more appropriate error message. Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Tested-by: Pengfei Xu <pengfei.xu@intel.com> Link: https://lore.kernel.org/r/20231005195137.3117166-9-jithu.joseph@intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86/intel/ifs: Add new CPU supportJithu Joseph1-0/+3
Add Granite Rapids(GNR) and Sierra Forest(SRF) cpuids to x86 match table so that IFS driver can be loaded for those. Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Tested-by: Pengfei Xu <pengfei.xu@intel.com> Link: https://lore.kernel.org/r/20231005195137.3117166-8-jithu.joseph@intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86/intel/ifs: Metadata validation for start_chunkJithu Joseph1-0/+7
Add an additional check to validate IFS image metadata field prior to loading the test image. If start_chunk is not a multiple of chunks_per_stride error out. Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Tested-by: Pengfei Xu <pengfei.xu@intel.com> Link: https://lore.kernel.org/r/20231005195137.3117166-7-jithu.joseph@intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86/intel/ifs: Validate image sizeJithu Joseph1-0/+8
Perform additional validation prior to loading IFS image. Error out if the size of the file being loaded doesn't match the size specified in the header. Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Tested-by: Pengfei Xu <pengfei.xu@intel.com> Link: https://lore.kernel.org/r/20231005195137.3117166-6-jithu.joseph@intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86/intel/ifs: Gen2 Scan test supportJithu Joseph2-13/+44
Width of chunk related bitfields is ACTIVATE_SCAN and SCAN_STATUS MSRs are different in newer IFS generation compared to gen0. Make changes to scan test flow such that MSRs are populated appropriately based on the generation supported by hardware. Account for the 8/16 bit MSR bitfield width differences between gen0 and newer generations for the scan test trace event too. Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Tested-by: Pengfei Xu <pengfei.xu@intel.com> Link: https://lore.kernel.org/r/20231005195137.3117166-5-jithu.joseph@intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06platform/x86/intel/ifs: Gen2 scan image loadingJithu Joseph2-2/+137
Scan image loading flow for newer IFS generations are slightly different from that of current generation. In newer schemes, loading need not be done once for each socket as was done in gen0. Also the width of NUM_CHUNKS bitfield in SCAN_HASHES_STATUS MSR has increased from 8 -> 16 bits. Similarly there are width differences for CHUNK_AUTHENTICATION_STATUS too. Further the parameter to AUTHENTICATE_AND_COPY_CHUNK is passed differently in newer generations. Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Tested-by: Pengfei Xu <pengfei.xu@intel.com> Link: https://lore.kernel.org/r/20231005195137.3117166-4-jithu.joseph@intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>