From: Rob Barnes robbarnes@google.com
[ Upstream commit 2cbf475a04b2ae3d722bbe41742e5d874a027fc3 ]
Create a uevent when an EC panic is detected. This will allow udev rules to trigger when a panic occurs. For example, a udev rule could be added to capture an EC coredump. This approach avoids the need to stuff all the processing into the driver.
Signed-off-by: Rob Barnes robbarnes@google.com Reviewed-by: Prashant Malani pmalani@chromium.org Signed-off-by: Tzung-Bi Shih tzungbi@kernel.org Link: https://lore.kernel.org/r/20230509232624.3120347-1-robbarnes@google.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/platform/chrome/cros_ec_lpc.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/platform/chrome/cros_ec_lpc.c b/drivers/platform/chrome/cros_ec_lpc.c index 68bba0fcafab3..2b1ce3e1abf2e 100644 --- a/drivers/platform/chrome/cros_ec_lpc.c +++ b/drivers/platform/chrome/cros_ec_lpc.c @@ -16,6 +16,7 @@ #include <linux/delay.h> #include <linux/io.h> #include <linux/interrupt.h> +#include <linux/kobject.h> #include <linux/module.h> #include <linux/platform_data/cros_ec_commands.h> #include <linux/platform_data/cros_ec_proto.h> @@ -315,6 +316,7 @@ static int cros_ec_lpc_readmem(struct cros_ec_device *ec, unsigned int offset,
static void cros_ec_lpc_acpi_notify(acpi_handle device, u32 value, void *data) { + static const char *env[] = { "ERROR=PANIC", NULL }; struct cros_ec_device *ec_dev = data; bool ec_has_more_events; int ret; @@ -324,6 +326,7 @@ static void cros_ec_lpc_acpi_notify(acpi_handle device, u32 value, void *data) if (value == ACPI_NOTIFY_CROS_EC_PANIC) { dev_emerg(ec_dev->dev, "CrOS EC Panic Reported. Shutdown is imminent!"); blocking_notifier_call_chain(&ec_dev->panic_notifier, 0, ec_dev); + kobject_uevent_env(&ec_dev->dev->kobj, KOBJ_CHANGE, (char **)env); /* Begin orderly shutdown. Force shutdown after 1 second. */ hw_protection_shutdown("CrOS EC Panic", 1000); /* Do not query for other events after a panic is reported */
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit 69d6b37695c1f2320cfa330e1e1636d50dd5040a ]
The Nextbook Ares 8A is a x86 ACPI tablet which ships with Android x86 as factory OS. Its DSDT contains a bunch of I2C devices which are not actually there (the Android x86 kernel fork ignores I2C devices described in the DSDT).
On this specific model this just not cause resource conflicts, one of the probe() calls for the non existing i2c_clients actually ends up toggling a GPIO or executing a _PS3 after a failed probe which turns the tablet off.
Add a ACPI_QUIRK_SKIP_I2C_CLIENTS for the Nextbook Ares 8 to the acpi_quirk_skip_dmi_ids table to avoid the bogus i2c_clients and to fix the tablet turning off during boot because of this.
Also add the "10EC5651" HID for the RealTek ALC5651 codec used in this tablet to the list of HIDs for which not to skipi2c_client instantiation, since the Intel SST sound driver relies on the codec being instantiated through ACPI.
Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/acpi/x86/utils.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c index 9c2d6f35f88a0..4cfee2da06756 100644 --- a/drivers/acpi/x86/utils.c +++ b/drivers/acpi/x86/utils.c @@ -365,7 +365,7 @@ static const struct dmi_system_id acpi_quirk_skip_dmi_ids[] = { ACPI_QUIRK_SKIP_ACPI_AC_AND_BATTERY), }, { - /* Nextbook Ares 8 */ + /* Nextbook Ares 8 (BYT version)*/ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "Insyde"), DMI_MATCH(DMI_PRODUCT_NAME, "M890BAP"), @@ -374,6 +374,16 @@ static const struct dmi_system_id acpi_quirk_skip_dmi_ids[] = { ACPI_QUIRK_SKIP_ACPI_AC_AND_BATTERY | ACPI_QUIRK_SKIP_GPIO_EVENT_HANDLERS), }, + { + /* Nextbook Ares 8A (CHT version)*/ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Insyde"), + DMI_MATCH(DMI_PRODUCT_NAME, "CherryTrail"), + DMI_MATCH(DMI_BIOS_VERSION, "M882"), + }, + .driver_data = (void *)(ACPI_QUIRK_SKIP_I2C_CLIENTS | + ACPI_QUIRK_SKIP_ACPI_AC_AND_BATTERY), + }, { /* Whitelabel (sold as various brands) TM800A550L */ .matches = { @@ -392,6 +402,7 @@ static const struct dmi_system_id acpi_quirk_skip_dmi_ids[] = { #if IS_ENABLED(CONFIG_X86_ANDROID_TABLETS) static const struct acpi_device_id i2c_acpi_known_good_ids[] = { { "10EC5640", 0 }, /* RealTek ALC5640 audio codec */ + { "10EC5651", 0 }, /* RealTek ALC5651 audio codec */ { "INT33F4", 0 }, /* X-Powers AXP288 PMIC */ { "INT33FD", 0 }, /* Intel Crystal Cove PMIC */ { "INT34D3", 0 }, /* Intel Whiskey Cove PMIC */
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit 4fd5556608bfa9c2bf276fc115ef04288331aded ]
The LID0 device on the Nextbook Ares 8A tablet always reports lid closed causing userspace to suspend the device as soon as booting is complete.
Add a DMI quirk to disable the broken lid functionality.
Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/acpi/button.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c index 475e1eddfa3b4..ef77c14c72a92 100644 --- a/drivers/acpi/button.c +++ b/drivers/acpi/button.c @@ -77,6 +77,15 @@ static const struct dmi_system_id dmi_lid_quirks[] = { }, .driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_DISABLED, }, + { + /* Nextbook Ares 8A tablet, _LID device always reports lid closed */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Insyde"), + DMI_MATCH(DMI_PRODUCT_NAME, "CherryTrail"), + DMI_MATCH(DMI_BIOS_VERSION, "M882"), + }, + .driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_DISABLED, + }, { /* * Lenovo Yoga 9 14ITL5, initial notification of the LID device
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit f91280f35895d6dcb53f504968fafd1da0b00397 ]
The Lenovo Yoga Book yb1-x90f/l 2-in-1 which ships with Android as Factory OS has (another) bug in its DSDT where the UART resource for the BTH0 ACPI device contains "\_SB.PCIO.URT1" as path to the UART.
Note that is with a letter 'O' instead of the number '0' which is wrong.
This causes Linux to instantiate a standard /dev/ttyS? device for the UART instead of a /sys/bus/serial device, which in turn causes bluetooth to not work.
Similar DSDT bugs have been encountered before and to work around those the acpi_quirk_skip_serdev_enumeration() helper exists.
Previous devices had the broken resource pointing to the first UART, while the BT HCI was on the second UART, which ACPI_QUIRK_UART1_TTY_UART2_SKIP deals with. Add a new ACPI_QUIRK_UART1_SKIP quirk for skipping enumeration of UART1 instead for the Yoga Book case and add this quirk to the existing DMI quirk table entry for the yb1-x90f/l .
This leaves the UART1 controller unbound allowing the x86-android-tablets module to manually instantiate a serdev for it fixing bluetooth.
Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/acpi/x86/utils.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c index 4cfee2da06756..c2b925f8cd4e4 100644 --- a/drivers/acpi/x86/utils.c +++ b/drivers/acpi/x86/utils.c @@ -259,10 +259,11 @@ bool force_storage_d3(void) * drivers/platform/x86/x86-android-tablets.c kernel module. */ #define ACPI_QUIRK_SKIP_I2C_CLIENTS BIT(0) -#define ACPI_QUIRK_UART1_TTY_UART2_SKIP BIT(1) -#define ACPI_QUIRK_SKIP_ACPI_AC_AND_BATTERY BIT(2) -#define ACPI_QUIRK_USE_ACPI_AC_AND_BATTERY BIT(3) -#define ACPI_QUIRK_SKIP_GPIO_EVENT_HANDLERS BIT(4) +#define ACPI_QUIRK_UART1_SKIP BIT(1) +#define ACPI_QUIRK_UART1_TTY_UART2_SKIP BIT(2) +#define ACPI_QUIRK_SKIP_ACPI_AC_AND_BATTERY BIT(3) +#define ACPI_QUIRK_USE_ACPI_AC_AND_BATTERY BIT(4) +#define ACPI_QUIRK_SKIP_GPIO_EVENT_HANDLERS BIT(5)
static const struct dmi_system_id acpi_quirk_skip_dmi_ids[] = { /* @@ -319,6 +320,7 @@ static const struct dmi_system_id acpi_quirk_skip_dmi_ids[] = { DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "YETI-11"), }, .driver_data = (void *)(ACPI_QUIRK_SKIP_I2C_CLIENTS | + ACPI_QUIRK_UART1_SKIP | ACPI_QUIRK_SKIP_ACPI_AC_AND_BATTERY | ACPI_QUIRK_SKIP_GPIO_EVENT_HANDLERS), }, @@ -449,6 +451,9 @@ int acpi_quirk_skip_serdev_enumeration(struct device *controller_parent, bool *s if (dmi_id) quirks = (unsigned long)dmi_id->driver_data;
+ if ((quirks & ACPI_QUIRK_UART1_SKIP) && uid == 1) + *skip = true; + if (quirks & ACPI_QUIRK_UART1_TTY_UART2_SKIP) { if (uid == 1) return -ENODEV; /* Create tty cdev instead of serdev */
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit 48436f2e9834b46b47b038b605c8142a1c07bc85 ]
Linux defaults to picking the non-working ACPI video backlight interface on the Apple iMac11,3 .
Add a DMI quirk to pick the working native radeon_bl0 interface instead.
Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/acpi/video_detect.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index bcc25d457581d..61586caebb01b 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -470,6 +470,14 @@ static const struct dmi_system_id video_detect_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "82BK"), }, }, + { + .callback = video_detect_force_native, + /* Apple iMac11,3 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "iMac11,3"), + }, + }, { /* https://bugzilla.redhat.com/show_bug.cgi?id=1217249 */ .callback = video_detect_force_native,
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit bd5d93df86a7ddf98a2a37e9c3751e3cb334a66c ]
Linux defaults to picking the non-working ACPI video backlight interface on the Lenovo ThinkPad X131e (3371 AMD version).
Add a DMI quirk to pick the working native radeon_bl0 interface instead.
Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/acpi/video_detect.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 61586caebb01b..b87783c5872dd 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -470,6 +470,14 @@ static const struct dmi_system_id video_detect_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "82BK"), }, }, + { + .callback = video_detect_force_native, + /* Lenovo ThinkPad X131e (3371 AMD version) */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "3371"), + }, + }, { .callback = video_detect_force_native, /* Apple iMac11,3 */
From: Kristina Martsenko kristina.martsenko@arm.com
[ Upstream commit b0c756fe996ac930033882ca56410639e5cad1ec ]
Detect if the system has the new HCRX_EL2 register added in ARMv8.7/9.2, so that subsequent patches can check for its presence.
KVM currently relies on the register being present on all CPUs (or none), so the kernel will panic if that is not the case. Fortunately no such systems currently exist, but this can be revisited if they appear. Note that the kernel will not panic if CONFIG_KVM is disabled.
Reviewed-by: Catalin Marinas catalin.marinas@arm.com Signed-off-by: Kristina Martsenko kristina.martsenko@arm.com Link: https://lore.kernel.org/r/20230509142235.3284028-3-kristina.martsenko@arm.co... Signed-off-by: Catalin Marinas catalin.marinas@arm.com Signed-off-by: Sasha Levin sashal@kernel.org --- arch/arm64/kernel/cpufeature.c | 8 ++++++++ arch/arm64/tools/cpucaps | 1 + 2 files changed, 9 insertions(+)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 7d7128c651614..9898ad77b1dba 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -364,6 +364,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = { static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = { ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_TIDCP1_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_AFP_SHIFT, 4, 0), + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_HCX_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_ETS_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_TWED_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_XNX_SHIFT, 4, 0), @@ -2309,6 +2310,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = { .type = ARM64_CPUCAP_SYSTEM_FEATURE, .matches = is_kvm_protected_mode, }, + { + .desc = "HCRX_EL2 register", + .capability = ARM64_HAS_HCX, + .type = ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE, + .matches = has_cpuid_feature, + ARM64_CPUID_FIELDS(ID_AA64MMFR1_EL1, HCX, IMP) + }, #endif { .desc = "Kernel page table isolation (KPTI)", diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps index 40ba95472594d..e1de10fa080e0 100644 --- a/arch/arm64/tools/cpucaps +++ b/arch/arm64/tools/cpucaps @@ -32,6 +32,7 @@ HAS_GENERIC_AUTH_IMP_DEF HAS_GIC_CPUIF_SYSREGS HAS_GIC_PRIO_MASKING HAS_GIC_PRIO_RELAXED_SYNC +HAS_HCX HAS_LDAPR HAS_LSE_ATOMICS HAS_NESTED_VIRT
On Sun, Jul 02, 2023 at 03:50:52PM -0400, Sasha Levin wrote:
From: Kristina Martsenko kristina.martsenko@arm.com
[ Upstream commit b0c756fe996ac930033882ca56410639e5cad1ec ]
Detect if the system has the new HCRX_EL2 register added in ARMv8.7/9.2, so that subsequent patches can check for its presence.
KVM currently relies on the register being present on all CPUs (or none), so the kernel will panic if that is not the case. Fortunately no such systems currently exist, but this can be revisited if they appear. Note that the kernel will not panic if CONFIG_KVM is disabled.
This is a new feature, it's not clear why we'd backport it (especially since it's a new feature which is a dependency for other features rather than something that people can use outside of the kernel)?
On Mon, Jul 03, 2023 at 12:51:57PM +0100, Mark Brown wrote:
On Sun, Jul 02, 2023 at 03:50:52PM -0400, Sasha Levin wrote:
From: Kristina Martsenko kristina.martsenko@arm.com
[ Upstream commit b0c756fe996ac930033882ca56410639e5cad1ec ]
Detect if the system has the new HCRX_EL2 register added in ARMv8.7/9.2, so that subsequent patches can check for its presence.
KVM currently relies on the register being present on all CPUs (or none), so the kernel will panic if that is not the case. Fortunately no such systems currently exist, but this can be revisited if they appear. Note that the kernel will not panic if CONFIG_KVM is disabled.
This is a new feature, it's not clear why we'd backport it (especially since it's a new feature which is a dependency for other features rather than something that people can use outside of the kernel)?
The second paragraph (above) suggested it should be.
On Sun, Jul 09, 2023 at 10:56:13AM -0400, Sasha Levin wrote:
On Mon, Jul 03, 2023 at 12:51:57PM +0100, Mark Brown wrote:
On Sun, Jul 02, 2023 at 03:50:52PM -0400, Sasha Levin wrote:
KVM currently relies on the register being present on all CPUs (or none), so the kernel will panic if that is not the case. Fortunately no such systems currently exist, but this can be revisited if they appear. Note that the kernel will not panic if CONFIG_KVM is disabled.
This is a new feature, it's not clear why we'd backport it (especially since it's a new feature which is a dependency for other features rather than something that people can use outside of the kernel)?
The second paragraph (above) suggested it should be.
That's saying that the code won't work properly on systems where some but not all of the CPUs support the feature. Note that the changelog says nothing about fixing any issue here.
On Sun, Jul 09, 2023 at 10:13:29PM +0100, Mark Brown wrote:
On Sun, Jul 09, 2023 at 10:56:13AM -0400, Sasha Levin wrote:
On Mon, Jul 03, 2023 at 12:51:57PM +0100, Mark Brown wrote:
On Sun, Jul 02, 2023 at 03:50:52PM -0400, Sasha Levin wrote:
KVM currently relies on the register being present on all CPUs (or none), so the kernel will panic if that is not the case. Fortunately no such systems currently exist, but this can be revisited if they appear. Note that the kernel will not panic if CONFIG_KVM is disabled.
This is a new feature, it's not clear why we'd backport it (especially since it's a new feature which is a dependency for other features rather than something that people can use outside of the kernel)?
The second paragraph (above) suggested it should be.
That's saying that the code won't work properly on systems where some but not all of the CPUs support the feature. Note that the changelog says nothing about fixing any issue here.
Try reading it like a GPU running an ML model:
"This is not a new feature, it's especially clear why we'd backport it."
Makes sense. *sigh*
We've been considering opting arm64 out of this for a while, but I don't think we do a great job of CC'ing stable either (I certainly forget to add it all the time and then hope that the Fixes: tag does the job),so it's not obviously going to improve things.
Maybe we just need a commit hook that yells if something with a Fixes: tag doesn't have a CC: stable on it?
Will
On Mon, Jul 10, 2023 at 10:44:38AM +0100, Will Deacon wrote:
On Sun, Jul 09, 2023 at 10:13:29PM +0100, Mark Brown wrote:
On Sun, Jul 09, 2023 at 10:56:13AM -0400, Sasha Levin wrote:
On Mon, Jul 03, 2023 at 12:51:57PM +0100, Mark Brown wrote:
On Sun, Jul 02, 2023 at 03:50:52PM -0400, Sasha Levin wrote:
KVM currently relies on the register being present on all CPUs (or none), so the kernel will panic if that is not the case. Fortunately no such systems currently exist, but this can be revisited if they appear. Note that the kernel will not panic if CONFIG_KVM is disabled.
This is a new feature, it's not clear why we'd backport it (especially since it's a new feature which is a dependency for other features rather than something that people can use outside of the kernel)?
The second paragraph (above) suggested it should be.
That's saying that the code won't work properly on systems where some but not all of the CPUs support the feature. Note that the changelog says nothing about fixing any issue here.
Try reading it like a GPU running an ML model:
"This is not a new feature, it's especially clear why we'd backport it."
Makes sense. *sigh*
We've been considering opting arm64 out of this for a while, but I don't think we do a great job of CC'ing stable either (I certainly forget to add it all the time and then hope that the Fixes: tag does the job),so it's not obviously going to improve things.
Maybe we just need a commit hook that yells if something with a Fixes: tag doesn't have a CC: stable on it?
I could start doing that, it's going to be really noisy...
greg k-h
On Mon, Jul 10, 2023 at 03:31:42PM +0200, Greg KH wrote:
On Mon, Jul 10, 2023 at 10:44:38AM +0100, Will Deacon wrote:
Maybe we just need a commit hook that yells if something with a Fixes: tag doesn't have a CC: stable on it?
I could start doing that, it's going to be really noisy...
It would need to exclude commits that are only in -next since that's a common legitimate use case for Fixes which shouldn't have a Cc to stable, and there's going to be a bunch of false positives from people who are overly enthusiastic in their use of fixes tags.
On Mon, Jul 10, 2023 at 02:47:12PM +0100, Mark Brown wrote:
On Mon, Jul 10, 2023 at 03:31:42PM +0200, Greg KH wrote:
On Mon, Jul 10, 2023 at 10:44:38AM +0100, Will Deacon wrote:
Maybe we just need a commit hook that yells if something with a Fixes: tag doesn't have a CC: stable on it?
I could start doing that, it's going to be really noisy...
It would need to exclude commits that are only in -next since that's a common legitimate use case for Fixes which shouldn't have a Cc to stable, and there's going to be a bunch of false positives from people who are overly enthusiastic in their use of fixes tags.
My scripts today already know where the original Fix tag came from, it's not hard to detect. So this should not be an issue, we don't even consider any commit with "Fixes:" in it for a kernel that has not already been released.
thanks,
greg k-h
From: Mario Limonciello mario.limonciello@amd.com
[ Upstream commit a9c4a912b7dc7ff922d4b9261160c001558f9755 ]
commit 9946e39fe8d0 ("ACPI: resource: skip IRQ override on AMD Zen platforms") attempted to overhaul the override logic so it didn't apply on X86 AMD Zen systems. This was intentional so that systems would prefer DSDT values instead of default MADT value for IRQ 1 on Ryzen 6000 systems which typically uses ActiveLow for IRQ1.
This turned out to be a bad assumption because several vendors add Interrupt Source Override but don't fix the DSDT. A pile of quirks was collecting that proved this wasn't sustaintable.
Furthermore some vendors have used ActiveHigh for IRQ1. To solve this problem revert the following commits: * commit 17bb7046e7ce ("ACPI: resource: Do IRQ override on all TongFang GMxRGxx") * commit f3cb9b740869 ("ACPI: resource: do IRQ override on Lenovo 14ALC7") * commit bfcdf58380b1 ("ACPI: resource: do IRQ override on LENOVO IdeaPad") * commit 7592b79ba4a9 ("ACPI: resource: do IRQ override on XMG Core 15") * commit 9946e39fe8d0 ("ACPI: resource: skip IRQ override on AMD Zen platforms")
Reported-by: evilsnoo@proton.me Link: https://bugzilla.kernel.org/show_bug.cgi?id=217394 Reported-by: ruinairas1992@gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=217406 Reported-by: nmschulte@gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=217336 Signed-off-by: Mario Limonciello mario.limonciello@amd.com Tested-by: Werner Sembach wse@tuxedocomputers.com Tested-by: Chuanhong Guo gch981213@gmail.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/acpi/resource.c | 60 ----------------------------------------- 1 file changed, 60 deletions(-)
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index 0800a9d775580..1dd8d5aebf678 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -470,52 +470,6 @@ static const struct dmi_system_id asus_laptop[] = { { } };
-static const struct dmi_system_id lenovo_laptop[] = { - { - .ident = "LENOVO IdeaPad Flex 5 14ALC7", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), - DMI_MATCH(DMI_PRODUCT_NAME, "82R9"), - }, - }, - { - .ident = "LENOVO IdeaPad Flex 5 16ALC7", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), - DMI_MATCH(DMI_PRODUCT_NAME, "82RA"), - }, - }, - { } -}; - -static const struct dmi_system_id tongfang_gm_rg[] = { - { - .ident = "TongFang GMxRGxx/XMG CORE 15 (M22)/TUXEDO Stellaris 15 Gen4 AMD", - .matches = { - DMI_MATCH(DMI_BOARD_NAME, "GMxRGxx"), - }, - }, - { } -}; - -static const struct dmi_system_id maingear_laptop[] = { - { - .ident = "MAINGEAR Vector Pro 2 15", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "Micro Electronics Inc"), - DMI_MATCH(DMI_PRODUCT_NAME, "MG-VCP2-15A3070T"), - } - }, - { - .ident = "MAINGEAR Vector Pro 2 17", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "Micro Electronics Inc"), - DMI_MATCH(DMI_PRODUCT_NAME, "MG-VCP2-17A3070T"), - }, - }, - { } -}; - static const struct dmi_system_id lg_laptop[] = { { .ident = "LG Electronics 17U70P", @@ -539,10 +493,6 @@ struct irq_override_cmp { static const struct irq_override_cmp override_table[] = { { medion_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, { asus_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, - { lenovo_laptop, 6, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, true }, - { lenovo_laptop, 10, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, true }, - { tongfang_gm_rg, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, - { maingear_laptop, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, { lg_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, };
@@ -562,16 +512,6 @@ static bool acpi_dev_irq_override(u32 gsi, u8 triggering, u8 polarity, return entry->override; }
-#ifdef CONFIG_X86 - /* - * IRQ override isn't needed on modern AMD Zen systems and - * this override breaks active low IRQs on AMD Ryzen 6000 and - * newer systems. Skip it. - */ - if (boot_cpu_has(X86_FEATURE_ZEN)) - return false; -#endif - return true; }
From: Youngmin Nam youngmin.nam@samsung.com
[ Upstream commit f6794950f0e5ba37e3bbedda4d6ab0aad7395dd3 ]
filter_irq_stacks() is supposed to cut entries which are related irq entries from its call stack. And in_irqentry_text() which is called by filter_irq_stacks() uses __irqentry_text_start/end symbol to find irq entries in callstack.
But it doesn't work correctly as without "CONFIG_FUNCTION_GRAPH_TRACER", arm64 kernel doesn't include gic_handle_irq which is entry point of arm64 irq between __irqentry_text_start and __irqentry_text_end as we discussed in below link. https://lore.kernel.org/all/CACT4Y+aReMGLYua2rCLHgFpS9io5cZC04Q8GLs-uNmrn1ez...
This problem can makes unintentional deep call stack entries especially in KASAN enabled situation as below.
[ 2479.383395]I[0:launcher-loader: 1719] Stack depot reached limit capacity [ 2479.383538]I[0:launcher-loader: 1719] WARNING: CPU: 0 PID: 1719 at lib/stackdepot.c:129 __stack_depot_save+0x464/0x46c [ 2479.385693]I[0:launcher-loader: 1719] pstate: 624000c5 (nZCv daIF +PAN -UAO +TCO -DIT -SSBS BTYPE=--) [ 2479.385724]I[0:launcher-loader: 1719] pc : __stack_depot_save+0x464/0x46c [ 2479.385751]I[0:launcher-loader: 1719] lr : __stack_depot_save+0x460/0x46c [ 2479.385774]I[0:launcher-loader: 1719] sp : ffffffc0080073c0 [ 2479.385793]I[0:launcher-loader: 1719] x29: ffffffc0080073e0 x28: ffffffd00b78a000 x27: 0000000000000000 [ 2479.385839]I[0:launcher-loader: 1719] x26: 000000000004d1dd x25: ffffff891474f000 x24: 00000000ca64d1dd [ 2479.385882]I[0:launcher-loader: 1719] x23: 0000000000000200 x22: 0000000000000220 x21: 0000000000000040 [ 2479.385925]I[0:launcher-loader: 1719] x20: ffffffc008007440 x19: 0000000000000000 x18: 0000000000000000 [ 2479.385969]I[0:launcher-loader: 1719] x17: 2065726568207475 x16: 000000000000005e x15: 2d2d2d2d2d2d2d20 [ 2479.386013]I[0:launcher-loader: 1719] x14: 5d39313731203a72 x13: 00000000002f6b30 x12: 00000000002f6af8 [ 2479.386057]I[0:launcher-loader: 1719] x11: 00000000ffffffff x10: ffffffb90aacf000 x9 : e8a74a6c16008800 [ 2479.386101]I[0:launcher-loader: 1719] x8 : e8a74a6c16008800 x7 : 00000000002f6b30 x6 : 00000000002f6af8 [ 2479.386145]I[0:launcher-loader: 1719] x5 : ffffffc0080070c8 x4 : ffffffd00b192380 x3 : ffffffd0092b313c [ 2479.386189]I[0:launcher-loader: 1719] x2 : 0000000000000001 x1 : 0000000000000004 x0 : 0000000000000022 [ 2479.386231]I[0:launcher-loader: 1719] Call trace: [ 2479.386248]I[0:launcher-loader: 1719] __stack_depot_save+0x464/0x46c [ 2479.386273]I[0:launcher-loader: 1719] kasan_save_stack+0x58/0x70 [ 2479.386303]I[0:launcher-loader: 1719] save_stack_info+0x34/0x138 [ 2479.386331]I[0:launcher-loader: 1719] kasan_save_free_info+0x18/0x24 [ 2479.386358]I[0:launcher-loader: 1719] ____kasan_slab_free+0x16c/0x170 [ 2479.386385]I[0:launcher-loader: 1719] __kasan_slab_free+0x10/0x20 [ 2479.386410]I[0:launcher-loader: 1719] kmem_cache_free+0x238/0x53c [ 2479.386435]I[0:launcher-loader: 1719] mempool_free_slab+0x1c/0x28 [ 2479.386460]I[0:launcher-loader: 1719] mempool_free+0x7c/0x1a0 [ 2479.386484]I[0:launcher-loader: 1719] bvec_free+0x34/0x80 [ 2479.386514]I[0:launcher-loader: 1719] bio_free+0x60/0x98 [ 2479.386540]I[0:launcher-loader: 1719] bio_put+0x50/0x21c [ 2479.386567]I[0:launcher-loader: 1719] f2fs_write_end_io+0x4ac/0x4d0 [ 2479.386594]I[0:launcher-loader: 1719] bio_endio+0x2dc/0x300 [ 2479.386622]I[0:launcher-loader: 1719] __dm_io_complete+0x324/0x37c [ 2479.386650]I[0:launcher-loader: 1719] dm_io_dec_pending+0x60/0xa4 [ 2479.386676]I[0:launcher-loader: 1719] clone_endio+0xf8/0x2f0 [ 2479.386700]I[0:launcher-loader: 1719] bio_endio+0x2dc/0x300 [ 2479.386727]I[0:launcher-loader: 1719] blk_update_request+0x258/0x63c [ 2479.386754]I[0:launcher-loader: 1719] scsi_end_request+0x50/0x304 [ 2479.386782]I[0:launcher-loader: 1719] scsi_io_completion+0x88/0x160 [ 2479.386808]I[0:launcher-loader: 1719] scsi_finish_command+0x17c/0x194 [ 2479.386833]I[0:launcher-loader: 1719] scsi_complete+0xcc/0x158 [ 2479.386859]I[0:launcher-loader: 1719] blk_mq_complete_request+0x4c/0x5c [ 2479.386885]I[0:launcher-loader: 1719] scsi_done_internal+0xf4/0x1e0 [ 2479.386910]I[0:launcher-loader: 1719] scsi_done+0x14/0x20 [ 2479.386935]I[0:launcher-loader: 1719] ufshcd_compl_one_cqe+0x578/0x71c [ 2479.386963]I[0:launcher-loader: 1719] ufshcd_mcq_poll_cqe_nolock+0xc8/0x150 [ 2479.386991]I[0:launcher-loader: 1719] ufshcd_intr+0x868/0xc0c [ 2479.387017]I[0:launcher-loader: 1719] __handle_irq_event_percpu+0xd0/0x348 [ 2479.387044]I[0:launcher-loader: 1719] handle_irq_event_percpu+0x24/0x74 [ 2479.387068]I[0:launcher-loader: 1719] handle_irq_event+0x74/0xe0 [ 2479.387091]I[0:launcher-loader: 1719] handle_fasteoi_irq+0x174/0x240 [ 2479.387118]I[0:launcher-loader: 1719] handle_irq_desc+0x7c/0x2c0 [ 2479.387147]I[0:launcher-loader: 1719] generic_handle_domain_irq+0x1c/0x28 [ 2479.387174]I[0:launcher-loader: 1719] gic_handle_irq+0x64/0x158 [ 2479.387204]I[0:launcher-loader: 1719] call_on_irq_stack+0x2c/0x54 [ 2479.387231]I[0:launcher-loader: 1719] do_interrupt_handler+0x70/0xa0 [ 2479.387258]I[0:launcher-loader: 1719] el1_interrupt+0x34/0x68 [ 2479.387283]I[0:launcher-loader: 1719] el1h_64_irq_handler+0x18/0x24 [ 2479.387308]I[0:launcher-loader: 1719] el1h_64_irq+0x68/0x6c [ 2479.387332]I[0:launcher-loader: 1719] blk_attempt_bio_merge+0x8/0x170 [ 2479.387356]I[0:launcher-loader: 1719] blk_mq_attempt_bio_merge+0x78/0x98 [ 2479.387383]I[0:launcher-loader: 1719] blk_mq_submit_bio+0x324/0xa40 [ 2479.387409]I[0:launcher-loader: 1719] __submit_bio+0x104/0x138 [ 2479.387436]I[0:launcher-loader: 1719] submit_bio_noacct_nocheck+0x1d0/0x4a0 [ 2479.387462]I[0:launcher-loader: 1719] submit_bio_noacct+0x618/0x804 [ 2479.387487]I[0:launcher-loader: 1719] submit_bio+0x164/0x180 [ 2479.387511]I[0:launcher-loader: 1719] f2fs_submit_read_bio+0xe4/0x1c4 [ 2479.387537]I[0:launcher-loader: 1719] f2fs_mpage_readpages+0x888/0xa4c [ 2479.387563]I[0:launcher-loader: 1719] f2fs_readahead+0xd4/0x19c [ 2479.387587]I[0:launcher-loader: 1719] read_pages+0xb0/0x4ac [ 2479.387614]I[0:launcher-loader: 1719] page_cache_ra_unbounded+0x238/0x288 [ 2479.387642]I[0:launcher-loader: 1719] do_page_cache_ra+0x60/0x6c [ 2479.387669]I[0:launcher-loader: 1719] page_cache_ra_order+0x318/0x364 [ 2479.387695]I[0:launcher-loader: 1719] ondemand_readahead+0x30c/0x3d8 [ 2479.387722]I[0:launcher-loader: 1719] page_cache_sync_ra+0xb4/0xc8 [ 2479.387749]I[0:launcher-loader: 1719] filemap_read+0x268/0xd24 [ 2479.387777]I[0:launcher-loader: 1719] f2fs_file_read_iter+0x1a0/0x62c [ 2479.387806]I[0:launcher-loader: 1719] vfs_read+0x258/0x34c [ 2479.387831]I[0:launcher-loader: 1719] ksys_pread64+0x8c/0xd0 [ 2479.387857]I[0:launcher-loader: 1719] __arm64_sys_pread64+0x48/0x54 [ 2479.387881]I[0:launcher-loader: 1719] invoke_syscall+0x58/0x158 [ 2479.387909]I[0:launcher-loader: 1719] el0_svc_common+0xf0/0x134 [ 2479.387935]I[0:launcher-loader: 1719] do_el0_svc+0x44/0x114 [ 2479.387961]I[0:launcher-loader: 1719] el0_svc+0x2c/0x80 [ 2479.387985]I[0:launcher-loader: 1719] el0t_64_sync_handler+0x48/0x114 [ 2479.388010]I[0:launcher-loader: 1719] el0t_64_sync+0x190/0x194 [ 2479.388038]I[0:launcher-loader: 1719] Kernel panic - not syncing: kernel: panic_on_warn set ...
So let's set __exception_irq_entry with __irq_entry as a default. Applying this patch, we can see gic_hande_irq is included in Systemp.map as below.
* Before ffffffc008010000 T __do_softirq ffffffc008010000 T __irqentry_text_end ffffffc008010000 T __irqentry_text_start ffffffc008010000 T __softirqentry_text_start ffffffc008010000 T _stext ffffffc00801066c T __softirqentry_text_end ffffffc008010670 T __entry_text_start
* After ffffffc008010000 T __irqentry_text_start ffffffc008010000 T _stext ffffffc008010000 t gic_handle_irq ffffffc00801013c t gic_handle_irq ffffffc008010294 T __irqentry_text_end ffffffc008010298 T __do_softirq ffffffc008010298 T __softirqentry_text_start ffffffc008010904 T __softirqentry_text_end ffffffc008010908 T __entry_text_start
Signed-off-by: Youngmin Nam youngmin.nam@samsung.com Signed-off-by: SEO HOYOUNG hy50.seo@samsung.com Reviewed-by: Mark Rutland mark.rutland@arm.com Link: https://lore.kernel.org/r/20230424010436.779733-1-youngmin.nam@samsung.com Signed-off-by: Catalin Marinas catalin.marinas@arm.com Signed-off-by: Sasha Levin sashal@kernel.org --- arch/arm64/include/asm/exception.h | 5 ----- 1 file changed, 5 deletions(-)
diff --git a/arch/arm64/include/asm/exception.h b/arch/arm64/include/asm/exception.h index e73af709cb7ad..88d8dfeed0db6 100644 --- a/arch/arm64/include/asm/exception.h +++ b/arch/arm64/include/asm/exception.h @@ -8,16 +8,11 @@ #define __ASM_EXCEPTION_H
#include <asm/esr.h> -#include <asm/kprobes.h> #include <asm/ptrace.h>
#include <linux/interrupt.h>
-#ifdef CONFIG_FUNCTION_GRAPH_TRACER #define __exception_irq_entry __irq_entry -#else -#define __exception_irq_entry __kprobes -#endif
static inline unsigned long disr_to_esr(u64 disr) {
From: Mark Rutland mark.rutland@arm.com
[ Upstream commit ab9b4008092c86dc12497af155a0901cc1156999 ]
Both create_mapping_noalloc() and update_mapping_prot() sanity-check their 'virt' parameter, but the check itself doesn't make much sense. The condition used today appears to be a historical accident.
The sanity-check condition:
if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }
... can only be true for the KASAN shadow region or the module region, and there's no reason to exclude these specifically for creating and updateing mappings.
When arm64 support was first upstreamed in commit:
c1cc1552616d0f35 ("arm64: MMU initialisation")
... the condition was:
if (virt < VMALLOC_START) { [ ... warning here ... ] return; }
At the time, VMALLOC_START was the lowest kernel address, and this was checking whether 'virt' would be translated via TTBR1.
Subsequently in commit:
14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
... the condition was changed to:
if ((virt >= VA_START) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }
This appear to have been a thinko. The commit moved the linear map to the bottom of the kernel address space, with VMALLOC_START being at the halfway point. The old condition would warn for changes to the linear map below this, and at the time VA_START was the end of the linear map.
Subsequently we cleaned up the naming of VA_START in commit:
77ad4ce69321abbe ("arm64: memory: rename VA_START to PAGE_END")
... keeping the erroneous condition as:
if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }
Correct the condition to check against the start of the TTBR1 address space, which is currently PAGE_OFFSET. This simplifies the logic, and more clearly matches the "outside kernel range" message in the warning.
Signed-off-by: Mark Rutland mark.rutland@arm.com Cc: Russell King linux@armlinux.org.uk Cc: Steve Capper steve.capper@arm.com Cc: Will Deacon will@kernel.org Reviewed-by: Russell King (Oracle) rmk+kernel@armlinux.org.uk Link: https://lore.kernel.org/r/20230615102628.1052103-1-mark.rutland@arm.com Signed-off-by: Catalin Marinas catalin.marinas@arm.com Signed-off-by: Sasha Levin sashal@kernel.org --- arch/arm64/mm/mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index af6bc8403ee46..72b3c21820b96 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -451,7 +451,7 @@ static phys_addr_t pgd_pgtable_alloc(int shift) void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt, phys_addr_t size, pgprot_t prot) { - if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { + if (virt < PAGE_OFFSET) { pr_warn("BUG: not creating mapping for %pa at 0x%016lx - outside kernel range\n", &phys, virt); return; @@ -478,7 +478,7 @@ void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys, static void update_mapping_prot(phys_addr_t phys, unsigned long virt, phys_addr_t size, pgprot_t prot) { - if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { + if (virt < PAGE_OFFSET) { pr_warn("BUG: not updating mapping for %pa at 0x%016lx - outside kernel range\n", &phys, virt); return;
From: Junhao He hejunhao3@huawei.com
[ Upstream commit 1a51688474c0d395b864e98236335fba712e29bf ]
Compared to the original PA device, H60PA offers higher bandwidth. The H60PA is a new device and we use HID to differentiate them.
The events supported by PAv3 and PAv2 are different. The PAv3 PMU removed some events which are supported by PAv2 PMU. The older PA PMU driver will probe v3 as v2. Therefore PA events displayed by "perf list" cannot work properly. We add the HISI0275 HID for PAv3 PMU to distinguish different.
For each H60PA PMU, except for the overflow interrupt register, other functions of the H60PA PMU are the same as the original PA PMU module. It has 8-programable counters and each counter is free-running. Interrupt is supported to handle counter (64-bits) overflow.
Signed-off-by: Junhao He hejunhao3@huawei.com Reviewed-by: Jonathan Cameron Jonathan.Cameron@huawei.com Reviewed-by: Yicong Yang yangyicong@hisilicon.com Acked-by: Mark Rutland mark.rutland@arm.com Link: https://lore.kernel.org/r/20230615125926.29832-2-hejunhao3@huawei.com Signed-off-by: Will Deacon will@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/perf/hisilicon/hisi_uncore_pa_pmu.c | 127 +++++++++++++++++--- drivers/perf/hisilicon/hisi_uncore_pmu.h | 8 ++ 2 files changed, 120 insertions(+), 15 deletions(-)
diff --git a/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c b/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c index 71b6687d66960..d941e746b4248 100644 --- a/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c +++ b/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c @@ -22,9 +22,15 @@ #define PA_TT_CTRL 0x1c08 #define PA_TGTID_CTRL 0x1c14 #define PA_SRCID_CTRL 0x1c18 + +/* H32 PA interrupt registers */ #define PA_INT_MASK 0x1c70 #define PA_INT_STATUS 0x1c78 #define PA_INT_CLEAR 0x1c7c + +#define H60PA_INT_STATUS 0x1c70 +#define H60PA_INT_MASK 0x1c74 + #define PA_EVENT_TYPE0 0x1c80 #define PA_PMU_VERSION 0x1cf0 #define PA_EVENT_CNT0_L 0x1d00 @@ -46,6 +52,12 @@ HISI_PMU_EVENT_ATTR_EXTRACTOR(srcid_cmd, config1, 32, 22); HISI_PMU_EVENT_ATTR_EXTRACTOR(srcid_msk, config1, 43, 33); HISI_PMU_EVENT_ATTR_EXTRACTOR(tracetag_en, config1, 44, 44);
+struct hisi_pa_pmu_int_regs { + u32 mask_offset; + u32 clear_offset; + u32 status_offset; +}; + static void hisi_pa_pmu_enable_tracetag(struct perf_event *event) { struct hisi_pmu *pa_pmu = to_hisi_pmu(event->pmu); @@ -219,40 +231,40 @@ static void hisi_pa_pmu_disable_counter(struct hisi_pmu *pa_pmu, static void hisi_pa_pmu_enable_counter_int(struct hisi_pmu *pa_pmu, struct hw_perf_event *hwc) { + struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private; u32 val;
/* Write 0 to enable interrupt */ - val = readl(pa_pmu->base + PA_INT_MASK); + val = readl(pa_pmu->base + regs->mask_offset); val &= ~(1 << hwc->idx); - writel(val, pa_pmu->base + PA_INT_MASK); + writel(val, pa_pmu->base + regs->mask_offset); }
static void hisi_pa_pmu_disable_counter_int(struct hisi_pmu *pa_pmu, struct hw_perf_event *hwc) { + struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private; u32 val;
/* Write 1 to mask interrupt */ - val = readl(pa_pmu->base + PA_INT_MASK); + val = readl(pa_pmu->base + regs->mask_offset); val |= 1 << hwc->idx; - writel(val, pa_pmu->base + PA_INT_MASK); + writel(val, pa_pmu->base + regs->mask_offset); }
static u32 hisi_pa_pmu_get_int_status(struct hisi_pmu *pa_pmu) { - return readl(pa_pmu->base + PA_INT_STATUS); + struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private; + + return readl(pa_pmu->base + regs->status_offset); }
static void hisi_pa_pmu_clear_int_status(struct hisi_pmu *pa_pmu, int idx) { - writel(1 << idx, pa_pmu->base + PA_INT_CLEAR); -} + struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private;
-static const struct acpi_device_id hisi_pa_pmu_acpi_match[] = { - { "HISI0273", }, - {} -}; -MODULE_DEVICE_TABLE(acpi, hisi_pa_pmu_acpi_match); + writel(1 << idx, pa_pmu->base + regs->clear_offset); +}
static int hisi_pa_pmu_init_data(struct platform_device *pdev, struct hisi_pmu *pa_pmu) @@ -276,6 +288,10 @@ static int hisi_pa_pmu_init_data(struct platform_device *pdev, pa_pmu->ccl_id = -1; pa_pmu->sccl_id = -1;
+ pa_pmu->dev_info = device_get_match_data(&pdev->dev); + if (!pa_pmu->dev_info) + return -ENODEV; + pa_pmu->base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(pa_pmu->base)) { dev_err(&pdev->dev, "ioremap failed for pa_pmu resource.\n"); @@ -314,6 +330,32 @@ static const struct attribute_group hisi_pa_pmu_v2_events_group = { .attrs = hisi_pa_pmu_v2_events_attr, };
+static struct attribute *hisi_pa_pmu_v3_events_attr[] = { + HISI_PMU_EVENT_ATTR(tx_req, 0x0), + HISI_PMU_EVENT_ATTR(tx_dat, 0x1), + HISI_PMU_EVENT_ATTR(tx_snp, 0x2), + HISI_PMU_EVENT_ATTR(rx_req, 0x7), + HISI_PMU_EVENT_ATTR(rx_dat, 0x8), + HISI_PMU_EVENT_ATTR(rx_snp, 0x9), + NULL +}; + +static const struct attribute_group hisi_pa_pmu_v3_events_group = { + .name = "events", + .attrs = hisi_pa_pmu_v3_events_attr, +}; + +static struct attribute *hisi_h60pa_pmu_events_attr[] = { + HISI_PMU_EVENT_ATTR(rx_flit, 0x50), + HISI_PMU_EVENT_ATTR(tx_flit, 0x65), + NULL +}; + +static const struct attribute_group hisi_h60pa_pmu_events_group = { + .name = "events", + .attrs = hisi_h60pa_pmu_events_attr, +}; + static DEVICE_ATTR(cpumask, 0444, hisi_cpumask_sysfs_show, NULL);
static struct attribute *hisi_pa_pmu_cpumask_attrs[] = { @@ -337,6 +379,12 @@ static const struct attribute_group hisi_pa_pmu_identifier_group = { .attrs = hisi_pa_pmu_identifier_attrs, };
+static struct hisi_pa_pmu_int_regs hisi_pa_pmu_regs = { + .mask_offset = PA_INT_MASK, + .clear_offset = PA_INT_CLEAR, + .status_offset = PA_INT_STATUS, +}; + static const struct attribute_group *hisi_pa_pmu_v2_attr_groups[] = { &hisi_pa_pmu_v2_format_group, &hisi_pa_pmu_v2_events_group, @@ -345,6 +393,46 @@ static const struct attribute_group *hisi_pa_pmu_v2_attr_groups[] = { NULL };
+static const struct hisi_pmu_dev_info hisi_h32pa_v2 = { + .name = "pa", + .attr_groups = hisi_pa_pmu_v2_attr_groups, + .private = &hisi_pa_pmu_regs, +}; + +static const struct attribute_group *hisi_pa_pmu_v3_attr_groups[] = { + &hisi_pa_pmu_v2_format_group, + &hisi_pa_pmu_v3_events_group, + &hisi_pa_pmu_cpumask_attr_group, + &hisi_pa_pmu_identifier_group, + NULL +}; + +static const struct hisi_pmu_dev_info hisi_h32pa_v3 = { + .name = "pa", + .attr_groups = hisi_pa_pmu_v3_attr_groups, + .private = &hisi_pa_pmu_regs, +}; + +static struct hisi_pa_pmu_int_regs hisi_h60pa_pmu_regs = { + .mask_offset = H60PA_INT_MASK, + .clear_offset = H60PA_INT_STATUS, /* Clear on write */ + .status_offset = H60PA_INT_STATUS, +}; + +static const struct attribute_group *hisi_h60pa_pmu_attr_groups[] = { + &hisi_pa_pmu_v2_format_group, + &hisi_h60pa_pmu_events_group, + &hisi_pa_pmu_cpumask_attr_group, + &hisi_pa_pmu_identifier_group, + NULL +}; + +static const struct hisi_pmu_dev_info hisi_h60pa = { + .name = "h60pa", + .attr_groups = hisi_h60pa_pmu_attr_groups, + .private = &hisi_h60pa_pmu_regs, +}; + static const struct hisi_uncore_ops hisi_uncore_pa_ops = { .write_evtype = hisi_pa_pmu_write_evtype, .get_event_idx = hisi_uncore_pmu_get_event_idx, @@ -375,7 +463,7 @@ static int hisi_pa_pmu_dev_probe(struct platform_device *pdev, if (ret) return ret;
- pa_pmu->pmu_events.attr_groups = hisi_pa_pmu_v2_attr_groups; + pa_pmu->pmu_events.attr_groups = pa_pmu->dev_info->attr_groups; pa_pmu->num_counters = PA_NR_COUNTERS; pa_pmu->ops = &hisi_uncore_pa_ops; pa_pmu->check_event = 0xB0; @@ -400,8 +488,9 @@ static int hisi_pa_pmu_probe(struct platform_device *pdev) if (ret) return ret;
- name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "hisi_sicl%u_pa%u", - pa_pmu->sicl_id, pa_pmu->index_id); + name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "hisi_sicl%d_%s%u", + pa_pmu->sicl_id, pa_pmu->dev_info->name, + pa_pmu->index_id); if (!name) return -ENOMEM;
@@ -435,6 +524,14 @@ static int hisi_pa_pmu_remove(struct platform_device *pdev) return 0; }
+static const struct acpi_device_id hisi_pa_pmu_acpi_match[] = { + { "HISI0273", (kernel_ulong_t)&hisi_h32pa_v2 }, + { "HISI0275", (kernel_ulong_t)&hisi_h32pa_v3 }, + { "HISI0274", (kernel_ulong_t)&hisi_h60pa }, + {} +}; +MODULE_DEVICE_TABLE(acpi, hisi_pa_pmu_acpi_match); + static struct platform_driver hisi_pa_pmu_driver = { .driver = { .name = "hisi_pa_pmu", diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.h b/drivers/perf/hisilicon/hisi_uncore_pmu.h index 07890a8e96ca7..772857b99dc5e 100644 --- a/drivers/perf/hisilicon/hisi_uncore_pmu.h +++ b/drivers/perf/hisilicon/hisi_uncore_pmu.h @@ -62,6 +62,13 @@ struct hisi_uncore_ops { void (*disable_filter)(struct perf_event *event); };
+/* Describes the HISI PMU chip features information */ +struct hisi_pmu_dev_info { + const char *name; + const struct attribute_group **attr_groups; + void *private; +}; + struct hisi_pmu_hwevents { struct perf_event *hw_events[HISI_MAX_COUNTERS]; DECLARE_BITMAP(used_mask, HISI_MAX_COUNTERS); @@ -72,6 +79,7 @@ struct hisi_pmu_hwevents { struct hisi_pmu { struct pmu pmu; const struct hisi_uncore_ops *ops; + const struct hisi_pmu_dev_info *dev_info; struct hisi_pmu_hwevents pmu_events; /* associated_cpus: All CPUs associated with the PMU */ cpumask_t associated_cpus;
On Sun, Jul 02, 2023 at 03:50:56PM -0400, Sasha Levin wrote:
From: Junhao He hejunhao3@huawei.com
[ Upstream commit 1a51688474c0d395b864e98236335fba712e29bf ]
Compared to the original PA device, H60PA offers higher bandwidth. The H60PA is a new device and we use HID to differentiate them.
The events supported by PAv3 and PAv2 are different. The PAv3 PMU removed some events which are supported by PAv2 PMU. The older PA PMU driver will probe v3 as v2. Therefore PA events displayed by "perf list" cannot work properly. We add the HISI0275 HID for PAv3 PMU to distinguish different.
For each H60PA PMU, except for the overflow interrupt register, other functions of the H60PA PMU are the same as the original PA PMU module. It has 8-programable counters and each counter is free-running. Interrupt is supported to handle counter (64-bits) overflow.
Signed-off-by: Junhao He hejunhao3@huawei.com Reviewed-by: Jonathan Cameron Jonathan.Cameron@huawei.com Reviewed-by: Yicong Yang yangyicong@hisilicon.com Acked-by: Mark Rutland mark.rutland@arm.com Link: https://lore.kernel.org/r/20230615125926.29832-2-hejunhao3@huawei.com Signed-off-by: Will Deacon will@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org
drivers/perf/hisilicon/hisi_uncore_pa_pmu.c | 127 +++++++++++++++++--- drivers/perf/hisilicon/hisi_uncore_pmu.h | 8 ++ 2 files changed, 120 insertions(+), 15 deletions(-)
Why is this being backported to stable?
This patch adds supoprt for new HW, and is clearly not a fix, so it's not clear to me why it has been selected.
Thanks, Mark.
diff --git a/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c b/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c index 71b6687d66960..d941e746b4248 100644 --- a/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c +++ b/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c @@ -22,9 +22,15 @@ #define PA_TT_CTRL 0x1c08 #define PA_TGTID_CTRL 0x1c14 #define PA_SRCID_CTRL 0x1c18
+/* H32 PA interrupt registers */ #define PA_INT_MASK 0x1c70 #define PA_INT_STATUS 0x1c78 #define PA_INT_CLEAR 0x1c7c
+#define H60PA_INT_STATUS 0x1c70 +#define H60PA_INT_MASK 0x1c74
#define PA_EVENT_TYPE0 0x1c80 #define PA_PMU_VERSION 0x1cf0 #define PA_EVENT_CNT0_L 0x1d00 @@ -46,6 +52,12 @@ HISI_PMU_EVENT_ATTR_EXTRACTOR(srcid_cmd, config1, 32, 22); HISI_PMU_EVENT_ATTR_EXTRACTOR(srcid_msk, config1, 43, 33); HISI_PMU_EVENT_ATTR_EXTRACTOR(tracetag_en, config1, 44, 44); +struct hisi_pa_pmu_int_regs {
- u32 mask_offset;
- u32 clear_offset;
- u32 status_offset;
+};
static void hisi_pa_pmu_enable_tracetag(struct perf_event *event) { struct hisi_pmu *pa_pmu = to_hisi_pmu(event->pmu); @@ -219,40 +231,40 @@ static void hisi_pa_pmu_disable_counter(struct hisi_pmu *pa_pmu, static void hisi_pa_pmu_enable_counter_int(struct hisi_pmu *pa_pmu, struct hw_perf_event *hwc) {
- struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private; u32 val;
/* Write 0 to enable interrupt */
- val = readl(pa_pmu->base + PA_INT_MASK);
- val = readl(pa_pmu->base + regs->mask_offset); val &= ~(1 << hwc->idx);
- writel(val, pa_pmu->base + PA_INT_MASK);
- writel(val, pa_pmu->base + regs->mask_offset);
} static void hisi_pa_pmu_disable_counter_int(struct hisi_pmu *pa_pmu, struct hw_perf_event *hwc) {
- struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private; u32 val;
/* Write 1 to mask interrupt */
- val = readl(pa_pmu->base + PA_INT_MASK);
- val = readl(pa_pmu->base + regs->mask_offset); val |= 1 << hwc->idx;
- writel(val, pa_pmu->base + PA_INT_MASK);
- writel(val, pa_pmu->base + regs->mask_offset);
} static u32 hisi_pa_pmu_get_int_status(struct hisi_pmu *pa_pmu) {
- return readl(pa_pmu->base + PA_INT_STATUS);
- struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private;
- return readl(pa_pmu->base + regs->status_offset);
} static void hisi_pa_pmu_clear_int_status(struct hisi_pmu *pa_pmu, int idx) {
- writel(1 << idx, pa_pmu->base + PA_INT_CLEAR);
-}
- struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private;
-static const struct acpi_device_id hisi_pa_pmu_acpi_match[] = {
- { "HISI0273", },
- {}
-}; -MODULE_DEVICE_TABLE(acpi, hisi_pa_pmu_acpi_match);
- writel(1 << idx, pa_pmu->base + regs->clear_offset);
+} static int hisi_pa_pmu_init_data(struct platform_device *pdev, struct hisi_pmu *pa_pmu) @@ -276,6 +288,10 @@ static int hisi_pa_pmu_init_data(struct platform_device *pdev, pa_pmu->ccl_id = -1; pa_pmu->sccl_id = -1;
- pa_pmu->dev_info = device_get_match_data(&pdev->dev);
- if (!pa_pmu->dev_info)
return -ENODEV;- pa_pmu->base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(pa_pmu->base)) { dev_err(&pdev->dev, "ioremap failed for pa_pmu resource.\n");
@@ -314,6 +330,32 @@ static const struct attribute_group hisi_pa_pmu_v2_events_group = { .attrs = hisi_pa_pmu_v2_events_attr, }; +static struct attribute *hisi_pa_pmu_v3_events_attr[] = {
- HISI_PMU_EVENT_ATTR(tx_req, 0x0),
- HISI_PMU_EVENT_ATTR(tx_dat, 0x1),
- HISI_PMU_EVENT_ATTR(tx_snp, 0x2),
- HISI_PMU_EVENT_ATTR(rx_req, 0x7),
- HISI_PMU_EVENT_ATTR(rx_dat, 0x8),
- HISI_PMU_EVENT_ATTR(rx_snp, 0x9),
- NULL
+};
+static const struct attribute_group hisi_pa_pmu_v3_events_group = {
- .name = "events",
- .attrs = hisi_pa_pmu_v3_events_attr,
+};
+static struct attribute *hisi_h60pa_pmu_events_attr[] = {
- HISI_PMU_EVENT_ATTR(rx_flit, 0x50),
- HISI_PMU_EVENT_ATTR(tx_flit, 0x65),
- NULL
+};
+static const struct attribute_group hisi_h60pa_pmu_events_group = {
- .name = "events",
- .attrs = hisi_h60pa_pmu_events_attr,
+};
static DEVICE_ATTR(cpumask, 0444, hisi_cpumask_sysfs_show, NULL); static struct attribute *hisi_pa_pmu_cpumask_attrs[] = { @@ -337,6 +379,12 @@ static const struct attribute_group hisi_pa_pmu_identifier_group = { .attrs = hisi_pa_pmu_identifier_attrs, }; +static struct hisi_pa_pmu_int_regs hisi_pa_pmu_regs = {
- .mask_offset = PA_INT_MASK,
- .clear_offset = PA_INT_CLEAR,
- .status_offset = PA_INT_STATUS,
+};
static const struct attribute_group *hisi_pa_pmu_v2_attr_groups[] = { &hisi_pa_pmu_v2_format_group, &hisi_pa_pmu_v2_events_group, @@ -345,6 +393,46 @@ static const struct attribute_group *hisi_pa_pmu_v2_attr_groups[] = { NULL }; +static const struct hisi_pmu_dev_info hisi_h32pa_v2 = {
- .name = "pa",
- .attr_groups = hisi_pa_pmu_v2_attr_groups,
- .private = &hisi_pa_pmu_regs,
+};
+static const struct attribute_group *hisi_pa_pmu_v3_attr_groups[] = {
- &hisi_pa_pmu_v2_format_group,
- &hisi_pa_pmu_v3_events_group,
- &hisi_pa_pmu_cpumask_attr_group,
- &hisi_pa_pmu_identifier_group,
- NULL
+};
+static const struct hisi_pmu_dev_info hisi_h32pa_v3 = {
- .name = "pa",
- .attr_groups = hisi_pa_pmu_v3_attr_groups,
- .private = &hisi_pa_pmu_regs,
+};
+static struct hisi_pa_pmu_int_regs hisi_h60pa_pmu_regs = {
- .mask_offset = H60PA_INT_MASK,
- .clear_offset = H60PA_INT_STATUS, /* Clear on write */
- .status_offset = H60PA_INT_STATUS,
+};
+static const struct attribute_group *hisi_h60pa_pmu_attr_groups[] = {
- &hisi_pa_pmu_v2_format_group,
- &hisi_h60pa_pmu_events_group,
- &hisi_pa_pmu_cpumask_attr_group,
- &hisi_pa_pmu_identifier_group,
- NULL
+};
+static const struct hisi_pmu_dev_info hisi_h60pa = {
- .name = "h60pa",
- .attr_groups = hisi_h60pa_pmu_attr_groups,
- .private = &hisi_h60pa_pmu_regs,
+};
static const struct hisi_uncore_ops hisi_uncore_pa_ops = { .write_evtype = hisi_pa_pmu_write_evtype, .get_event_idx = hisi_uncore_pmu_get_event_idx, @@ -375,7 +463,7 @@ static int hisi_pa_pmu_dev_probe(struct platform_device *pdev, if (ret) return ret;
- pa_pmu->pmu_events.attr_groups = hisi_pa_pmu_v2_attr_groups;
- pa_pmu->pmu_events.attr_groups = pa_pmu->dev_info->attr_groups; pa_pmu->num_counters = PA_NR_COUNTERS; pa_pmu->ops = &hisi_uncore_pa_ops; pa_pmu->check_event = 0xB0;
@@ -400,8 +488,9 @@ static int hisi_pa_pmu_probe(struct platform_device *pdev) if (ret) return ret;
- name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "hisi_sicl%u_pa%u",
pa_pmu->sicl_id, pa_pmu->index_id);
- name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "hisi_sicl%d_%s%u",
pa_pmu->sicl_id, pa_pmu->dev_info->name,pa_pmu->index_id);@@ -435,6 +524,14 @@ static int hisi_pa_pmu_remove(struct platform_device *pdev) return 0; } +static const struct acpi_device_id hisi_pa_pmu_acpi_match[] = {
- { "HISI0273", (kernel_ulong_t)&hisi_h32pa_v2 },
- { "HISI0275", (kernel_ulong_t)&hisi_h32pa_v3 },
- { "HISI0274", (kernel_ulong_t)&hisi_h60pa },
- {}
+}; +MODULE_DEVICE_TABLE(acpi, hisi_pa_pmu_acpi_match);
static struct platform_driver hisi_pa_pmu_driver = { .driver = { .name = "hisi_pa_pmu", diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.h b/drivers/perf/hisilicon/hisi_uncore_pmu.h index 07890a8e96ca7..772857b99dc5e 100644 --- a/drivers/perf/hisilicon/hisi_uncore_pmu.h +++ b/drivers/perf/hisilicon/hisi_uncore_pmu.h @@ -62,6 +62,13 @@ struct hisi_uncore_ops { void (*disable_filter)(struct perf_event *event); }; +/* Describes the HISI PMU chip features information */ +struct hisi_pmu_dev_info {
- const char *name;
- const struct attribute_group **attr_groups;
- void *private;
+};
struct hisi_pmu_hwevents { struct perf_event *hw_events[HISI_MAX_COUNTERS]; DECLARE_BITMAP(used_mask, HISI_MAX_COUNTERS); @@ -72,6 +79,7 @@ struct hisi_pmu_hwevents { struct hisi_pmu { struct pmu pmu; const struct hisi_uncore_ops *ops;
- const struct hisi_pmu_dev_info *dev_info; struct hisi_pmu_hwevents pmu_events; /* associated_cpus: All CPUs associated with the PMU */ cpumask_t associated_cpus;
-- 2.39.2
On Mon, Jul 03, 2023 at 11:14:37AM +0100, Mark Rutland wrote:
On Sun, Jul 02, 2023 at 03:50:56PM -0400, Sasha Levin wrote:
From: Junhao He hejunhao3@huawei.com
[ Upstream commit 1a51688474c0d395b864e98236335fba712e29bf ]
Compared to the original PA device, H60PA offers higher bandwidth. The H60PA is a new device and we use HID to differentiate them.
The events supported by PAv3 and PAv2 are different. The PAv3 PMU removed some events which are supported by PAv2 PMU. The older PA PMU driver will probe v3 as v2. Therefore PA events displayed by "perf list" cannot work properly. We add the HISI0275 HID for PAv3 PMU to distinguish different.
For each H60PA PMU, except for the overflow interrupt register, other functions of the H60PA PMU are the same as the original PA PMU module. It has 8-programable counters and each counter is free-running. Interrupt is supported to handle counter (64-bits) overflow.
Signed-off-by: Junhao He hejunhao3@huawei.com Reviewed-by: Jonathan Cameron Jonathan.Cameron@huawei.com Reviewed-by: Yicong Yang yangyicong@hisilicon.com Acked-by: Mark Rutland mark.rutland@arm.com Link: https://lore.kernel.org/r/20230615125926.29832-2-hejunhao3@huawei.com Signed-off-by: Will Deacon will@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org
drivers/perf/hisilicon/hisi_uncore_pa_pmu.c | 127 +++++++++++++++++--- drivers/perf/hisilicon/hisi_uncore_pmu.h | 8 ++ 2 files changed, 120 insertions(+), 15 deletions(-)
Why is this being backported to stable?
This patch adds supoprt for new HW, and is clearly not a fix, so it's not clear to me why it has been selected.
I'll drop it, thanks.
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit 23d28cc0444be3f694eb986cd653b6888b78431d ]
The Dell Studio 1569 predates Windows 8, so it defaults to using acpi_video# for backlight control, but this is non functional on this model.
Add a DMI quirk to use the native intel_backlight interface which does work properly.
Reported-by: raycekarneal raycekarneal@gmail.com Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/acpi/video_detect.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index b87783c5872dd..e7d04ab864a16 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -528,6 +528,14 @@ static const struct dmi_system_id video_detect_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "Precision 7510"), }, }, + { + .callback = video_detect_force_native, + /* Dell Studio 1569 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Studio 1569"), + }, + }, { .callback = video_detect_force_native, /* Acer Aspire 3830TG */
On Sun, Jul 2, 2023 at 12:51 PM Sasha Levin sashal@kernel.org wrote:
From: Rob Barnes robbarnes@google.com
[ Upstream commit 2cbf475a04b2ae3d722bbe41742e5d874a027fc3 ]
Create a uevent when an EC panic is detected. This will allow udev rules to trigger when a panic occurs. For example, a udev rule could be added to capture an EC coredump. This approach avoids the need to stuff all the processing into the driver.
Signed-off-by: Rob Barnes robbarnes@google.com Reviewed-by: Prashant Malani pmalani@chromium.org Signed-off-by: Tzung-Bi Shih tzungbi@kernel.org Link: https://lore.kernel.org/r/20230509232624.3120347-1-robbarnes@google.com Signed-off-by: Sasha Levin sashal@kernel.org
drivers/platform/chrome/cros_ec_lpc.c | 3 +++ 1 file changed, 3 insertions(+)
What sorcery determined this was a valid for-linux-stable patch? It's a new feature, and definitely not a for-stable candidate. Please remove this from the queue.
Brian
On Mon, Jul 10, 2023 at 03:46:21PM -0700, Brian Norris wrote:
On Sun, Jul 2, 2023 at 12:51 PM Sasha Levin sashal@kernel.org wrote:
From: Rob Barnes robbarnes@google.com
[ Upstream commit 2cbf475a04b2ae3d722bbe41742e5d874a027fc3 ]
Create a uevent when an EC panic is detected. This will allow udev rules to trigger when a panic occurs. For example, a udev rule could be added to capture an EC coredump. This approach avoids the need to stuff all the processing into the driver.
Signed-off-by: Rob Barnes robbarnes@google.com Reviewed-by: Prashant Malani pmalani@chromium.org Signed-off-by: Tzung-Bi Shih tzungbi@kernel.org Link: https://lore.kernel.org/r/20230509232624.3120347-1-robbarnes@google.com Signed-off-by: Sasha Levin sashal@kernel.org
drivers/platform/chrome/cros_ec_lpc.c | 3 +++ 1 file changed, 3 insertions(+)
What sorcery determined this was a valid for-linux-stable patch? It's a new feature, and definitely not a for-stable candidate. Please remove this from the queue.
Dropped, thanks.
linux-stable-mirror@lists.linaro.org
-
Brian Norris -
Greg KH -
Mark Brown -
Mark Rutland -
Sasha Levin -
Will Deacon