linux.git/drivers/platform/x86/amd, branch master

Merge tag 'rtc-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux

2026-06-27T18:00:18+00:00

Pull RTC updates from Alexandre Belloni:
 "Most of the work and improvements are for features of the m41t93.

  The ds1307 also gets support for OSF (Oscillator Stop Flag) for
  new variants.

  The pcap driver is being removed as the Motorola EZX support was
  removed a while ago.

  Subsystem:
   - add rtc_read_next_alarm() to read next expiring timer

  Drivers:
   - ds1307: handle OSF for ds1337/ds1339/ds3231, add clock provider for
     ds1307, fix wday for rx8130
   - m41t93: DT support, alarm, clock provider, watchdog support
   - mv: add suspend/resume support for wakeup
   - pcap: remove driver
   - renesas-rtca3: many fixes"

* tag 'rtc-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (36 commits)
  rtc: ds1307: update reference to removed CONFIG_RTC_DRV_DS1307_HWMON
  platform/x86: amd-pmc: Fix S0i3 wakeup with alarmtimer
  rtc: s35390a: fix typo in comment
  rtc: cmos: unregister HPET IRQ handler on probe failure
  rtc: ds1307: Fix off-by-one issue with wday for rx8130
  dt-bindings: rtc: ds1307: Add epson,rx8901
  rtc: bq32000: add delay between RTC reads
  rtc: m41t93: Add watchdog support
  rtc: m41t93: Add square wave clock provider support
  rtc: m41t93: Add alarm support
  rtc: m41t93: migrate to regmap api for register access
  rtc: m41t93: add device tree support
  dt-bindings: rtc: Add ST m41t93
  rtc: ds1307: add support for clock provider in ds1307
  rtc: mv: add suspend/resume support for wakeup
  rtc: aspeed: add AST2700 compatible
  dt-bindings: rtc: add ASPEED AST2700 compatible
  rtc: interface: fix typos in rtc_handle_legacy_irq() documentation
  rtc: msc313: fix NULL deref in shared IRQ handler at probe
  rtc: remove unused pcap driver
  ...

platform/x86: amd-pmc: Fix S0i3 wakeup with alarmtimer

2026-06-25T12:42:54+00:00

It was reported that suspend-then-hibernate stopped working with modern
systemd versions on AMD Cezanne systems. The reason for this breakage
was because systemd switched to using alarmtimer instead of the wakealarm
sysfs file.

On AMD Cezanne systems, amd_pmc_verify_czn_rtc() programs a secondary
timer with the alarm time. This was introduced by
commit 59348401ebed ("platform/x86: amd-pmc: Add special handling for
timer based S0i3 wakeup"). However, this function uses rtc_read_alarm(),
which only reads the aie_timer, not the next expiring timer from the
timerqueue.

When both alarmtimer and wakealarm are active, the first expiring timer
might be the alarmtimer, but amd_pmc_verify_czn_rtc() would only see
the aie_timer, potentially missing the earlier alarm.

Switch to rtc_read_next_alarm() to read whichever timer will fire next.
Also handle -ENOENT (no alarm pending) explicitly as a non-error case.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3591
Signed-off-by: Mario Limonciello 
Acked-by: Ilpo Järvinen 
Link: https://patch.msgid.link/20260521043714.1022930-3-mario.limonciello@amd.com
Signed-off-by: Alexandre Belloni

platform/x86/amd/hsmp: Clamp ioctl/send_message indices (Spectre v1)

2026-06-12T12:24:04+00:00

Although validate_message() checks msg_id, a mispredicted branch can
still allow speculative indexing into hsmp_msg_desc_table[]. Clamp
msg.msg_id with array_index_nospec() at entry to hsmp_ioctl_msg() so
downstream dereferences (including via is_get_msg() and
hsmp_send_message()) see a bounded index.

Similarly, hsmp_send_message() bounds-checks msg->sock_ind before
indexing hsmp_pdev.sock[], but a mispredicted branch can still
speculatively use the raw index (Spectre v1, CVE-2017-5753). Apply
array_index_nospec() after the check so every caller that reaches
hsmp_pdev.sock[] through this helper sees a clamped socket
index—including hsmp_ioctl_msg() and any other path that hands a
user-derived struct hsmp_message to hsmp_send_message().

Reviewed-by: Muthusamy Ramalingam 
Signed-off-by: Muralidhara M K 
Link: https://patch.msgid.link/20260612042610.1629037-7-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen

platform/x86/amd/pmc: Don't log during intermediate wakeups

2026-06-11T16:53:57+00:00

The ECs in the IdeaPads that need the delay_suspend quirk send lots
of messages when charging, which not only causes intermediate wakeups
when suspended, but also prevents the device from reaching the deepest
suspend state.

Because of this amd_pmc_intermediate_wakeup_need_delay() returns false
during intermediate wakeups and amd_pmc_want_suspend_delay() is called.
So far it always logged its "Delaying suspend by 2.5s ..." messages
then, which spams dmesg. This commit makes sure that those messages are
only logged once per suspend.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221383
Reviewed-by: Hans de Goede 
Signed-off-by: Daniel Gibson 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260611150426.3683372-5-daniel@gibson.sh
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen

platform/x86/amd/pmc: Add delay_suspend module parameter

2026-06-11T16:53:56+00:00

Enabling the new delay_suspend module parameter delays suspend for
2.5 seconds which is known to help for some AMD-based Lenovo Laptops
that otherwise failed to send/receive events for key presses or the
lid switch after s2idle. Apparently the EC needs to do some things
in the background before suspend or it gets into a bad state.

There are many reports of AMD-based laptops (mostly but not exclusively
IdeaPads) about similar issues on the web; this parameter gives
affected users an easy way to try out if their issues have the same
root cause and to work around them until their specific device is added
to the quirks list.

The parameter description has a note encouraging users to report
their device so it can be added to the quirks list, inspired by a
similar request in parameter descriptions of the ideapad-laptop module.

The module parameter can be set to "1" to explicitly enable it,
"0" to disable it even on devices that are assumed to be affected,
or -1 (the default) to enable it if the device is assumed to be affected
(according to fwbug_list[])

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221383
Reviewed-by: Hans de Goede 
Signed-off-by: Daniel Gibson 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260611150426.3683372-4-daniel@gibson.sh
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen

platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops

2026-06-11T16:53:54+00:00

Some IdeaPad Slim 3 devices and similar with AMD CPUs have a
nonfunctional keyboard and lid switch after s2idle.

It helps to delay suspend by 2.5 seconds so the EC has some time
to do whatever it needs to get done before suspend - unfortunately
at least on my 16ABR8 waking it with a timer (wakealarm) still
triggers the issue, but at least normal resume via keypress or
lid works fine. On the 14ARP10 wakealarm has been reported to also
work fine with this patch.

This issue has been reported for many different devices, this patch
has been tested with the Zen3-based IdeaPad Slim 3 16ABR8 (82XR)
and the Zen3+-based IdeaPad Slim 3 14ARP10 (83K6) and IdeaPad Slim 3
15ARP10 (83MM).

Reported-by: Sindre Henriksen 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221383
Tested-by: Sindre Henriksen 
Suggested-by: Mario Limonciello (AMD) 
Reviewed-by: Mario Limonciello (AMD) 
Reviewed-by: Ilpo Järvinen 
Reviewed-by: Hans de Goede 
Signed-off-by: Daniel Gibson 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260611150426.3683372-3-daniel@gibson.sh
Signed-off-by: Ilpo Järvinen

platform/x86/amd/pmc: Check for intermediate wakeup in function

2026-06-11T16:53:51+00:00

Refactor code introduced by commit 9f5595d5f03f ("pmc: Require at
least 2.5 seconds between HW sleep cycles") to allow adding different
conditions for that delay in an upcoming change.

Signed-off-by: Daniel Gibson 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260611150426.3683372-2-daniel@gibson.sh
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen

platform/x86/amd/pmc: Add PMC driver support for AMD 1Ah M80H SoC

2026-06-10T11:14:26+00:00

The 1Ah M80H SoC uses a different set of SMU mailbox register offsets
compared to the existing 1Ah variants: message at 0xA10, argument at
0xA18, and response at 0xA14.

Add amd_1ah_m80_cpu_info with these offsets, wire it into the PCI ID
table via PCI_DEVICE_DATA(), populate scratch_reg field with
AMD_PMC_SCRATCH_REG_1AH and add the corresponding ACPI ID AMDI000C.

Reviewed-by: Mario Limonciello (AMD) 
Co-developed-by: Sanket Goswami 
Signed-off-by: Sanket Goswami 
Signed-off-by: Shyam Sundar S K 
Link: https://patch.msgid.link/20260609143952.2999707-3-Shyam-sundar.S-k@amd.com
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen

platform/x86/amd/pmc: Use per-SoC cpu_info struct for SMU mailbox and IP info

2026-06-10T11:14:24+00:00

Replace the scattered per-field assignments in amd_pmc_get_ip_info() with
a single amd_pmc_cpu_info struct capturing all SoC-specific parameters
such as SMU offsets, IP block table, and OS hint.

Define static const instances per SoC variant and embed them as driver_data
in the PCI ID table via PCI_DEVICE_DATA(). Consolidate pci_match_id() into
amd_pmc_set_cpu_info(), which assigns driver_data directly to cpu_info,
the switch falls through only for 1Ah M20H/M60H variants requiring
boot_cpu_data.x86_model detection to distinguish the M70 sub-variant.

Add scratch_reg to amd_pmc_cpu_info and populate it for each SoC
variant, allowing amd_pmc_idlemask_read() to drop its cpu_id switch
in favour of a single cpu_info->scratch_reg lookup.

Move dev->cpu_id assignment into amd_pmc_set_cpu_info() so it is valid
before the switch statement. Handle SP/SHP directly in the switch since
their NULL driver_data bypasses the early return, and remove the duplicate
check from probe.

Remove amd_pmc_get_os_hint() and use cpu_info->os_hint directly at call
sites and rename AMD_CPU_ID_* to PCI_DEVICE_ID_AMD_CPU_ID_* with backward
compatibility aliases.

Reviewed-by: Mario Limonciello (AMD) 
Co-developed-by: Sanket Goswami 
Signed-off-by: Sanket Goswami 
Signed-off-by: Shyam Sundar S K 
Link: https://patch.msgid.link/20260609143952.2999707-2-Shyam-sundar.S-k@amd.com
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen

platform/x86/amd: hfi: Support for ranking table versions

2026-05-19T10:42:04+00:00

Add changes to support new ranking table version. Version 2 of the
heterogeneous ranking table provides static CPU rankings. Version 3 adds
dynamic ranking table support on newer AMD platforms. These changes ensure
that platforms still reporting version 2 continue to function with the
existing static ranking path, avoiding regressions on older hardware
that does not supply a dynamic ranking table.

Signed-off-by: Krishnamoorthi M 
Reviewed-by: Mario Limonciello (AMD) 
Reviewed-by: Shyam Sundar S K 
Link: https://patch.msgid.link/20260507190926.1211726-1-krishnamoorthi.m@amd.com
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Ilpo Järvinen