JIRA: https://issues.redhat.com/browse/RHEL-68176
CVE: CVE-2024-53072
commit bceec87a73804bb4c33b9a6c96e2d27cd893a801
Author: Corey Hickey <bugfood-c@fatooh.org>
Date: Mon Oct 28 11:02:41 2024 -0700
platform/x86/amd/pmc: Detect when STB is not available
Loading the amd_pmc module as:
amd_pmc enable_stb=1
...can result in the following messages in the kernel ring buffer:
amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff
ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff
WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340
Further debugging reveals that this occurs when the requests for
S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0,
indicating that the STB is inaccessible. To prevent the ioremap
warning and provide clarity to the user, handle the invalid address
and display an error message.
Link: https://lore.kernel.org/platform-driver-x86/c588ff5d-3e04-4549-9a86-284b9b4419ba@amd.com
Fixes: 3d7d407dfb05 ("platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature")
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: Corey Hickey <bugfood-c@fatooh.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20241028180241.1341624-1-bugfood-ml@fatooh.org
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit 236f7d8034ff401d02fa6d74bae494a2b54e1834
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Thu Dec 28 15:51:04 2023 +0530
platform/x86/amd/pmc: Modify SMU message port for latest AMD platform
The latest platforms use a different SMU message port(0x938) from the one
currently being used (0x538). Make code changes to adapt to this new
information.
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20231228102104.1785383-7-Shyam-sundar.S-k@amd.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit d33e992ec87a7a7b1839fac38573d2c0721569f9
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Thu Dec 28 15:51:03 2023 +0530
platform/x86/amd/pmc: Add 1Ah family series to STB support list
AMD newer platforms, (AMDI000A or family 1Ah series) also supports the STB
functionality. Add this to amd_pmc_is_stb_supported().
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20231228102104.1785383-6-Shyam-sundar.S-k@amd.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit 9ae57d88609d2077a8340d316fc9849a601844f9
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Thu Dec 28 15:51:02 2023 +0530
platform/x86/amd/pmc: Add idlemask support for 1Ah family
Idlemask is an indication of each IP block current state (i.e. whether it
is running or idle) during s2idle transistion. The newer 1Ah family
supports this feature, add it to the support list.
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20231228102104.1785383-5-Shyam-sundar.S-k@amd.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit 13313c135266ed62d33f43281fb22289865064fd
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Thu Dec 28 15:51:01 2023 +0530
platform/x86/amd/pmc: call amd_pmc_get_ip_info() during driver probe
In the current code, amd_pmc_get_ip_info() is being called from
amd_pmc_s2d_init() and that code block gets enabled only when the STB is
being enabled.
But the information from amd_pmc_get_ip_info() will be required outside of
STB usecase. Hence move this call into driver probe sequence.
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20231228102104.1785383-4-Shyam-sundar.S-k@amd.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit d8fb50fe6c5c3632079a1642afdd87d30e0d1bbe
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Thu Dec 28 15:51:00 2023 +0530
platform/x86/amd/pmc: Add VPE information for AMDI000A platform
Latest AMD SoCs has VPE (Video Processing Engine) IP block and the
statistics related to this IP can be obtained as a part of metrics table
information that the PMFW propogates. Add this support for 1Ah family
series.
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20231228102104.1785383-3-Shyam-sundar.S-k@amd.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit 9efa2a04ce7c827bf265c8963b38553306a8225e
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Thu Dec 28 15:50:59 2023 +0530
platform/x86/amd/pmc: Send OS_HINT command for AMDI000A platform
To initiate the HW deep state transistion the OS_HINT command has to be
sent the PMFW. Add this support to the platforms that has AMDI000A
support.
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20231228102104.1785383-2-Shyam-sundar.S-k@amd.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit a55bdad5dfd1efd4ed9ffe518897a21ca8e4e193
Author: Mario Limonciello <mario.limonciello@amd.com>
Date: Mon Dec 11 22:50:06 2023 -0600
platform/x86/amd/pmc: Disable keyboard wakeup on AMD Framework 13
The Laptop 13 (AMD Ryzen 7040Series) BIOS 03.03 has a workaround
included in the EC firmware that will cause the EC to emit a "spurious"
keypress during the resume from s0i3 [1].
This series of keypress events can be observed in the kernel log on
resume.
```
atkbd serio0: Unknown key pressed (translated set 2, code 0x6b on isa0060/serio0).
atkbd serio0: Use 'setkeycodes 6b <keycode>' to make it known.
atkbd serio0: Unknown key released (translated set 2, code 0x6b on isa0060/serio0).
atkbd serio0: Use 'setkeycodes 6b <keycode>' to make it known.
```
In some user flows this is harmless, but if a user has specifically
suspended the laptop and then closed the lid it will cause the laptop
to wakeup. The laptop wakes up because the ACPI SCI triggers when
the lid is closed and when the kernel sees that IRQ1 is "also" active.
The kernel can't distinguish from a real keyboard keypress and wakes the
system.
Add the model into the list of quirks to disable keyboard wakeup source.
This is intentionally only matching the production BIOS version in hopes
that a newer EC firmware included in a newer BIOS can avoid this behavior.
Cc: Kieran Levin <ktl@framework.net>
Link: https://github.com/FrameworkComputer/EmbeddedController/blob/lotus-zephyr/zephyr/program/lotus/azalea/src/power_sequence.c#L313 [1]
Link: https://community.frame.work/t/amd-wont-sleep-properly/41755
Link: https://community.frame.work/t/tracking-framework-amd-ryzen-7040-series-lid-wakeup-behavior-feedback/39128
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20231212045006.97581-5-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit b614a4bd73efeddc2b20d9e6deb6c2710373802b
Author: Mario Limonciello <mario.limonciello@amd.com>
Date: Mon Dec 11 22:50:05 2023 -0600
platform/x86/amd/pmc: Move keyboard wakeup disablement detection to pmc-quirks
Other platforms may need to disable keyboard wakeup besides Cezanne,
so move the detection into amd_pmc_quirks_init() where it may be applied
to multiple platforms.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20231212045006.97581-4-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit 2d53c0ab61e62302d7b62d660fe76de2bff6bf45
Author: Mario Limonciello <mario.limonciello@amd.com>
Date: Mon Dec 11 22:50:04 2023 -0600
platform/x86/amd/pmc: Only run IRQ1 firmware version check on Cezanne
amd_pmc_wa_czn_irq1() only runs on Cezanne platforms currently but
may be extended to other platforms in the future. Rename the function
and only check platform firmware version when it's called for a Cezanne
based platform.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20231212045006.97581-3-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit 85980669a863514dd47761efd6c1bc4677a2ae08
Author: Mario Limonciello <mario.limonciello@amd.com>
Date: Mon Dec 11 22:50:03 2023 -0600
platform/x86/amd/pmc: Move platform defines to header
The platform defines will be used by the quirks in the future,
so move them to the common header to allow use by both source
files.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20231212045006.97581-2-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit c6ea14d557343cd3af6c6be2f5a78c98bdb281bb
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Thu Nov 16 22:31:21 2023 +0530
platform/x86/amd/pmc: adjust getting DRAM size behavior
amd_pmc_get_dram_size() is used to get the DRAM size information. But
in the current code, mailbox command to get the DRAM size info is sent
based on the values of dev->major and dev->minor.
But dev->major and dev->minor will have either junk or zero assigned to
them until at least once a call to amd_pmc_get_smu_version() is made
which ideally populates dev->major and dev->minor.
However, adding a amd_pmc_get_smu_version() call to
amd_pmc_get_dram_size() has a downside of elevating the boot times.
After talking to the PMFW team, it's understood that the "get dram
size" mbox command would only be supported on specific platforms (like
Mendocino) and not all. So, adjust getting DRAM size behavior such
that,
- if running on Rembrandt or Mendocino and the underlying PMFW knows
how to execute the "get dram size" command it shall give the custom
dram size.
- if the underlying FW does not report the dram size, we just proceed
further and assign the default dram size.
The simplest way to address this is to remove amd_pmc_get_dram_size()
function and directly call the "get dram size" command in the
amd_pmc_s2d_init().
Reported-by: Mark Hasemeyer <markhas@chromium.org>
Fixes: be8325fb3d8c ("platform/x86/amd: pmc: Get STB DRAM size from PMFW")
Cc: stable@vger.kernel.org
Suggested-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/20231116170121.3372222-1-Shyam-sundar.S-k@amd.com
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit 3bde7ec13c971445faade32172cb0b4370b841d9
Author: David Lazar <dlazar@gmail.com>
Date: Wed Oct 25 21:30:16 2023 +0200
platform/x86: Add s2idle quirk for more Lenovo laptops
When suspending to idle and resuming on some Lenovo laptops using the
Mendocino APU, multiple NVME IOMMU page faults occur, showing up in
dmesg as repeated errors:
nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000b
address=0xb6674000 flags=0x0000]
The system is unstable afterwards.
Applying the s2idle quirk introduced by commit 455cd867b85b ("platform/x86:
thinkpad_acpi: Add a s2idle resume quirk for a number of laptops")
allows these systems to work with the IOMMU enabled and s2idle
resume to work.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218024
Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: David Lazar <dlazar@gmail.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://lore.kernel.org/r/ZTlsyOaFucF2pWrL@localhost
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit 3f720b21ec5af466e50e99dc517af267b67d248c
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Tue Oct 10 20:20:03 2023 +0530
platform/x86/amd/pmc: Add dump_custom_stb module parameter
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>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit b136225746a9793bdff9c78b215eac4f64bf21f2
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Tue Oct 10 20:20:02 2023 +0530
platform/x86/amd/pmc: Handle overflow cases where the num_samples range is 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>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit d9f421da6b9287000f8253628d54cf89b0c14da5
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Tue Oct 10 20:20:01 2023 +0530
platform/x86/amd/pmc: Use flex array when calling amd_pmc_stb_debugfs_open_v2()
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>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit cdb1013808bed0c0c392b44ed4eed6c7743028c3
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Sun Sep 10 19:50:33 2023 +0530
platform/x86/amd/pmc: Add PMFW command id to support S2D force flush
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 <Sanket.Goswami@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/20230910142034.2967110-1-Shyam-sundar.S-k@amd.com
[ij: Corrected whitespace in dev_dbg_once()]
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit 5ee473bbf43086f23eb2cd1b5a50498438e296a6
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Sat Aug 26 21:42:13 2023 +0530
platform/x86/amd/pmc: Fix build error with randconfig
on x86_64:
CONFIG_SUSPEND is not set
CONFIG_PM is not set
this leads to build failure of the AMD PMC driver. Add a 'depends on'
in the Kconfig.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Closes: https://lore.kernel.org/lkml/5181685c-29d8-22a4-a2d7-682f26e2e031@infradead.org/
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20230826161213.3180194-1-Shyam-sundar.S-k@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: David Arcari <darcari@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-24991
commit 92c2fb8fa56c46d534feea2073e55ecc61fa5089
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date: Fri Aug 11 16:51:13 2023 +0530
platform/x86/amd/pmc: Move PMC driver to separate directory
With latest commits having PMC code spread across multiple files, it would
be easier to maintain them in a separate directory under amd/pmc.
Co-developed-by: Sanket Goswami <Sanket.Goswami@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/20230811112116.2279419-2-Shyam-sundar.S-k@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: David Arcari <darcari@redhat.com>
CKI Backport Bot
David Arcari