[linux-yocto][v6.6/standard/x86 and v6.6/standard/preempt-rt/x86][PATCH 3/3] iommu: Add support to change default domain of an iommu group
From: Sai Praneeth Prakhya Presently, the default domain of an iommu group is allocated during boot time and it cannot be changed later. So, the device would typically be either in identity (also known as pass_through) mode or the device would be in DMA mode as long as the machine is up and running. There is no way to change the default domain type dynamically i.e. after booting, a device cannot switch between identity mode and DMA mode. But, assume a use case wherein the user trusts the device and believes that the OS is secure enough and hence wants *only* this device to bypass IOMMU (so that it could be high performing) whereas all the other devices to go through IOMMU (so that the system is protected). Presently, this use case is not supported. It will be helpful if there is some way to change the default domain of an iommu group dynamically. Hence, add such support. A privileged user could request the kernel to change the default domain type of a iommu group by writing to "/sys/kernel/iommu_groups//type" file. Presently, only three values are supported 1. identity: all the DMA transactions from the device in this group are *not* translated by the iommu 2. DMA: all the DMA transactions from the device in this group are translated by the iommu 3. auto: change to the type the device was booted with Note: 1. Default domain of an iommu group with two or more devices cannot be changed. 2. The device in the iommu group shouldn't be bound to any driver. 3. The device shouldn't be assigned to user for direct access. 4. The change request will fail if any device in the group has a mandatory default domain type and the requested one conflicts with that. Please see "Documentation/ABI/testing/sysfs-kernel-iommu_groups" for more information. NOTE: This back-port does not support using the /sys interface on GRR. It simply adds macros for GRR (8086:0dbd), GRR_QAT_PF (8086:578a) and GRR_QAT_VF (8086:578b). Signed-off-by: Sai Praneeth Prakhya Signed-off-by: Lu Baolu Cc: Christoph Hellwig Cc: Joerg Roedel Cc: Ashok Raj Cc: Will Deacon Cc: Sohil Mehta Cc: Robin Murphy Cc: Jacob Pan Cc: Magnus Hjohlman Link: https://lore.kernel.org/r/20201124130604.2912899-3-baolu...@linux.intel.com Signed-off-by: Will Deacon Back-ported-by: John Jacques [YL: Original patch from https://github.com/intel-collab/networking.wireless.transport.rdk.board-support.meta-intel-axxia.git.] Signed-off-by: Yongxin Liu --- drivers/iommu/intel/iommu.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 744e4e6b8d72..ae6b343912c3 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -39,6 +39,11 @@ #define IS_USB_DEVICE(pdev) ((pdev->class >> 8) == PCI_CLASS_SERIAL_USB) #define IS_ISA_DEVICE(pdev) ((pdev->class >> 8) == PCI_CLASS_BRIDGE_ISA) #define IS_AZALIA(pdev) ((pdev)->vendor == 0x8086 && (pdev)->device == 0x3a3e) +#define IS_GRR(pdev) ((pdev)->vendor == 0x8086 && (pdev)->device == 0x0dbd) +#define IS_GRR_QAT_PF(pdev) \ + ((pdev)->vendor == 0x8086 && (pdev)->device == 0x578a) +#define IS_GRR_QAT_VF(pdev) \ + ((pdev)->vendor == 0x8086 && (pdev)->device == 0x578b) #define IOAPIC_RANGE_START (0xfee0) #define IOAPIC_RANGE_END (0xfeef) @@ -2545,6 +2550,15 @@ static int device_def_domain_type(struct device *dev) if ((iommu_identity_mapping & IDENTMAP_GFX) && IS_GFX_DEVICE(pdev)) return IOMMU_DOMAIN_IDENTITY; + + if (IS_GRR(pdev)) + return IOMMU_DOMAIN_IDENTITY; + + if (IS_GRR_QAT_PF(pdev)) + return IOMMU_DOMAIN_IDENTITY; + + if (IS_GRR_QAT_VF(pdev)) + return IOMMU_DOMAIN_IDENTITY; } return 0; -- 2.45.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13976): https://lists.yoctoproject.org/g/linux-yocto/message/13976 Mute This Topic: https://lists.yoctoproject.org/mt/106499074/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.6/standard/x86 and v6.6/standard/preempt-rt/x86][PATCH 0/3] Patches for Intel Grand Ridge and Snow Ridge
From: Yongxin Liu Hi Bruce, Please help to merge the following 3 patches to linux-yocto, branch "v6.6/standard/x86" and "v6.6/standard/preempt-rt/x86". They are from Intel's repo https://github.com/intel-collab/networking.wireless.transport.rdk.board-support.meta-intel-axxia.git 1) Patch "drivers/watchdog: Ignore 'No Reboot' Bit" will do nothing unless 'iTCO_wdt.assume_noreboot_access=1' is added to the kernel command line. 2) Patch "clocksource: Add option to force acpi_pm as clocksource watchdog" adds a kernel command line option to force the use of acpi_pm as the watchdog clocksource. To use it add "ricardo_clocksource_wd=force_acpi_pm_wd" to kernel command line. 3) Patch "iommu: Add support to change default domain of an iommu group" only adds macros for GRR (8086:0dbd), GRR_QAT_PF (8086:578a) and and GRR_QAT_VF (8086:578b). John Jacques (2): drivers/watchdog: Ignore 'No Reboot' Bit clocksource: Add option to force acpi_pm as clocksource watchdog Sai Praneeth Prakhya (1): iommu: Add support to change default domain of an iommu group drivers/iommu/intel/iommu.c | 14 +++ drivers/watchdog/iTCO_wdt.c | 46 + kernel/time/clocksource.c | 82 - 3 files changed, 124 insertions(+), 18 deletions(-) Thanks, Yongxin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13973): https://lists.yoctoproject.org/g/linux-yocto/message/13973 Mute This Topic: https://lists.yoctoproject.org/mt/106499071/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.6/standard/x86 and v6.6/standard/preempt-rt/x86][PATCH 2/3] clocksource: Add option to force acpi_pm as clocksource watchdog
From: John Jacques
Add a kernel command line option to force the use of acpi_pm as the
watchdog clocksource. To use it, add the following to the
kernel command line:
ricardo_clocksource_wd=force_acpi_pm_wd
and in dmesg look for:
RICARDO: Force acpi_pm as watchdog
Also, add a debugfs entry to inspect the current clocksource watchdog
and the history watchdoug sources. The file is
/sys/kernel/debug/ricardo_clocksource/watchdog_info
It look like something like:
CURRENT: acpi_pm
HISTORY:
apci-pm
Signed-off-by: Ricardo Neri
Signed-off-by: John Jacques
[YL: Original patch from
https://github.com/intel-collab/networking.wireless.transport.rdk.board-support.meta-intel-axxia.git.]
Signed-off-by: Yongxin Liu
---
kernel/time/clocksource.c | 82 ++-
1 file changed, 80 insertions(+), 2 deletions(-)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 3052b1f1168e..fb89243cb6d6 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -16,7 +16,7 @@
#include
#include
#include
-
+#include
#include "tick-internal.h"
#include "timekeeping_internal.h"
@@ -398,6 +398,58 @@ static inline void clocksource_reset_watchdog(void)
}
+#define RICARDO_WD_HISTORY_SIZE 1024
+static bool force_acpi_pm_wd;
+static char ricardo_watchdog_history[RICARDO_WD_HISTORY_SIZE];
+
+static void ricardo_append_wd_select(const char *name)
+{
+ static bool buff_full = false;
+ static unsigned buff_pos = 0;
+ unsigned int len;
+
+ if (buff_full)
+ return;
+
+ if (!name)
+ return;
+
+ if (!buff_pos)
+ memset(ricardo_watchdog_history, '\0', RICARDO_WD_HISTORY_SIZE
* sizeof(char));
+
+ len = strlen(name);
+
+ if ((buff_pos + len) > (RICARDO_WD_HISTORY_SIZE - 6)) {
+ memcpy(ricardo_watchdog_history + buff_pos, "FULL\n", 6);
+ buff_full = true;
+ return;
+ }
+
+ memcpy(ricardo_watchdog_history + buff_pos, name, len);
+ buff_pos += len;
+ memcpy(ricardo_watchdog_history + buff_pos, "\n", 1);
+ buff_pos ++;
+}
+
+static int ricardo_watchdog_name_show(struct seq_file *m, void *data)
+{
+ seq_printf(m, "CURRENT: %s\n", watchdog ? watchdog->name : "none");
+ seq_printf(m, "HISTORY: \n%s\n", ricardo_watchdog_history);
+ return 0;
+}
+
+DEFINE_SHOW_ATTRIBUTE(ricardo_watchdog_name);
+
+static int __init ricardo_override_cs_watchdog(char *str)
+{
+ if (!strcmp(str, "force_acpi_pm_wd")) {
+ printk(KERN_ERR "RICARDO: Force acpi_pm as watchdog\n");
+ force_acpi_pm_wd = true;
+ }
+ return 1;
+}
+early_param("ricardo_clocksource_wd", ricardo_override_cs_watchdog);
+
static void clocksource_watchdog(struct timer_list *unused)
{
u64 csnow, wdnow, cslast, wdlast, delta;
@@ -642,13 +694,23 @@ static void clocksource_select_watchdog(bool fallback)
if (!watchdog || cs->rating > watchdog->rating)
watchdog = cs;
}
+
/* If we failed to find a fallback restore the old one. */
if (!watchdog)
watchdog = old_wd;
+ /*
+* If selected watchdog is not old_wd, replace with old one. It
+* will be NULL if not watchdog has been selected
+*/
+ if (force_acpi_pm_wd && strcmp(watchdog->name, "acpi_pm"))
+ watchdog = old_wd;
+
/* If we changed the watchdog we need to reset cycles. */
- if (watchdog != old_wd)
+ if (watchdog != old_wd) {
clocksource_reset_watchdog();
+ ricardo_append_wd_select(watchdog->name);
+ }
/* Check if the watchdog timer needs to be started. */
clocksource_start_watchdog();
@@ -1077,6 +1139,12 @@ static void clocksource_select_fallback(void)
*/
static int __init clocksource_done_booting(void)
{
+ /*
+* static variable to ensure debugfs entry is called only once even
+* if this function is called multiple times (once per SMP core up?)
+*/
+ static bool debugfs_done = false;
+ struct dentry *root;
mutex_lock(_mutex);
curr_clocksource = clocksource_default_clock();
finished_booting = 1;
@@ -1086,6 +1154,16 @@ static int __init clocksource_done_booting(void)
__clocksource_watchdog_kthread();
clocksource_select();
mutex_unlock(_mutex);
+
+ if (!debugfs_done) {
+ debugfs_done = true;
+ root = debugfs_create_dir("ricardo_clocksource", NULL);
+ if (!root) {
+ printk(KERN_ERR "RICARDO Unable to create debugfs
dir\n");
+ return 0;
+ }
+ debugfs_create_file("watchdog_info", 0444, root, NULL,
_watchdog_name_fops);
+ }
return 0;
}
fs_initcall(clocksource_done_booting);
--
2.45.0
-=-=-=-=-=-=-=-=-=-=-=-
Links:
[linux-yocto][v6.6/standard/x86 and v6.6/standard/preempt-rt/x86][PATCH 1/3] drivers/watchdog: Ignore 'No Reboot' Bit
From: John Jacques
Early versions of the SNR chip do not allow the "no reboot"
bit to be accessed. This commit simply assumes that it is
writeable without checking in order to allow the watchdog to
but used in Linux. This will be fixed in later versions of
the chip.
Signed-off-by: John Jacques
Signed-off-by: Daniel Dragomir
[YL: Original patch from
https://github.com/intel-collab/networking.wireless.transport.rdk.board-support.meta-intel-axxia.git.
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately]
Signed-off-by: Yongxin Liu
---
drivers/watchdog/iTCO_wdt.c | 46 -
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/drivers/watchdog/iTCO_wdt.c b/drivers/watchdog/iTCO_wdt.c
index 264857d314da..01cec5d845f1 100644
--- a/drivers/watchdog/iTCO_wdt.c
+++ b/drivers/watchdog/iTCO_wdt.c
@@ -126,6 +126,11 @@ module_param(turn_SMI_watchdog_clear_off, int, 0);
MODULE_PARM_DESC(turn_SMI_watchdog_clear_off,
"Turn off SMI clearing watchdog (depends on TCO-version)(default=1)");
+static int assume_noreboot_access;
+module_param(assume_noreboot_access, int, 0);
+MODULE_PARM_DESC(assume_norebot_access,
+ "Assume that the No Reboot Bit is Accessible (Don't Check)");
+
/*
* Some TCO specific functions
*/
@@ -274,10 +279,12 @@ static int iTCO_wdt_start(struct watchdog_device *wd_dev)
iTCO_vendor_pre_start(p->smi_res, wd_dev->timeout);
/* disable chipset's NO_REBOOT bit */
- if (p->update_no_reboot_bit(p->no_reboot_priv, false)) {
- spin_unlock(>io_lock);
- dev_err(wd_dev->parent, "failed to reset NO_REBOOT flag, reboot
disabled by hardware/BIOS\n");
- return -EIO;
+ if (assume_noreboot_access == 0) {
+ if (p->update_no_reboot_bit(p->no_reboot_priv, false)) {
+ spin_unlock(>io_lock);
+ dev_err(wd_dev->parent, "failed to reset NO_REBOOT
flag, reboot disabled by hardware/BIOS\n");
+ return -EIO;
+ }
}
/* Force the timer to its reload value by writing to the TCO_RLD
@@ -315,7 +322,8 @@ static int iTCO_wdt_stop(struct watchdog_device *wd_dev)
val = inw(TCO1_CNT(p));
/* Set the NO_REBOOT bit to prevent later reboots, just for sure */
- p->update_no_reboot_bit(p->no_reboot_priv, true);
+ if (assume_noreboot_access == 0)
+ p->update_no_reboot_bit(p->no_reboot_priv, true);
spin_unlock(>io_lock);
@@ -507,18 +515,24 @@ static int iTCO_wdt_probe(struct platform_device *pdev)
* Get the Memory-Mapped GCS or PMC register, we need it for the
* NO_REBOOT flag (TCO v2 and v3).
*/
- if (p->iTCO_version >= 2 && p->iTCO_version < 6 &&
- !pdata->no_reboot_use_pmc) {
- p->gcs_pmc = devm_platform_ioremap_resource(pdev,
ICH_RES_MEM_GCS_PMC);
- if (IS_ERR(p->gcs_pmc))
- return PTR_ERR(p->gcs_pmc);
- }
- /* Check chipset's NO_REBOOT bit */
- if (p->update_no_reboot_bit(p->no_reboot_priv, false) &&
- iTCO_vendor_check_noreboot_on()) {
- dev_info(dev, "unable to reset NO_REBOOT flag, device disabled
by hardware/BIOS\n");
- return -ENODEV; /* Cannot reset NO_REBOOT bit */
+ if (assume_noreboot_access == 0) {
+ if (p->iTCO_version >= 2 && p->iTCO_version < 6 &&
+ !pdata->no_reboot_use_pmc) {
+ p->gcs_pmc = devm_platform_ioremap_resource(pdev,
ICH_RES_MEM_GCS_PMC);
+ if (IS_ERR(p->gcs_pmc))
+ return PTR_ERR(p->gcs_pmc);
+ }
+
+ /* Check chipset's NO_REBOOT bit */
+ if (p->update_no_reboot_bit(p->no_reboot_priv, false) &&
+ iTCO_vendor_check_noreboot_on()) {
+ dev_info(dev, "unable to reset NO_REBOOT flag, device
disabled by hardware/BIOS\n");
+ return -ENODEV; /* Cannot reset NO_REBOOT bit */
+ }
+
+ /* Set the NO_REBOOT bit to prevent later reboots, just for
sure */
+ p->update_no_reboot_bit(p->no_reboot_priv, true);
}
if (turn_SMI_watchdog_clear_off >= p->iTCO_version) {
--
2.45.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13974):
https://lists.yoctoproject.org/g/linux-yocto/message/13974
Mute This Topic: https://lists.yoctoproject.org/mt/106499072/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto][yocto-kernel-cache][yocto-6.1/yocto-6.6/master][PATCH V2] bsp/intel-x86: enable PCIe Advanced Error Reporting driver
> -Original Message- > From: Bruce Ashfield > Sent: Wednesday, May 8, 2024 9:20 > To: Liu, Yongxin > Cc: Hao, Kexin ; linux- > yo...@lists.yoctoproject.org > Subject: Re: [linux-yocto][yocto-kernel-cache][yocto-6.1/yocto- > 6.6/master][PATCH V2] bsp/intel-x86: enable PCIe Advanced Error Reporting > driver > > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and > know the content is safe. > > v2 worked perfectly. > > It is now merged. Thanks. But this patch is for yocto-6.1, yocto-6.6 and master. I saw it only in yocto-6.1. Please help to check. Thanks, Yongxin > > Bruce -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13909): https://lists.yoctoproject.org/g/linux-yocto/message/13909 Mute This Topic: https://lists.yoctoproject.org/mt/105971882/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto][yocto-kernel-cache][yocto-6.1/yocto-6.6/master][PATCH] bsp/intel-x86: enable PCIe Advanced Error Reporting driver
> -Original Message- > From: Bruce Ashfield > Sent: Wednesday, May 8, 2024 3:45 > To: bruce.ashfi...@gmail.com > Cc: Liu, Yongxin ; Hao, Kexin > ; linux-yocto@lists.yoctoproject.org > Subject: Re: [linux-yocto][yocto-kernel-cache][yocto-6.1/yocto- > 6.6/master][PATCH] bsp/intel-x86: enable PCIe Advanced Error Reporting > driver > > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and > know the content is safe. > > Make sure you are following the configuration advice here: > > https://docs.yoctoproject.org/contributor-guide/submit- > changes.html#fixing-your-from-identity > > And if the issue persists, we'll have to get into some of the discussion > here: > > https://lore.kernel.org/yocto-docs/20240502191839a351b43b@mail.local/T/#t > > I'll drop this while I wait for a v2 I have sent a V2 after applying "git config --global sendemail.from "yongxin@windriver.com"". But a new line "From: Yongxin Liu " appears in email body. I don't know whether it matters or not. Please have a try on the V2. Thanks, Yongxin > > Bruce > > On Tue, May 7, 2024 at 3:28 PM Bruce Ashfield via lists.yoctoproject.org > wrote: > > > > I spoke too soon, the mailing list mangled the author field. > > > > remote: ## > > remote: Invalid author Yongxin Liu via lists.yoctoproject.org > > remote: ## > > > > I'm looking for the latest advice on fixing your client so that the > > list software doesn't do the mangling. > > > > So for now, I've dropped the patch. > > > > Bruce > > > > > > On Tue, May 7, 2024 at 3:25 PM Bruce Ashfield via > > lists.yoctoproject.org > > wrote: > > > > > > merged. > > > > > > Bruce > > > > > > In message: > > > [linux-yocto][yocto-kernel-cache][yocto-6.1/yocto-6.6/master][PATCH] > bsp/intel-x86: enable PCIe Advanced Error Reporting driver on 06/05/2024 > Yongxin Liu via lists.yoctoproject.org wrote: > > > > > > > Signed-off-by: Yongxin Liu > > > > --- > > > > bsp/intel-x86/intel-x86.cfg | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/bsp/intel-x86/intel-x86.cfg > > > > b/bsp/intel-x86/intel-x86.cfg index 8266bf8f..87e50c06 100644 > > > > --- a/bsp/intel-x86/intel-x86.cfg > > > > +++ b/bsp/intel-x86/intel-x86.cfg > > > > @@ -95,6 +95,7 @@ CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_ACPI=y > > > > > > > > CONFIG_PCIEPORTBUS=y > > > > +CONFIG_PCIEAER=y > > > > CONFIG_PCIEASPM=y > > > > CONFIG_PCIEASPM_DEFAULT=y > > > > > > > > -- > > > > 2.43.2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await thee > at its end > - "Use the force Harry" - Gandalf, Star Trek II -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13906): https://lists.yoctoproject.org/g/linux-yocto/message/13906 Mute This Topic: https://lists.yoctoproject.org/mt/105931613/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][yocto-kernel-cache][yocto-6.1/yocto-6.6/master][PATCH V2] bsp/intel-x86: enable PCIe Advanced Error Reporting driver
From: Yongxin Liu Signed-off-by: Yongxin Liu --- bsp/intel-x86/intel-x86.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/bsp/intel-x86/intel-x86.cfg b/bsp/intel-x86/intel-x86.cfg index 8266bf8f..87e50c06 100644 --- a/bsp/intel-x86/intel-x86.cfg +++ b/bsp/intel-x86/intel-x86.cfg @@ -95,6 +95,7 @@ CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_ACPI=y CONFIG_PCIEPORTBUS=y +CONFIG_PCIEAER=y CONFIG_PCIEASPM=y CONFIG_PCIEASPM_DEFAULT=y -- 2.43.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13905): https://lists.yoctoproject.org/g/linux-yocto/message/13905 Mute This Topic: https://lists.yoctoproject.org/mt/105971882/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.6/standard/x86 and v6.6/standard/preempt-rt/x86][Pull Request ] cstate, uncore, i10nm_edac and igen6_edac update for some x86 platforms
Hi Bruce, Please help to review and merge this Pull Request for linux-yocto, branch "v6.6/standard/x86" and "v6.6/standard/preempt-rt/x86". All patches are from mainline kernel. This patch series basically did the following changes. 1) Intel cstate performance events: add support for Grand Ridge and Sierra Forest 2) Intel uncore performance events: add support for Sierra Forest, Grand Ridge and Granite Rapids 3) EDAC/i10nm: add support for Intel Grand Ridge 4) EDAC/igen6: add support for Intel Alder Lake N The following changes since commit 6655dc03f5de7bb734da3ec8eb97f9be281dfbdb: Merge tag 'v6.6.29' into v6.6/standard/base (2024-05-01 16:42:09 -0400) are available in the Git repository at: https://github.com/liux2085/linux-yocto.git v6.6_x86_pull for you to fetch changes up to 9a03c31e128c6be5e0427e54198f76f9b904fe4a: EDAC/i10nm: Add Intel Grand Ridge micro-server support (2024-05-06 20:14:41 +0800) Kan Liang (8): perf/x86/intel/cstate: Cleanup duplicate attr_groups perf/x86/intel/cstate: Add Sierra Forest support perf/x86/intel/cstate: Add Grand Ridge support perf/x86/intel/uncore: Generic uncore_get_uncores and MMIO format of SPR perf/x86/uncore: Use u64 to replace unsigned for the uncore offsets array perf/x86/intel/uncore: Support Granite Rapids perf/x86/intel/uncore: Support IIO free-running counters on GNR perf/x86/intel/uncore: Support Sierra Forest and Grand Ridge Qiuxu Zhuo (3): EDAC/igen6: Make get_mchbar() helper function EDAC/igen6: Add Intel Alder Lake-N SoCs support EDAC/i10nm: Add Intel Grand Ridge micro-server support arch/x86/events/intel/cstate.c | 158 +- arch/x86/events/intel/uncore.c | 12 arch/x86/events/intel/uncore.h | 10 +++--- arch/x86/events/intel/uncore_discovery.c | 5 +++-- arch/x86/events/intel/uncore_discovery.h | 2 +- arch/x86/events/intel/uncore_nhmex.c | 2 +- arch/x86/events/intel/uncore_snbep.c | 137 +++-- drivers/edac/i10nm_base.c| 1 + drivers/edac/igen6_edac.c| 81 ++--- 9 files changed, 339 insertions(+), 69 deletions(-) Thanks, Yongxin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13891): https://lists.yoctoproject.org/g/linux-yocto/message/13891 Mute This Topic: https://lists.yoctoproject.org/mt/105938064/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][yocto-kernel-cache][yocto-6.1/yocto-6.6/master][PATCH] bsp/intel-x86: enable PCIe Advanced Error Reporting driver
Signed-off-by: Yongxin Liu --- bsp/intel-x86/intel-x86.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/bsp/intel-x86/intel-x86.cfg b/bsp/intel-x86/intel-x86.cfg index 8266bf8f..87e50c06 100644 --- a/bsp/intel-x86/intel-x86.cfg +++ b/bsp/intel-x86/intel-x86.cfg @@ -95,6 +95,7 @@ CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_ACPI=y CONFIG_PCIEPORTBUS=y +CONFIG_PCIEAER=y CONFIG_PCIEASPM=y CONFIG_PCIEASPM_DEFAULT=y -- 2.43.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13890): https://lists.yoctoproject.org/g/linux-yocto/message/13890 Mute This Topic: https://lists.yoctoproject.org/mt/105931613/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][PATCH] EDAC/i10nm: Add Intel Grand Ridge micro-server support
From: Qiuxu Zhuo
commit e77086c3750834553cf6fd2255c5f3ee04843ed8 upstream.
The Grand Ridge CPU model uses similar memory controller registers with
Granite Rapids server. Add Grand Ridge CPU model ID for EDAC support.
Tested-by: Ricardo Neri
Signed-off-by: Qiuxu Zhuo
Signed-off-by: Tony Luck
Link: https://lore.kernel.org/r/20240129062040.60809-3-qiuxu.z...@intel.com
Signed-off-by: Yongxin Liu
---
drivers/edac/i10nm_base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/edac/i10nm_base.c b/drivers/edac/i10nm_base.c
index 04ca336b879f..2f2f24f829de 100644
--- a/drivers/edac/i10nm_base.c
+++ b/drivers/edac/i10nm_base.c
@@ -907,6 +907,7 @@ static const struct x86_cpu_id i10nm_cpuids[] = {
X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(EMERALDRAPIDS_X,
X86_STEPPINGS(0x0, 0xf), _cfg),
X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(GRANITERAPIDS_X,
X86_STEPPINGS(0x0, 0xf), _cfg),
X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(ATOM_CRESTMONT_X,
X86_STEPPINGS(0x0, 0xf), _cfg),
+ X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(ATOM_CRESTMONT,
X86_STEPPINGS(0x0, 0xf), _cfg),
{}
};
MODULE_DEVICE_TABLE(x86cpu, i10nm_cpuids);
--
2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13862):
https://lists.yoctoproject.org/g/linux-yocto/message/13862
Mute This Topic: https://lists.yoctoproject.org/mt/105705247/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][PATCH 0/1] Fix Intel Grand Ridge cannot boot issue
Hi Bruce,
Intel Grand Ridge cannot boot after the backport of commit a6a5006dad57
("iommu/vt-d: Retrieve IOMMU perfmon capability information"), in v6.1.83.
This patch is the second patch of the following patch series in mainline.
d8a7c0cf05a2 2023-02-03 11:06 Kan Liangiommu/vt-d: Enable IOMMU perfmon
support
4a0d4265659b 2023-02-03 11:06 Kan Liangiommu/vt-d: Add IOMMU perfmon
overflow handler support
46284c6ceb5e 2023-02-03 11:06 Kan Liangiommu/vt-d: Support cpumask for
IOMMU perfmon
7232ab8b89e9 2023-02-03 11:06 Kan Liangiommu/vt-d: Add IOMMU perfmon
support
dc57875866ab 2023-02-03 11:06 Kan Liangiommu/vt-d: Support Enhanced
Command Interface
a6a5006dad57 2023-02-03 11:06 Kan Liangiommu/vt-d: Retrieve IOMMU
perfmon capability information
4db96bfe9d77 2023-02-03 11:06 Kan Liangiommu/vt-d: Support size of the
register set in DRHD
It is strange only one patch was backported in linux-stable v6.1.
Because in order to eable IOMMU perfmon, all patches should be backported.
Anyway, we need to back port the first patch to boot kernel on newer hardware,
such as Intel GrandRidge.
So please help to merge this patch to v6.1/standard/x86 and
v6.1/standard/preempt-rt/x86.
Thanks,
Yongxin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13861):
https://lists.yoctoproject.org/g/linux-yocto/message/13861
Mute This Topic: https://lists.yoctoproject.org/mt/105704897/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][PATCH 1/1] iommu/vt-d: Support size of the register set in DRHD
From: Kan Liang
commit 4db96bfe9d7772d6ddedd62ce478895999043fd7 upstream.
A new field, which indicates the size of the remapping hardware register
set for this remapping unit, is introduced in the DMA-remapping hardware
unit definition (DRHD) structure with the VT-d Spec 4.0. With this
information, SW doesn't need to 'guess' the size of the register set
anymore.
Update the struct acpi_dmar_hardware_unit to reflect the field. Store the
size of the register set in struct dmar_drhd_unit for each dmar device.
The 'size' information is ResvZ for the old BIOS and platforms. Fall back
to the old guessing method. There is nothing changed.
Signed-off-by: Kan Liang
Link:
https://lore.kernel.org/r/20230128200428.1459118-2-kan.li...@linux.intel.com
Signed-off-by: Lu Baolu
Signed-off-by: Joerg Roedel
Signed-off-by: Yongxin Liu
---
drivers/iommu/intel/dmar.c | 11 +++
include/acpi/actbl1.h | 2 +-
include/linux/dmar.h | 1 +
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 4759f79ad7b9..b8dd628125f4 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -428,6 +428,8 @@ static int dmar_parse_one_drhd(struct acpi_dmar_header
*header, void *arg)
memcpy(dmaru->hdr, header, header->length);
dmaru->reg_base_addr = drhd->address;
dmaru->segment = drhd->segment;
+ /* The size of the register set is 2 ^ N 4 KB pages. */
+ dmaru->reg_size = 1UL << (drhd->size + 12);
dmaru->include_all = drhd->flags & 0x1; /* BIT0: INCLUDE_ALL */
dmaru->devices = dmar_alloc_dev_scope((void *)(drhd + 1),
((void *)drhd) +
drhd->header.length,
@@ -957,17 +959,18 @@ static void unmap_iommu(struct intel_iommu *iommu)
/**
* map_iommu: map the iommu's registers
* @iommu: the iommu to map
- * @phys_addr: the physical address of the base resgister
+ * @drhd: DMA remapping hardware definition structure
*
* Memory map the iommu's registers. Start w/ a single page, and
* possibly expand if that turns out to be insufficent.
*/
-static int map_iommu(struct intel_iommu *iommu, u64 phys_addr)
+static int map_iommu(struct intel_iommu *iommu, struct dmar_drhd_unit *drhd)
{
+ u64 phys_addr = drhd->reg_base_addr;
int map_size, err=0;
iommu->reg_phys = phys_addr;
- iommu->reg_size = VTD_PAGE_SIZE;
+ iommu->reg_size = drhd->reg_size;
if (!request_mem_region(iommu->reg_phys, iommu->reg_size, iommu->name))
{
pr_err("Can't reserve memory\n");
@@ -1051,7 +1054,7 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
}
sprintf(iommu->name, "dmar%d", iommu->seq_id);
- err = map_iommu(iommu, drhd->reg_base_addr);
+ err = map_iommu(iommu, drhd);
if (err) {
pr_err("Failed to map %s\n", iommu->name);
goto error_free_seq_id;
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 15c78678c5d3..c5deb47ecee1 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -655,7 +655,7 @@ struct acpi_dmar_pci_path {
struct acpi_dmar_hardware_unit {
struct acpi_dmar_header header;
u8 flags;
- u8 reserved;
+ u8 size;/* Size of the register set */
u16 segment;
u64 address;/* Register Base Address */
};
diff --git a/include/linux/dmar.h b/include/linux/dmar.h
index d81a51978d01..725d5e6acec0 100644
--- a/include/linux/dmar.h
+++ b/include/linux/dmar.h
@@ -39,6 +39,7 @@ struct dmar_drhd_unit {
struct list_head list; /* list of drhd units */
struct acpi_dmar_header *hdr; /* ACPI header */
u64 reg_base_addr; /* register base address*/
+ unsigned long reg_size; /* size of register set */
struct dmar_dev_scope *devices;/* target device array */
int devices_cnt;/* target device count */
u16 segment;/* PCI domain */
--
2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13860):
https://lists.yoctoproject.org/g/linux-yocto/message/13860
Mute This Topic: https://lists.yoctoproject.org/mt/105704896/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][yocto-kernel-cache][master/yocto-6.6][PATCH 1/3] features/vfio: remove CONFIG_VFIO_VIRQFD
CONFIG_VFIO_VIRQFD was changed to bool in kernel commit
e2d55709398e ("vfio: Fold vfio_virqfd.ko into vfio.ko") and
it is not user selectable.
Signed-off-by: Yongxin Liu
---
features/vfio/vfio.cfg | 1 -
1 file changed, 1 deletion(-)
diff --git a/features/vfio/vfio.cfg b/features/vfio/vfio.cfg
index 96c9208e..2a38f6d9 100644
--- a/features/vfio/vfio.cfg
+++ b/features/vfio/vfio.cfg
@@ -1,6 +1,5 @@
# SPDX-License-Identifier: MIT
CONFIG_VFIO_IOMMU_TYPE1=m
-CONFIG_VFIO_VIRQFD=m
CONFIG_VFIO=m
CONFIG_VFIO_PCI=m
CONFIG_VFIO_PCI_VGA=y
--
2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13692):
https://lists.yoctoproject.org/g/linux-yocto/message/13692
Mute This Topic: https://lists.yoctoproject.org/mt/105000432/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][yocto-kernel-cache][master/yocto-6.6][PATCH 2/3] features/vfio: remove CONFIG_VFIO_MDEV
CONFIG_VFIO_MDEV wasn't a user choice after kerne commit
8bf8c5ee1f38 ("vfio-mdev: turn VFIO_MDEV into a selectable symbol").
Signed-off-by: Yongxin Liu
---
features/vfio/vfio.cfg | 1 -
1 file changed, 1 deletion(-)
diff --git a/features/vfio/vfio.cfg b/features/vfio/vfio.cfg
index 2a38f6d9..94991365 100644
--- a/features/vfio/vfio.cfg
+++ b/features/vfio/vfio.cfg
@@ -6,4 +6,3 @@ CONFIG_VFIO_PCI_VGA=y
CONFIG_VFIO_PCI_MMAP=y
CONFIG_VFIO_PCI_INTX=y
CONFIG_VIRT_DRIVERS=y
-CONFIG_VFIO_MDEV=m
--
2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13693):
https://lists.yoctoproject.org/g/linux-yocto/message/13693
Mute This Topic: https://lists.yoctoproject.org/mt/105000433/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][yocto-kernel-cache][master/yocto-6.6][PATCH 3/3] bsp/intel-x86: remove CONFIG_IXGB
ixgb driver was removed in kernel commit e485f3a6eae0
("ixgb: Remove ixgb driver").
Signed-off-by: Yongxin Liu
---
bsp/intel-x86/intel-x86.cfg | 5 -
1 file changed, 5 deletions(-)
diff --git a/bsp/intel-x86/intel-x86.cfg b/bsp/intel-x86/intel-x86.cfg
index ee01e61e..8266bf8f 100644
--- a/bsp/intel-x86/intel-x86.cfg
+++ b/bsp/intel-x86/intel-x86.cfg
@@ -153,11 +153,6 @@ CONFIG_HOSTAP=y
#
CONFIG_RTL8723BE=m
-#
-# Intel devices
-#
-CONFIG_IXGB=y
-
#
# nvram support
#
--
2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13694):
https://lists.yoctoproject.org/g/linux-yocto/message/13694
Mute This Topic: https://lists.yoctoproject.org/mt/105000434/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][yocto-kernel-cache][master/yocto-6.6][PATCH] bsp/intel-x86: remove intel-x86-64-preempt-rt.cfg in scc file
intel-x86-64-preempt-rt.cfg was removed in commit bd20a636b044
("config: remove mis-located configuration fragment").
Signed-off-by: Yongxin Liu
---
bsp/intel-x86/intel-x86-64-preempt-rt.scc | 1 -
1 file changed, 1 deletion(-)
diff --git a/bsp/intel-x86/intel-x86-64-preempt-rt.scc
b/bsp/intel-x86/intel-x86-64-preempt-rt.scc
index 63d517ec..e776cfa9 100644
--- a/bsp/intel-x86/intel-x86-64-preempt-rt.scc
+++ b/bsp/intel-x86/intel-x86-64-preempt-rt.scc
@@ -8,4 +8,3 @@ include ktypes/preempt-rt
include intel-x86-64.scc
include features/tsn/tsn.scc
kconf hardware cfs-bandwidth.cfg
-kconf hardware intel-x86-64-preempt-rt.cfg
--
2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13691):
https://lists.yoctoproject.org/g/linux-yocto/message/13691
Mute This Topic: https://lists.yoctoproject.org/mt/104997867/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][yocto-kernel-cache][yocto-5.15 and yocto-6.1][PATCH] features/net_sched: remove retired config NET_SCH_CBQ and NET_SCH_DSMARK
CONFIG_NET_SCH_CBQ was retired in kernel upstream commit 051d442098421
("net/sched: Retire CBQ qdisc").
CONFIG_NET_SCH_DSMARK was retired in kernel upstream commit bbe77c14ee61
("net/sched: Retire dsmark qdisc").
Signed-off-by: Yongxin Liu
---
features/net_sched/net_sched.cfg | 2 --
1 file changed, 2 deletions(-)
diff --git a/features/net_sched/net_sched.cfg b/features/net_sched/net_sched.cfg
index 4d72a9f9..d0473170 100644
--- a/features/net_sched/net_sched.cfg
+++ b/features/net_sched/net_sched.cfg
@@ -7,7 +7,6 @@ CONFIG_NET_SCHED=y
#
# Queueing/Scheduling
#
-CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_PRIO=m
@@ -16,7 +15,6 @@ CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
-CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_SCH_CODEL=m
--
2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13627):
https://lists.yoctoproject.org/g/linux-yocto/message/13627
Mute This Topic: https://lists.yoctoproject.org/mt/104714319/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][Pull Request ] cstate, uncore, i10nm_edac and isst update for some x86 platforms
Hi Bruce and others, Please help to review and merge this Pull Request for linux-yocto, branch "v6.1/standard/x86" and "v6.1/standard/preempt-rt/x86". All patches are from mainline kernel. Just some context change in several patches. This patch series basically did the following changes. 1) Intel cstate performance events: add support for Grand Ridge and Sierra Forest 2) Intel uncore performance events: add support for Sierra Forest, Grand Ridge and Granite Rapids 3) EDAC/i10nm: add/improve support for Sierra Forest, Granite Rapids, Emerald Rapids and Sapphire Rapids 4) Intel Speed Select Technology driver support for Sierra Forest and Granite Rapids Thanks @Hamer, Marcel and @Abdelsayed, George for your valuable help on the issue about Grand Ridge. The following changes since commit 63f434d8f5ebe61bb6060a5a6cb1f75d0d40901f: Merge branch 'v6.1/standard/base' into v6.1/standard/x86 (2024-02-20 20:13:42 -0500) are available in the Git repository at: https://github.com/liux2085/linux-yocto.git v6.1_x86_pull for you to fetch changes up to f87e41cf8d9f201a56b30abb9c090699fd1bf3f0: perf/x86/intel/uncore: Support Sierra Forest and Grand Ridge (2024-02-25 15:42:49 +0800) Alexander Antonov (7): perf/x86/intel/uncore: Generalize IIO topology support perf/x86/intel/uncore: Introduce UPI topology type perf/x86/intel/uncore: Generalize get_topology() for SKX PMUs perf/x86/intel/uncore: Enable UPI topology discovery for Skylake Server perf/x86/intel/uncore: Get UPI NodeID and GroupID perf/x86/intel/uncore: Enable UPI topology discovery for Icelake Server perf/x86/intel/uncore: Enable UPI topology discovery for Sapphire Rapids Artem Bityutskiy (1): perf/x86/cstate: Add Granite Rapids support Kan Liang (15): perf/x86/uncore: Factor out uncore_device_to_die() perf/x86/uncore: Fix potential NULL pointer in uncore_get_alias_name perf/x86/uncore: Ignore broken units in discovery table perf/x86/uncore: Add a quirk for UPI on SPR perf/x86/intel: Add Granite Rapids perf/x86/msr: Add Granite Rapids perf/x86/intel/cstate: Cleanup duplicate attr_groups perf/x86/intel/cstate: Add Sierra Forest support perf/x86/intel/cstate: Add Grand Ridge support x86/smp: Export symbol cpu_clustergroup_mask() perf/x86/intel/uncore: Generic uncore_get_uncores and MMIO format of SPR perf/x86/uncore: Use u64 to replace unsigned for the uncore offsets array perf/x86/intel/uncore: Support Granite Rapids perf/x86/intel/uncore: Support IIO free-running counters on GNR perf/x86/intel/uncore: Support Sierra Forest and Grand Ridge Peter Zijlstra (1): x86/cpu: Fix Crestmont uarch Qiuxu Zhuo (4): EDAC/i10nm: Add Intel Emerald Rapids server support EDAC/i10nm: Make more configurations CPU model specific EDAC/i10nm: Add Intel Granite Rapids server support EDAC/i10nm: Add Intel Sierra Forest server support Srinivas Pandruvada (2): x86/intel_epb: Set Alder Lake N and Raptor Lake P normal EPB platform/x86: ISST: Add support for MSR 0x54 Stephane Eranian (1): perf/x86/intel/uncore: Add events for Intel SPR IMC PMU Youquan Song (1): EDAC/i10nm: Add driver decoder for Sapphire Rapids server arch/x86/events/intel/core.c| 16 +- arch/x86/events/intel/cstate.c | 160 + arch/x86/events/intel/uncore.c | 46 - arch/x86/events/intel/uncore.h | 35 +++- arch/x86/events/intel/uncore_discovery.c| 47 +++-- arch/x86/events/intel/uncore_discovery.h| 16 +- arch/x86/events/intel/uncore_nhmex.c| 2 +- arch/x86/events/intel/uncore_snbep.c| 732 - arch/x86/events/msr.c | 2 + arch/x86/include/asm/intel-family.h | 5 +- arch/x86/include/asm/msr-index.h| 1 + arch/x86/kernel/cpu/intel_epb.c | 7 +- arch/x86/kernel/smpboot.c | 1 + drivers/edac/i10nm_base.c | 460 ++-- drivers/edac/skx_common.h | 37 +++- drivers/platform/x86/intel/speed_select_if/isst_if_common.c | 28 +++ 16 files changed, 1345 insertions(+), 250 deletions(-) Thanks, Yongxin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13606): https://lists.yoctoproject.org/g/linux-yocto/message/13606 Mute This Topic: https://lists.yoctoproject.org/mt/104560572/21656 Group Owner:
[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][PATCH 1/2] EDAC/igen6: Make get_mchbar() helper function
From: Qiuxu Zhuo
commit a264f715ecb3e6dac7c4d7135db74eb2379cb086 upstream.
Make get_mchbar() helper function to retrieve the BAR address of
the memory controller. No function changes.
Signed-off-by: Qiuxu Zhuo
Signed-off-by: Tony Luck
Signed-off-by: Yongxin Liu
---
drivers/edac/igen6_edac.c | 46 ++-
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/edac/igen6_edac.c b/drivers/edac/igen6_edac.c
index 8ec70da8d84f..3d30b370615f 100644
--- a/drivers/edac/igen6_edac.c
+++ b/drivers/edac/igen6_edac.c
@@ -222,6 +222,36 @@ static struct work_struct ecclog_work;
#define DID_ADL_SKU3 0x4621
#define DID_ADL_SKU4 0x4641
+static int get_mchbar(struct pci_dev *pdev, u64 *mchbar)
+{
+ union {
+ u64 v;
+ struct {
+ u32 v_lo;
+ u32 v_hi;
+ };
+ } u;
+
+ if (pci_read_config_dword(pdev, MCHBAR_OFFSET, _lo)) {
+ igen6_printk(KERN_ERR, "Failed to read lower MCHBAR\n");
+ return -ENODEV;
+ }
+
+ if (pci_read_config_dword(pdev, MCHBAR_OFFSET + 4, _hi)) {
+ igen6_printk(KERN_ERR, "Failed to read upper MCHBAR\n");
+ return -ENODEV;
+ }
+
+ if (!(u.v & MCHBAR_EN)) {
+ igen6_printk(KERN_ERR, "MCHBAR is disabled\n");
+ return -ENODEV;
+ }
+
+ *mchbar = MCHBAR_BASE(u.v);
+
+ return 0;
+}
+
static bool ehl_ibecc_available(struct pci_dev *pdev)
{
u32 v;
@@ -969,22 +999,8 @@ static int igen6_pci_setup(struct pci_dev *pdev, u64
*mchbar)
igen6_tom = u.v & GENMASK_ULL(38, 20);
- if (pci_read_config_dword(pdev, MCHBAR_OFFSET, _lo)) {
- igen6_printk(KERN_ERR, "Failed to read lower MCHBAR\n");
- goto fail;
- }
-
- if (pci_read_config_dword(pdev, MCHBAR_OFFSET + 4, _hi)) {
- igen6_printk(KERN_ERR, "Failed to read upper MCHBAR\n");
+ if (get_mchbar(pdev, mchbar))
goto fail;
- }
-
- if (!(u.v & MCHBAR_EN)) {
- igen6_printk(KERN_ERR, "MCHBAR is disabled\n");
- goto fail;
- }
-
- *mchbar = MCHBAR_BASE(u.v);
#ifdef CONFIG_EDAC_DEBUG
if (pci_read_config_dword(pdev, TOUUD_OFFSET, _lo))
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13585):
https://lists.yoctoproject.org/g/linux-yocto/message/13585
Mute This Topic: https://lists.yoctoproject.org/mt/104464076/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][PATCH 2/2] EDAC/igen6: Add Intel Alder Lake-N SoCs support
From: Qiuxu Zhuo
commit c4a5398991fd2ad3011c486571300574495bc834 upstream.
Add Intel Alder Lake-N SoC compute die IDs for EDAC support.
Alder Lake-N, with one memory controller, is a reduced version of
Alder Lake-P, which has two memory controllers.
Signed-off-by: Qiuxu Zhuo
Signed-off-by: Tony Luck
Signed-off-by: Yongxin Liu
---
drivers/edac/igen6_edac.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/edac/igen6_edac.c b/drivers/edac/igen6_edac.c
index 3d30b370615f..8317655d8b93 100644
--- a/drivers/edac/igen6_edac.c
+++ b/drivers/edac/igen6_edac.c
@@ -222,6 +222,19 @@ static struct work_struct ecclog_work;
#define DID_ADL_SKU3 0x4621
#define DID_ADL_SKU4 0x4641
+/* Compute die IDs for Alder Lake-N with IBECC */
+#define DID_ADL_N_SKU1 0x4614
+#define DID_ADL_N_SKU2 0x4617
+#define DID_ADL_N_SKU3 0x461b
+#define DID_ADL_N_SKU4 0x461c
+#define DID_ADL_N_SKU5 0x4673
+#define DID_ADL_N_SKU6 0x4674
+#define DID_ADL_N_SKU7 0x4675
+#define DID_ADL_N_SKU8 0x4677
+#define DID_ADL_N_SKU9 0x4678
+#define DID_ADL_N_SKU100x4679
+#define DID_ADL_N_SKU110x467c
+
static int get_mchbar(struct pci_dev *pdev, u64 *mchbar)
{
union {
@@ -433,6 +446,17 @@ static struct res_config adl_cfg = {
.err_addr_to_imc_addr = adl_err_addr_to_imc_addr,
};
+static struct res_config adl_n_cfg = {
+ .machine_check = true,
+ .num_imc= 1,
+ .imc_base = 0xd800,
+ .ibecc_base = 0xd400,
+ .ibecc_error_log_offset = 0x68,
+ .ibecc_available= tgl_ibecc_available,
+ .err_addr_to_sys_addr = adl_err_addr_to_sys_addr,
+ .err_addr_to_imc_addr = adl_err_addr_to_imc_addr,
+};
+
static const struct pci_device_id igen6_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, DID_EHL_SKU5), (kernel_ulong_t)_cfg },
{ PCI_VDEVICE(INTEL, DID_EHL_SKU6), (kernel_ulong_t)_cfg },
@@ -454,6 +478,17 @@ static const struct pci_device_id igen6_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, DID_ADL_SKU2), (kernel_ulong_t)_cfg },
{ PCI_VDEVICE(INTEL, DID_ADL_SKU3), (kernel_ulong_t)_cfg },
{ PCI_VDEVICE(INTEL, DID_ADL_SKU4), (kernel_ulong_t)_cfg },
+ { PCI_VDEVICE(INTEL, DID_ADL_N_SKU1), (kernel_ulong_t)_n_cfg },
+ { PCI_VDEVICE(INTEL, DID_ADL_N_SKU2), (kernel_ulong_t)_n_cfg },
+ { PCI_VDEVICE(INTEL, DID_ADL_N_SKU3), (kernel_ulong_t)_n_cfg },
+ { PCI_VDEVICE(INTEL, DID_ADL_N_SKU4), (kernel_ulong_t)_n_cfg },
+ { PCI_VDEVICE(INTEL, DID_ADL_N_SKU5), (kernel_ulong_t)_n_cfg },
+ { PCI_VDEVICE(INTEL, DID_ADL_N_SKU6), (kernel_ulong_t)_n_cfg },
+ { PCI_VDEVICE(INTEL, DID_ADL_N_SKU7), (kernel_ulong_t)_n_cfg },
+ { PCI_VDEVICE(INTEL, DID_ADL_N_SKU8), (kernel_ulong_t)_n_cfg },
+ { PCI_VDEVICE(INTEL, DID_ADL_N_SKU9), (kernel_ulong_t)_n_cfg },
+ { PCI_VDEVICE(INTEL, DID_ADL_N_SKU10), (kernel_ulong_t)_n_cfg },
+ { PCI_VDEVICE(INTEL, DID_ADL_N_SKU11), (kernel_ulong_t)_n_cfg },
{ },
};
MODULE_DEVICE_TABLE(pci, igen6_pci_tbl);
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13587):
https://lists.yoctoproject.org/g/linux-yocto/message/13587
Mute This Topic: https://lists.yoctoproject.org/mt/104464078/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][PATCH 0/2] Add EDAC support for Alder Lake N
Hi Bruce, The following two patches are from mainline kernel without any change. They can add EDAC support on Alder Lake N. Could you help to merge them to v6.1/standard/x86 and v6.1/standard/preempt-rt/x86? Qiuxu Zhuo (2): EDAC/igen6: Make get_mchbar() helper function EDAC/igen6: Add Intel Alder Lake-N SoCs support drivers/edac/igen6_edac.c | 81 +++ 1 file changed, 66 insertions(+), 15 deletions(-) Thanks, Yongxin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13586): https://lists.yoctoproject.org/g/linux-yocto/message/13586 Mute This Topic: https://lists.yoctoproject.org/mt/104464077/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][yocto-kernel-cache][master/yocto-6.6/yocto-6.1][PATCH] bsp/intel-x86: add support for TI DP83867 Gigabit PHY
Signed-off-by: Yongxin Liu --- bsp/intel-x86/intel-x86.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/bsp/intel-x86/intel-x86.cfg b/bsp/intel-x86/intel-x86.cfg index c36e938b..ee01e61e 100644 --- a/bsp/intel-x86/intel-x86.cfg +++ b/bsp/intel-x86/intel-x86.cfg @@ -366,3 +366,4 @@ CONFIG_EXTCON=y # MII PHY device drivers CONFIG_MARVELL_PHY=y +CONFIG_DP83867_PHY=y -- 2.40.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13506): https://lists.yoctoproject.org/g/linux-yocto/message/13506 Mute This Topic: https://lists.yoctoproject.org/mt/103927284/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs
> -Original Message-
> From: Gortmaker, Paul
> Sent: Friday, December 1, 2023 11:14
> To: Liu, Yongxin
> Cc: Bruce Ashfield ; linux-
> yo...@lists.yoctoproject.org
> Subject: Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number
> of CPUs
>
> [RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs]
> On 30/11/2023 (Thu 21:43) Liu, Yongxin wrote:
>
> > > -Original Message-
> > > From: Gortmaker, Paul
> > > Sent: Friday, December 1, 2023 10:27
> > > To: Liu, Yongxin
> > > Cc: Bruce Ashfield ; linux-
> > > yo...@lists.yoctoproject.org
> > > Subject: Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for
> > > number of CPUs
> > >
> > > [RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number
> > > of CPUs] On 30/11/2023 (Thu 20:12) Liu, Yongxin wrote:
> > >
> > > > > -Original Message-
> > > > > From: linux-yocto@lists.yoctoproject.org > > > > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
> > > > > lists.yoctoproject.org
> > > > > Sent: Friday, December 1, 2023 03:08
> > > > > To: Bruce Ashfield
> > > > > Cc: linux-yocto@lists.yoctoproject.org
> > > > > Subject: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for
> > > > > number of CPUs
> > > > >
> > > > > From: Paul Gortmaker
> > > > >
> > > > > The x86-64 BSP isn't quite the same as the "more specific" BSP
> > > > > like a Beaglebone Black or the (now deleted) Edgerouter. Where
> > > > > we have exact hardware specifics for boards like those, the
> > > > > x86-64 BSP is more of a "generic" thing used as the baseline
> > > > > across an endless sea
> > > of boards.
> > > > >
> > > > > To that end, this is somewhat a revert of commit bd77e1f904f6
> > > > > ("bsp/intel-x86: change the supported maximum number of CPUs to
> > > > > 512 in 64- bit bsp")
> > > > >
> > > > > It is great that a handful of people out there are using Yocto
> > > > > on these huge server machines, but that doesn't reflect 99% of
> > > > > the rest of us who continue to lean towards the original
> > > > > "embedded theme" of
> > > Yocto.
> > > > >
> > > > > That means a whole bunch of extra per-CPU jumping through hoops;
> > > > > some can be mitigated by booting with "nr_cpus=4" (or whatever
> > > > > the core count
> > > > > is) but I guarantee largely nobody out there is doing that.
> > > > >
> > > > > Let those users with the crazy CPU count own that config
> > > > > customization locally. The default is 64 which still seems way
> > > > > too large IMHO, but at least we are moving in the right direction.
> > > >
> > > >
> > > > This intel-x86-64 BSP is a generic one used from mobile to server.
> > > >
> > > > Customers need to customize not only the CPU number config but
> > > > also other configs, like, removing unused drivers or adding debug
> options.
> > > > From this point of view, there is no difference between 64 or 512.
> >
> > I changed 64 to 512. Because we have server machines with more than 64
> CPU.
> > I want the BSP support those machines by default.
>
> But you still miss the point. It doesn't matter what you or any company
> "want" in this case. Like it or not, it is a shared resource and so the
> defaults have to be what is good for Yocto project and not for *you*
>
> >
> > >
> > > So you've basically argued my case for me. If changes are
> > > inevitable, then why do we change the default?
> > >
> > > > But it changes the "rule" that intel-x86-64 works for all
> > > > supported
> > > platforms.
> > > > We need to do extra work for servers with large CPU number.
> > >
> > > No. There is no "rule" in Yocto like that. That is nonsense
> > > because there is no way Yocto can commit to "support" all the crazy
> > > different
> > > x86-64 variants out there.
> >
> >
> > I think this "bsp/intel-x86" is used only by Wind River.
> > So bsp/intel-x86 should work for all supported machines claimed by Wind
> River.
>
> No. That is where you are dead wrong. Wind River does not own Yocto.
> Think for a minute. A new Yocto user comes along and sees "intel-x86"
> and because that name is so generic -- thinks "I'll build that for my old
> PC."
I have a question why we need bsp/intel-x86, because Yocto already has
bsp/intel-common and bsp/common-pc?
>
> > If we need to do some local change to support some machine. That's not
> good.
> > Because people usually build image with default configs and then
> complain something doesn't work.
>
> Again, it is NOT the problem of the Yocto project what isn't good for YOU.
> If you need EDAC and NUMA and 500+ CPU support, then make a proper BSP
> with those settings and submit it as "bsp/mega-server-2000" or whatever.
Then I think we should revise bsp/intel-x86, because it has enabled many
uncommon features by
intel-x86.scc:include features/intel-idxd/intel-idxd.scc
intel-x86.scc:include features/intel-uncore-frequency/intel-uncore-frequency.scc
intel-x86.scc:include features/intel-dptf/intel-dptf.scc
intel-x86.scc:include
Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs
> -Original Message-
> From: Gortmaker, Paul
> Sent: Friday, December 1, 2023 10:27
> To: Liu, Yongxin
> Cc: Bruce Ashfield ; linux-
> yo...@lists.yoctoproject.org
> Subject: Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number
> of CPUs
>
> [RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs]
> On 30/11/2023 (Thu 20:12) Liu, Yongxin wrote:
>
> > > -Original Message-
> > > From: linux-yocto@lists.yoctoproject.org > > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
> > > lists.yoctoproject.org
> > > Sent: Friday, December 1, 2023 03:08
> > > To: Bruce Ashfield
> > > Cc: linux-yocto@lists.yoctoproject.org
> > > Subject: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for
> > > number of CPUs
> > >
> > > From: Paul Gortmaker
> > >
> > > The x86-64 BSP isn't quite the same as the "more specific" BSP like
> > > a Beaglebone Black or the (now deleted) Edgerouter. Where we have
> > > exact hardware specifics for boards like those, the x86-64 BSP is
> > > more of a "generic" thing used as the baseline across an endless sea
> of boards.
> > >
> > > To that end, this is somewhat a revert of commit bd77e1f904f6
> > > ("bsp/intel-x86: change the supported maximum number of CPUs to 512
> > > in 64- bit bsp")
> > >
> > > It is great that a handful of people out there are using Yocto on
> > > these huge server machines, but that doesn't reflect 99% of the rest
> > > of us who continue to lean towards the original "embedded theme" of
> Yocto.
> > >
> > > That means a whole bunch of extra per-CPU jumping through hoops;
> > > some can be mitigated by booting with "nr_cpus=4" (or whatever the
> > > core count
> > > is) but I guarantee largely nobody out there is doing that.
> > >
> > > Let those users with the crazy CPU count own that config
> > > customization locally. The default is 64 which still seems way too
> > > large IMHO, but at least we are moving in the right direction.
> >
> >
> > This intel-x86-64 BSP is a generic one used from mobile to server.
> >
> > Customers need to customize not only the CPU number config but also
> > other configs, like, removing unused drivers or adding debug options.
> > From this point of view, there is no difference between 64 or 512.
I changed 64 to 512. Because we have server machines with more than 64 CPU.
I want the BSP support those machines by default.
>
> So you've basically argued my case for me. If changes are inevitable,
> then why do we change the default?
>
> > But it changes the "rule" that intel-x86-64 works for all supported
> platforms.
> > We need to do extra work for servers with large CPU number.
>
> No. There is no "rule" in Yocto like that. That is nonsense because
> there is no way Yocto can commit to "support" all the crazy different
> x86-64 variants out there.
I think this "bsp/intel-x86" is used only by Wind River.
So bsp/intel-x86 should work for all supported machines claimed by Wind River.
If we need to do some local change to support some machine. That's not good.
Because people usually build image with default configs and then complain
something doesn't work.
Thanks,
Yongxin
> If a re-seller/integrator wants to take Yocto and tune it for platform XYZ
> because there is customer demand and claim it is then "supported" by them,
> then fine. But then to expect the Yocto project to own that? No.
>
> Paul.
> --
>
> >
> > Thanks,
> > Yongxin
> >
> > >
> > > Signed-off-by: Paul Gortmaker
> > > ---
> > > bsp/intel-x86/intel-x86-64.cfg | 3 ---
> > > 1 file changed, 3 deletions(-)
> > >
> > > diff --git a/bsp/intel-x86/intel-x86-64.cfg
> > > b/bsp/intel-x86/intel-x86- 64.cfg index 58b0fed637e8..da9bc7b57eca
> > > 100644
> > > --- a/bsp/intel-x86/intel-x86-64.cfg
> > > +++ b/bsp/intel-x86/intel-x86-64.cfg
> > > @@ -31,6 +31,3 @@ CONFIG_CRYPTO_DEV_QAT_DH895xCCVF=m
> > >
> > > # x86 CPU resource control support
> > > CONFIG_X86_CPU_RESCTRL=y
> > > -
> > > -# Processor type and features
> > > -CONFIG_NR_CPUS=512
> > > --
> > > 2.40.0
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13345):
https://lists.yoctoproject.org/g/linux-yocto/message/13345
Mute This Topic: https://lists.yoctoproject.org/mt/102900654/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs
> -Original Message-
> From: linux-yocto@lists.yoctoproject.org yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
> lists.yoctoproject.org
> Sent: Friday, December 1, 2023 03:08
> To: Bruce Ashfield
> Cc: linux-yocto@lists.yoctoproject.org
> Subject: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of
> CPUs
>
> From: Paul Gortmaker
>
> The x86-64 BSP isn't quite the same as the "more specific" BSP like a
> Beaglebone Black or the (now deleted) Edgerouter. Where we have exact
> hardware specifics for boards like those, the x86-64 BSP is more of a
> "generic" thing used as the baseline across an endless sea of boards.
>
> To that end, this is somewhat a revert of commit bd77e1f904f6
> ("bsp/intel-x86: change the supported maximum number of CPUs to 512 in 64-
> bit bsp")
>
> It is great that a handful of people out there are using Yocto on these
> huge server machines, but that doesn't reflect 99% of the rest of us who
> continue to lean towards the original "embedded theme" of Yocto.
>
> That means a whole bunch of extra per-CPU jumping through hoops; some can
> be mitigated by booting with "nr_cpus=4" (or whatever the core count
> is) but I guarantee largely nobody out there is doing that.
>
> Let those users with the crazy CPU count own that config customization
> locally. The default is 64 which still seems way too large IMHO, but at
> least we are moving in the right direction.
This intel-x86-64 BSP is a generic one used from mobile to server.
Customers need to customize not only the CPU number config but also other
configs,
like, removing unused drivers or adding debug options.
>From this point of view, there is no difference between 64 or 512.
But it changes the "rule" that intel-x86-64 works for all supported platforms.
We need to do extra work for servers with large CPU number.
Thanks,
Yongxin
>
> Signed-off-by: Paul Gortmaker
> ---
> bsp/intel-x86/intel-x86-64.cfg | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86-
> 64.cfg index 58b0fed637e8..da9bc7b57eca 100644
> --- a/bsp/intel-x86/intel-x86-64.cfg
> +++ b/bsp/intel-x86/intel-x86-64.cfg
> @@ -31,6 +31,3 @@ CONFIG_CRYPTO_DEV_QAT_DH895xCCVF=m
>
> # x86 CPU resource control support
> CONFIG_X86_CPU_RESCTRL=y
> -
> -# Processor type and features
> -CONFIG_NR_CPUS=512
> --
> 2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13342):
https://lists.yoctoproject.org/g/linux-yocto/message/13342
Mute This Topic: https://lists.yoctoproject.org/mt/102900654/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [PATCH 3/5] x86-64: don't force EDAC support on everyone
> -Original Message- > From: linux-yocto@lists.yoctoproject.org yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via > lists.yoctoproject.org > Sent: Friday, December 1, 2023 03:08 > To: Bruce Ashfield > Cc: linux-yocto@lists.yoctoproject.org > Subject: [linux-yocto] [PATCH 3/5] x86-64: don't force EDAC support on > everyone > > From: Paul Gortmaker > > Similar to the argument of why we shouldn't force NUMA on everyone, the > 9 chip registered ECC RAM type stuff also tends to be found mostly on > larger server type stuff and less so on embedded targets. > > We already have a skeleton EDAC feature, so move the features over there. > One could argue that we might want to separate into arch specific config > fragments, but to me - that seems overkill at this point in time. > > Signed-off-by: Paul Gortmaker > --- > bsp/intel-x86/intel-x86-64.cfg | 13 - > features/edac/edac.cfg | 8 > 2 files changed, 8 insertions(+), 13 deletions(-) > > diff --git a/bsp/intel-x86/intel-x86-64.cfg b/bsp/intel-x86/intel-x86- > 64.cfg index f31711e73181..58b0fed637e8 100644 > --- a/bsp/intel-x86/intel-x86-64.cfg > +++ b/bsp/intel-x86/intel-x86-64.cfg > @@ -3,19 +3,6 @@ > # General setup > # > > -# EDAC > -CONFIG_EDAC=y > -CONFIG_EDAC_DEBUG=y > -CONFIG_EDAC_SBRIDGE=m > -CONFIG_ACPI_APEI=y > -CONFIG_ACPI_APEI_EINJ=m > -CONFIG_ACPI_APEI_GHES=y > -CONFIG_EDAC_PND2=m > -CONFIG_EDAC_SKX=m > -CONFIG_EDAC_I10NM=m > -CONFIG_EDAC_IGEN6=m > - > - > # ISH > CONFIG_INTEL_ISH_HID=m > > diff --git a/features/edac/edac.cfg b/features/edac/edac.cfg index > 9b3d3fc59eae..4f75d2f825ee 100644 > --- a/features/edac/edac.cfg > +++ b/features/edac/edac.cfg > @@ -15,3 +15,11 @@ > CONFIG_RAS=y > CONFIG_EDAC=y > CONFIG_EDAC_DEBUG=y > +CONFIG_EDAC_SBRIDGE=m > +CONFIG_ACPI_APEI=y > +CONFIG_ACPI_APEI_EINJ=m > +CONFIG_ACPI_APEI_GHES=y > +CONFIG_EDAC_PND2=m > +CONFIG_EDAC_SKX=m > +CONFIG_EDAC_I10NM=m Other arch/bsp may include edac.scc. They clearly don't want EDAC drivers for x86 platform. And since CONFIG_EDAC_I10NM depends on X86_64, won't it cause warnings when doing kernel_configcheck for other arch? Thanks, Yongxin > +CONFIG_EDAC_IGEN6=m > -- > 2.40.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13341): https://lists.yoctoproject.org/g/linux-yocto/message/13341 Mute This Topic: https://lists.yoctoproject.org/mt/102900653/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v5.15 standard/x86/preempt-rt/x86][PATCH 3/4] Fix to avoid link statys update in KR autneg mode
From: Sudheesh Mavila
Signed-off-by: Sudheesh Mavila
Signed-off-by: Yongxin Liu
---
drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
index ca7372369b3e..ba515ea7a012 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
@@ -1374,7 +1374,8 @@ static void xgbe_phy_status(struct xgbe_prv_data *pdata)
_restart);
if (an_restart) {
xgbe_phy_config_aneg(pdata);
- goto adjust_link;
+ if(XGBE_MODE_KR != pdata->phy_if.phy_impl.cur_mode(pdata))
+ goto adjust_link;
}
if (pdata->phy.link) {
@@ -1394,7 +1395,7 @@ static void xgbe_phy_status(struct xgbe_prv_data *pdata)
if (test_bit(XGBE_LINK_INIT, >dev_state)) {
xgbe_check_link_timeout(pdata);
- if (link_aneg)
+ if ((link_aneg) && (XGBE_MODE_KR !=
pdata->phy_if.phy_impl.cur_mode(pdata)))
return;
}
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13018):
https://lists.yoctoproject.org/g/linux-yocto/message/13018
Mute This Topic: https://lists.yoctoproject.org/mt/100956971/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v5.15 standard/x86/preempt-rt/x86][PATCH 4/4] amd-xgbe KR link up fix , with PHY reset if AN fails
From: Sudheesh Mavila
Signed-off-by: Sudheesh Mavila
Signed-off-by: Yongxin Liu
---
drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 40 +++--
drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 4 +--
2 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
index ba515ea7a012..3cdc51755164 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
@@ -827,6 +827,7 @@ static void xgbe_an37_state_machine(struct xgbe_prv_data
*pdata)
static void xgbe_an73_state_machine(struct xgbe_prv_data *pdata)
{
enum xgbe_an cur_state = pdata->an_state;
+ int phy_reset = 0;
if (!pdata->an_int)
return;
@@ -892,6 +893,10 @@ static void xgbe_an73_state_machine(struct xgbe_prv_data
*pdata)
pdata->an_int = 0;
xgbe_an73_clear_interrupts(pdata);
}
+ /* Bug fix for AN failure in KR mode */
+ if ((pdata->an_state == XGBE_AN_NO_LINK) || (pdata->an_state ==
XGBE_AN_ERROR)) {
+ phy_reset = 1;
+ }
if (pdata->an_state >= XGBE_AN_COMPLETE) {
pdata->an_result = pdata->an_state;
@@ -905,6 +910,12 @@ static void xgbe_an73_state_machine(struct xgbe_prv_data
*pdata)
netif_dbg(pdata, link, pdata->netdev, "CL73 AN result: %s\n",
xgbe_state_as_string(pdata->an_result));
+ /* Bug fix for AN failure in KR mode */
+ if(phy_reset) {
+ xgbe_kr_mode(pdata);
+ pdata->phy_if.phy_reset(pdata);
+ netif_dbg(pdata, link, pdata->netdev, " PHY Reset\n");
+ }
}
if (cur_state != pdata->an_state)
@@ -1183,12 +1194,11 @@ static int xgbe_phy_config_fixed(struct xgbe_prv_data
*pdata)
return 0;
}
+/* caller should hold an_mutex */
static int __xgbe_phy_config_aneg(struct xgbe_prv_data *pdata, bool set_mode)
{
int ret;
- mutex_lock(>an_mutex);
-
set_bit(XGBE_LINK_INIT, >dev_state);
pdata->link_check = jiffies;
@@ -1255,8 +1265,6 @@ static int __xgbe_phy_config_aneg(struct xgbe_prv_data
*pdata, bool set_mode)
else
clear_bit(XGBE_LINK_ERR, >dev_state);
- mutex_unlock(>an_mutex);
-
return ret;
}
@@ -1361,6 +1369,8 @@ static void xgbe_phy_status(struct xgbe_prv_data *pdata)
unsigned int link_aneg;
int an_restart;
+ mutex_lock(>an_mutex);
+
if (test_bit(XGBE_LINK_ERR, >dev_state)) {
netif_carrier_off(pdata->netdev);
@@ -1374,13 +1384,14 @@ static void xgbe_phy_status(struct xgbe_prv_data *pdata)
_restart);
if (an_restart) {
xgbe_phy_config_aneg(pdata);
- if(XGBE_MODE_KR != pdata->phy_if.phy_impl.cur_mode(pdata))
- goto adjust_link;
+ mutex_unlock(>an_mutex);
+ return;
}
if (pdata->phy.link) {
if (link_aneg && !xgbe_phy_aneg_done(pdata)) {
xgbe_check_link_timeout(pdata);
+ mutex_unlock(>an_mutex);
return;
}
@@ -1394,18 +1405,25 @@ static void xgbe_phy_status(struct xgbe_prv_data *pdata)
} else {
if (test_bit(XGBE_LINK_INIT, >dev_state)) {
xgbe_check_link_timeout(pdata);
-
- if ((link_aneg) && (XGBE_MODE_KR !=
pdata->phy_if.phy_impl.cur_mode(pdata)))
+ /* Bug fix for AN failure in KR mode */
+ if ((link_aneg) && ((XGBE_MODE_KR !=
pdata->phy_if.phy_impl.cur_mode(pdata)) && (XGBE_MODE_KX_1000 !=
pdata->phy_if.phy_impl.cur_mode(pdata {
+ mutex_unlock(>an_mutex);
return;
+ }
}
xgbe_phy_status_result(pdata);
netif_carrier_off(pdata->netdev);
+ /* Bug fix for AN failure in KR mode */
+ if ((link_aneg) && ((XGBE_MODE_KR ==
pdata->phy_if.phy_impl.cur_mode(pdata)) || (XGBE_MODE_KX_1000==
pdata->phy_if.phy_impl.cur_mode(pdata {
+ xgbe_phy_config_aneg(pdata);
+ }
}
adjust_link:
xgbe_phy_adjust_link(pdata);
+ mutex_unlock(>an_mutex);
}
static void xgbe_phy_stop(struct xgbe_prv_data *pdata)
@@ -1484,8 +1502,10 @@ static int xgbe_phy_start(struct xgbe_prv_data *pdata)
xgbe_an_init(pdata);
xgbe_an_enable_interrupts(pdata);
-
- return xgbe_phy_config_aneg(pdata);
+ mutex_lock(>an_mutex);
+ ret = xgbe_phy_config_aneg(pdata);
+ mutex_unlock(>an_mutex);
+ return ret;
err_irq:
if (pdata->dev_irq != pdata->an_irq)
diff
[linux-yocto][v5.15 standard/x86/preempt-rt/x86][PATCH 0/4] amd-x86: fix amd-xgbe connection up and down issue in peer-to-peer network
Hi Bruce, Those 4 patches were from AMD engineer to fix amd-xgbe connection up and down issue in p2p network on amd snowy owl board. Sudheesh Mavila (4): amd-xgbe Sometimes driver report incorrect link status and results in timeout error in driver EMBSWDEV-6825 amd-xgbe KR link up fix Fix to avoid link statys update in KR autneg mode amd-xgbe KR link up fix , with PHY reset if AN fails drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 39 - drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 15 ++-- 2 files changed, 43 insertions(+), 11 deletions(-) Please help to merge them to the following 4 branches. v5.15/standard/x86 v5.15/standard/preempt-rt/x86 v6.1/standard/x86 v6.1/standard/preempt-rt/x86 Thanks, Yongxin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13015): https://lists.yoctoproject.org/g/linux-yocto/message/13015 Mute This Topic: https://lists.yoctoproject.org/mt/100956967/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v5.15 standard/x86/preempt-rt/x86][PATCH 1/4] amd-xgbe Sometimes driver report incorrect link status and results in timeout error in driver EMBSWDEV-6825
From: Sudheesh Mavila
Signed-off-by: Sudheesh Mavila
Signed-off-by: Yongxin Liu
---
drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
index 97e32c0490f8..922ea03ea94a 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
@@ -2628,8 +2628,19 @@ static int xgbe_phy_link_status(struct xgbe_prv_data
*pdata, int *an_restart)
*/
reg = XMDIO_READ(pdata, MDIO_MMD_PCS, MDIO_STAT1);
reg = XMDIO_READ(pdata, MDIO_MMD_PCS, MDIO_STAT1);
- if (reg & MDIO_STAT1_LSTATUS)
- return 1;
+
+ if(phy_data->sfp_speed == XGBE_SFP_SPEED_1) {
+ if ((reg & MDIO_STAT1_LSTATUS) && !(reg & MDIO_STAT1_FAULT)) {
+ return 1;
+ } else {
+ *an_restart = 1;
+ pdata->phy_if.phy_reset(pdata);
+ return 0;
+ }
+ } else {
+ if (reg & MDIO_STAT1_LSTATUS)
+ return 1;
+ }
if (pdata->phy.autoneg == AUTONEG_ENABLE &&
phy_data->port_mode == XGBE_PORT_MODE_BACKPLANE) {
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13016):
https://lists.yoctoproject.org/g/linux-yocto/message/13016
Mute This Topic: https://lists.yoctoproject.org/mt/100956968/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v5.15 standard/x86/preempt-rt/x86][PATCH 2/4] amd-xgbe KR link up fix
From: Sudheesh Mavila
Signed-off-by: Sudheesh Mavila
Signed-off-by: Yongxin Liu
---
drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
index 922ea03ea94a..2b681a09e046 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
@@ -2629,12 +2629,14 @@ static int xgbe_phy_link_status(struct xgbe_prv_data
*pdata, int *an_restart)
reg = XMDIO_READ(pdata, MDIO_MMD_PCS, MDIO_STAT1);
reg = XMDIO_READ(pdata, MDIO_MMD_PCS, MDIO_STAT1);
- if(phy_data->sfp_speed == XGBE_SFP_SPEED_1) {
+ if(phy_data->sfp_speed == XGBE_SFP_SPEED_1 ||(XGBE_MODE_KR ==
xgbe_phy_cur_mode(pdata))) {
if ((reg & MDIO_STAT1_LSTATUS) && !(reg & MDIO_STAT1_FAULT)) {
return 1;
} else {
+ mutex_lock(>an_mutex);
*an_restart = 1;
pdata->phy_if.phy_reset(pdata);
+ mutex_unlock(>an_mutex);
return 0;
}
} else {
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13017):
https://lists.yoctoproject.org/g/linux-yocto/message/13017
Mute This Topic: https://lists.yoctoproject.org/mt/100956969/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][yocto-kernel-cache][yocto-5.19 to master][PATCH] bsp/amd-x86: change PINCTRL_AMD to be built-in driver
Due to kernel commit 41ef3c1a6bb0 ("pinctrl: Don't allow PINCTRL_AMD to
be a module"), driver PINCTRL_AMD can only be built as built-in driver
or disabled.
Signed-off-by: Yongxin Liu
---
bsp/amd-x86/amd-x86.cfg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsp/amd-x86/amd-x86.cfg b/bsp/amd-x86/amd-x86.cfg
index d4a0a8c8..ddd07f20 100644
--- a/bsp/amd-x86/amd-x86.cfg
+++ b/bsp/amd-x86/amd-x86.cfg
@@ -42,7 +42,7 @@ CONFIG_DRM_RADEON_USERPTR=y
#
# PPS generators support
#
-CONFIG_PINCTRL_AMD=m
+CONFIG_PINCTRL_AMD=y
#
# Native drivers
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13009):
https://lists.yoctoproject.org/g/linux-yocto/message/13009
Mute This Topic: https://lists.yoctoproject.org/mt/100908454/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][yocto-kernel-cache][yocto-5.15 to master][PATCH] features/intel-pinctrl: add pinctrl driver for Intel Alder Lake
Signed-off-by: Yongxin Liu --- features/intel-pinctrl/intel-pinctrl.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/features/intel-pinctrl/intel-pinctrl.cfg b/features/intel-pinctrl/intel-pinctrl.cfg index c6a3e7ab..ca928504 100644 --- a/features/intel-pinctrl/intel-pinctrl.cfg +++ b/features/intel-pinctrl/intel-pinctrl.cfg @@ -1,5 +1,6 @@ # SPDX-License-Identifier: MIT CONFIG_PINCTRL_INTEL=y +CONFIG_PINCTRL_ALDERLAKE=y CONFIG_PINCTRL_BAYTRAIL=y CONFIG_PINCTRL_CHERRYVIEW=y CONFIG_PINCTRL_BROXTON=y -- 2.39.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12935): https://lists.yoctoproject.org/g/linux-yocto/message/12935 Mute This Topic: https://lists.yoctoproject.org/mt/100542268/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][yocto-kernel-cache][yocto-5.15 to master][PATCH] bsp/intel-x86: change Intel I225-LM/I225-V driver to be built-in
Need igc driver to mount network filesystem. Signed-off-by: Yongxin Liu --- bsp/intel-x86/intel-x86-igc-overrides.cfg | 2 ++ bsp/intel-x86/intel-x86.scc | 1 + 2 files changed, 3 insertions(+) create mode 100644 bsp/intel-x86/intel-x86-igc-overrides.cfg diff --git a/bsp/intel-x86/intel-x86-igc-overrides.cfg b/bsp/intel-x86/intel-x86-igc-overrides.cfg new file mode 100644 index ..870e9883 --- /dev/null +++ b/bsp/intel-x86/intel-x86-igc-overrides.cfg @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: MIT +CONFIG_IGC=y diff --git a/bsp/intel-x86/intel-x86.scc b/bsp/intel-x86/intel-x86.scc index 874b4373..a747961f 100644 --- a/bsp/intel-x86/intel-x86.scc +++ b/bsp/intel-x86/intel-x86.scc @@ -65,3 +65,4 @@ kconf hardware intel-x86-i915-overrides.cfg kconf hardware intel-x86-dptf-overrides.cfg kconf hardware intel-x86-serial-8250-overrides.cfg kconf hardware intel-x86-i40e-overrides.cfg +kconf hardware intel-x86-igc-overrides.cfg -- 2.39.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12887): https://lists.yoctoproject.org/g/linux-yocto/message/12887 Mute This Topic: https://lists.yoctoproject.org/mt/100345939/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][PATCH 3/3] thunderbolt: Mask ring interrupt on Intel hardware as well
From: Mika Westerberg
commit 9f9666e65359d5047089aef97ac87c50f624ecb0 upstream.
When resuming from system sleep states the driver issues following
warning on Intel hardware:
thunderbolt :07:00.0: interrupt for TX ring 0 is already enabled
The reason for this is that the commit in question did not mask the ring
interrupt on Intel hardware leaving the interrupt active. Fix this by
masking it also in Intel hardware.
Reported-by: beld zhang
Tested-by: beld zhang
Closes: https://lore.kernel.org/linux-usb/zhkw5neabmfhg...@debian.me/
Fixes: c4af8e3fecd0 ("thunderbolt: Clear registers properly when auto clear
isn't in use")
Cc: sta...@vger.kernel.org
Reviewed-by: Mario Limonciello
Signed-off-by: Mika Westerberg
Signed-off-by: Yongxin Liu
---
drivers/thunderbolt/nhi.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
index 0a525f44ea31..4a6a3802d7e5 100644
--- a/drivers/thunderbolt/nhi.c
+++ b/drivers/thunderbolt/nhi.c
@@ -56,9 +56,14 @@ static int ring_interrupt_index(const struct tb_ring *ring)
static void nhi_mask_interrupt(struct tb_nhi *nhi, int mask, int ring)
{
- if (nhi->quirks & QUIRK_AUTO_CLEAR_INT)
- return;
- iowrite32(mask, nhi->iobase + REG_RING_INTERRUPT_MASK_CLEAR_BASE +
ring);
+ if (nhi->quirks & QUIRK_AUTO_CLEAR_INT) {
+ u32 val;
+
+ val = ioread32(nhi->iobase + REG_RING_INTERRUPT_BASE + ring);
+ iowrite32(val & ~mask, nhi->iobase + REG_RING_INTERRUPT_BASE +
ring);
+ } else {
+ iowrite32(mask, nhi->iobase +
REG_RING_INTERRUPT_MASK_CLEAR_BASE + ring);
+ }
}
static void nhi_clear_interrupt(struct tb_nhi *nhi, int ring)
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12776):
https://lists.yoctoproject.org/g/linux-yocto/message/12776
Mute This Topic: https://lists.yoctoproject.org/mt/99615835/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][PATCH 2/3] Bluetooth: add missing hci_codec_list_clear() back
hci_codec_list_clear() was missing in commit d0b137062b2d
("Bluetooth: hci_sync: Rework init stages"). Without it, there
are following kernel memory leaks.
unreferenced object 0x9fe454c12ca0 (size 32):
comm "kworker/u9:0", pid 82, jiffies 4294756186 (age 75.617s)
hex dump (first 32 bytes):
a8 93 7b 76 e4 9f ff ff e0 2d c1 54 e4 9f ff ff ..{v.-.T
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[] __kmem_cache_alloc_node+0x1e6/0x3d0
[] __kmalloc+0x51/0x1a0
[] hci_codec_list_add.isra.0+0x35/0xc0
[] hci_read_codec_capabilities+0x127/0x1f0
[] hci_read_supported_codecs+0x115/0x1e0
[] hci_read_local_codecs_sync+0x28/0x40
[] hci_init_sync+0x14f/0x360
[] hci_dev_init_sync+0xf8/0x180
[] hci_dev_open_sync+0x8a/0x2e0
[] hci_power_on+0x60/0x220
[] process_one_work+0x257/0x580
[] worker_thread+0x58/0x3c0
[] kthread+0x10b/0x140
[] ret_from_fork+0x29/0x50
Fixes: d0b137062b2d ("Bluetooth: hci_sync: Rework init stages")
Link:
https://patchwork.kernel.org/project/bluetooth/patch/20230520055147.3212541-1-yongxin@windriver.com
Signed-off-by: Yongxin Liu
---
net/bluetooth/hci_sync.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index e8b78104a407..630a90828c1d 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -4933,6 +4933,7 @@ int hci_dev_close_sync(struct hci_dev *hdev)
memset(hdev->eir, 0, sizeof(hdev->eir));
memset(hdev->dev_class, 0, sizeof(hdev->dev_class));
bacpy(>random_addr, BDADDR_ANY);
+ hci_codec_list_clear(>local_codecs);
hci_dev_put(hdev);
return err;
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12775):
https://lists.yoctoproject.org/g/linux-yocto/message/12775
Mute This Topic: https://lists.yoctoproject.org/mt/99615833/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][PATCH 0/3] Three patches fixing i915, bluetooth and thunderbolt related issues
Hi Bruce, Here are three patches for v6.1/standard/x86 and v6.1/standard/preempt-rt/x86 branches. 1) The patch "thunderbolt: Mask ring interrupt on Intel hardware as well" comes from upstream, fixing the following issue. thunderbolt :00:0d.2: interrupt for TX ring 0 is already enabled thunderbolt :00:0d.2: interrupt for RX ring 0 is already enabled 2) The following two patches are used to fix corresponding kernel memory leaks. They have been sent to communites, but got no feedback so far. I added the links to commit log. I will continue tracking them. drm/i915/dp: fix a memory leak in struct intel_vbt_panel_data Bluetooth: add missing hci_codec_list_clear() back Could you help to merge them? Thanks, Yongxin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12773): https://lists.yoctoproject.org/g/linux-yocto/message/12773 Mute This Topic: https://lists.yoctoproject.org/mt/99615831/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][PATCH 1/3] drm/i915/dp: fix a memory leak in struct intel_vbt_panel_data
In commit 3f9ffce5765d ("drm/i915: Do panel VBT init early if the VBT
declares an explicit panel type"), intel_bios_init_panel_early() was
added to intel_edp_init_connector(), and it may call parse_lfp_panel_dtd()
to alloc memory for panel->vbt.lfp_lvds_vbt_mode.
If intel_edp_init_connector() returns false from lable out_vdd_off, the
memory pointed by panel->vbt.lfp_lvds_vbt_mode will be eventually lost by
kfree(connector) in intel_ddi_init_dp_connector().
Fix the following memory leak.
unreferenced object 0x9e076562f100 (size 128):
comm "modprobe", pid 365, jiffies 4294749388 (age 73.473s)
hex dump (first 32 bytes):
14 44 02 00 80 07 d8 07 05 08 98 08 00 00 38 04 .D8.
3b 04 41 04 65 04 00 00 0a 00 00 00 00 00 00 00 ;.A.e...
backtrace:
__kmem_cache_alloc_node+0x1e6/0x3d0
kmalloc_trace+0x2a/0xf0
parse_lfp_data+0x1a9/0x300 [i915]
intel_bios_init_panel+0x131/0x3d0 [i915]
intel_bios_init_panel_early+0x13/0x20 [i915]
intel_edp_init_connector+0xb2/0x620 [i915]
intel_dp_init_connector+0x277/0x490 [i915]
intel_ddi_init+0x877/0xd70 [i915]
intel_setup_outputs+0x79d/0xbc0 [i915]
intel_modeset_init_nogem+0x1a1/0x300 [i915]
i915_driver_probe+0x2cd/0x580 [i915]
i915_pci_probe+0xcd/0x150 [i915]
local_pci_probe+0x44/0xa0
pci_call_probe+0x54/0x160
pci_device_probe+0x7e/0x100
really_probe+0x197/0x3c0
Link:
https://patchwork.kernel.org/project/intel-gfx/patch/20230608024527.1280985-1-yongxin@windriver.com
Signed-off-by: Yongxin Liu
---
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b1653308f145..99072661b046 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5270,6 +5270,7 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
out_vdd_off:
intel_pps_vdd_off_sync(intel_dp);
+ intel_bios_fini_panel(_connector->panel);
return false;
}
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12774):
https://lists.yoctoproject.org/g/linux-yocto/message/12774
Mute This Topic: https://lists.yoctoproject.org/mt/99615832/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
