aboutsummaryrefslogtreecommitdiff
path: root/drivers/platform
AgeCommit message (Collapse)AuthorFilesLines
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 <[email protected]> Closes: https://lore.kernel.org/platform-driver-x86/[email protected]/ Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Signed-off-by: Justin Stitt <[email protected]> Reviewed-by: Mark Pearson <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/20231020-strncpy-drivers-platform-x86-thinkpad_acpi-c-v1-1-312f2e33034f@google.com Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
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 <[email protected]> Signed-off-by: Orlando Chamberlain <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
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 <[email protected]> Reviewed-by: Maximilian Luz <[email protected]> Tested-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
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 <[email protected]> Closes: https://lore.kernel.org/platform-driver-x86/[email protected]/ Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716 Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Closes: https://lore.kernel.org/platform-driver-x86/[email protected]/ Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716 Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Closes: https://lore.kernel.org/platform-driver-x86/[email protected]/ Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716 Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]>
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 <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Co-developed-by: Harsh Jain <[email protected]> Signed-off-by: Harsh Jain <[email protected]> Signed-off-by: Sanket Goswami <[email protected]> Signed-off-by: Shyam Sundar S K <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ij: Renamed flex_arr -> stb_data_arr] Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Sanket Goswami <[email protected]> Signed-off-by: Shyam Sundar S K <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ij: renamed flex_arr -> stb_data_arr] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Sanket Goswami <[email protected]> Signed-off-by: Shyam Sundar S K <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ij: renamed flex_arr -> stb_data_arr] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Reviewed-by: Naveen Krishna Chatradhi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Reviewed-by: Naveen Krishna Chatradhi <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ij: lseek -> lseek(), dram -> DRAM in dev_err()] [ij: added period to terminate a documentation sentence] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Reviewed-by: Naveen Krishna Chatradhi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Cc: Jose Angel Pastrana <[email protected]> Signed-off-by: Nikita Kravets <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
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 <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
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 <[email protected]> Cc: Jose Angel Pastrana <[email protected]> Signed-off-by: Nikita Kravets <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Cc: Jose Angel Pastrana <[email protected]> Signed-off-by: Nikita Kravets <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Closes: https://lore.kernel.org/lkml/[email protected]/T/ Signed-off-by: Vadim Pasternak <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
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 <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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. [[email protected]] use the new skl_int3472_fill_gpiod_lookup() helper Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Co-developed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Reviewed-by: Tony Luck <[email protected]> Tested-by: Pengfei Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ij: ARRAY_GEN_* -> ARRAY_GEN* for consistency] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Tested-by: Pengfei Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Tested-by: Pengfei Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Reviewed-by: Tony Luck <[email protected]> Tested-by: Pengfei Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Tested-by: Pengfei Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Tested-by: Pengfei Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]>
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 <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Tested-by: Pengfei Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]>
2023-10-06platform/x86/intel/ifs: Refactor image loading codeJithu Joseph1-12/+19
IFS image loading flow is slightly different for newer IFS generations. In preparation for adding support for newer IFS generations, refactor portions of existing image loading code for reuse. Signed-off-by: Jithu Joseph <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Tested-by: Pengfei Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]>
2023-10-06platform/x86/intel/ifs: Store IFS generation numberJithu Joseph2-0/+5
IFS generation number is reported via MSR_INTEGRITY_CAPS. As IFS support gets added to newer CPUs, some differences are expected during IFS image loading and test flows. Define MSR bitmasks to extract and store the generation in driver data, so that driver can modify its MSR interaction appropriately. Signed-off-by: Jithu Joseph <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Tested-by: Pengfei Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]>
2023-10-06platform/x86/amd/pmc: Add PMFW command id to support S2D force flushShyam Sundar S K1-1/+8
Recent PMFW have the capability that can force flush the FIFO contents to DRAM on sending a command id via the mailbox. Add this support to the driver. Co-developed-by: Sanket Goswami <[email protected]> Signed-off-by: Sanket Goswami <[email protected]> Signed-off-by: Shyam Sundar S K <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ij: Corrected whitespace in dev_dbg_once()] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
2023-10-05platform/x86: touchscreen_dmi: Add info for the Positivo C4128BRenan Guilherme Lebre Ramos1-0/+23
Add information for the Positivo C4128B, a notebook/tablet convertible. Link: https://github.com/onitake/gsl-firmware/pull/217 Signed-off-by: Renan Guilherme Lebre Ramos <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-10-05platform/chrome: kunit: make EC protocol tests independentTzung-Bi Shih5-10/+7
Remove CONFIG_CROS_KUNIT and common code concept for ChromeOS Kunit but make it bundle to ChromeOS EC protocol tests. Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tzung-Bi Shih <[email protected]>
2023-10-05platform/chrome: kunit: initialize lock for fake ec_devTzung-Bi Shih1-0/+1
cros_ec_cmd_xfer() uses ec_dev->lock. Initialize it. Otherwise, dmesg shows the following: > DEBUG_LOCKS_WARN_ON(lock->magic != lock) > ... > Call Trace: > ? __mutex_lock > ? __warn > ? __mutex_lock > ... > ? cros_ec_cmd_xfer Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tzung-Bi Shih <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.