[PATCH v3 0/2] PCI MCFG consolidation and APEI resource filterin

[PATCH v3 0/2] PCI MCFG consolidation and APEI resource filterin

[Xuesong Chen]

Hello All,

The idea of this patch set is very strainforward, it's somehow a refactor
of the original codes to share some ones that they should do. Based on that,
we can resolve the MCFG address access issue in APEI module on x86 in a 
command way instead of the current arch-dependent one, while this issue also
does happen on ARM64 platform.

The logic of the series is very clear(IMO it's even time-wasting to explain that):

Patch #1: Escalating the 'pci_mmcfg_list' and 'pci_mmcfg_region' to the
pci.[c,h] which will shared by all the arches. A common sense, in some degree.

Patch #2: Since the 'pci_mmcfg_list' now can be shared across all arches,
the arch-specific fix method can be replaced by the new solution naturally.

Now the v3 patch has been finalized, can we move forward to the next step? -
either give the concerns/objections or pick it up.

Xuesong Chen (2):
  PCI: MCFG: Consolidate the separate PCI MCFG table entry list
  ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method

 arch/x86/include/asm/pci_x86.h | 17 +---------------
 arch/x86/pci/mmconfig-shared.c | 30 ----------------------------
 drivers/acpi/apei/apei-base.c  | 45 ++++++++++++++++++++++++++++--------------
 drivers/acpi/pci_mcfg.c        | 34 ++++++++++++-------------------
 drivers/pci/pci.c              |  2 ++
 include/linux/pci.h            | 17 ++++++++++++++++
 6 files changed, 63 insertions(+), 82 deletions(-)

-- 
1.8.3.1

[PATCH v3 0/2] PCI MCFG consolidation and APEI resource filterin

[Xuesong Chen]

Hello All,

The idea of this patch set is very strainforward, it's somehow a refactor
of the original codes to share some ones that they should do. Based on that,
we can resolve the MCFG address access issue in APEI module on x86 in a 
command way instead of the current arch-dependent one, while this issue also
does happen on ARM64 platform.

The logic of the series is very clear(IMO it's even time-wasting to explain that):

Patch #1: Escalating the 'pci_mmcfg_list' and 'pci_mmcfg_region' to the
pci.[c,h] which will shared by all the arches. A common sense, in some degree.

Patch #2: Since the 'pci_mmcfg_list' now can be shared across all arches,
the arch-specific fix method can be replaced by the new solution naturally.

Now the v3 patch has been finalized, can we move forward to the next step? -
either give the concerns/objections or pick it up.

Xuesong Chen (2):
  PCI: MCFG: Consolidate the separate PCI MCFG table entry list
  ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method

 arch/x86/include/asm/pci_x86.h | 17 +---------------
 arch/x86/pci/mmconfig-shared.c | 30 ----------------------------
 drivers/acpi/apei/apei-base.c  | 45 ++++++++++++++++++++++++++++--------------
 drivers/acpi/pci_mcfg.c        | 34 ++++++++++++-------------------
 drivers/pci/pci.c              |  2 ++
 include/linux/pci.h            | 17 ++++++++++++++++
 6 files changed, 63 insertions(+), 82 deletions(-)

-- 
1.8.3.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/2] PCI MCFG consolidation and APEI resource filterin

[Bjorn Helgaas]

On Tue, Oct 19, 2021 at 12:49:16PM +0800, Xuesong Chen wrote:
> Hello All,
> 
> The idea of this patch set is very strainforward, it's somehow a refactor
> of the original codes to share some ones that they should do. Based on that,
> we can resolve the MCFG address access issue in APEI module on x86 in a 
> command way instead of the current arch-dependent one, while this issue also
> does happen on ARM64 platform.
> 
> The logic of the series is very clear(IMO it's even time-wasting to explain that):

If you want people to look at and care about your changes, it is never
a waste of time to explain them.

> Patch #1: Escalating the 'pci_mmcfg_list' and 'pci_mmcfg_region' to the
> pci.[c,h] which will shared by all the arches. A common sense, in some degree.
> 
> Patch #2: Since the 'pci_mmcfg_list' now can be shared across all arches,
> the arch-specific fix method can be replaced by the new solution naturally.
> 
> Now the v3 patch has been finalized, can we move forward to the next step? -
> either give the concerns/objections or pick it up.

It's helpful to your reviewers if you include a note about changes
between v2 and v3, as you did in your v2 0/2 cover letter.

It's also helpful if you thread the series with patches 1 and 2 as
responses to the cover letter.  That makes it easy to download the
patches using b4.  Here's a little more background:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/5.Posting.rst?id=v5.14#n320

> Xuesong Chen (2):
>   PCI: MCFG: Consolidate the separate PCI MCFG table entry list
>   ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method
> 
>  arch/x86/include/asm/pci_x86.h | 17 +---------------
>  arch/x86/pci/mmconfig-shared.c | 30 ----------------------------
>  drivers/acpi/apei/apei-base.c  | 45 ++++++++++++++++++++++++++++--------------
>  drivers/acpi/pci_mcfg.c        | 34 ++++++++++++-------------------
>  drivers/pci/pci.c              |  2 ++
>  include/linux/pci.h            | 17 ++++++++++++++++
>  6 files changed, 63 insertions(+), 82 deletions(-)
> 
> -- 
> 1.8.3.1
> 

Re: [PATCH v3 0/2] PCI MCFG consolidation and APEI resource filterin

[Bjorn Helgaas]

On Tue, Oct 19, 2021 at 12:49:16PM +0800, Xuesong Chen wrote:
> Hello All,
> 
> The idea of this patch set is very strainforward, it's somehow a refactor
> of the original codes to share some ones that they should do. Based on that,
> we can resolve the MCFG address access issue in APEI module on x86 in a 
> command way instead of the current arch-dependent one, while this issue also
> does happen on ARM64 platform.
> 
> The logic of the series is very clear(IMO it's even time-wasting to explain that):

If you want people to look at and care about your changes, it is never
a waste of time to explain them.

> Patch #1: Escalating the 'pci_mmcfg_list' and 'pci_mmcfg_region' to the
> pci.[c,h] which will shared by all the arches. A common sense, in some degree.
> 
> Patch #2: Since the 'pci_mmcfg_list' now can be shared across all arches,
> the arch-specific fix method can be replaced by the new solution naturally.
> 
> Now the v3 patch has been finalized, can we move forward to the next step? -
> either give the concerns/objections or pick it up.

It's helpful to your reviewers if you include a note about changes
between v2 and v3, as you did in your v2 0/2 cover letter.

It's also helpful if you thread the series with patches 1 and 2 as
responses to the cover letter.  That makes it easy to download the
patches using b4.  Here's a little more background:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/5.Posting.rst?id=v5.14#n320

> Xuesong Chen (2):
>   PCI: MCFG: Consolidate the separate PCI MCFG table entry list
>   ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method
> 
>  arch/x86/include/asm/pci_x86.h | 17 +---------------
>  arch/x86/pci/mmconfig-shared.c | 30 ----------------------------
>  drivers/acpi/apei/apei-base.c  | 45 ++++++++++++++++++++++++++++--------------
>  drivers/acpi/pci_mcfg.c        | 34 ++++++++++++-------------------
>  drivers/pci/pci.c              |  2 ++
>  include/linux/pci.h            | 17 ++++++++++++++++
>  6 files changed, 63 insertions(+), 82 deletions(-)
> 
> -- 
> 1.8.3.1
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/2] PCI MCFG consolidation and APEI resource filterin

[Xuesong Chen]

On 19/10/2021 23:12, Bjorn Helgaas wrote:
> On Tue, Oct 19, 2021 at 12:49:16PM +0800, Xuesong Chen wrote:
>> Hello All,
>>
>> The idea of this patch set is very strainforward, it's somehow a refactor
>> of the original codes to share some ones that they should do. Based on that,
>> we can resolve the MCFG address access issue in APEI module on x86 in a 
>> command way instead of the current arch-dependent one, while this issue also
>> does happen on ARM64 platform.
>>
>> The logic of the series is very clear(IMO it's even time-wasting to explain that):
> 
> If you want people to look at and care about your changes, it is never
> a waste of time to explain them.

En, very good point and professional, I'll keep in mind ;-)
> 
>> Patch #1: Escalating the 'pci_mmcfg_list' and 'pci_mmcfg_region' to the
>> pci.[c,h] which will shared by all the arches. A common sense, in some degree.
>>
>> Patch #2: Since the 'pci_mmcfg_list' now can be shared across all arches,
>> the arch-specific fix method can be replaced by the new solution naturally.
>>
>> Now the v3 patch has been finalized, can we move forward to the next step? -
>> either give the concerns/objections or pick it up.
> 
> It's helpful to your reviewers if you include a note about changes
> between v2 and v3, as you did in your v2 0/2 cover letter.
> 
> It's also helpful if you thread the series with patches 1 and 2 as
> responses to the cover letter.  That makes it easy to download the
> patches using b4.  Here's a little more background:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/5.Posting.rst?id=v5.14#n320

OK, I will rewrite it in the next version...
> 
>> Xuesong Chen (2):
>>   PCI: MCFG: Consolidate the separate PCI MCFG table entry list
>>   ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method
>>
>>  arch/x86/include/asm/pci_x86.h | 17 +---------------
>>  arch/x86/pci/mmconfig-shared.c | 30 ----------------------------
>>  drivers/acpi/apei/apei-base.c  | 45 ++++++++++++++++++++++++++++--------------
>>  drivers/acpi/pci_mcfg.c        | 34 ++++++++++++-------------------
>>  drivers/pci/pci.c              |  2 ++
>>  include/linux/pci.h            | 17 ++++++++++++++++
>>  6 files changed, 63 insertions(+), 82 deletions(-)
>>
>> -- 
>> 1.8.3.1
>>

Re: [PATCH v3 0/2] PCI MCFG consolidation and APEI resource filterin

[Xuesong Chen]

On 19/10/2021 23:12, Bjorn Helgaas wrote:
> On Tue, Oct 19, 2021 at 12:49:16PM +0800, Xuesong Chen wrote:
>> Hello All,
>>
>> The idea of this patch set is very strainforward, it's somehow a refactor
>> of the original codes to share some ones that they should do. Based on that,
>> we can resolve the MCFG address access issue in APEI module on x86 in a 
>> command way instead of the current arch-dependent one, while this issue also
>> does happen on ARM64 platform.
>>
>> The logic of the series is very clear(IMO it's even time-wasting to explain that):
> 
> If you want people to look at and care about your changes, it is never
> a waste of time to explain them.

En, very good point and professional, I'll keep in mind ;-)
> 
>> Patch #1: Escalating the 'pci_mmcfg_list' and 'pci_mmcfg_region' to the
>> pci.[c,h] which will shared by all the arches. A common sense, in some degree.
>>
>> Patch #2: Since the 'pci_mmcfg_list' now can be shared across all arches,
>> the arch-specific fix method can be replaced by the new solution naturally.
>>
>> Now the v3 patch has been finalized, can we move forward to the next step? -
>> either give the concerns/objections or pick it up.
> 
> It's helpful to your reviewers if you include a note about changes
> between v2 and v3, as you did in your v2 0/2 cover letter.
> 
> It's also helpful if you thread the series with patches 1 and 2 as
> responses to the cover letter.  That makes it easy to download the
> patches using b4.  Here's a little more background:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/5.Posting.rst?id=v5.14#n320

OK, I will rewrite it in the next version...
> 
>> Xuesong Chen (2):
>>   PCI: MCFG: Consolidate the separate PCI MCFG table entry list
>>   ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method
>>
>>  arch/x86/include/asm/pci_x86.h | 17 +---------------
>>  arch/x86/pci/mmconfig-shared.c | 30 ----------------------------
>>  drivers/acpi/apei/apei-base.c  | 45 ++++++++++++++++++++++++++++--------------
>>  drivers/acpi/pci_mcfg.c        | 34 ++++++++++++-------------------
>>  drivers/pci/pci.c              |  2 ++
>>  include/linux/pci.h            | 17 ++++++++++++++++
>>  6 files changed, 63 insertions(+), 82 deletions(-)
>>
>> -- 
>> 1.8.3.1
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Xuesong Chen]

The issue of commit d91525eb8ee6 ("ACPI, EINJ: Enhance error injection tolerance
level") on x86 is also happened on our own ARM64 platform. We sent a patch[1]
trying to fix this issue in an arch-specific way as x86 does at first, but
according to the suggestion from Lorenzo Pieralisi and Catalin Marinas, we can
consolidate the PCI MCFG part then fix it in a more common way, that's why this
patch series comes.

[1] https://marc.info/?l=linux-arm-kernel&m=163108478627166&w=2

---
Change from v3 to v4:
  - Add a new patch (patch #3) to address the quirk ECAM access issue. Because
    the normal ECAM config space can be accessed in a lockless way, so we don't
    need the mutual exclusion with the EINJ action. But those quirks maybe break
    this rule and corrupt the configuration access, reserve its MCFG address
    regions in this case to avoid that happens. 
  
  - Add another patch (patch #4) to log the PCI MCFG entry parse message per
    the suggestion from Bjorn Helgaas. The output on ARM64 as:
    ACPI: MCFG entry for domain 0000 [bus 00-0f] at [mem 0x50000000-0x50ffffff] (base 0x50000000)
  
  - Commit message updated with more details of patch #2

Change from v2 to v3:
  - Address the comments of Lorenzo Pieralisi about the CONFIG_PCI
    dependence issue in APEI module (patch #2)

Change from v1 to v2:
  - Fix the "undefined reference to `pci_mmcfg_list'" build error in case
    of PCI_CONFIG=n, reported by the kernel test robot

Xuesong Chen (4):
  PCI: MCFG: Consolidate the separate PCI MCFG table entry list
  ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method
  ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation
  PCI: MCFG: Add the MCFG entry parse log message

 arch/x86/include/asm/pci_x86.h | 17 +----------
 arch/x86/pci/mmconfig-shared.c | 30 -------------------
 drivers/acpi/apei/apei-base.c  | 68 ++++++++++++++++++++++++++++++++----------
 drivers/acpi/pci_mcfg.c        | 46 +++++++++++++++-------------
 drivers/pci/pci.c              |  2 ++
 drivers/pci/quirks.c           |  2 ++
 include/linux/pci.h            | 18 +++++++++++
 7 files changed, 101 insertions(+), 82 deletions(-)

-- 
1.8.3.1

[PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Xuesong Chen]

The issue of commit d91525eb8ee6 ("ACPI, EINJ: Enhance error injection tolerance
level") on x86 is also happened on our own ARM64 platform. We sent a patch[1]
trying to fix this issue in an arch-specific way as x86 does at first, but
according to the suggestion from Lorenzo Pieralisi and Catalin Marinas, we can
consolidate the PCI MCFG part then fix it in a more common way, that's why this
patch series comes.

[1] https://marc.info/?l=linux-arm-kernel&m=163108478627166&w=2

---
Change from v3 to v4:
  - Add a new patch (patch #3) to address the quirk ECAM access issue. Because
    the normal ECAM config space can be accessed in a lockless way, so we don't
    need the mutual exclusion with the EINJ action. But those quirks maybe break
    this rule and corrupt the configuration access, reserve its MCFG address
    regions in this case to avoid that happens. 
  
  - Add another patch (patch #4) to log the PCI MCFG entry parse message per
    the suggestion from Bjorn Helgaas. The output on ARM64 as:
    ACPI: MCFG entry for domain 0000 [bus 00-0f] at [mem 0x50000000-0x50ffffff] (base 0x50000000)
  
  - Commit message updated with more details of patch #2

Change from v2 to v3:
  - Address the comments of Lorenzo Pieralisi about the CONFIG_PCI
    dependence issue in APEI module (patch #2)

Change from v1 to v2:
  - Fix the "undefined reference to `pci_mmcfg_list'" build error in case
    of PCI_CONFIG=n, reported by the kernel test robot

Xuesong Chen (4):
  PCI: MCFG: Consolidate the separate PCI MCFG table entry list
  ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method
  ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation
  PCI: MCFG: Add the MCFG entry parse log message

 arch/x86/include/asm/pci_x86.h | 17 +----------
 arch/x86/pci/mmconfig-shared.c | 30 -------------------
 drivers/acpi/apei/apei-base.c  | 68 ++++++++++++++++++++++++++++++++----------
 drivers/acpi/pci_mcfg.c        | 46 +++++++++++++++-------------
 drivers/pci/pci.c              |  2 ++
 drivers/pci/quirks.c           |  2 ++
 include/linux/pci.h            | 18 +++++++++++
 7 files changed, 101 insertions(+), 82 deletions(-)

-- 
1.8.3.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v4 1/4] PCI: MCFG: Consolidate the separate PCI MCFG table entry list

[Xuesong Chen]

The PCI MCFG entry list is redundant on x86 and other arches like ARM64
in current implementation, this list variable can be consolidated for
unnecessary duplication and other purposes, for example, we can remove
some of the arch-specific codes in the APEI/EINJ module and re-implement
it in a more common arch-agnostic way.

To reduce the redundancy, it:
  - Moves the "struct pci_mmcfg_region" definition from
    arch/x86/include/asm/pci_x86.h to include/linux/pci.h, where it
    can be shared across arches.

  - Moves pci_mmcfg_list (a list of pci_mmcfg_region structs) from
    arch/x86/pci/mmconfig-shared.c to drivers/pci/pci.c, where it can
    be shared across arches.

  - On x86 (which does not enable CONFIG_ACPI_MCFG), pci_mmcfg_list is
    built in arch/x86/pci/mmconfig-shared.c as before.

  - Removes the "struct mcfg_entry" from drivers/acpi/pci_mcfg.c.

  - Replaces pci_mcfg_list (previously a list of mcfg_entry structs)
    in drivers/acpi/pci_mcfg.c with the newly-shared pci_mmcfg_list (a
    list of pci_mmcfg_region structs).

  - On ARM64 (which does enable CONFIG_ACPI_MCFG), pci_mmcfg_list is
    built in drivers/acpi/pci_mcfg.c.

Signed-off-by: Xuesong Chen <xuesong.chen@linux.alibaba.com>
---
 arch/x86/include/asm/pci_x86.h | 17 +----------------
 arch/x86/pci/mmconfig-shared.c |  2 --
 drivers/acpi/pci_mcfg.c        | 35 ++++++++++++++---------------------
 drivers/pci/pci.c              |  2 ++
 include/linux/pci.h            | 17 +++++++++++++++++
 5 files changed, 34 insertions(+), 39 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 490411d..1f4257c 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -146,20 +146,7 @@ static inline int  __init pci_acpi_init(void)
 extern void pcibios_fixup_irqs(void);
 
 /* pci-mmconfig.c */
-
-/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
-#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
-
-struct pci_mmcfg_region {
-	struct list_head list;
-	struct resource res;
-	u64 address;
-	char __iomem *virt;
-	u16 segment;
-	u8 start_bus;
-	u8 end_bus;
-	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
-};
+struct pci_mmcfg_region;
 
 extern int __init pci_mmcfg_arch_init(void);
 extern void __init pci_mmcfg_arch_free(void);
@@ -174,8 +161,6 @@ extern struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
 
 extern struct list_head pci_mmcfg_list;
 
-#define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
-
 /*
  * On AMD Fam10h CPUs, all PCI MMIO configuration space accesses must use
  * %eax.  No other source or target registers may be used.  The following
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 758cbfe..0b961fe6 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -31,8 +31,6 @@
 static DEFINE_MUTEX(pci_mmcfg_lock);
 #define pci_mmcfg_lock_held() lock_is_held(&(pci_mmcfg_lock).dep_map)
 
-LIST_HEAD(pci_mmcfg_list);
-
 static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
 {
 	if (cfg->res.parent)
diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index 53cab97..6ce467f 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -13,14 +13,7 @@
 #include <linux/pci-acpi.h>
 #include <linux/pci-ecam.h>
 
-/* Structure to hold entries from the MCFG table */
-struct mcfg_entry {
-	struct list_head	list;
-	phys_addr_t		addr;
-	u16			segment;
-	u8			bus_start;
-	u8			bus_end;
-};
+extern struct list_head pci_mmcfg_list;
 
 #ifdef CONFIG_PCI_QUIRKS
 struct mcfg_fixup {
@@ -214,16 +207,13 @@ static void pci_mcfg_apply_quirks(struct acpi_pci_root *root,
 #endif
 }
 
-/* List to save MCFG entries */
-static LIST_HEAD(pci_mcfg_list);
-
 int pci_mcfg_lookup(struct acpi_pci_root *root, struct resource *cfgres,
 		    const struct pci_ecam_ops **ecam_ops)
 {
 	const struct pci_ecam_ops *ops = &pci_generic_ecam_ops;
 	struct resource *bus_res = &root->secondary;
 	u16 seg = root->segment;
-	struct mcfg_entry *e;
+	struct pci_mmcfg_region *e;
 	struct resource res;
 
 	/* Use address from _CBA if present, otherwise lookup MCFG */
@@ -233,10 +223,10 @@ int pci_mcfg_lookup(struct acpi_pci_root *root, struct resource *cfgres,
 	/*
 	 * We expect the range in bus_res in the coverage of MCFG bus range.
 	 */
-	list_for_each_entry(e, &pci_mcfg_list, list) {
-		if (e->segment == seg && e->bus_start <= bus_res->start &&
-		    e->bus_end >= bus_res->end) {
-			root->mcfg_addr = e->addr;
+	list_for_each_entry(e, &pci_mmcfg_list, list) {
+		if (e->segment == seg && e->start_bus <= bus_res->start &&
+		    e->end_bus >= bus_res->end) {
+			root->mcfg_addr = e->address;
 		}
 
 	}
@@ -268,7 +258,7 @@ static __init int pci_mcfg_parse(struct acpi_table_header *header)
 {
 	struct acpi_table_mcfg *mcfg;
 	struct acpi_mcfg_allocation *mptr;
-	struct mcfg_entry *e, *arr;
+	struct pci_mmcfg_region *e, *arr;
 	int i, n;
 
 	if (header->length < sizeof(struct acpi_table_mcfg))
@@ -285,10 +275,13 @@ static __init int pci_mcfg_parse(struct acpi_table_header *header)
 
 	for (i = 0, e = arr; i < n; i++, mptr++, e++) {
 		e->segment = mptr->pci_segment;
-		e->addr =  mptr->address;
-		e->bus_start = mptr->start_bus_number;
-		e->bus_end = mptr->end_bus_number;
-		list_add(&e->list, &pci_mcfg_list);
+		e->address =  mptr->address;
+		e->start_bus = mptr->start_bus_number;
+		e->end_bus = mptr->end_bus_number;
+		e->res.start = e->address + PCI_MMCFG_BUS_OFFSET(e->start_bus);
+		e->res.end = e->address + PCI_MMCFG_BUS_OFFSET(e->end_bus + 1) - 1;
+		e->res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		list_add(&e->list, &pci_mmcfg_list);
 	}
 
 #ifdef CONFIG_PCI_QUIRKS
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e01b21a..4e8386c 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -47,6 +47,8 @@
 int pci_pci_problems;
 EXPORT_SYMBOL(pci_pci_problems);
 
+LIST_HEAD(pci_mmcfg_list);
+
 unsigned int pci_pm_d3hot_delay;
 
 static void pci_pme_list_scan(struct work_struct *work);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index b4dbcc8..34b0cbb 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -55,6 +55,23 @@
 #define PCI_RESET_PROBE		true
 #define PCI_RESET_DO_RESET	false
 
+#define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
+
+/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
+#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
+
+/* pci mcfg region */
+struct pci_mmcfg_region {
+	struct list_head list;
+	struct resource res;
+	u64 address;
+	char __iomem *virt;
+	u16 segment;
+	u8 start_bus;
+	u8 end_bus;
+	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
+};
+
 /*
  * The PCI interface treats multi-function devices as independent
  * devices.  The slot/function address of each device is encoded
-- 
1.8.3.1

[PATCH v4 1/4] PCI: MCFG: Consolidate the separate PCI MCFG table entry list

[Xuesong Chen]

The PCI MCFG entry list is redundant on x86 and other arches like ARM64
in current implementation, this list variable can be consolidated for
unnecessary duplication and other purposes, for example, we can remove
some of the arch-specific codes in the APEI/EINJ module and re-implement
it in a more common arch-agnostic way.

To reduce the redundancy, it:
  - Moves the "struct pci_mmcfg_region" definition from
    arch/x86/include/asm/pci_x86.h to include/linux/pci.h, where it
    can be shared across arches.

  - Moves pci_mmcfg_list (a list of pci_mmcfg_region structs) from
    arch/x86/pci/mmconfig-shared.c to drivers/pci/pci.c, where it can
    be shared across arches.

  - On x86 (which does not enable CONFIG_ACPI_MCFG), pci_mmcfg_list is
    built in arch/x86/pci/mmconfig-shared.c as before.

  - Removes the "struct mcfg_entry" from drivers/acpi/pci_mcfg.c.

  - Replaces pci_mcfg_list (previously a list of mcfg_entry structs)
    in drivers/acpi/pci_mcfg.c with the newly-shared pci_mmcfg_list (a
    list of pci_mmcfg_region structs).

  - On ARM64 (which does enable CONFIG_ACPI_MCFG), pci_mmcfg_list is
    built in drivers/acpi/pci_mcfg.c.

Signed-off-by: Xuesong Chen <xuesong.chen@linux.alibaba.com>
---
 arch/x86/include/asm/pci_x86.h | 17 +----------------
 arch/x86/pci/mmconfig-shared.c |  2 --
 drivers/acpi/pci_mcfg.c        | 35 ++++++++++++++---------------------
 drivers/pci/pci.c              |  2 ++
 include/linux/pci.h            | 17 +++++++++++++++++
 5 files changed, 34 insertions(+), 39 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 490411d..1f4257c 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -146,20 +146,7 @@ static inline int  __init pci_acpi_init(void)
 extern void pcibios_fixup_irqs(void);
 
 /* pci-mmconfig.c */
-
-/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
-#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
-
-struct pci_mmcfg_region {
-	struct list_head list;
-	struct resource res;
-	u64 address;
-	char __iomem *virt;
-	u16 segment;
-	u8 start_bus;
-	u8 end_bus;
-	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
-};
+struct pci_mmcfg_region;
 
 extern int __init pci_mmcfg_arch_init(void);
 extern void __init pci_mmcfg_arch_free(void);
@@ -174,8 +161,6 @@ extern struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
 
 extern struct list_head pci_mmcfg_list;
 
-#define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
-
 /*
  * On AMD Fam10h CPUs, all PCI MMIO configuration space accesses must use
  * %eax.  No other source or target registers may be used.  The following
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 758cbfe..0b961fe6 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -31,8 +31,6 @@
 static DEFINE_MUTEX(pci_mmcfg_lock);
 #define pci_mmcfg_lock_held() lock_is_held(&(pci_mmcfg_lock).dep_map)
 
-LIST_HEAD(pci_mmcfg_list);
-
 static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
 {
 	if (cfg->res.parent)
diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index 53cab97..6ce467f 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -13,14 +13,7 @@
 #include <linux/pci-acpi.h>
 #include <linux/pci-ecam.h>
 
-/* Structure to hold entries from the MCFG table */
-struct mcfg_entry {
-	struct list_head	list;
-	phys_addr_t		addr;
-	u16			segment;
-	u8			bus_start;
-	u8			bus_end;
-};
+extern struct list_head pci_mmcfg_list;
 
 #ifdef CONFIG_PCI_QUIRKS
 struct mcfg_fixup {
@@ -214,16 +207,13 @@ static void pci_mcfg_apply_quirks(struct acpi_pci_root *root,
 #endif
 }
 
-/* List to save MCFG entries */
-static LIST_HEAD(pci_mcfg_list);
-
 int pci_mcfg_lookup(struct acpi_pci_root *root, struct resource *cfgres,
 		    const struct pci_ecam_ops **ecam_ops)
 {
 	const struct pci_ecam_ops *ops = &pci_generic_ecam_ops;
 	struct resource *bus_res = &root->secondary;
 	u16 seg = root->segment;
-	struct mcfg_entry *e;
+	struct pci_mmcfg_region *e;
 	struct resource res;
 
 	/* Use address from _CBA if present, otherwise lookup MCFG */
@@ -233,10 +223,10 @@ int pci_mcfg_lookup(struct acpi_pci_root *root, struct resource *cfgres,
 	/*
 	 * We expect the range in bus_res in the coverage of MCFG bus range.
 	 */
-	list_for_each_entry(e, &pci_mcfg_list, list) {
-		if (e->segment == seg && e->bus_start <= bus_res->start &&
-		    e->bus_end >= bus_res->end) {
-			root->mcfg_addr = e->addr;
+	list_for_each_entry(e, &pci_mmcfg_list, list) {
+		if (e->segment == seg && e->start_bus <= bus_res->start &&
+		    e->end_bus >= bus_res->end) {
+			root->mcfg_addr = e->address;
 		}
 
 	}
@@ -268,7 +258,7 @@ static __init int pci_mcfg_parse(struct acpi_table_header *header)
 {
 	struct acpi_table_mcfg *mcfg;
 	struct acpi_mcfg_allocation *mptr;
-	struct mcfg_entry *e, *arr;
+	struct pci_mmcfg_region *e, *arr;
 	int i, n;
 
 	if (header->length < sizeof(struct acpi_table_mcfg))
@@ -285,10 +275,13 @@ static __init int pci_mcfg_parse(struct acpi_table_header *header)
 
 	for (i = 0, e = arr; i < n; i++, mptr++, e++) {
 		e->segment = mptr->pci_segment;
-		e->addr =  mptr->address;
-		e->bus_start = mptr->start_bus_number;
-		e->bus_end = mptr->end_bus_number;
-		list_add(&e->list, &pci_mcfg_list);
+		e->address =  mptr->address;
+		e->start_bus = mptr->start_bus_number;
+		e->end_bus = mptr->end_bus_number;
+		e->res.start = e->address + PCI_MMCFG_BUS_OFFSET(e->start_bus);
+		e->res.end = e->address + PCI_MMCFG_BUS_OFFSET(e->end_bus + 1) - 1;
+		e->res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		list_add(&e->list, &pci_mmcfg_list);
 	}
 
 #ifdef CONFIG_PCI_QUIRKS
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e01b21a..4e8386c 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -47,6 +47,8 @@
 int pci_pci_problems;
 EXPORT_SYMBOL(pci_pci_problems);
 
+LIST_HEAD(pci_mmcfg_list);
+
 unsigned int pci_pm_d3hot_delay;
 
 static void pci_pme_list_scan(struct work_struct *work);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index b4dbcc8..34b0cbb 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -55,6 +55,23 @@
 #define PCI_RESET_PROBE		true
 #define PCI_RESET_DO_RESET	false
 
+#define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
+
+/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
+#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
+
+/* pci mcfg region */
+struct pci_mmcfg_region {
+	struct list_head list;
+	struct resource res;
+	u64 address;
+	char __iomem *virt;
+	u16 segment;
+	u8 start_bus;
+	u8 end_bus;
+	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
+};
+
 /*
  * The PCI interface treats multi-function devices as independent
  * devices.  The slot/function address of each device is encoded
-- 
1.8.3.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v4 2/4] ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method

[Xuesong Chen]

The commit d91525eb8ee6 ("ACPI, EINJ: Enhance error injection tolerance
level") fixes the issue that the ACPI/APEI can not access the PCI MCFG
address on x86 platform, but this issue can also happen on other
architectures, for instance, we got below error message on ARM64 platform:
...
APEI: Can not request [mem 0x50100000-0x50100003] for APEI EINJ Trigger registers
...

The above register range is within the MCFG area, because the PCI ECAM
can access the configuration space in an atomic way in case of the
hardware implementation of ECAM is correct, which means we don't need
a mutual exclusion for the EINJ action, thus we can remove this register
address region from the MCFG safely just like the x86 fix does.

Since all the MCFG resources have been saved into the pci_mmcfg_list
which is shared across different arches, thus we can filter the MCFG
resources from the APEI by apei_resources_sub(...) in a more common
arch-agnostic way, which will be beneficial to all the APEI-dependent
platforms after that.

Signed-off-by: Xuesong Chen <xuesong.chen@linux.alibaba.com>
---
 arch/x86/pci/mmconfig-shared.c | 28 --------------------------
 drivers/acpi/apei/apei-base.c  | 45 ++++++++++++++++++++++++++++--------------
 2 files changed, 30 insertions(+), 43 deletions(-)

diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 0b961fe6..12f7d96 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -605,32 +605,6 @@ static int __init pci_parse_mcfg(struct acpi_table_header *header)
 	return 0;
 }
 
-#ifdef CONFIG_ACPI_APEI
-extern int (*arch_apei_filter_addr)(int (*func)(__u64 start, __u64 size,
-				     void *data), void *data);
-
-static int pci_mmcfg_for_each_region(int (*func)(__u64 start, __u64 size,
-				     void *data), void *data)
-{
-	struct pci_mmcfg_region *cfg;
-	int rc;
-
-	if (list_empty(&pci_mmcfg_list))
-		return 0;
-
-	list_for_each_entry(cfg, &pci_mmcfg_list, list) {
-		rc = func(cfg->res.start, resource_size(&cfg->res), data);
-		if (rc)
-			return rc;
-	}
-
-	return 0;
-}
-#define set_apei_filter() (arch_apei_filter_addr = pci_mmcfg_for_each_region)
-#else
-#define set_apei_filter()
-#endif
-
 static void __init __pci_mmcfg_init(int early)
 {
 	pci_mmcfg_reject_broken(early);
@@ -665,8 +639,6 @@ void __init pci_mmcfg_early_init(void)
 		else
 			acpi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
 		__pci_mmcfg_init(1);
-
-		set_apei_filter();
 	}
 }
 
diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
index c7fdb12..daae75a 100644
--- a/drivers/acpi/apei/apei-base.c
+++ b/drivers/acpi/apei/apei-base.c
@@ -21,6 +21,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/init.h>
+#include <linux/pci.h>
 #include <linux/acpi.h>
 #include <linux/slab.h>
 #include <linux/io.h>
@@ -448,13 +449,34 @@ static int apei_get_nvs_resources(struct apei_resources *resources)
 	return acpi_nvs_for_each_region(apei_get_res_callback, resources);
 }
 
-int (*arch_apei_filter_addr)(int (*func)(__u64 start, __u64 size,
-				     void *data), void *data);
-static int apei_get_arch_resources(struct apei_resources *resources)
+#ifdef CONFIG_PCI
+extern struct list_head pci_mmcfg_list;
+static int apei_filter_mcfg_addr(struct apei_resources *res,
+			struct apei_resources *mcfg_res)
+{
+	int rc = 0;
+	struct pci_mmcfg_region *cfg;
+
+	if (list_empty(&pci_mmcfg_list))
+		return 0;
+
+	apei_resources_init(mcfg_res);
+	list_for_each_entry(cfg, &pci_mmcfg_list, list) {
+		rc = apei_res_add(&mcfg_res->iomem, cfg->res.start, resource_size(&cfg->res));
+		if (rc)
+			return rc;
+	}
 
+	/* filter the mcfg resource from current APEI's */
+	return apei_resources_sub(res, mcfg_res);
+}
+#else
+static inline int apei_filter_mcfg_addr(struct apei_resources *res,
+			struct apei_resources *mcfg_res)
 {
-	return arch_apei_filter_addr(apei_get_res_callback, resources);
+	return 0;
 }
+#endif
 
 /*
  * IO memory/port resource management mechanism is used to check
@@ -486,15 +508,9 @@ int apei_resources_request(struct apei_resources *resources,
 	if (rc)
 		goto nvs_res_fini;
 
-	if (arch_apei_filter_addr) {
-		apei_resources_init(&arch_res);
-		rc = apei_get_arch_resources(&arch_res);
-		if (rc)
-			goto arch_res_fini;
-		rc = apei_resources_sub(resources, &arch_res);
-		if (rc)
-			goto arch_res_fini;
-	}
+	rc = apei_filter_mcfg_addr(resources, &arch_res);
+	if (rc)
+		goto arch_res_fini;
 
 	rc = -EINVAL;
 	list_for_each_entry(res, &resources->iomem, list) {
@@ -544,8 +560,7 @@ int apei_resources_request(struct apei_resources *resources,
 		release_mem_region(res->start, res->end - res->start);
 	}
 arch_res_fini:
-	if (arch_apei_filter_addr)
-		apei_resources_fini(&arch_res);
+	apei_resources_fini(&arch_res);
 nvs_res_fini:
 	apei_resources_fini(&nvs_resources);
 	return rc;
-- 
1.8.3.1

[PATCH v4 2/4] ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method

[Xuesong Chen]

The commit d91525eb8ee6 ("ACPI, EINJ: Enhance error injection tolerance
level") fixes the issue that the ACPI/APEI can not access the PCI MCFG
address on x86 platform, but this issue can also happen on other
architectures, for instance, we got below error message on ARM64 platform:
...
APEI: Can not request [mem 0x50100000-0x50100003] for APEI EINJ Trigger registers
...

The above register range is within the MCFG area, because the PCI ECAM
can access the configuration space in an atomic way in case of the
hardware implementation of ECAM is correct, which means we don't need
a mutual exclusion for the EINJ action, thus we can remove this register
address region from the MCFG safely just like the x86 fix does.

Since all the MCFG resources have been saved into the pci_mmcfg_list
which is shared across different arches, thus we can filter the MCFG
resources from the APEI by apei_resources_sub(...) in a more common
arch-agnostic way, which will be beneficial to all the APEI-dependent
platforms after that.

Signed-off-by: Xuesong Chen <xuesong.chen@linux.alibaba.com>
---
 arch/x86/pci/mmconfig-shared.c | 28 --------------------------
 drivers/acpi/apei/apei-base.c  | 45 ++++++++++++++++++++++++++++--------------
 2 files changed, 30 insertions(+), 43 deletions(-)

diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 0b961fe6..12f7d96 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -605,32 +605,6 @@ static int __init pci_parse_mcfg(struct acpi_table_header *header)
 	return 0;
 }
 
-#ifdef CONFIG_ACPI_APEI
-extern int (*arch_apei_filter_addr)(int (*func)(__u64 start, __u64 size,
-				     void *data), void *data);
-
-static int pci_mmcfg_for_each_region(int (*func)(__u64 start, __u64 size,
-				     void *data), void *data)
-{
-	struct pci_mmcfg_region *cfg;
-	int rc;
-
-	if (list_empty(&pci_mmcfg_list))
-		return 0;
-
-	list_for_each_entry(cfg, &pci_mmcfg_list, list) {
-		rc = func(cfg->res.start, resource_size(&cfg->res), data);
-		if (rc)
-			return rc;
-	}
-
-	return 0;
-}
-#define set_apei_filter() (arch_apei_filter_addr = pci_mmcfg_for_each_region)
-#else
-#define set_apei_filter()
-#endif
-
 static void __init __pci_mmcfg_init(int early)
 {
 	pci_mmcfg_reject_broken(early);
@@ -665,8 +639,6 @@ void __init pci_mmcfg_early_init(void)
 		else
 			acpi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
 		__pci_mmcfg_init(1);
-
-		set_apei_filter();
 	}
 }
 
diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
index c7fdb12..daae75a 100644
--- a/drivers/acpi/apei/apei-base.c
+++ b/drivers/acpi/apei/apei-base.c
@@ -21,6 +21,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/init.h>
+#include <linux/pci.h>
 #include <linux/acpi.h>
 #include <linux/slab.h>
 #include <linux/io.h>
@@ -448,13 +449,34 @@ static int apei_get_nvs_resources(struct apei_resources *resources)
 	return acpi_nvs_for_each_region(apei_get_res_callback, resources);
 }
 
-int (*arch_apei_filter_addr)(int (*func)(__u64 start, __u64 size,
-				     void *data), void *data);
-static int apei_get_arch_resources(struct apei_resources *resources)
+#ifdef CONFIG_PCI
+extern struct list_head pci_mmcfg_list;
+static int apei_filter_mcfg_addr(struct apei_resources *res,
+			struct apei_resources *mcfg_res)
+{
+	int rc = 0;
+	struct pci_mmcfg_region *cfg;
+
+	if (list_empty(&pci_mmcfg_list))
+		return 0;
+
+	apei_resources_init(mcfg_res);
+	list_for_each_entry(cfg, &pci_mmcfg_list, list) {
+		rc = apei_res_add(&mcfg_res->iomem, cfg->res.start, resource_size(&cfg->res));
+		if (rc)
+			return rc;
+	}
 
+	/* filter the mcfg resource from current APEI's */
+	return apei_resources_sub(res, mcfg_res);
+}
+#else
+static inline int apei_filter_mcfg_addr(struct apei_resources *res,
+			struct apei_resources *mcfg_res)
 {
-	return arch_apei_filter_addr(apei_get_res_callback, resources);
+	return 0;
 }
+#endif
 
 /*
  * IO memory/port resource management mechanism is used to check
@@ -486,15 +508,9 @@ int apei_resources_request(struct apei_resources *resources,
 	if (rc)
 		goto nvs_res_fini;
 
-	if (arch_apei_filter_addr) {
-		apei_resources_init(&arch_res);
-		rc = apei_get_arch_resources(&arch_res);
-		if (rc)
-			goto arch_res_fini;
-		rc = apei_resources_sub(resources, &arch_res);
-		if (rc)
-			goto arch_res_fini;
-	}
+	rc = apei_filter_mcfg_addr(resources, &arch_res);
+	if (rc)
+		goto arch_res_fini;
 
 	rc = -EINVAL;
 	list_for_each_entry(res, &resources->iomem, list) {
@@ -544,8 +560,7 @@ int apei_resources_request(struct apei_resources *resources,
 		release_mem_region(res->start, res->end - res->start);
 	}
 arch_res_fini:
-	if (arch_apei_filter_addr)
-		apei_resources_fini(&arch_res);
+	apei_resources_fini(&arch_res);
 nvs_res_fini:
 	apei_resources_fini(&nvs_resources);
 	return rc;
-- 
1.8.3.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation

[Xuesong Chen]

On some platforms, the hardware ECAM implementiation is not generic
as expected, which will make the PCI configuration access atomic
primitive lost. In this case, we need to reserve those quirk MCFG
address regions when filtering the normal MCFG resource to make sure
the mutual exclusion still works between the MCFG configuration
access and EINJ's operation.

Signed-off-by: Xuesong Chen <xuesong.chen@linux.alibaba.com>
---
 drivers/acpi/apei/apei-base.c | 25 ++++++++++++++++++++++++-
 drivers/acpi/pci_mcfg.c       |  8 ++++++++
 drivers/pci/quirks.c          |  2 ++
 include/linux/pci.h           |  1 +
 4 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
index daae75a..4f7311a 100644
--- a/drivers/acpi/apei/apei-base.c
+++ b/drivers/acpi/apei/apei-base.c
@@ -450,6 +450,23 @@ static int apei_get_nvs_resources(struct apei_resources *resources)
 }
 
 #ifdef CONFIG_PCI
+int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
+{
+#ifdef CONFIG_PCI_QUIRKS
+	int rc = 0;
+	struct apei_resources quirk_res;
+
+	apei_resources_init(&quirk_res);
+	rc = apei_res_add(&quirk_res.iomem, pci_quirk_mcfg_res.start,
+		resource_size(&pci_quirk_mcfg_res));
+	if (rc)
+		return rc;
+
+	return apei_resources_sub(mcfg_res, &quirk_res);
+#else
+	return 0;
+#endif
+}
 extern struct list_head pci_mmcfg_list;
 static int apei_filter_mcfg_addr(struct apei_resources *res,
 			struct apei_resources *mcfg_res)
@@ -462,11 +479,17 @@ static int apei_filter_mcfg_addr(struct apei_resources *res,
 
 	apei_resources_init(mcfg_res);
 	list_for_each_entry(cfg, &pci_mmcfg_list, list) {
-		rc = apei_res_add(&mcfg_res->iomem, cfg->res.start, resource_size(&cfg->res));
+		rc = apei_res_add(&mcfg_res->iomem, cfg->res.start,
+				resource_size(&cfg->res));
 		if (rc)
 			return rc;
 	}
 
+	/* remove the pci quirk mcfg resource if any from the mcfg_res */
+	rc = remove_quirk_mcfg_res(mcfg_res);
+	if (rc)
+		return rc;
+
 	/* filter the mcfg resource from current APEI's */
 	return apei_resources_sub(res, mcfg_res);
 }
diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index 6ce467f..b5ab866 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -26,6 +26,8 @@ struct mcfg_fixup {
 	struct resource cfgres;
 };
 
+static bool pci_quirk_matched;
+
 #define MCFG_BUS_RANGE(start, end)	DEFINE_RES_NAMED((start),	\
 						((end) - (start) + 1),	\
 						NULL, IORESOURCE_BUS)
@@ -195,6 +197,7 @@ static void pci_mcfg_apply_quirks(struct acpi_pci_root *root,
 
 	for (i = 0, f = mcfg_quirks; i < ARRAY_SIZE(mcfg_quirks); i++, f++) {
 		if (pci_mcfg_quirk_matches(f, segment, bus_range)) {
+			pci_quirk_matched = true;
 			if (f->cfgres.start)
 				*cfgres = f->cfgres;
 			if (f->ops)
@@ -251,6 +254,11 @@ int pci_mcfg_lookup(struct acpi_pci_root *root, struct resource *cfgres,
 
 	*cfgres = res;
 	*ecam_ops = ops;
+#ifdef CONFIG_PCI_QUIRKS
+	if (pci_quirk_matched)
+		pci_quirk_mcfg_res = res;
+#endif
+
 	return 0;
 }
 
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index f284ab4..bf64232 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -32,6 +32,8 @@
 #include <asm/dma.h>	/* isa_dma_bridge_buggy */
 #include "pci.h"
 
+struct resource pci_quirk_mcfg_res;
+
 static ktime_t fixup_debug_start(struct pci_dev *dev,
 				 void (*fn)(struct pci_dev *dev))
 {
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 34b0cbb..10d2c17 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -2103,6 +2103,7 @@ enum pci_fixup_pass {
 		suspend_late##hook, vendor, device, PCI_ANY_ID, 0, hook)
 
 #ifdef CONFIG_PCI_QUIRKS
+extern struct resource pci_quirk_mcfg_res;
 void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev);
 #else
 static inline void pci_fixup_device(enum pci_fixup_pass pass,
-- 
1.8.3.1

[PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation

[Xuesong Chen]

On some platforms, the hardware ECAM implementiation is not generic
as expected, which will make the PCI configuration access atomic
primitive lost. In this case, we need to reserve those quirk MCFG
address regions when filtering the normal MCFG resource to make sure
the mutual exclusion still works between the MCFG configuration
access and EINJ's operation.

Signed-off-by: Xuesong Chen <xuesong.chen@linux.alibaba.com>
---
 drivers/acpi/apei/apei-base.c | 25 ++++++++++++++++++++++++-
 drivers/acpi/pci_mcfg.c       |  8 ++++++++
 drivers/pci/quirks.c          |  2 ++
 include/linux/pci.h           |  1 +
 4 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
index daae75a..4f7311a 100644
--- a/drivers/acpi/apei/apei-base.c
+++ b/drivers/acpi/apei/apei-base.c
@@ -450,6 +450,23 @@ static int apei_get_nvs_resources(struct apei_resources *resources)
 }
 
 #ifdef CONFIG_PCI
+int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
+{
+#ifdef CONFIG_PCI_QUIRKS
+	int rc = 0;
+	struct apei_resources quirk_res;
+
+	apei_resources_init(&quirk_res);
+	rc = apei_res_add(&quirk_res.iomem, pci_quirk_mcfg_res.start,
+		resource_size(&pci_quirk_mcfg_res));
+	if (rc)
+		return rc;
+
+	return apei_resources_sub(mcfg_res, &quirk_res);
+#else
+	return 0;
+#endif
+}
 extern struct list_head pci_mmcfg_list;
 static int apei_filter_mcfg_addr(struct apei_resources *res,
 			struct apei_resources *mcfg_res)
@@ -462,11 +479,17 @@ static int apei_filter_mcfg_addr(struct apei_resources *res,
 
 	apei_resources_init(mcfg_res);
 	list_for_each_entry(cfg, &pci_mmcfg_list, list) {
-		rc = apei_res_add(&mcfg_res->iomem, cfg->res.start, resource_size(&cfg->res));
+		rc = apei_res_add(&mcfg_res->iomem, cfg->res.start,
+				resource_size(&cfg->res));
 		if (rc)
 			return rc;
 	}
 
+	/* remove the pci quirk mcfg resource if any from the mcfg_res */
+	rc = remove_quirk_mcfg_res(mcfg_res);
+	if (rc)
+		return rc;
+
 	/* filter the mcfg resource from current APEI's */
 	return apei_resources_sub(res, mcfg_res);
 }
diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index 6ce467f..b5ab866 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -26,6 +26,8 @@ struct mcfg_fixup {
 	struct resource cfgres;
 };
 
+static bool pci_quirk_matched;
+
 #define MCFG_BUS_RANGE(start, end)	DEFINE_RES_NAMED((start),	\
 						((end) - (start) + 1),	\
 						NULL, IORESOURCE_BUS)
@@ -195,6 +197,7 @@ static void pci_mcfg_apply_quirks(struct acpi_pci_root *root,
 
 	for (i = 0, f = mcfg_quirks; i < ARRAY_SIZE(mcfg_quirks); i++, f++) {
 		if (pci_mcfg_quirk_matches(f, segment, bus_range)) {
+			pci_quirk_matched = true;
 			if (f->cfgres.start)
 				*cfgres = f->cfgres;
 			if (f->ops)
@@ -251,6 +254,11 @@ int pci_mcfg_lookup(struct acpi_pci_root *root, struct resource *cfgres,
 
 	*cfgres = res;
 	*ecam_ops = ops;
+#ifdef CONFIG_PCI_QUIRKS
+	if (pci_quirk_matched)
+		pci_quirk_mcfg_res = res;
+#endif
+
 	return 0;
 }
 
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index f284ab4..bf64232 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -32,6 +32,8 @@
 #include <asm/dma.h>	/* isa_dma_bridge_buggy */
 #include "pci.h"
 
+struct resource pci_quirk_mcfg_res;
+
 static ktime_t fixup_debug_start(struct pci_dev *dev,
 				 void (*fn)(struct pci_dev *dev))
 {
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 34b0cbb..10d2c17 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -2103,6 +2103,7 @@ enum pci_fixup_pass {
 		suspend_late##hook, vendor, device, PCI_ANY_ID, 0, hook)
 
 #ifdef CONFIG_PCI_QUIRKS
+extern struct resource pci_quirk_mcfg_res;
 void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev);
 #else
 static inline void pci_fixup_device(enum pci_fixup_pass pass,
-- 
1.8.3.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v4 4/4] PCI: MCFG: Add the MCFG entry parse log message

[Xuesong Chen]

To make it to be consistent with x86's MMCONFIG and ease the
disection of PCI MCFG entry parse process.

Signed-off-by: Xuesong Chen <xuesong.chen@linux.alibaba.com>
---
 drivers/acpi/pci_mcfg.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index b5ab866..99c9bf5 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -290,6 +290,9 @@ static __init int pci_mcfg_parse(struct acpi_table_header *header)
 		e->res.end = e->address + PCI_MMCFG_BUS_OFFSET(e->end_bus + 1) - 1;
 		e->res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 		list_add(&e->list, &pci_mmcfg_list);
+		pr_info("MCFG entry for domain %04x [bus %02x-%02x] at %pR "
+			"(base %#lx)\n", e->segment, e->start_bus,
+			e->end_bus, &e->res, (unsigned long)e->address);
 	}
 
 #ifdef CONFIG_PCI_QUIRKS
-- 
1.8.3.1

[PATCH v4 4/4] PCI: MCFG: Add the MCFG entry parse log message

[Xuesong Chen]

To make it to be consistent with x86's MMCONFIG and ease the
disection of PCI MCFG entry parse process.

Signed-off-by: Xuesong Chen <xuesong.chen@linux.alibaba.com>
---
 drivers/acpi/pci_mcfg.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index b5ab866..99c9bf5 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -290,6 +290,9 @@ static __init int pci_mcfg_parse(struct acpi_table_header *header)
 		e->res.end = e->address + PCI_MMCFG_BUS_OFFSET(e->end_bus + 1) - 1;
 		e->res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 		list_add(&e->list, &pci_mmcfg_list);
+		pr_info("MCFG entry for domain %04x [bus %02x-%02x] at %pR "
+			"(base %#lx)\n", e->segment, e->start_bus,
+			e->end_bus, &e->res, (unsigned long)e->address);
 	}
 
 #ifdef CONFIG_PCI_QUIRKS
-- 
1.8.3.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 4642 bytes --]

Hi Xuesong,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on helgaas-pci/next]
[also build test WARNING on rafael-pm/linux-next tip/x86/core arm64/for-next/core v5.15-rc7 next-20211027]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-randconfig-a002-20211027 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 5db7568a6a1fcb408eb8988abdaff2a225a8eb72)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
        git checkout 8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> drivers/acpi/apei/apei-base.c:453:5: warning: no previous prototype for function 'remove_quirk_mcfg_res' [-Wmissing-prototypes]
   int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
       ^
   drivers/acpi/apei/apei-base.c:453:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
   ^
   static 
   drivers/acpi/apei/apei-base.c:804:12: warning: no previous prototype for function 'arch_apei_enable_cmcff' [-Wmissing-prototypes]
   int __weak arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr,
              ^
   drivers/acpi/apei/apei-base.c:804:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   int __weak arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr,
   ^
   static 
   drivers/acpi/apei/apei-base.c:811:13: warning: no previous prototype for function 'arch_apei_report_mem_error' [-Wmissing-prototypes]
   void __weak arch_apei_report_mem_error(int sev,
               ^
   drivers/acpi/apei/apei-base.c:811:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void __weak arch_apei_report_mem_error(int sev,
   ^
   static 
   3 warnings generated.


vim +/remove_quirk_mcfg_res +453 drivers/acpi/apei/apei-base.c

   451	
   452	#ifdef CONFIG_PCI
 > 453	int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
   454	{
   455	#ifdef CONFIG_PCI_QUIRKS
   456		int rc = 0;
   457		struct apei_resources quirk_res;
   458	
   459		apei_resources_init(&quirk_res);
   460		rc = apei_res_add(&quirk_res.iomem, pci_quirk_mcfg_res.start,
   461			resource_size(&pci_quirk_mcfg_res));
   462		if (rc)
   463			return rc;
   464	
   465		return apei_resources_sub(mcfg_res, &quirk_res);
   466	#else
   467		return 0;
   468	#endif
   469	}
   470	extern struct list_head pci_mmcfg_list;
   471	static int apei_filter_mcfg_addr(struct apei_resources *res,
   472				struct apei_resources *mcfg_res)
   473	{
   474		int rc = 0;
   475		struct pci_mmcfg_region *cfg;
   476	
   477		if (list_empty(&pci_mmcfg_list))
   478			return 0;
   479	
   480		apei_resources_init(mcfg_res);
   481		list_for_each_entry(cfg, &pci_mmcfg_list, list) {
   482			rc = apei_res_add(&mcfg_res->iomem, cfg->res.start,
   483					resource_size(&cfg->res));
   484			if (rc)
   485				return rc;
   486		}
   487	
   488		/* remove the pci quirk mcfg resource if any from the mcfg_res */
   489		rc = remove_quirk_mcfg_res(mcfg_res);
   490		if (rc)
   491			return rc;
   492	
   493		/* filter the mcfg resource from current APEI's */
   494		return apei_resources_sub(res, mcfg_res);
   495	}
   496	#else
   497	static inline int apei_filter_mcfg_addr(struct apei_resources *res,
   498				struct apei_resources *mcfg_res)
   499	{
   500		return 0;
   501	}
   502	#endif
   503	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 37965 bytes --]

Re: [PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 4756 bytes --]

Hi Xuesong,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on helgaas-pci/next]
[also build test WARNING on rafael-pm/linux-next tip/x86/core arm64/for-next/core v5.15-rc7 next-20211027]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-randconfig-a002-20211027 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 5db7568a6a1fcb408eb8988abdaff2a225a8eb72)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
        git checkout 8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> drivers/acpi/apei/apei-base.c:453:5: warning: no previous prototype for function 'remove_quirk_mcfg_res' [-Wmissing-prototypes]
   int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
       ^
   drivers/acpi/apei/apei-base.c:453:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
   ^
   static 
   drivers/acpi/apei/apei-base.c:804:12: warning: no previous prototype for function 'arch_apei_enable_cmcff' [-Wmissing-prototypes]
   int __weak arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr,
              ^
   drivers/acpi/apei/apei-base.c:804:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   int __weak arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr,
   ^
   static 
   drivers/acpi/apei/apei-base.c:811:13: warning: no previous prototype for function 'arch_apei_report_mem_error' [-Wmissing-prototypes]
   void __weak arch_apei_report_mem_error(int sev,
               ^
   drivers/acpi/apei/apei-base.c:811:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void __weak arch_apei_report_mem_error(int sev,
   ^
   static 
   3 warnings generated.


vim +/remove_quirk_mcfg_res +453 drivers/acpi/apei/apei-base.c

   451	
   452	#ifdef CONFIG_PCI
 > 453	int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
   454	{
   455	#ifdef CONFIG_PCI_QUIRKS
   456		int rc = 0;
   457		struct apei_resources quirk_res;
   458	
   459		apei_resources_init(&quirk_res);
   460		rc = apei_res_add(&quirk_res.iomem, pci_quirk_mcfg_res.start,
   461			resource_size(&pci_quirk_mcfg_res));
   462		if (rc)
   463			return rc;
   464	
   465		return apei_resources_sub(mcfg_res, &quirk_res);
   466	#else
   467		return 0;
   468	#endif
   469	}
   470	extern struct list_head pci_mmcfg_list;
   471	static int apei_filter_mcfg_addr(struct apei_resources *res,
   472				struct apei_resources *mcfg_res)
   473	{
   474		int rc = 0;
   475		struct pci_mmcfg_region *cfg;
   476	
   477		if (list_empty(&pci_mmcfg_list))
   478			return 0;
   479	
   480		apei_resources_init(mcfg_res);
   481		list_for_each_entry(cfg, &pci_mmcfg_list, list) {
   482			rc = apei_res_add(&mcfg_res->iomem, cfg->res.start,
   483					resource_size(&cfg->res));
   484			if (rc)
   485				return rc;
   486		}
   487	
   488		/* remove the pci quirk mcfg resource if any from the mcfg_res */
   489		rc = remove_quirk_mcfg_res(mcfg_res);
   490		if (rc)
   491			return rc;
   492	
   493		/* filter the mcfg resource from current APEI's */
   494		return apei_resources_sub(res, mcfg_res);
   495	}
   496	#else
   497	static inline int apei_filter_mcfg_addr(struct apei_resources *res,
   498				struct apei_resources *mcfg_res)
   499	{
   500		return 0;
   501	}
   502	#endif
   503	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 37965 bytes --]

Re: [PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]

Hi Xuesong,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on helgaas-pci/next]
[also build test WARNING on rafael-pm/linux-next tip/x86/core arm64/for-next/core v5.15-rc7 next-20211027]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-randconfig-s022-20211027 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
        git checkout 8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
        # save the attached .config to linux build tree
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/acpi/apei/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
>> drivers/acpi/apei/apei-base.c:453:5: sparse: sparse: symbol 'remove_quirk_mcfg_res' was not declared. Should it be static?
   drivers/acpi/apei/apei-base.c:804:12: sparse: sparse: symbol 'arch_apei_enable_cmcff' was not declared. Should it be static?
   drivers/acpi/apei/apei-base.c:811:13: sparse: sparse: symbol 'arch_apei_report_mem_error' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 36046 bytes --]

[RFC PATCH] ACPI: APEI: remove_quirk_mcfg_res() can be static

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

drivers/acpi/apei/apei-base.c:453:5: warning: symbol 'remove_quirk_mcfg_res' was not declared. Should it be static?

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: kernel test robot <lkp@intel.com>
---
 apei-base.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
index 4f7311a55a342..dbb0fa4125e32 100644
--- a/drivers/acpi/apei/apei-base.c
+++ b/drivers/acpi/apei/apei-base.c
@@ -450,7 +450,7 @@ static int apei_get_nvs_resources(struct apei_resources *resources)
 }
 
 #ifdef CONFIG_PCI
-int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
+static int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
 {
 #ifdef CONFIG_PCI_QUIRKS
 	int rc = 0;

Re: [PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 3871 bytes --]

Hi Xuesong,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on helgaas-pci/next]
[also build test WARNING on rafael-pm/linux-next tip/x86/core arm64/for-next/core v5.15-rc7 next-20211027]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: i386-debian-10.3 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/0day-ci/linux/commit/8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
        git checkout 8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> drivers/acpi/apei/apei-base.c:453:5: warning: no previous prototype for 'remove_quirk_mcfg_res' [-Wmissing-prototypes]
     453 | int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
         |     ^~~~~~~~~~~~~~~~~~~~~
   drivers/acpi/apei/apei-base.c:804:12: warning: no previous prototype for 'arch_apei_enable_cmcff' [-Wmissing-prototypes]
     804 | int __weak arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr,
         |            ^~~~~~~~~~~~~~~~~~~~~~
   drivers/acpi/apei/apei-base.c:811:13: warning: no previous prototype for 'arch_apei_report_mem_error' [-Wmissing-prototypes]
     811 | void __weak arch_apei_report_mem_error(int sev,
         |             ^~~~~~~~~~~~~~~~~~~~~~~~~~


vim +/remove_quirk_mcfg_res +453 drivers/acpi/apei/apei-base.c

   451	
   452	#ifdef CONFIG_PCI
 > 453	int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
   454	{
   455	#ifdef CONFIG_PCI_QUIRKS
   456		int rc = 0;
   457		struct apei_resources quirk_res;
   458	
   459		apei_resources_init(&quirk_res);
   460		rc = apei_res_add(&quirk_res.iomem, pci_quirk_mcfg_res.start,
   461			resource_size(&pci_quirk_mcfg_res));
   462		if (rc)
   463			return rc;
   464	
   465		return apei_resources_sub(mcfg_res, &quirk_res);
   466	#else
   467		return 0;
   468	#endif
   469	}
   470	extern struct list_head pci_mmcfg_list;
   471	static int apei_filter_mcfg_addr(struct apei_resources *res,
   472				struct apei_resources *mcfg_res)
   473	{
   474		int rc = 0;
   475		struct pci_mmcfg_region *cfg;
   476	
   477		if (list_empty(&pci_mmcfg_list))
   478			return 0;
   479	
   480		apei_resources_init(mcfg_res);
   481		list_for_each_entry(cfg, &pci_mmcfg_list, list) {
   482			rc = apei_res_add(&mcfg_res->iomem, cfg->res.start,
   483					resource_size(&cfg->res));
   484			if (rc)
   485				return rc;
   486		}
   487	
   488		/* remove the pci quirk mcfg resource if any from the mcfg_res */
   489		rc = remove_quirk_mcfg_res(mcfg_res);
   490		if (rc)
   491			return rc;
   492	
   493		/* filter the mcfg resource from current APEI's */
   494		return apei_resources_sub(res, mcfg_res);
   495	}
   496	#else
   497	static inline int apei_filter_mcfg_addr(struct apei_resources *res,
   498				struct apei_resources *mcfg_res)
   499	{
   500		return 0;
   501	}
   502	#endif
   503	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 38507 bytes --]

Re: [PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 3920 bytes --]

Hi Xuesong,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on helgaas-pci/next]
[also build test ERROR on rafael-pm/linux-next tip/x86/core arm64/for-next/core v5.15-rc7 next-20211029]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/0day-ci/linux/commit/8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
        git checkout 8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> drivers/acpi/apei/apei-base.c:453:5: error: no previous prototype for 'remove_quirk_mcfg_res' [-Werror=missing-prototypes]
     453 | int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
         |     ^~~~~~~~~~~~~~~~~~~~~
   drivers/acpi/apei/apei-base.c:804:12: error: no previous prototype for 'arch_apei_enable_cmcff' [-Werror=missing-prototypes]
     804 | int __weak arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr,
         |            ^~~~~~~~~~~~~~~~~~~~~~
   drivers/acpi/apei/apei-base.c:811:13: error: no previous prototype for 'arch_apei_report_mem_error' [-Werror=missing-prototypes]
     811 | void __weak arch_apei_report_mem_error(int sev,
         |             ^~~~~~~~~~~~~~~~~~~~~~~~~~
   cc1: all warnings being treated as errors


vim +/remove_quirk_mcfg_res +453 drivers/acpi/apei/apei-base.c

   451	
   452	#ifdef CONFIG_PCI
 > 453	int remove_quirk_mcfg_res(struct apei_resources *mcfg_res)
   454	{
   455	#ifdef CONFIG_PCI_QUIRKS
   456		int rc = 0;
   457		struct apei_resources quirk_res;
   458	
   459		apei_resources_init(&quirk_res);
   460		rc = apei_res_add(&quirk_res.iomem, pci_quirk_mcfg_res.start,
   461			resource_size(&pci_quirk_mcfg_res));
   462		if (rc)
   463			return rc;
   464	
   465		return apei_resources_sub(mcfg_res, &quirk_res);
   466	#else
   467		return 0;
   468	#endif
   469	}
   470	extern struct list_head pci_mmcfg_list;
   471	static int apei_filter_mcfg_addr(struct apei_resources *res,
   472				struct apei_resources *mcfg_res)
   473	{
   474		int rc = 0;
   475		struct pci_mmcfg_region *cfg;
   476	
   477		if (list_empty(&pci_mmcfg_list))
   478			return 0;
   479	
   480		apei_resources_init(mcfg_res);
   481		list_for_each_entry(cfg, &pci_mmcfg_list, list) {
   482			rc = apei_res_add(&mcfg_res->iomem, cfg->res.start,
   483					resource_size(&cfg->res));
   484			if (rc)
   485				return rc;
   486		}
   487	
   488		/* remove the pci quirk mcfg resource if any from the mcfg_res */
   489		rc = remove_quirk_mcfg_res(mcfg_res);
   490		if (rc)
   491			return rc;
   492	
   493		/* filter the mcfg resource from current APEI's */
   494		return apei_resources_sub(res, mcfg_res);
   495	}
   496	#else
   497	static inline int apei_filter_mcfg_addr(struct apei_resources *res,
   498				struct apei_resources *mcfg_res)
   499	{
   500		return 0;
   501	}
   502	#endif
   503	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 66055 bytes --]

Re: [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Xuesong Chen]

How about the status of this series, it's really bad, bad and still bad... to wait long
time for the final judgement, especially you take extremely serious to rework it round
by round, finaly you receive nothing. Everyone's work should be repected!

Technically, I don't think it's very hard to say yes or no (what's your concerns) for
the patch set. If you give your objections and convince me, then I will drop it, that's
nothing. Hopefully our maintainers can take the responsibility that they should take,
I totally understand that our maintainers are very busy and will face tens of thousands
of mails. But, YOU ARE THE MAINTAINER! 

Responsiblity!Responsiblity!! Still TMD f*cking FucResponsiblity!!!

On 27/10/2021 16:10, Xuesong Chen wrote:
> The issue of commit d91525eb8ee6 ("ACPI, EINJ: Enhance error injection tolerance
> level") on x86 is also happened on our own ARM64 platform. We sent a patch[1]
> trying to fix this issue in an arch-specific way as x86 does at first, but
> according to the suggestion from Lorenzo Pieralisi and Catalin Marinas, we can
> consolidate the PCI MCFG part then fix it in a more common way, that's why this
> patch series comes.
> 
> [1] https://marc.info/?l=linux-arm-kernel&m=163108478627166&w=2
> 
> ---
> Change from v3 to v4:
>   - Add a new patch (patch #3) to address the quirk ECAM access issue. Because
>     the normal ECAM config space can be accessed in a lockless way, so we don't
>     need the mutual exclusion with the EINJ action. But those quirks maybe break
>     this rule and corrupt the configuration access, reserve its MCFG address
>     regions in this case to avoid that happens. 
>   
>   - Add another patch (patch #4) to log the PCI MCFG entry parse message per
>     the suggestion from Bjorn Helgaas. The output on ARM64 as:
>     ACPI: MCFG entry for domain 0000 [bus 00-0f] at [mem 0x50000000-0x50ffffff] (base 0x50000000)
>   
>   - Commit message updated with more details of patch #2
> 
> Change from v2 to v3:
>   - Address the comments of Lorenzo Pieralisi about the CONFIG_PCI
>     dependence issue in APEI module (patch #2)
> 
> Change from v1 to v2:
>   - Fix the "undefined reference to `pci_mmcfg_list'" build error in case
>     of PCI_CONFIG=n, reported by the kernel test robot
> 
> Xuesong Chen (4):
>   PCI: MCFG: Consolidate the separate PCI MCFG table entry list
>   ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method
>   ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation
>   PCI: MCFG: Add the MCFG entry parse log message
> 
>  arch/x86/include/asm/pci_x86.h | 17 +----------
>  arch/x86/pci/mmconfig-shared.c | 30 -------------------
>  drivers/acpi/apei/apei-base.c  | 68 ++++++++++++++++++++++++++++++++----------
>  drivers/acpi/pci_mcfg.c        | 46 +++++++++++++++-------------
>  drivers/pci/pci.c              |  2 ++
>  drivers/pci/quirks.c           |  2 ++
>  include/linux/pci.h            | 18 +++++++++++
>  7 files changed, 101 insertions(+), 82 deletions(-)
> 

Re: [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Xuesong Chen]

How about the status of this series, it's really bad, bad and still bad... to wait long
time for the final judgement, especially you take extremely serious to rework it round
by round, finaly you receive nothing. Everyone's work should be repected!

Technically, I don't think it's very hard to say yes or no (what's your concerns) for
the patch set. If you give your objections and convince me, then I will drop it, that's
nothing. Hopefully our maintainers can take the responsibility that they should take,
I totally understand that our maintainers are very busy and will face tens of thousands
of mails. But, YOU ARE THE MAINTAINER! 

Responsiblity!Responsiblity!! Still TMD f*cking FucResponsiblity!!!

On 27/10/2021 16:10, Xuesong Chen wrote:
> The issue of commit d91525eb8ee6 ("ACPI, EINJ: Enhance error injection tolerance
> level") on x86 is also happened on our own ARM64 platform. We sent a patch[1]
> trying to fix this issue in an arch-specific way as x86 does at first, but
> according to the suggestion from Lorenzo Pieralisi and Catalin Marinas, we can
> consolidate the PCI MCFG part then fix it in a more common way, that's why this
> patch series comes.
> 
> [1] https://marc.info/?l=linux-arm-kernel&m=163108478627166&w=2
> 
> ---
> Change from v3 to v4:
>   - Add a new patch (patch #3) to address the quirk ECAM access issue. Because
>     the normal ECAM config space can be accessed in a lockless way, so we don't
>     need the mutual exclusion with the EINJ action. But those quirks maybe break
>     this rule and corrupt the configuration access, reserve its MCFG address
>     regions in this case to avoid that happens. 
>   
>   - Add another patch (patch #4) to log the PCI MCFG entry parse message per
>     the suggestion from Bjorn Helgaas. The output on ARM64 as:
>     ACPI: MCFG entry for domain 0000 [bus 00-0f] at [mem 0x50000000-0x50ffffff] (base 0x50000000)
>   
>   - Commit message updated with more details of patch #2
> 
> Change from v2 to v3:
>   - Address the comments of Lorenzo Pieralisi about the CONFIG_PCI
>     dependence issue in APEI module (patch #2)
> 
> Change from v1 to v2:
>   - Fix the "undefined reference to `pci_mmcfg_list'" build error in case
>     of PCI_CONFIG=n, reported by the kernel test robot
> 
> Xuesong Chen (4):
>   PCI: MCFG: Consolidate the separate PCI MCFG table entry list
>   ACPI: APEI: Filter the PCI MCFG address with an arch-agnostic method
>   ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation
>   PCI: MCFG: Add the MCFG entry parse log message
> 
>  arch/x86/include/asm/pci_x86.h | 17 +----------
>  arch/x86/pci/mmconfig-shared.c | 30 -------------------
>  drivers/acpi/apei/apei-base.c  | 68 ++++++++++++++++++++++++++++++++----------
>  drivers/acpi/pci_mcfg.c        | 46 +++++++++++++++-------------
>  drivers/pci/pci.c              |  2 ++
>  drivers/pci/quirks.c           |  2 ++
>  include/linux/pci.h            | 18 +++++++++++
>  7 files changed, 101 insertions(+), 82 deletions(-)
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Will Deacon]

Hi,

On Mon, Nov 01, 2021 at 10:18:35AM +0800, Xuesong Chen wrote:
> How about the status of this series, it's really bad, bad and still bad... to wait long
> time for the final judgement, especially you take extremely serious to rework it round
> by round, finaly you receive nothing. Everyone's work should be repected!

I've trimmed the rest of your response as it wasn't especially constructive.
Please can you try to keep things civil, even when you're frustrated? It's
not very pleasant being on the end of a rant.

One likely explanation for you not getting a reply on your patches is that
I've discovered many of your emails have ended up in my spam, for some
reason. I'm using gmail for my inbox so, if Bjorn is doing that as well,
then there's a good chance he hasn't seen them either.

The other thing to keep in mind is that the 5.16 merge window opened today
and you posted the latest version of your patches on Wednesday. That doesn't
really leave enough time for the patches to be reviewed (noting that patch 3
is new in this version and the kernel build robot was still complaining on
Friday), queued and put into linux-next, so I would suspect that this series
is looking more like 5.17 material and therefore not a priority for
maintainers at the moment.

Your best is probably to post a v5, with the kbuild warnings addressed,
when -rc1 is released in a couple of weeks. I'm not sure how to fix the
spam issue though :(

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Will Deacon]

Hi,

On Mon, Nov 01, 2021 at 10:18:35AM +0800, Xuesong Chen wrote:
> How about the status of this series, it's really bad, bad and still bad... to wait long
> time for the final judgement, especially you take extremely serious to rework it round
> by round, finaly you receive nothing. Everyone's work should be repected!

I've trimmed the rest of your response as it wasn't especially constructive.
Please can you try to keep things civil, even when you're frustrated? It's
not very pleasant being on the end of a rant.

One likely explanation for you not getting a reply on your patches is that
I've discovered many of your emails have ended up in my spam, for some
reason. I'm using gmail for my inbox so, if Bjorn is doing that as well,
then there's a good chance he hasn't seen them either.

The other thing to keep in mind is that the 5.16 merge window opened today
and you posted the latest version of your patches on Wednesday. That doesn't
really leave enough time for the patches to be reviewed (noting that patch 3
is new in this version and the kernel build robot was still complaining on
Friday), queued and put into linux-next, so I would suspect that this series
is looking more like 5.17 material and therefore not a priority for
maintainers at the moment.

Your best is probably to post a v5, with the kbuild warnings addressed,
when -rc1 is released in a couple of weeks. I'm not sure how to fix the
spam issue though :(

Will

Re: [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Xuesong Chen]

Hi Will,

Thanks for the feedback!

On 01/11/2021 17:36, Will Deacon wrote:
> Hi,
> 
> On Mon, Nov 01, 2021 at 10:18:35AM +0800, Xuesong Chen wrote:
>> How about the status of this series, it's really bad, bad and still bad... to wait long
>> time for the final judgement, especially you take extremely serious to rework it round
>> by round, finaly you receive nothing. Everyone's work should be repected!
> 
> I've trimmed the rest of your response as it wasn't especially constructive.
> Please can you try to keep things civil, even when you're frustrated? It's
> not very pleasant being on the end of a rant.

I'm very sorry about the non-constructived response, and I'd like to take this chance to
withdraw them entirely... personally this is not a good example in terms of the mood or
the way of expression.

> 
> One likely explanation for you not getting a reply on your patches is that
> I've discovered many of your emails have ended up in my spam, for some
> reason. I'm using gmail for my inbox so, if Bjorn is doing that as well,
> then there's a good chance he hasn't seen them either.
> 
> The other thing to keep in mind is that the 5.16 merge window opened today
> and you posted the latest version of your patches on Wednesday. That doesn't
> really leave enough time for the patches to be reviewed (noting that patch 3
> is new in this version and the kernel build robot was still complaining on
> Friday), queued and put into linux-next, so I would suspect that this series
> is looking more like 5.17 material and therefore not a priority for
> maintainers at the moment.
> 
> Your best is probably to post a v5, with the kbuild warnings addressed,
> when -rc1 is released in a couple of weeks. I'm not sure how to fix the
> spam issue though :(

I've noticed the kbuild warning by the robot, so I plan to fix it and post the v5 soon.

Thanks,
Xuesong

> 
> Will
> 

Re: [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Xuesong Chen]

Hi Will,

Thanks for the feedback!

On 01/11/2021 17:36, Will Deacon wrote:
> Hi,
> 
> On Mon, Nov 01, 2021 at 10:18:35AM +0800, Xuesong Chen wrote:
>> How about the status of this series, it's really bad, bad and still bad... to wait long
>> time for the final judgement, especially you take extremely serious to rework it round
>> by round, finaly you receive nothing. Everyone's work should be repected!
> 
> I've trimmed the rest of your response as it wasn't especially constructive.
> Please can you try to keep things civil, even when you're frustrated? It's
> not very pleasant being on the end of a rant.

I'm very sorry about the non-constructived response, and I'd like to take this chance to
withdraw them entirely... personally this is not a good example in terms of the mood or
the way of expression.

> 
> One likely explanation for you not getting a reply on your patches is that
> I've discovered many of your emails have ended up in my spam, for some
> reason. I'm using gmail for my inbox so, if Bjorn is doing that as well,
> then there's a good chance he hasn't seen them either.
> 
> The other thing to keep in mind is that the 5.16 merge window opened today
> and you posted the latest version of your patches on Wednesday. That doesn't
> really leave enough time for the patches to be reviewed (noting that patch 3
> is new in this version and the kernel build robot was still complaining on
> Friday), queued and put into linux-next, so I would suspect that this series
> is looking more like 5.17 material and therefore not a priority for
> maintainers at the moment.
> 
> Your best is probably to post a v5, with the kbuild warnings addressed,
> when -rc1 is released in a couple of weeks. I'm not sure how to fix the
> spam issue though :(

I've noticed the kbuild warning by the robot, so I plan to fix it and post the v5 soon.

Thanks,
Xuesong

> 
> Will
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Borislav Petkov]

On Mon, Nov 01, 2021 at 08:12:15PM +0800, Xuesong Chen wrote:
> I'm very sorry about the non-constructived response, and I'd like to
> take this chance to withdraw them entirely... personally this is not a
> good example in terms of the mood or the way of expression.

Good idea. There are other maintainers who would ignore you indefinitely
for uncalled for explosions like that. And then you would have achieved
the opposite of what you were aiming for, with that rant.

To Will's point, you can always read Documentation/process/ while
waiting for your patches to get reviewed - there the whole process is
explained and what the best ways and times are to send a patchset.

HTH.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Borislav Petkov]

On Mon, Nov 01, 2021 at 08:12:15PM +0800, Xuesong Chen wrote:
> I'm very sorry about the non-constructived response, and I'd like to
> take this chance to withdraw them entirely... personally this is not a
> good example in terms of the mood or the way of expression.

Good idea. There are other maintainers who would ignore you indefinitely
for uncalled for explosions like that. And then you would have achieved
the opposite of what you were aiming for, with that rant.

To Will's point, you can always read Documentation/process/ while
waiting for your patches to get reviewed - there the whole process is
explained and what the best ways and times are to send a patchset.

HTH.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Xuesong Chen]

On 01/11/2021 20:22, Borislav Petkov wrote:
> On Mon, Nov 01, 2021 at 08:12:15PM +0800, Xuesong Chen wrote:
>> I'm very sorry about the non-constructived response, and I'd like to
>> take this chance to withdraw them entirely... personally this is not a
>> good example in terms of the mood or the way of expression.
> 
> Good idea. There are other maintainers who would ignore you indefinitely
> for uncalled for explosions like that. And then you would have achieved
> the opposite of what you were aiming for, with that rant.

Actually that's my original intention, especially when you take lots of serious
effors to rework it round by round, but no one say YES or NO, which is really
frustrating. Hopefully the newbies can also be treated fairly in the community.
During my working experience in the community before, lot's of nice maintainers
give me very deep impression. What a splendid memory!

> 
> To Will's point, you can always read Documentation/process/ while
> waiting for your patches to get reviewed - there the whole process is
> explained and what the best ways and times are to send a patchset.

Good suggestion, learnt and thanks!

Thanks,
Xuesong
> 
> HTH.
> 

Re: [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Xuesong Chen]

On 01/11/2021 20:22, Borislav Petkov wrote:
> On Mon, Nov 01, 2021 at 08:12:15PM +0800, Xuesong Chen wrote:
>> I'm very sorry about the non-constructived response, and I'd like to
>> take this chance to withdraw them entirely... personally this is not a
>> good example in terms of the mood or the way of expression.
> 
> Good idea. There are other maintainers who would ignore you indefinitely
> for uncalled for explosions like that. And then you would have achieved
> the opposite of what you were aiming for, with that rant.

Actually that's my original intention, especially when you take lots of serious
effors to rework it round by round, but no one say YES or NO, which is really
frustrating. Hopefully the newbies can also be treated fairly in the community.
During my working experience in the community before, lot's of nice maintainers
give me very deep impression. What a splendid memory!

> 
> To Will's point, you can always read Documentation/process/ while
> waiting for your patches to get reviewed - there the whole process is
> explained and what the best ways and times are to send a patchset.

Good suggestion, learnt and thanks!

Thanks,
Xuesong
> 
> HTH.
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Borislav Petkov]

On Mon, Nov 01, 2021 at 09:32:31PM +0800, Xuesong Chen wrote:
> Actually that's my original intention

There's a misunderstanding here - I don't think your original intention
is to get ignored indefinitely.

> especially when you take lots of serious effors to rework it round by
> round, but no one say YES or NO, which is really frustrating.

Well, try to put yourself in the maintainer's shoes, maybe that would
answer some of that frustration:

- Most of the maintainers are overworked and backlogged until forever.

- If you rework something and you don't get an answer, maybe the
maintainer is not sure yet and is thinking about the pros and cons of
taking that patch.

Greg has formulated this particular issue of the maintainers very
nicely:

"Seriously. It's easier for the maintainer to not accept your code at
all. To accept it, it takes time to review it, apply it, send it on up
the development chain, handle any problems that might happen with the
patch, accept responsibility for the patch, possibly fix any problems
that happen later on when you disappear, and maintain it for the next 20
years.

That's a lot of work that you are asking someone else to do on your
behalf…

So your goal is, when sending a patch, to give me no excuse to not
accept it. To make it such that if I ignore it, or reject it, I am the
one that is the problem here, not you."

And this thing is not really clear to all submitters - once their
patch(es) is applied, they're done. But maintainers have to deal with
that code forever.

So before you send your patchset, try to think as a maintainer and
think whether your change makes sense for the *whole* tree and whether
maintaining it forward would be easy.

- Did I say that maintainers are overworked?

Submitters don't see the amount of work maintainers do in the
background, testing everything and fixing build issues and bugs. Because
most of the time, submitters submit and the cleanups and bugs get mopped
after them by the maintainers - not the submitters.

Look at how some trees resort to maintainer *groups* because a single
maintainer simply doesn't scale, at the risk of a burnout or whatever
nasty.

And those maintainer groups have *all* their hands full.

> Hopefully the newbies can also be treated fairly in the community.

Newbies are treated fairly in the community - especially those who come
prepared and try to understand why the maintainers say things they way
they do and listen to feedback.

If there are examples against that, we would all like to know about
them.

I sincerely hope that explains the situation and hope that it'll help
you see it from the maintainers' POV too and maybe help you deal with
future submissions a lot better.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v4 0/4] PCI MCFG consolidation and APEI resource filtering

[Borislav Petkov]

On Mon, Nov 01, 2021 at 09:32:31PM +0800, Xuesong Chen wrote:
> Actually that's my original intention

There's a misunderstanding here - I don't think your original intention
is to get ignored indefinitely.

> especially when you take lots of serious effors to rework it round by
> round, but no one say YES or NO, which is really frustrating.

Well, try to put yourself in the maintainer's shoes, maybe that would
answer some of that frustration:

- Most of the maintainers are overworked and backlogged until forever.

- If you rework something and you don't get an answer, maybe the
maintainer is not sure yet and is thinking about the pros and cons of
taking that patch.

Greg has formulated this particular issue of the maintainers very
nicely:

"Seriously. It's easier for the maintainer to not accept your code at
all. To accept it, it takes time to review it, apply it, send it on up
the development chain, handle any problems that might happen with the
patch, accept responsibility for the patch, possibly fix any problems
that happen later on when you disappear, and maintain it for the next 20
years.

That's a lot of work that you are asking someone else to do on your
behalf…

So your goal is, when sending a patch, to give me no excuse to not
accept it. To make it such that if I ignore it, or reject it, I am the
one that is the problem here, not you."

And this thing is not really clear to all submitters - once their
patch(es) is applied, they're done. But maintainers have to deal with
that code forever.

So before you send your patchset, try to think as a maintainer and
think whether your change makes sense for the *whole* tree and whether
maintaining it forward would be easy.

- Did I say that maintainers are overworked?

Submitters don't see the amount of work maintainers do in the
background, testing everything and fixing build issues and bugs. Because
most of the time, submitters submit and the cleanups and bugs get mopped
after them by the maintainers - not the submitters.

Look at how some trees resort to maintainer *groups* because a single
maintainer simply doesn't scale, at the risk of a burnout or whatever
nasty.

And those maintainer groups have *all* their hands full.

> Hopefully the newbies can also be treated fairly in the community.

Newbies are treated fairly in the community - especially those who come
prepared and try to understand why the maintainers say things they way
they do and listen to feedback.

If there are examples against that, we would all like to know about
them.

I sincerely hope that explains the situation and hope that it'll help
you see it from the maintainers' POV too and maybe help you deal with
future submissions a lot better.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation

[Bjorn Helgaas]

[+cc linux-pci, Konstantin, since you're thinking about this area, too]

The 0-day bot seems to remove mailing lists from the recipient list,
which means reports like the one below don't become part of the public
email thread and don't get connected to the patch in patchwork.  I
think this is a problem.

For example here are Xuesong's original patch, the patch in patchwork,
and the 0-day bot report:

  https://lore.kernel.org/all/20211027081312.53682-1-xuesong.chen@linux.alibaba.com/
  https://patchwork.kernel.org/project/linux-pci/patch/20211027081312.53682-1-xuesong.chen@linux.alibaba.com/
  https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org/thread/QISVC5TJIHTEMAPX7T7YXOZEDS5CBURY/

Neither the lore link nor the patchwork have any indication that the
0-day bot found a problem.

It looks like the 0-day bot sent the report to all the individual
recipients from the original patch, but it ADDED these recipients:

  llvm@lists.linux.dev
  kbuild-all@lists.01.org

and REMOVED these:

  linux-pci@vger.kernel.org
  linux-acpi@vger.kernel.org
  linux-arm-kernel@lists.infradead.org
  linux-kernel@vger.kernel.org

Gmail filed Xuesong's original patch and the 0-day report as spam.
That's a problem on my end, but the bigger problem is that I work from
the patchwork queue, which has no indication of the problem.

I'm sure you have a reason for removing the mailing lists.  Should we
revisit that?  Should I be approaching this a different way?

If a *person* responds to a patch on the list, I expect a reply-all so
the response becomes part of the thread.  Why should the 0-day bot be
different?

I added linux-pci to cc, but since the 0-day report didn't go to the
list, I don't think this message will be threaded correctly on lore.
It should be part of
https://lore.kernel.org/all/20211027081035.53370-1-xuesong.chen@linux.alibaba.com/

On Thu, Oct 28, 2021 at 06:46:16AM +0800, kernel test robot wrote:
> Hi Xuesong,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on helgaas-pci/next]
> [also build test WARNING on rafael-pm/linux-next tip/x86/core arm64/for-next/core v5.15-rc7 next-20211027]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:    https://github.com/0day-ci/linux/commits/Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
> config: x86_64-randconfig-s022-20211027 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> reproduce:
>         # apt-get install sparse
>         # sparse version: v0.6.4-dirty
>         # https://github.com/0day-ci/linux/commit/8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
>         git remote add linux-review https://github.com/0day-ci/linux
>         git fetch --no-tags linux-review Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
>         git checkout 8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
>         # save the attached .config to linux build tree
>         make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/acpi/apei/
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
> 
> 
> sparse warnings: (new ones prefixed by >>)
> >> drivers/acpi/apei/apei-base.c:453:5: sparse: sparse: symbol 'remove_quirk_mcfg_res' was not declared. Should it be static?
>    drivers/acpi/apei/apei-base.c:804:12: sparse: sparse: symbol 'arch_apei_enable_cmcff' was not declared. Should it be static?
>    drivers/acpi/apei/apei-base.c:811:13: sparse: sparse: symbol 'arch_apei_report_mem_error' was not declared. Should it be static?
> 
> Please review and possibly fold the followup patch.
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

Re: [PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation

[Bjorn Helgaas]

[-- Attachment #1: Type: text/plain, Size: 4162 bytes --]

[+cc linux-pci, Konstantin, since you're thinking about this area, too]

The 0-day bot seems to remove mailing lists from the recipient list,
which means reports like the one below don't become part of the public
email thread and don't get connected to the patch in patchwork.  I
think this is a problem.

For example here are Xuesong's original patch, the patch in patchwork,
and the 0-day bot report:

  https://lore.kernel.org/all/20211027081312.53682-1-xuesong.chen(a)linux.alibaba.com/
  https://patchwork.kernel.org/project/linux-pci/patch/20211027081312.53682-1-xuesong.chen(a)linux.alibaba.com/
  https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org/thread/QISVC5TJIHTEMAPX7T7YXOZEDS5CBURY/

Neither the lore link nor the patchwork have any indication that the
0-day bot found a problem.

It looks like the 0-day bot sent the report to all the individual
recipients from the original patch, but it ADDED these recipients:

  llvm(a)lists.linux.dev
  kbuild-all(a)lists.01.org

and REMOVED these:

  linux-pci(a)vger.kernel.org
  linux-acpi(a)vger.kernel.org
  linux-arm-kernel(a)lists.infradead.org
  linux-kernel(a)vger.kernel.org

Gmail filed Xuesong's original patch and the 0-day report as spam.
That's a problem on my end, but the bigger problem is that I work from
the patchwork queue, which has no indication of the problem.

I'm sure you have a reason for removing the mailing lists.  Should we
revisit that?  Should I be approaching this a different way?

If a *person* responds to a patch on the list, I expect a reply-all so
the response becomes part of the thread.  Why should the 0-day bot be
different?

I added linux-pci to cc, but since the 0-day report didn't go to the
list, I don't think this message will be threaded correctly on lore.
It should be part of
https://lore.kernel.org/all/20211027081035.53370-1-xuesong.chen(a)linux.alibaba.com/

On Thu, Oct 28, 2021 at 06:46:16AM +0800, kernel test robot wrote:
> Hi Xuesong,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on helgaas-pci/next]
> [also build test WARNING on rafael-pm/linux-next tip/x86/core arm64/for-next/core v5.15-rc7 next-20211027]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:    https://github.com/0day-ci/linux/commits/Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
> config: x86_64-randconfig-s022-20211027 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> reproduce:
>         # apt-get install sparse
>         # sparse version: v0.6.4-dirty
>         # https://github.com/0day-ci/linux/commit/8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
>         git remote add linux-review https://github.com/0day-ci/linux
>         git fetch --no-tags linux-review Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
>         git checkout 8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
>         # save the attached .config to linux build tree
>         make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/acpi/apei/
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
> 
> 
> sparse warnings: (new ones prefixed by >>)
> >> drivers/acpi/apei/apei-base.c:453:5: sparse: sparse: symbol 'remove_quirk_mcfg_res' was not declared. Should it be static?
>    drivers/acpi/apei/apei-base.c:804:12: sparse: sparse: symbol 'arch_apei_enable_cmcff' was not declared. Should it be static?
>    drivers/acpi/apei/apei-base.c:811:13: sparse: sparse: symbol 'arch_apei_report_mem_error' was not declared. Should it be static?
> 
> Please review and possibly fold the followup patch.
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

Re: [kbuild-all] Re: [PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation

[Rong Chen]

On 11/2/21 1:15 AM, Bjorn Helgaas wrote:
> [+cc linux-pci, Konstantin, since you're thinking about this area, too]
>
> The 0-day bot seems to remove mailing lists from the recipient list,
> which means reports like the one below don't become part of the public
> email thread and don't get connected to the patch in patchwork.  I
> think this is a problem.
>
> For example here are Xuesong's original patch, the patch in patchwork,
> and the 0-day bot report:
>
>    https://lore.kernel.org/all/20211027081312.53682-1-xuesong.chen@linux.alibaba.com/
>    https://patchwork.kernel.org/project/linux-pci/patch/20211027081312.53682-1-xuesong.chen@linux.alibaba.com/
>    https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org/thread/QISVC5TJIHTEMAPX7T7YXOZEDS5CBURY/
>
> Neither the lore link nor the patchwork have any indication that the
> 0-day bot found a problem.
>
> It looks like the 0-day bot sent the report to all the individual
> recipients from the original patch, but it ADDED these recipients:
>
>    llvm@lists.linux.dev
>    kbuild-all@lists.01.org
>
> and REMOVED these:
>
>    linux-pci@vger.kernel.org
>    linux-acpi@vger.kernel.org
>    linux-arm-kernel@lists.infradead.org
>    linux-kernel@vger.kernel.org
>
> Gmail filed Xuesong's original patch and the 0-day report as spam.
> That's a problem on my end, but the bigger problem is that I work from
> the patchwork queue, which has no indication of the problem.
>
> I'm sure you have a reason for removing the mailing lists.  Should we
> revisit that?  Should I be approaching this a different way?
>
> If a *person* responds to a patch on the list, I expect a reply-all so
> the response becomes part of the thread.  Why should the 0-day bot be
> different?

Hi Bjorn,

Sorry for the inconvenience, we expect replying to the mailing lists too,
it should be a problem in 0-day side.

Best Regards,
Rong Chen

>
> I added linux-pci to cc, but since the 0-day report didn't go to the
> list, I don't think this message will be threaded correctly on lore.
> It should be part of
> https://lore.kernel.org/all/20211027081035.53370-1-xuesong.chen@linux.alibaba.com/
>
> On Thu, Oct 28, 2021 at 06:46:16AM +0800, kernel test robot wrote:
>> Hi Xuesong,
>>
>> Thank you for the patch! Perhaps something to improve:
>>
>> [auto build test WARNING on helgaas-pci/next]
>> [also build test WARNING on rafael-pm/linux-next tip/x86/core arm64/for-next/core v5.15-rc7 next-20211027]
>> [If your patch is applied to the wrong git tree, kindly drop us a note.
>> And when submitting patch, we suggest to use '--base' as documented in
>> https://git-scm.com/docs/git-format-patch]
>>
>> url:    https://github.com/0day-ci/linux/commits/Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
>> config: x86_64-randconfig-s022-20211027 (attached as .config)
>> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
>> reproduce:
>>          # apt-get install sparse
>>          # sparse version: v0.6.4-dirty
>>          # https://github.com/0day-ci/linux/commit/8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
>>          git remote add linux-review https://github.com/0day-ci/linux
>>          git fetch --no-tags linux-review Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
>>          git checkout 8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
>>          # save the attached .config to linux build tree
>>          make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/acpi/apei/
>>
>> If you fix the issue, kindly add following tag as appropriate
>> Reported-by: kernel test robot <lkp@intel.com>
>>
>>
>> sparse warnings: (new ones prefixed by >>)
>>>> drivers/acpi/apei/apei-base.c:453:5: sparse: sparse: symbol 'remove_quirk_mcfg_res' was not declared. Should it be static?
>>     drivers/acpi/apei/apei-base.c:804:12: sparse: sparse: symbol 'arch_apei_enable_cmcff' was not declared. Should it be static?
>>     drivers/acpi/apei/apei-base.c:811:13: sparse: sparse: symbol 'arch_apei_report_mem_error' was not declared. Should it be static?
>>
>> Please review and possibly fold the followup patch.
>>
>> ---
>> 0-DAY CI Kernel Test Service, Intel Corporation
>> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
> _______________________________________________
> kbuild-all mailing list -- kbuild-all@lists.01.org
> To unsubscribe send an email to kbuild-all-leave@lists.01.org

Re: [PATCH v4 3/4] ACPI: APEI: Reserve the MCFG address for quirk ECAM implementation

[Rong Chen]

[-- Attachment #1: Type: text/plain, Size: 4668 bytes --]



On 11/2/21 1:15 AM, Bjorn Helgaas wrote:
> [+cc linux-pci, Konstantin, since you're thinking about this area, too]
>
> The 0-day bot seems to remove mailing lists from the recipient list,
> which means reports like the one below don't become part of the public
> email thread and don't get connected to the patch in patchwork.  I
> think this is a problem.
>
> For example here are Xuesong's original patch, the patch in patchwork,
> and the 0-day bot report:
>
>    https://lore.kernel.org/all/20211027081312.53682-1-xuesong.chen(a)linux.alibaba.com/
>    https://patchwork.kernel.org/project/linux-pci/patch/20211027081312.53682-1-xuesong.chen(a)linux.alibaba.com/
>    https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org/thread/QISVC5TJIHTEMAPX7T7YXOZEDS5CBURY/
>
> Neither the lore link nor the patchwork have any indication that the
> 0-day bot found a problem.
>
> It looks like the 0-day bot sent the report to all the individual
> recipients from the original patch, but it ADDED these recipients:
>
>    llvm(a)lists.linux.dev
>    kbuild-all(a)lists.01.org
>
> and REMOVED these:
>
>    linux-pci(a)vger.kernel.org
>    linux-acpi(a)vger.kernel.org
>    linux-arm-kernel(a)lists.infradead.org
>    linux-kernel(a)vger.kernel.org
>
> Gmail filed Xuesong's original patch and the 0-day report as spam.
> That's a problem on my end, but the bigger problem is that I work from
> the patchwork queue, which has no indication of the problem.
>
> I'm sure you have a reason for removing the mailing lists.  Should we
> revisit that?  Should I be approaching this a different way?
>
> If a *person* responds to a patch on the list, I expect a reply-all so
> the response becomes part of the thread.  Why should the 0-day bot be
> different?

Hi Bjorn,

Sorry for the inconvenience, we expect replying to the mailing lists too,
it should be a problem in 0-day side.

Best Regards,
Rong Chen

>
> I added linux-pci to cc, but since the 0-day report didn't go to the
> list, I don't think this message will be threaded correctly on lore.
> It should be part of
> https://lore.kernel.org/all/20211027081035.53370-1-xuesong.chen(a)linux.alibaba.com/
>
> On Thu, Oct 28, 2021 at 06:46:16AM +0800, kernel test robot wrote:
>> Hi Xuesong,
>>
>> Thank you for the patch! Perhaps something to improve:
>>
>> [auto build test WARNING on helgaas-pci/next]
>> [also build test WARNING on rafael-pm/linux-next tip/x86/core arm64/for-next/core v5.15-rc7 next-20211027]
>> [If your patch is applied to the wrong git tree, kindly drop us a note.
>> And when submitting patch, we suggest to use '--base' as documented in
>> https://git-scm.com/docs/git-format-patch]
>>
>> url:    https://github.com/0day-ci/linux/commits/Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
>> config: x86_64-randconfig-s022-20211027 (attached as .config)
>> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
>> reproduce:
>>          # apt-get install sparse
>>          # sparse version: v0.6.4-dirty
>>          # https://github.com/0day-ci/linux/commit/8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
>>          git remote add linux-review https://github.com/0day-ci/linux
>>          git fetch --no-tags linux-review Xuesong-Chen/PCI-MCFG-Consolidate-the-separate-PCI-MCFG-table-entry-list/20211027-171229
>>          git checkout 8fce66d9da6f8e55c5cf0dda4a13dba6bd51492d
>>          # save the attached .config to linux build tree
>>          make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/acpi/apei/
>>
>> If you fix the issue, kindly add following tag as appropriate
>> Reported-by: kernel test robot <lkp@intel.com>
>>
>>
>> sparse warnings: (new ones prefixed by >>)
>>>> drivers/acpi/apei/apei-base.c:453:5: sparse: sparse: symbol 'remove_quirk_mcfg_res' was not declared. Should it be static?
>>     drivers/acpi/apei/apei-base.c:804:12: sparse: sparse: symbol 'arch_apei_enable_cmcff' was not declared. Should it be static?
>>     drivers/acpi/apei/apei-base.c:811:13: sparse: sparse: symbol 'arch_apei_report_mem_error' was not declared. Should it be static?
>>
>> Please review and possibly fold the followup patch.
>>
>> ---
>> 0-DAY CI Kernel Test Service, Intel Corporation
>> https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
> _______________________________________________
> kbuild-all mailing list -- kbuild-all(a)lists.01.org
> To unsubscribe send an email to kbuild-all-leave(a)lists.01.org