- 03 Feb, 2023 6 commits
-
-
Srinivas Pandruvada authored
Due to some recent kernel changes, reading cpufreq attributes like scaling_max_freq on offline CPUs returns error. So avoid reading cpufreq attributes on offline CPUs. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Zhang Rui authored
strlen() and strtok() takes null-termimated strings as input. Make sure these strings are null-terminated before using them. Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
Zhang Rui authored
Remove the duplicate dup() invocation. Signed-off-by:
-
Zhang Rui authored
Add handling for open() failure case to make sure a valid file descriptor is passed to dup(). Signed-off-by:
-
Zhang Rui authored
variable 'non_block' is always 0, thus remove the variable and the handling for "non_block != 0" case. Signed-off-by:
-
Zhang Rui authored
struct isst_id *id is a pointer, comparing it with less than zero is wrong. The check is there to make sure the id->pkg and id->die is set to -1, when it is illegal or unavailable. Here comparing with MAX_PACKAGE_COUNT and MAX_DIE_PER_PACKAGE is sufficient. Hence remove the wrong check. Signed-off-by:
-
- 02 Feb, 2023 18 commits
-
-
Rishit Bansal authored
Follow up from https://lore.kernel.org/all/20230120221214.24426-1-rishitbansal0@gmail.com/ There is a "Win-Lock" key on HP Omen Laptops which supports enabling and disabling the Windows key, which trigger commands 0x21a4 and 0x121a4 respectively. Currently the hp-wmi driver throws warnings for this event. These can be ignored using KE_IGNORE as the functionality is handled by the keyboard firmware itself. Signed-off-by:
Rishit Bansal <rishitbansal0@gmail.com> Link: https://lore.kernel.org/r/20230123214150.62597-1-rishitbansal0@gmail.comReviewed-by:
-
Hans de Goede authored
The apple_gmux code no longer uses any symbols from the ACPI_VIDEO code, so that dependency can be dropped. Signed-off-by:
-
Andy Shevchenko authored
The acpi_evaluate_dsm_typed() provides a way to check the type of the object evaluated by _DSM call. Use it instead of open coded variant. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230119180904.78446-1-andriy.shevchenko@linux.intel.comReviewed-by:
-
Andy Shevchenko authored
The acpi_evaluate_dsm_typed() provides a way to check the type of the object evaluated by _DSM call. Use it instead of open coded variant. Signed-off-by:
Rajneesh Bhardwaj <irenic.rajneesh@gmail.com> Link: https://lore.kernel.org/r/20230118095440.41634-1-andriy.shevchenko@linux.intel.comReviewed-by:
-
Andy Shevchenko authored
The acpi_evaluate_dsm_typed() provides a way to check the type of the object evaluated by _DSM call. Use it instead of open coded variant. Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20230118093823.39679-1-andriy.shevchenko@linux.intel.comReviewed-by:
-
Maximilian Luz authored
We currently have a struct ssam_request_sync and a function ssam_request_sync(). While this is valid C, there are some downsides to it. One of these is that current Sphinx versions (>= 3.0) cannot disambiguate between the two (see disucssion and pull request linked below). It instead emits a "WARNING: Duplicate C declaration" and links for the struct and function in the resulting documentation link to the same entry (i.e. both to either function or struct documentation) instead of their respective own entries. While we could just ignore that and wait for a fix, there's also a point to be made that the current naming can be somewhat confusing when searching (e.g. via grep) or trying to understand the levels of abstraction at play: We currently have struct ssam_request_sync and associated functions ssam_request_sync_[alloc|free|init|wait|...]() operating on this struct. However, function ssam_request_sync() is one abstraction level above this. Similarly, ssam_request_sync_with_buffer() is not a function operating on struct ssam_request_sync, but rather a sibling to ssam_request_sync(), both using the struct under the hood. Therefore, rename the top level request functions: ssam_request_sync() -> ssam_request_do_sync() ssam_request_sync_with_buffer() -> ssam_request_do_sync_with_buffer() ssam_request_sync_onstack() -> ssam_request_do_sync_onstack() Link: https://lore.kernel.org/all/085e0ada65c11da9303d07e70c510dc45f21315b.1656756450.git.mchehab@kernel.org/ Link: https://github.com/sphinx-doc/sphinx/pull/8313Signed-off-by:
-
Maximilian Luz authored
The target ID of the base hub is currently set to KIP (keyboard/ peripherals). However, even though it manages such devices with the KIP target ID, the base hub itself is actually accessed via the SAM target ID. So set it accordingly. Note that the target ID of the hub can be chosen arbitrarily and does not directly correspond to any physical or virtual component of the EC. This change is only a code improvement intended for consistency and clarity, it does not fix an actual bug. Signed-off-by:
-
Maximilian Luz authored
Similar to the target category (TC), the target ID (TID) can be one value out of a small number of choices, given in enum ssam_ssh_tid. In the device ID macros, SSAM_SDEV() and SSAM_VDEV() we already use text expansion to, both, remove some textual clutter for the target category values and enforce that the value belongs to the known set. Now that we know the names for the target IDs, use the same trick for them as well. Also rename the SSAM_ANY_x macros to SSAM_SSH_x_ANY to better fit in. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20221202223327.690880-9-luzmaximilian@gmail.comReviewed-by:
-
Maximilian Luz authored
Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by:
-
Maximilian Luz authored
Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by:
-
Maximilian Luz authored
Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by:
-
Maximilian Luz authored
Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by:
-
Maximilian Luz authored
Add command source and target IDs to trace events. Tracing support for the Surface Aggregator driver was originally implemented at a time when only two peers were known: Host and SAM. We now know that there are at least five, with three actively being used (Host, SAM, KIP; four with Debug if you want to count manually enabling that interface). So it makes sense to also explicitly name the peers involved when tracing. Signed-off-by:
-
Maximilian Luz authored
The `tid_in` and `tid_out` fields of the serial hub protocol command struct (struct ssh_command) are actually source and target IDs, indicating the peer from which the message originated and the peer for which it is intended. Change the naming of those fields accordingly and improve the protocol documentation. Additionally, introduce an enum containing all currently known peers, i.e. targets and sources. Signed-off-by:
-
Uwe Kleine-König authored
A remove callback just returning 0 is equivalent to no remove callback at all. So drop the useless function. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20221213162359.651529-4-u.kleine-koenig@pengutronix.deReviewed-by:
-
Uwe Kleine-König authored
A remove callback just returning 0 is equivalent to no remove callback at all. So drop the useless function. Signed-off-by:
-
Uwe Kleine-König authored
A remove callback just returning 0 is equivalent to no remove callback at all. So drop the useless function. Signed-off-by:
Peter Kaestle <peter@piie.net> Link: https://lore.kernel.org/r/20221213162359.651529-2-u.kleine-koenig@pengutronix.deReviewed-by:
-
Hans de Goede authored
Add a DMI match for the CWI501 version of the Chuwi Vi8 tablet, pointing to the same chuwi_vi8_data as the existing CWI506 version DMI match. Signed-off-by:
-
- 30 Jan, 2023 8 commits
-
-
Hans de Goede authored
Reading the thinklight LED brightnes while the LED is on returns 255 (LED_FULL) but we advertise a max_brightness of 1, so this should be 1 (LED_ON). Fixes: db5e2a4c ("platform/x86: thinkpad_acpi: Fix max_brightness of thinklight") Signed-off-by:
-
Arnd Bergmann authored
Using the serio subsystem now requires the code to be reachable: x86_64-linux-ld: drivers/platform/x86/amd/pmc.o: in function `amd_pmc_suspend_handler': pmc.c:(.text+0x86c): undefined reference to `serio_bus' Add the usual dependency: as other users of serio use 'select' rather than 'depends on', use the same here. Fixes: 8e60615e ("platform/x86/amd: pmc: Disable IRQ1 wakeup for RN/CZN") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230127093950.2368575-1-arnd@kernel.orgReviewed-by:
-
Hans de Goede authored
As soon as the first handler or sysfs file is registered the mutex may get used. Move the initialization to before any handler registration / sysfs file creation. Likewise move the destruction of the mutex to after all the de-initialization is done. Fixes: da5ce22d ("platform/x86/amd/pmf: Add support for PMF core layer") Signed-off-by:
-
Shyam Sundar S K authored
Every power mode of static power slider has its own AC and DC power settings. When the power source changes from AC to DC, corresponding DC thermals were not updated from PMF config store and this leads the system to always run on AC power settings. Fix it by registering with power_supply notifier and apply DC settings upon getting notified by the power_supply handler. Fixes: da5ce22d ("platform/x86/amd/pmf: Add support for PMF core layer") Suggested-by:
Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230125095936.3292883-6-Shyam-sundar.S-k@amd.comReviewed-by:
-
Shyam Sundar S K authored
By design PMF static slider will be set to BALANCED during init, but updating to corresponding thermal values from the PMF config store was missed, leading to improper settings getting propagated to PMFW. Fixes: 4c71ae41 ("platform/x86/amd/pmf: Add support SPS PMF feature") Suggested-by:
-
Shyam Sundar S K authored
Auto-mode thermal limits should be updated only after receiving the AMT event. But due to a bug in the older commit, these settings were getting applied during the auto-mode init. Fix this by removing amd_pmf_set_automode() during auto-mode initialization. Fixes: 3f5571d9 ("platform/x86/amd/pmf: Add support for Auto mode feature") Suggested-by:
-
Shyam Sundar S K authored
Add helper routine to check if the current platform profile is balanced mode and remove duplicate code occurrences. Signed-off-by:
-
Shyam Sundar S K authored
Add helper routine to update the static slider information and remove the duplicate code occurrences after this change. Signed-off-by:
-
- 25 Jan, 2023 1 commit
-
-
Mark Pearson authored
My last commit to fix profile mode displays on AMD platforms caused an issue on Intel platforms - sorry! In it I was reading the current functional mode (MMC, PSC, AMT) from the BIOS but didn't account for the fact that on some of our Intel platforms I use a different API which returns just the profile and not the functional mode. This commit fixes it so that on Intel platforms it knows the functional mode is always MMC. I also fixed a potential problem that a platform may try to set the mode for both MMC and PSC - which was incorrect. Tested on X1 Carbon 9 (Intel) and Z13 (AMD). Link: https://bugzilla.kernel.org/show_bug.cgi?id=216963 Fixes: fde5f74c ("platform/x86: thinkpad_acpi: Fix profile mode display in AMT mode") Cc: stable@vger.kernel.org Reviewed-by:
Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://lore.kernel.org/r/20230124153623.145188-1-mpearson-lenovo@squebb.caReviewed-by:
-
- 24 Jan, 2023 7 commits
-
-
Hans de Goede authored
Some apple laptop models have an ACPI device with a HID of APP000B and that device has an IO resource (so it does not describe the new unsupported MMIO based gmux type), but there actually is no gmux in the laptop at all. The gmux_probe() function of the actual apple-gmux driver has code to detect this, this code has been factored out into a new apple_gmux_detect() helper in apple-gmux.h. Use this new function to fix acpi_video_get_backlight_type() wrongly returning apple_gmux as type on the following laptops: MacBookPro5,4 https://pastebin.com/8Xjq7RhS MacBookPro8,1 https://linux-hardware.org/?probe=e513cfbadb&log=dmesg MacBookPro9,2 https://bugzilla.kernel.org/attachment.cgi?id=278961 MacBookPro10,2 https://lkml.org/lkml/2014/9/22/657 MacBookPro11,2 https://forums.fedora-fr.org/viewtopic.php?id=70142 MacBookPro11,4 https://raw.githubusercontent.com/im-0/investigate-card-reader-suspend-problem-on-mbp11.4/mast Fixes: 21245df3 ("ACPI: video: Add Apple GMUX brightness control detection") Link: https://lore.kernel.org/platform-driver-x86/20230123113750.462144-1-hdegoede@redhat.com/Reported-by:
Emmanouil Kouroupakis <kartebi@gmail.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Hans de Goede authored
Add a new (static inline) apple_gmux_detect() helper to apple-gmux.h which can be used for gmux detection instead of apple_gmux_present(). The latter is not really reliable since an ACPI device with a HID of APP000B is present on some devices without a gmux at all, as well as on devices with a newer (unsupported) MMIO based gmux model. This causes apple_gmux_present() to return false-positives on a number of different Apple laptop models. This new helper uses the same probing as the actual apple-gmux driver, so that it does not return false positives. To avoid code duplication the gmux_probe() function of the actual driver is also moved over to using the new apple_gmux_detect() helper. This avoids false positives (vs _HID + IO region detection) on: MacBookPro5,4 https://pastebin.com/8Xjq7RhS MacBookPro8,1 https://linux-hardware.org/?probe=e513cfbadb&log=dmesg MacBookPro9,2 https://bugzilla.kernel.org/attachment.cgi?id=278961 MacBookPro10,2 https://lkml.org/lkml/2014/9/22/657 MacBookPro11,2 https://forums.fedora-fr.org/viewtopic.php?id=70142 MacBookPro11,4 https://raw.githubusercontent.com/im-0/investigate-card-reader-suspend-problem-on-mbp11.4/master/test-16/dmesg Fixes: 21245df3 ("ACPI: video: Add Apple GMUX brightness control detection") Link: https://lore.kernel.org/platform-driver-x86/20230123113750.462144-1-hdegoede@redhat.com/Reported-by:
-
Hans de Goede authored
This is a preparation patch for adding a new static inline apple_gmux_detect() helper which actually checks a supported gmux is present, rather then only checking an ACPI device with the HID is there as apple_gmux_present() does. Fixes: 21245df3 ("ACPI: video: Add Apple GMUX brightness control detection") Link: https://lore.kernel.org/platform-driver-x86/20230123113750.462144-1-hdegoede@redhat.com/Reported-by:
-
Hans de Goede authored
Fix the following compiler warning: drivers/platform/x86/hp/hp-wmi.c:551:24: warning: cast to smaller integer type 'enum hp_wmi_radio' from 'void *' [-Wvoid-pointer-to-enum-cast] Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Mario Limonciello authored
Some users may want to live with the bugs that exist in platform firmware and have workarounds in AMD PMC driver. To allow them to bypass these workarounds, introduce a module parameter. Signed-off-by:
-
Mario Limonciello authored
By default when the system is configured for low power idle in the FADT the keyboard is set up as a wake source. This matches the behavior that Windows uses for Modern Standby as well. It has been reported that a variety of AMD based designs there are spurious wakeups are happening where two IRQ sources are active. For example: ``` PM: Triggering wakeup from IRQ 9 PM: Triggering wakeup from IRQ 1 ``` In these designs IRQ 9 is the ACPI SCI and IRQ 1 is the keyboard. One way to trigger this problem is to suspend the laptop and then unplug the AC adapter. The SOC will be in a hardware sleep state and plugging in the AC adapter returns control to the kernel's s2idle loop. Normally if just IRQ 9 was active the s2idle loop would advance any EC transactions and no other IRQ being active would cause the s2idle loop to put the SOC back into hardware sleep state. When this bug occurred IRQ 1 is also active even if no keyboard activity occurred. This causes the s2idle loop to break and the system to wake. This is a platform firmware bug triggering IRQ1 without keyboard activity. This occurs in Windows as well, but Windows will enter "SW DRIPS" and then with no activity enters back into "HW DRIPS" (hardware sleep state). This issue affects Renoir, Lucienne, Cezanne, and Barcelo platforms. It does not happen on newer systems such as Mendocino or Rembrandt. It's been fixed in newer platform firmware. To avoid triggering the bug on older systems check the SMU F/W version and adjust the policy at suspend time for s2idle wakeup from keyboard on these systems. A lot of thought and experimentation has been given around the timing of disabling IRQ1, and to make it work the "suspend" PM callback is restored. Reported-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Reported-by:
Xaver Hugl <xaver.hugl@gmail.com> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2115 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1951Signed-off-by:
-
Hans de Goede authored
Commit 1ea0d3b4 ("platform/x86: asus-wmi: Simplify tablet-mode-switch handling") unified the asus-wmi tablet-switch handling, but it did not take into account that the value returned for the kbd_dock_devid WMI method is inverted where as the other ones are not inverted. This causes asus-wmi to report an inverted tablet-switch state for devices which use the kbd_dock_devid, which causes libinput to ignore touchpad events while the affected T10x model 2-in-1s are docked. Add inverting of the return value in the kbd_dock_devid case to fix this. Fixes: 1ea0d3b4 ("platform/x86: asus-wmi: Simplify tablet-mode-switch handling") Signed-off-by:
-
