Re: [PATCH v3 3/4] PCI/AER: Disable AER interrupt on suspend
On Thu, Apr 20, 2023 at 10:53 PM Sathyanarayanan Kuppuswamy
wrote:
>
>
>
> On 4/20/23 5:59 AM, Kai-Heng Feng wrote:
> > PCIe service that shares IRQ with PME may cause spurious wakeup on
> > system suspend.
> >
> > PCIe Base Spec 5.0, section 5.2 "Link State Power Management" states
> > that TLP and DLLP transmission is disabled for a Link in L2/L3 Ready
> > (D3hot), L2 (D3cold with aux power) and L3 (D3cold), so we don't lose
> > much here to disable AER during system suspend.
> >
> > This is very similar to previous attempts to suspend AER and DPC [1],
> > but with a different reason.
> >
> > [1]
> > https://lore.kernel.org/linux-pci/20220408153159.106741-1-kai.heng.f...@canonical.com/
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=216295
> >
> > Reviewed-by: Mika Westerberg
> > Signed-off-by: Kai-Heng Feng
> > ---
>
> In Patch #1, you skip clearing AER errors in the resume path, right? So if we
> disable
> interrupts here, will AER driver not be notified on resume path error?
I agree the driver should report the error via aer_isr_one_error() on
resume path.
But on the system I am using (Intel ADL PCH), once the interrupt is
disabled, PCI_ERR_ROOT_STATUS doesn't record error anymore.
Not sure if it's intended though.
Kai-Heng
>
> > v3:
> > - No change.
> >
> > v2:
> > - Only disable AER IRQ.
> > - No more check on PME IRQ#.
> > - Use helper.
> >
> > drivers/pci/pcie/aer.c | 22 ++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> > index 1420e1f27105..9c07fdbeb52d 100644
> > --- a/drivers/pci/pcie/aer.c
> > +++ b/drivers/pci/pcie/aer.c
> > @@ -1356,6 +1356,26 @@ static int aer_probe(struct pcie_device *dev)
> > return 0;
> > }
> >
> > +static int aer_suspend(struct pcie_device *dev)
> > +{
> > + struct aer_rpc *rpc = get_service_data(dev);
> > + struct pci_dev *pdev = rpc->rpd;
> > +
> > + aer_disable_irq(pdev);
> > +
> > + return 0;
> > +}
> > +
> > +static int aer_resume(struct pcie_device *dev)
> > +{
> > + struct aer_rpc *rpc = get_service_data(dev);
> > + struct pci_dev *pdev = rpc->rpd;
> > +
> > + aer_enable_irq(pdev);
> > +
> > + return 0;
> > +}
> > +
> > /**
> > * aer_root_reset - reset Root Port hierarchy, RCEC, or RCiEP
> > * @dev: pointer to Root Port, RCEC, or RCiEP
> > @@ -1420,6 +1440,8 @@ static struct pcie_port_service_driver aerdriver = {
> > .service= PCIE_PORT_SERVICE_AER,
> >
> > .probe = aer_probe,
> > + .suspend= aer_suspend,
> > + .resume = aer_resume,
> > .remove = aer_remove,
> > };
> >
>
> --
> Sathyanarayanan Kuppuswamy
> Linux Kernel Developer
Re: [PATCH 01/22] powerpc, workqueue: Use alloc_ordered_workqueue() to create ordered workqueues
Tejun Heo writes:
> BACKGROUND
> ==
>
> When multiple work items are queued to a workqueue, their execution order
> doesn't match the queueing order. They may get executed in any order and
> simultaneously. When fully serialized execution - one by one in the queueing
> order - is needed, an ordered workqueue should be used which can be created
> with alloc_ordered_workqueue().
>
> However, alloc_ordered_workqueue() was a later addition. Before it, an
> ordered workqueue could be obtained by creating an UNBOUND workqueue with
> @max_active==1. This originally was an implementation side-effect which was
> broken by 4c16bd327c74 ("workqueue: restore WQ_UNBOUND/max_active==1 to be
> ordered"). Because there were users that depended on the ordered execution,
> 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered")
> made workqueue allocation path to implicitly promote UNBOUND workqueues w/
> @max_active==1 to ordered workqueues.
>
> While this has worked okay, overloading the UNBOUND allocation interface
> this way creates other issues. It's difficult to tell whether a given
> workqueue actually needs to be ordered and users that legitimately want a
> min concurrency level wq unexpectedly gets an ordered one instead. With
> planned UNBOUND workqueue updates to improve execution locality and more
> prevalence of chiplet designs which can benefit from such improvements, this
> isn't a state we wanna be in forever.
>
> This patch series audits all callsites that create an UNBOUND workqueue w/
> @max_active==1 and converts them to alloc_ordered_workqueue() as necessary.
>
> WHAT TO LOOK FOR
>
>
> The conversions are from
>
> alloc_workqueue(WQ_UNBOUND | flags, 1, args..)
>
> to
>
> alloc_ordered_workqueue(flags, args...)
>
> which don't cause any functional changes. If you know that fully ordered
> execution is not ncessary, please let me know. I'll drop the conversion and
> instead add a comment noting the fact to reduce confusion while conversion
> is in progress.
>
> If you aren't fully sure, it's completely fine to let the conversion
> through. The behavior will stay exactly the same and we can always
> reconsider later.
>
> As there are follow-up workqueue core changes, I'd really appreciate if the
> patch can be routed through the workqueue tree w/ your acks. Thanks.
>
> Signed-off-by: Tejun Heo
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christophe Leroy
> Cc: Nathan Lynch
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> arch/powerpc/kernel/tau_6xx.c | 2 +-
> arch/powerpc/platforms/pseries/dlpar.c | 3 +--
> 2 files changed, 2 insertions(+), 3 deletions(-)
Acked-by: Michael Ellerman (powerpc)
> diff --git a/arch/powerpc/kernel/tau_6xx.c b/arch/powerpc/kernel/tau_6xx.c
> index 828d0f4106d2..cba6dd15de3b 100644
> --- a/arch/powerpc/kernel/tau_6xx.c
> +++ b/arch/powerpc/kernel/tau_6xx.c
> @@ -200,7 +200,7 @@ static int __init TAU_init(void)
> tau_int_enable = IS_ENABLED(CONFIG_TAU_INT) &&
>!strcmp(cur_cpu_spec->platform, "ppc750");
>
> - tau_workq = alloc_workqueue("tau", WQ_UNBOUND, 1);
> + tau_workq = alloc_ordered_workqueue("tau", 0);
> if (!tau_workq)
> return -ENOMEM;
>
> diff --git a/arch/powerpc/platforms/pseries/dlpar.c
> b/arch/powerpc/platforms/pseries/dlpar.c
> index 75ffdbcd2865..e9117b03807e 100644
> --- a/arch/powerpc/platforms/pseries/dlpar.c
> +++ b/arch/powerpc/platforms/pseries/dlpar.c
> @@ -564,8 +564,7 @@ int __init dlpar_workqueue_init(void)
> if (pseries_hp_wq)
> return 0;
>
> - pseries_hp_wq = alloc_workqueue("pseries hotplug workqueue",
> - WQ_UNBOUND, 1);
> + pseries_hp_wq = alloc_ordered_workqueue("pseries hotplug workqueue", 0);
>
> return pseries_hp_wq ? 0 : -ENOMEM;
> }
The change log of commit 9054619ef54a ("powerpc/pseries: Add pseries
hotplug workqueue") makes it fairly clear that this code does explicitly
want an ordered queue.
cheers
[powerpc:next] BUILD SUCCESS e4f42c1467e9233c35716eb2b4511fef990cdc23
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: e4f42c1467e9233c35716eb2b4511fef990cdc23 powerpc/configs/powernv: Add IGB=y elapsed time: 725m configs tested: 239 configs skipped: 21 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alpha defconfig gcc alpharandconfig-r004-20230416 gcc alpharandconfig-r032-20230416 gcc alpharandconfig-r036-20230420 gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-r006-20230417 gcc arc randconfig-r011-20230416 gcc arc randconfig-r011-20230420 gcc arc randconfig-r012-20230418 gcc arc randconfig-r022-20230417 gcc arc randconfig-r024-20230417 gcc arc randconfig-r033-20230416 gcc arc randconfig-r034-20230416 gcc arc randconfig-r043-20230416 gcc arc randconfig-r043-20230417 gcc arc randconfig-r043-20230418 gcc arc randconfig-r043-20230419 gcc arc randconfig-r043-20230420 gcc arm allmodconfig gcc arm allyesconfig gcc arm buildonly-randconfig-r001-20230420 clang arm buildonly-randconfig-r003-20230420 clang arm buildonly-randconfig-r005-20230417 gcc arm buildonly-randconfig-r006-20230418 clang arm defconfig gcc arm randconfig-r002-20230416 gcc arm randconfig-r002-20230417 clang arm randconfig-r012-20230416 clang arm randconfig-r013-20230417 gcc arm randconfig-r023-20230416 clang arm randconfig-r046-20230416 clang arm randconfig-r046-20230417 gcc arm randconfig-r046-20230418 clang arm randconfig-r046-20230419 gcc arm randconfig-r046-20230420 clang arm64allyesconfig gcc arm64buildonly-randconfig-r001-20230417 gcc arm64 defconfig gcc arm64randconfig-r001-20230418 clang arm64randconfig-r004-20230417 gcc arm64randconfig-r006-20230416 clang arm64randconfig-r013-20230418 gcc arm64randconfig-r016-20230416 gcc arm64randconfig-r022-20230416 gcc arm64randconfig-r032-20230420 clang arm64randconfig-r034-20230419 gcc cskydefconfig gcc csky randconfig-r011-20230418 gcc csky randconfig-r012-20230416 gcc csky randconfig-r024-20230416 gcc csky randconfig-r033-20230417 gcc csky randconfig-r035-20230417 gcc csky randconfig-r036-20230417 gcc hexagon randconfig-r005-20230416 clang hexagon randconfig-r006-20230418 clang hexagon randconfig-r015-20230416 clang hexagon randconfig-r032-20230417 clang hexagon randconfig-r033-20230417 clang hexagon randconfig-r035-20230417 clang hexagon randconfig-r041-20230416 clang hexagon randconfig-r041-20230417 clang hexagon randconfig-r041-20230418 clang hexagon randconfig-r041-20230419 clang hexagon randconfig-r041-20230420 clang hexagon randconfig-r045-20230416 clang hexagon randconfig-r045-20230417 clang hexagon randconfig-r045-20230418 clang hexagon randconfig-r045-20230419 clang hexagon randconfig-r045-20230420 clang i386 allyesconfig gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-a001-20230417 gcc i386 randconfig-a002-20230417 gcc i386 randconfig-a003-20230417 gcc i386 randconfig-a004-20230417 gcc i386 randconfig-a005-20230417 gcc i386 randconfig-a006-20230417 gcc i386 randconfig-a011-20230417 clang i386 randconfig-a012-20230417 clang i386 randconfig-a013-20230417 clang i386 randconfig-a014-20230417 clang i386 randconfig-a015-20230417 clang i386 randconfig-a016
[powerpc:merge] BUILD SUCCESS 5741d7d2a179be6418fbd85442d92b026477f5b8
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: 5741d7d2a179be6418fbd85442d92b026477f5b8 Automatic merge of 'next' into merge (2023-04-21 00:06) elapsed time: 726m configs tested: 167 configs skipped: 15 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alphabuildonly-randconfig-r005-20230417 gcc alpha defconfig gcc alpharandconfig-r004-20230416 gcc alpharandconfig-r036-20230420 gcc arc allyesconfig gcc arc buildonly-randconfig-r006-20230416 gcc arc defconfig gcc arc randconfig-r025-20230419 gcc arc randconfig-r043-20230416 gcc arc randconfig-r043-20230417 gcc arc randconfig-r043-20230418 gcc arm allmodconfig gcc arm allyesconfig gcc arm defconfig gcc arm randconfig-r013-20230417 gcc arm randconfig-r021-20230416 clang arm randconfig-r046-20230416 clang arm randconfig-r046-20230417 gcc arm randconfig-r046-20230418 clang arm64allyesconfig gcc arm64 defconfig gcc arm64randconfig-r006-20230416 clang arm64randconfig-r016-20230416 gcc arm64randconfig-r023-20230419 clang arm64randconfig-r026-20230419 clang arm64randconfig-r034-20230419 gcc cskydefconfig gcc csky randconfig-r013-20230420 gcc csky randconfig-r036-20230417 gcc hexagon buildonly-randconfig-r003-20230417 clang hexagon randconfig-r012-20230420 clang hexagon randconfig-r032-20230417 clang hexagon randconfig-r033-20230417 clang hexagon randconfig-r035-20230417 clang hexagon randconfig-r041-20230416 clang hexagon randconfig-r041-20230417 clang hexagon randconfig-r041-20230418 clang hexagon randconfig-r045-20230416 clang hexagon randconfig-r045-20230417 clang hexagon randconfig-r045-20230418 clang i386 allyesconfig gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-a001-20230417 gcc i386 randconfig-a002-20230417 gcc i386 randconfig-a003-20230417 gcc i386 randconfig-a004-20230417 gcc i386 randconfig-a005-20230417 gcc i386 randconfig-a006-20230417 gcc i386 randconfig-a011-20230417 clang i386 randconfig-a012-20230417 clang i386 randconfig-a013-20230417 clang i386 randconfig-a014-20230417 clang i386 randconfig-a015-20230417 clang i386 randconfig-a016-20230417 clang ia64 allmodconfig gcc ia64 buildonly-randconfig-r002-20230417 gcc ia64 buildonly-randconfig-r005-20230416 gcc ia64defconfig gcc ia64 randconfig-r002-20230417 gcc ia64 randconfig-r012-20230416 gcc ia64 randconfig-r031-20230419 gcc ia64 randconfig-r036-20230416 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchbuildonly-randconfig-r006-20230418 gcc loongarch defconfig gcc loongarchrandconfig-r011-20230420 gcc m68k allmodconfig gcc m68k buildonly-randconfig-r005-20230418 gcc m68kdefconfig gcc m68k randconfig-r011-20230417 gcc m68k randconfig-r013-20230416 gcc microblaze buildonly-randconfig-r003-20230418 gcc microblaze randconfig-r001-20230417 gcc microblaze randconfig-r006-20230417 gcc microblaze randconfig-r014-20230417 gcc microblaze randconfig-r016-20230417 gcc microblaze randconfig-r023-20230420 gcc mips allmodconfig gcc mips allyesconfig gcc mips randconfig-r001-20230416 gcc nios2 defconfig gcc nios2randconfig-r014-20230420 gcc nios2
[PATCH 01/22] powerpc, workqueue: Use alloc_ordered_workqueue() to create ordered workqueues
BACKGROUND
==
When multiple work items are queued to a workqueue, their execution order
doesn't match the queueing order. They may get executed in any order and
simultaneously. When fully serialized execution - one by one in the queueing
order - is needed, an ordered workqueue should be used which can be created
with alloc_ordered_workqueue().
However, alloc_ordered_workqueue() was a later addition. Before it, an
ordered workqueue could be obtained by creating an UNBOUND workqueue with
@max_active==1. This originally was an implementation side-effect which was
broken by 4c16bd327c74 ("workqueue: restore WQ_UNBOUND/max_active==1 to be
ordered"). Because there were users that depended on the ordered execution,
5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered")
made workqueue allocation path to implicitly promote UNBOUND workqueues w/
@max_active==1 to ordered workqueues.
While this has worked okay, overloading the UNBOUND allocation interface
this way creates other issues. It's difficult to tell whether a given
workqueue actually needs to be ordered and users that legitimately want a
min concurrency level wq unexpectedly gets an ordered one instead. With
planned UNBOUND workqueue updates to improve execution locality and more
prevalence of chiplet designs which can benefit from such improvements, this
isn't a state we wanna be in forever.
This patch series audits all callsites that create an UNBOUND workqueue w/
@max_active==1 and converts them to alloc_ordered_workqueue() as necessary.
WHAT TO LOOK FOR
The conversions are from
alloc_workqueue(WQ_UNBOUND | flags, 1, args..)
to
alloc_ordered_workqueue(flags, args...)
which don't cause any functional changes. If you know that fully ordered
execution is not ncessary, please let me know. I'll drop the conversion and
instead add a comment noting the fact to reduce confusion while conversion
is in progress.
If you aren't fully sure, it's completely fine to let the conversion
through. The behavior will stay exactly the same and we can always
reconsider later.
As there are follow-up workqueue core changes, I'd really appreciate if the
patch can be routed through the workqueue tree w/ your acks. Thanks.
Signed-off-by: Tejun Heo
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: Nathan Lynch
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/tau_6xx.c | 2 +-
arch/powerpc/platforms/pseries/dlpar.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/tau_6xx.c b/arch/powerpc/kernel/tau_6xx.c
index 828d0f4106d2..cba6dd15de3b 100644
--- a/arch/powerpc/kernel/tau_6xx.c
+++ b/arch/powerpc/kernel/tau_6xx.c
@@ -200,7 +200,7 @@ static int __init TAU_init(void)
tau_int_enable = IS_ENABLED(CONFIG_TAU_INT) &&
!strcmp(cur_cpu_spec->platform, "ppc750");
- tau_workq = alloc_workqueue("tau", WQ_UNBOUND, 1);
+ tau_workq = alloc_ordered_workqueue("tau", 0);
if (!tau_workq)
return -ENOMEM;
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
b/arch/powerpc/platforms/pseries/dlpar.c
index 75ffdbcd2865..e9117b03807e 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -564,8 +564,7 @@ int __init dlpar_workqueue_init(void)
if (pseries_hp_wq)
return 0;
- pseries_hp_wq = alloc_workqueue("pseries hotplug workqueue",
- WQ_UNBOUND, 1);
+ pseries_hp_wq = alloc_ordered_workqueue("pseries hotplug workqueue", 0);
return pseries_hp_wq ? 0 : -ENOMEM;
}
--
2.40.0
Re: [PATCH 01/33] s390: Use _pt_s390_gaddr for gmap address tracking
On Wed, Apr 19, 2023 at 12:54 AM David Hildenbrand wrote:
>
> On 18.04.23 23:33, Vishal Moola wrote:
> > On Tue, Apr 18, 2023 at 8:45 AM David Hildenbrand wrote:
> >>
> >> On 17.04.23 22:50, Vishal Moola (Oracle) wrote:
> >>> s390 uses page->index to keep track of page tables for the guest address
> >>> space. In an attempt to consolidate the usage of page fields in s390,
> >>> replace _pt_pad_2 with _pt_s390_gaddr to replace page->index in gmap.
> >>>
> >>> This will help with the splitting of struct ptdesc from struct page, as
> >>> well as allow s390 to use _pt_frag_refcount for fragmented page table
> >>> tracking.
> >>>
> >>> Since page->_pt_s390_gaddr aliases with mapping, ensure its set to NULL
> >>> before freeing the pages as well.
> >>>
> >>> Signed-off-by: Vishal Moola (Oracle)
> >>> ---
> >>
> >> [...]
> >>
> >>> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> >>> index 3fc9e680f174..2616d64c0e8c 100644
> >>> --- a/include/linux/mm_types.h
> >>> +++ b/include/linux/mm_types.h
> >>> @@ -144,7 +144,7 @@ struct page {
> >>>struct {/* Page table pages */
> >>>unsigned long _pt_pad_1;/* compound_head */
> >>>pgtable_t pmd_huge_pte; /* protected by page->ptl
> >>> */
> >>> - unsigned long _pt_pad_2;/* mapping */
> >>> + unsigned long _pt_s390_gaddr; /* mapping */
> >>>union {
> >>>struct mm_struct *pt_mm; /* x86 pgds only
> >>> */
> >>>atomic_t pt_frag_refcount; /* powerpc */
> >>
> >> The confusing part is, that these gmap page tables are not ordinary
> >> process page tables that we would ordinarily place into this section
> >> here. That's why they are also not allocated/freed using the typical
> >> page table constructor/destructor ...
> >
> > I initially thought the same, so I was quite confused when I saw
> > __gmap_segment_gaddr was using pmd_pgtable_page().
> >
> > Although they are not ordinary process page tables, since we
> > eventually want to move them out of struct page, I think shifting them
> > to be in ptdescs, being a memory descriptor for page tables, makes
> > the most sense.
>
> Seeing utilities like tlb_remove_page_ptdesc() that don't really apply
> to such page tables, I wonder if we should much rather treat such
> shadow/auxiliary/... page tables (just like other architectures like
> x86, arm, ... employ as well) as a distinct type.
>
> And have ptdesc be the common type for all process page tables.
Although I do like the idea of having a distinct type for them, I'm not sure
I see the merits of having another type specifically for those types of
page tables.
As it currently is, tlb_remove_table() is only distinct from tlb_remove_page()
when an architecture defines its own removal function. I'm not too familiar
with most of their differences, but we can probably continue to let them do
that. As of now, I'm not too sure what a distinct type would look like that
could meet all their needs holistically.
> >
> > Another option is to leave pmd_pgtable_page() as is just for this case.
> > Or we can revert commit 7e25de77bc5ea which uses the function here
> > then figure out where these gmap pages table pages will go later.
>
> I'm always confused when reading gmap code, so let me have another look :)
>
> The confusing part is that s390x shares the lowest level page tables
> (PTE tables) between the process and gmap ("guest mapping", similar to
> EPT on x86-64). It maps these process PTE tables (covering 1 MiB) into
> gmap-specific PMD tables.
Especially in cases like this. If the architecture wants to share page tables
then everything being in form ptdesc would make that easiest, and
continue to let them define their own niche functions for their needs.
> pmd_pgtable_page() should indeed always give us a gmap-specific
> PMD-table. In fact, something allocated via gmap_alloc_table().
>
> Decoupling both concepts sounds like a good idea.
Yeah, I'm not a fan of how this gmap caller is the only external caller
using this to get a page for their own purposes. I'll update that in v2.
[PATCH 1/1] PCI: layerscape: Add the endpoint linkup notifier support
Layerscape has PME interrupt, which can be use as linkup notifer.
Set CFG_READY bit when linkup detected.
Signed-off-by: Xiaowei Bao
Signed-off-by: Frank Li
---
.../pci/controller/dwc/pci-layerscape-ep.c| 104 +-
1 file changed, 103 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index c640db60edc6..66d4a78a30a4 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -18,6 +18,20 @@
#include "pcie-designware.h"
+#define PEX_PF0_CONFIG 0xC0014
+#define PEX_PF0_CFG_READY BIT(0)
+
+/* PEX PFa PCIE pme and message interrupt registers*/
+#define PEX_PF0_PME_MES_DR 0xC0020
+#define PEX_PF0_PME_MES_DR_LUD BIT(7)
+#define PEX_PF0_PME_MES_DR_LDD BIT(9)
+#define PEX_PF0_PME_MES_DR_HRD BIT(10)
+
+#define PEX_PF0_PME_MES_IER0xC0028
+#define PEX_PF0_PME_MES_IER_LUDIE BIT(7)
+#define PEX_PF0_PME_MES_IER_LDDIE BIT(9)
+#define PEX_PF0_PME_MES_IER_HRDIE BIT(10)
+
#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
struct ls_pcie_ep_drvdata {
@@ -30,8 +44,88 @@ struct ls_pcie_ep {
struct dw_pcie *pci;
struct pci_epc_features *ls_epc;
const struct ls_pcie_ep_drvdata *drvdata;
+ boolbig_endian;
+ int irq;
};
+static u32 ls_lut_readl(struct ls_pcie_ep *pcie, u32 offset)
+{
+ struct dw_pcie *pci = pcie->pci;
+
+ if (pcie->big_endian)
+ return ioread32be(pci->dbi_base + offset);
+ else
+ return ioread32(pci->dbi_base + offset);
+}
+
+static void ls_lut_writel(struct ls_pcie_ep *pcie, u32 offset,
+ u32 value)
+{
+ struct dw_pcie *pci = pcie->pci;
+
+ if (pcie->big_endian)
+ iowrite32be(value, pci->dbi_base + offset);
+ else
+ iowrite32(value, pci->dbi_base + offset);
+}
+
+static irqreturn_t ls_pcie_ep_event_handler(int irq, void *dev_id)
+{
+ struct ls_pcie_ep *pcie = (struct ls_pcie_ep *)dev_id;
+ struct dw_pcie *pci = pcie->pci;
+ u32 val, cfg;
+
+ val = ls_lut_readl(pcie, PEX_PF0_PME_MES_DR);
+ if (!val)
+ return IRQ_NONE;
+
+ if (val & PEX_PF0_PME_MES_DR_LUD) {
+ cfg = ls_lut_readl(pcie, PEX_PF0_CONFIG);
+ cfg |= PEX_PF0_CFG_READY;
+ ls_lut_writel(pcie, PEX_PF0_CONFIG, cfg);
+ dw_pcie_ep_linkup(>ep);
+
+ dev_info(pci->dev, "Detect the link up state !\n");
+ } else if (val & PEX_PF0_PME_MES_DR_LDD) {
+ dev_info(pci->dev, "Detect the link down state !\n");
+ } else if (val & PEX_PF0_PME_MES_DR_HRD) {
+ dev_info(pci->dev, "Detect the hot reset state !\n");
+ }
+
+ ls_lut_writel(pcie, PEX_PF0_PME_MES_DR, val);
+
+ return IRQ_HANDLED;
+}
+
+static int ls_pcie_ep_interrupt_init(struct ls_pcie_ep *pcie,
+struct platform_device *pdev)
+{
+ u32 val;
+ int ret;
+
+ pcie->irq = platform_get_irq_byname(pdev, "pme");
+ if (pcie->irq < 0) {
+ dev_err(>dev, "Can't get 'pme' irq.\n");
+ return pcie->irq;
+ }
+
+ ret = devm_request_irq(>dev, pcie->irq,
+ ls_pcie_ep_event_handler, IRQF_SHARED,
+ pdev->name, pcie);
+ if (ret) {
+ dev_err(>dev, "Can't register PCIe IRQ.\n");
+ return ret;
+ }
+
+ /* Enable interrupts */
+ val = ls_lut_readl(pcie, PEX_PF0_PME_MES_IER);
+ val |= PEX_PF0_PME_MES_IER_LDDIE | PEX_PF0_PME_MES_IER_HRDIE |
+ PEX_PF0_PME_MES_IER_LUDIE;
+ ls_lut_writel(pcie, PEX_PF0_PME_MES_IER, val);
+
+ return 0;
+}
+
static const struct pci_epc_features*
ls_pcie_ep_get_features(struct dw_pcie_ep *ep)
{
@@ -125,6 +219,7 @@ static int __init ls_pcie_ep_probe(struct platform_device
*pdev)
struct ls_pcie_ep *pcie;
struct pci_epc_features *ls_epc;
struct resource *dbi_base;
+ int ret;
pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
if (!pcie)
@@ -144,6 +239,7 @@ static int __init ls_pcie_ep_probe(struct platform_device
*pdev)
pci->ops = pcie->drvdata->dw_pcie_ops;
ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4);
+ ls_epc->linkup_notifier = true;
pcie->pci = pci;
pcie->ls_epc = ls_epc;
@@ -155,9 +251,15 @@ static int __init ls_pcie_ep_probe(struct platform_device
*pdev)
pci->ep.ops = _pcie_ep_ops;
+ pcie->big_endian = of_property_read_bool(dev->of_node, "big-endian");
+
platform_set_drvdata(pdev, pcie);
- return dw_pcie_ep_init(>ep);
+ ret = dw_pcie_ep_init(>ep);
+ if
Re: [PATCH v2] powerpc/iommu: DMA address offset is incorrectly calculated with 2MB TCEs
Hello Michael,
I was looking into the Bug: 199106
(https://bugzilla.linux.ibm.com/show_bug.cgi?id=199106).
In the Bug, Mellanox driver was timing out when enabling SRIOV device.
I tested, Alexey's patch and it fixes the issue with Mellanox driver.
The down side
to Alexey's fix is that even a small memory request by the driver will
be aligned up
to 2MB. In my test, the Mellanox driver is issuing multiple requests of
64K size.
All these will get aligned up to 2MB, which is quite a waste of resources.
In any case, both the patches work. Let me know which approach you
prefer. In case
we decide to go with my patch, I just realized that I need to fix
nio_pages in
iommu_free_coherent() as well.
Thanks,
Gaurav
On 4/20/23 10:21 AM, Michael Ellerman wrote:
Gaurav Batra writes:
When DMA window is backed by 2MB TCEs, the DMA address for the mapped
page should be the offset of the page relative to the 2MB TCE. The code
was incorrectly setting the DMA address to the beginning of the TCE
range.
Mellanox driver is reporting timeout trying to ENABLE_HCA for an SR-IOV
ethernet port, when DMA window is backed by 2MB TCEs.
I assume this is similar or related to the bug Srikar reported?
https://lore.kernel.org/linuxppc-dev/20230323095333.gi1005...@linux.vnet.ibm.com/
In that thread Alexey suggested a patch, have you tried his patch? He
suggested rounding up the allocation size, rather than adjusting the
dma_handle.
Fixes: 3872731187141d5d0a5c4fb30007b8b9ec36a44d
That's not the right syntax, it's described in the documentation how to
generate it.
It should be:
Fixes: 387273118714 ("powerps/pseries/dma: Add support for 2M IOMMU page
size")
cheers
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index ee95937bdaf1..ca57526ce47a 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -517,7 +517,7 @@ int ppc_iommu_map_sg(struct device *dev, struct iommu_table
*tbl,
/* Convert entry to a dma_addr_t */
entry += tbl->it_offset;
dma_addr = entry << tbl->it_page_shift;
- dma_addr |= (s->offset & ~IOMMU_PAGE_MASK(tbl));
+ dma_addr |= (vaddr & ~IOMMU_PAGE_MASK(tbl));
DBG(" - %lu pages, entry: %lx, dma_addr: %lx\n",
npages, entry, dma_addr);
@@ -904,6 +904,7 @@ void *iommu_alloc_coherent(struct device *dev, struct
iommu_table *tbl,
unsigned int order;
unsigned int nio_pages, io_order;
struct page *page;
+ int tcesize = (1 << tbl->it_page_shift);
size = PAGE_ALIGN(size);
order = get_order(size);
@@ -930,7 +931,8 @@ void *iommu_alloc_coherent(struct device *dev, struct
iommu_table *tbl,
memset(ret, 0, size);
/* Set up tces to cover the allocated range */
- nio_pages = size >> tbl->it_page_shift;
+ nio_pages = IOMMU_PAGE_ALIGN(size, tbl) >> tbl->it_page_shift;
+
io_order = get_iommu_order(size, tbl);
mapping = iommu_alloc(dev, tbl, ret, nio_pages, DMA_BIDIRECTIONAL,
mask >> tbl->it_page_shift, io_order, 0);
@@ -938,7 +940,8 @@ void *iommu_alloc_coherent(struct device *dev, struct
iommu_table *tbl,
free_pages((unsigned long)ret, order);
return NULL;
}
- *dma_handle = mapping;
+
+ *dma_handle = mapping | ((u64)ret & (tcesize - 1));
return ret;
}
--
Re: [PATCH v9 0/6] Introduce 64b relocatable kernel
Hello: This series was applied to riscv/linux.git (for-next) by Palmer Dabbelt : On Wed, 29 Mar 2023 06:53:23 +0200 you wrote: > After multiple attempts, this patchset is now based on the fact that the > 64b kernel mapping was moved outside the linear mapping. > > The first patch allows to build relocatable kernels but is not selected > by default. That patch is a requirement for KASLR. > The second and third patches take advantage of an already existing powerpc > script that checks relocations at compile-time, and uses it for riscv. > > [...] Here is the summary with links: - [v9,1/6] riscv: Prepare EFI header for relocatable kernels https://git.kernel.org/riscv/c/55de1e4ad43b - [v9,2/6] riscv: Move .rela.dyn outside of init to avoid empty relocations https://git.kernel.org/riscv/c/69a90d2fe107 - [v9,3/6] riscv: Introduce CONFIG_RELOCATABLE https://git.kernel.org/riscv/c/39b33072941f - [v9,4/6] powerpc: Move script to check relocations at compile time in scripts/ https://git.kernel.org/riscv/c/47981b5cc687 - [v9,5/6] riscv: Check relocations at compile time https://git.kernel.org/riscv/c/c2dea0bc5339 - [v9,6/6] riscv: Use --emit-relocs in order to move .rela.dyn in init https://git.kernel.org/riscv/c/559d1e45a16d You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH v2] powerpc/iommu: DMA address offset is incorrectly calculated with 2MB TCEs
Gaurav Batra writes:
> When DMA window is backed by 2MB TCEs, the DMA address for the mapped
> page should be the offset of the page relative to the 2MB TCE. The code
> was incorrectly setting the DMA address to the beginning of the TCE
> range.
>
> Mellanox driver is reporting timeout trying to ENABLE_HCA for an SR-IOV
> ethernet port, when DMA window is backed by 2MB TCEs.
I assume this is similar or related to the bug Srikar reported?
https://lore.kernel.org/linuxppc-dev/20230323095333.gi1005...@linux.vnet.ibm.com/
In that thread Alexey suggested a patch, have you tried his patch? He
suggested rounding up the allocation size, rather than adjusting the
dma_handle.
> Fixes: 3872731187141d5d0a5c4fb30007b8b9ec36a44d
That's not the right syntax, it's described in the documentation how to
generate it.
It should be:
Fixes: 387273118714 ("powerps/pseries/dma: Add support for 2M IOMMU page
size")
cheers
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index ee95937bdaf1..ca57526ce47a 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -517,7 +517,7 @@ int ppc_iommu_map_sg(struct device *dev, struct
> iommu_table *tbl,
> /* Convert entry to a dma_addr_t */
> entry += tbl->it_offset;
> dma_addr = entry << tbl->it_page_shift;
> - dma_addr |= (s->offset & ~IOMMU_PAGE_MASK(tbl));
> + dma_addr |= (vaddr & ~IOMMU_PAGE_MASK(tbl));
>
> DBG(" - %lu pages, entry: %lx, dma_addr: %lx\n",
> npages, entry, dma_addr);
> @@ -904,6 +904,7 @@ void *iommu_alloc_coherent(struct device *dev, struct
> iommu_table *tbl,
> unsigned int order;
> unsigned int nio_pages, io_order;
> struct page *page;
> + int tcesize = (1 << tbl->it_page_shift);
>
> size = PAGE_ALIGN(size);
> order = get_order(size);
> @@ -930,7 +931,8 @@ void *iommu_alloc_coherent(struct device *dev, struct
> iommu_table *tbl,
> memset(ret, 0, size);
>
> /* Set up tces to cover the allocated range */
> - nio_pages = size >> tbl->it_page_shift;
> + nio_pages = IOMMU_PAGE_ALIGN(size, tbl) >> tbl->it_page_shift;
> +
> io_order = get_iommu_order(size, tbl);
> mapping = iommu_alloc(dev, tbl, ret, nio_pages, DMA_BIDIRECTIONAL,
> mask >> tbl->it_page_shift, io_order, 0);
> @@ -938,7 +940,8 @@ void *iommu_alloc_coherent(struct device *dev, struct
> iommu_table *tbl,
> free_pages((unsigned long)ret, order);
> return NULL;
> }
> - *dma_handle = mapping;
> +
> + *dma_handle = mapping | ((u64)ret & (tcesize - 1));
> return ret;
> }
>
> --
Re: [PATCH 10/11] iommu: Split iommu_group_add_device()
On Thu, Apr 20, 2023 at 12:25:11PM +0800, Baolu Lu wrote:
> On 4/20/23 12:11 AM, Jason Gunthorpe wrote:
> > @@ -451,16 +454,17 @@ static int __iommu_probe_device(struct device *dev,
> > struct list_head *group_list
> > goto out_unlock;
> > group = dev->iommu_group;
> > - ret = iommu_group_add_device(group, dev);
> > + gdev = iommu_group_alloc_device(group, dev);
> > mutex_lock(>mutex);
> > - if (ret)
> > + if (IS_ERR(gdev)) {
> > + ret = PTR_ERR(gdev);
> > goto err_put_group;
> > + }
> > + list_add_tail(>list, >devices);
>
> Do we need to put
>
> dev->iommu_group = group;
>
> here?
It is done in iommu_init_driver() and iommu_deinit_driver() NULL's it
group = ops->device_group(dev);
if (WARN_ON_ONCE(group == NULL))
group = ERR_PTR(-EINVAL);
if (IS_ERR(group)) {
ret = PTR_ERR(group);
goto err_unlink;
}
dev->iommu_group = group;
Jason
Re: [PATCH v3 3/4] PCI/AER: Disable AER interrupt on suspend
On 4/20/23 5:59 AM, Kai-Heng Feng wrote:
> PCIe service that shares IRQ with PME may cause spurious wakeup on
> system suspend.
>
> PCIe Base Spec 5.0, section 5.2 "Link State Power Management" states
> that TLP and DLLP transmission is disabled for a Link in L2/L3 Ready
> (D3hot), L2 (D3cold with aux power) and L3 (D3cold), so we don't lose
> much here to disable AER during system suspend.
>
> This is very similar to previous attempts to suspend AER and DPC [1],
> but with a different reason.
>
> [1]
> https://lore.kernel.org/linux-pci/20220408153159.106741-1-kai.heng.f...@canonical.com/
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216295
>
> Reviewed-by: Mika Westerberg
> Signed-off-by: Kai-Heng Feng
> ---
In Patch #1, you skip clearing AER errors in the resume path, right? So if we
disable
interrupts here, will AER driver not be notified on resume path error?
> v3:
> - No change.
>
> v2:
> - Only disable AER IRQ.
> - No more check on PME IRQ#.
> - Use helper.
>
> drivers/pci/pcie/aer.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index 1420e1f27105..9c07fdbeb52d 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -1356,6 +1356,26 @@ static int aer_probe(struct pcie_device *dev)
> return 0;
> }
>
> +static int aer_suspend(struct pcie_device *dev)
> +{
> + struct aer_rpc *rpc = get_service_data(dev);
> + struct pci_dev *pdev = rpc->rpd;
> +
> + aer_disable_irq(pdev);
> +
> + return 0;
> +}
> +
> +static int aer_resume(struct pcie_device *dev)
> +{
> + struct aer_rpc *rpc = get_service_data(dev);
> + struct pci_dev *pdev = rpc->rpd;
> +
> + aer_enable_irq(pdev);
> +
> + return 0;
> +}
> +
> /**
> * aer_root_reset - reset Root Port hierarchy, RCEC, or RCiEP
> * @dev: pointer to Root Port, RCEC, or RCiEP
> @@ -1420,6 +1440,8 @@ static struct pcie_port_service_driver aerdriver = {
> .service= PCIE_PORT_SERVICE_AER,
>
> .probe = aer_probe,
> + .suspend= aer_suspend,
> + .resume = aer_resume,
> .remove = aer_remove,
> };
>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
Re: [PATCH v3 2/4] PCI/AER: Factor out interrupt toggling into helpers
On 4/20/23 5:59 AM, Kai-Heng Feng wrote:
> There are many places that enable and disable AER interrput, so move
> them into helpers.
Add "No functional changes intended"
>
> Signed-off-by: Kai-Heng Feng
> ---
Looks good to me.
Reviewed-by: Kuppuswamy Sathyanarayanan
> v3:
> - Correct subject.
>
> v2:
> - New patch.
>
> drivers/pci/pcie/aer.c | 45 +-
> 1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index f6c24ded134c..1420e1f27105 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -1227,6 +1227,28 @@ static irqreturn_t aer_irq(int irq, void *context)
> return IRQ_WAKE_THREAD;
> }
>
> +static void aer_enable_irq(struct pci_dev *pdev)
> +{
> + int aer = pdev->aer_cap;
> + u32 reg32;
> +
> + /* Enable Root Port's interrupt in response to error messages */
> + pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
> + reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
> + pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
> +}
> +
> +static void aer_disable_irq(struct pci_dev *pdev)
> +{
> + int aer = pdev->aer_cap;
> + u32 reg32;
> +
> + /* Disable Root's interrupt in response to error messages */
> + pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
> + reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
> + pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
> +}
> +
> /**
> * aer_enable_rootport - enable Root Port's interrupts when receiving
> messages
> * @rpc: pointer to a Root Port data structure
> @@ -1256,10 +1278,7 @@ static void aer_enable_rootport(struct aer_rpc *rpc)
> pci_read_config_dword(pdev, aer + PCI_ERR_UNCOR_STATUS, );
> pci_write_config_dword(pdev, aer + PCI_ERR_UNCOR_STATUS, reg32);
>
> - /* Enable Root Port's interrupt in response to error messages */
> - pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
> - reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
> - pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
> + aer_enable_irq(pdev);
> }
>
> /**
> @@ -1274,10 +1293,7 @@ static void aer_disable_rootport(struct aer_rpc *rpc)
> int aer = pdev->aer_cap;
> u32 reg32;
>
> - /* Disable Root's interrupt in response to error messages */
> - pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
> - reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
> - pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
> + aer_disable_irq(pdev);
>
> /* Clear Root's error status reg */
> pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_STATUS, );
> @@ -1372,12 +1388,8 @@ static pci_ers_result_t aer_root_reset(struct pci_dev
> *dev)
>*/
> aer = root ? root->aer_cap : 0;
>
> - if ((host->native_aer || pcie_ports_native) && aer) {
> - /* Disable Root's interrupt in response to error messages */
> - pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, );
> - reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
> - pci_write_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, reg32);
> - }
> + if ((host->native_aer || pcie_ports_native) && aer)
> + aer_disable_irq(root);
>
> if (type == PCI_EXP_TYPE_RC_EC || type == PCI_EXP_TYPE_RC_END) {
> rc = pcie_reset_flr(dev, PCI_RESET_DO_RESET);
> @@ -1396,10 +1408,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev
> *dev)
> pci_read_config_dword(root, aer + PCI_ERR_ROOT_STATUS, );
> pci_write_config_dword(root, aer + PCI_ERR_ROOT_STATUS, reg32);
>
> - /* Enable Root Port's interrupt in response to error messages */
> - pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, );
> - reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
> - pci_write_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, reg32);
> + aer_enable_irq(root);
> }
>
> return rc ? PCI_ERS_RESULT_DISCONNECT : PCI_ERS_RESULT_RECOVERED;
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
Re: [RFC PATCH] KVM: PPC: Update MAINTAINERS
Nicholas Piggin writes: > Michael is maintaining KVM PPC with the powerpc tree at the moment, > just doesn't necessarily have time to be across all of KVM. But I > think that's okay, from mechanics of how patches flow upstream he is > maintainer. And it probably makes a bit more sense to people who need > to look at the MAINTAINERS file if we have some contacts there. > > So add mpe as KVM PPC maintainer and I am a reviewer. Split out the > subarchs that don't get much attention. Yeah I guess this is better than what we have now. Can you send a non-RFC and SOB'ed version, and maybe Cc the KVM list as well? cheers
Re: [PATCH v3 2/4] PCI/AER: Factor out interrupt toggling into helpers
On Thu, Apr 20, 2023 at 08:59:38PM +0800, Kai-Heng Feng wrote: > There are many places that enable and disable AER interrput, so move > them into helpers. > > Signed-off-by: Kai-Heng Feng Reviewed-by: Mika Westerberg
[PATCH v3 4/4] PCI/DPC: Disable DPC interrupt during suspend
PCIe service that shares IRQ with PME may cause spurious wakeup on
system suspend.
Since AER is conditionally disabled in previous patch, also apply the
same logic to disable DPC which depends on AER to work.
PCIe Base Spec 5.0, section 5.2 "Link State Power Management" states
that TLP and DLLP transmission is disabled for a Link in L2/L3 Ready
(D3hot), L2 (D3cold with aux power) and L3 (D3cold), so we don't lose
much here to disable DPC during system suspend.
This is very similar to previous attempts to suspend AER and DPC [1],
but with a different reason.
[1]
https://lore.kernel.org/linux-pci/20220408153159.106741-1-kai.heng.f...@canonical.com/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216295
Reviewed-by: Mika Westerberg
Signed-off-by: Kai-Heng Feng
---
v3:
- No change.
v2:
- Only disable DPC IRQ.
- No more check on PME IRQ#.
drivers/pci/pcie/dpc.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index a5d7c69b764e..98bdefde6df1 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -385,6 +385,30 @@ static int dpc_probe(struct pcie_device *dev)
return status;
}
+static int dpc_suspend(struct pcie_device *dev)
+{
+ struct pci_dev *pdev = dev->port;
+ u16 ctl;
+
+ pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, );
+ ctl &= ~PCI_EXP_DPC_CTL_INT_EN;
+ pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl);
+
+ return 0;
+}
+
+static int dpc_resume(struct pcie_device *dev)
+{
+ struct pci_dev *pdev = dev->port;
+ u16 ctl;
+
+ pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, );
+ ctl |= PCI_EXP_DPC_CTL_INT_EN;
+ pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl);
+
+ return 0;
+}
+
static void dpc_remove(struct pcie_device *dev)
{
struct pci_dev *pdev = dev->port;
@@ -400,6 +424,8 @@ static struct pcie_port_service_driver dpcdriver = {
.port_type = PCIE_ANY_PORT,
.service= PCIE_PORT_SERVICE_DPC,
.probe = dpc_probe,
+ .suspend= dpc_suspend,
+ .resume = dpc_resume,
.remove = dpc_remove,
};
--
2.34.1
[PATCH v3 3/4] PCI/AER: Disable AER interrupt on suspend
PCIe service that shares IRQ with PME may cause spurious wakeup on
system suspend.
PCIe Base Spec 5.0, section 5.2 "Link State Power Management" states
that TLP and DLLP transmission is disabled for a Link in L2/L3 Ready
(D3hot), L2 (D3cold with aux power) and L3 (D3cold), so we don't lose
much here to disable AER during system suspend.
This is very similar to previous attempts to suspend AER and DPC [1],
but with a different reason.
[1]
https://lore.kernel.org/linux-pci/20220408153159.106741-1-kai.heng.f...@canonical.com/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216295
Reviewed-by: Mika Westerberg
Signed-off-by: Kai-Heng Feng
---
v3:
- No change.
v2:
- Only disable AER IRQ.
- No more check on PME IRQ#.
- Use helper.
drivers/pci/pcie/aer.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 1420e1f27105..9c07fdbeb52d 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -1356,6 +1356,26 @@ static int aer_probe(struct pcie_device *dev)
return 0;
}
+static int aer_suspend(struct pcie_device *dev)
+{
+ struct aer_rpc *rpc = get_service_data(dev);
+ struct pci_dev *pdev = rpc->rpd;
+
+ aer_disable_irq(pdev);
+
+ return 0;
+}
+
+static int aer_resume(struct pcie_device *dev)
+{
+ struct aer_rpc *rpc = get_service_data(dev);
+ struct pci_dev *pdev = rpc->rpd;
+
+ aer_enable_irq(pdev);
+
+ return 0;
+}
+
/**
* aer_root_reset - reset Root Port hierarchy, RCEC, or RCiEP
* @dev: pointer to Root Port, RCEC, or RCiEP
@@ -1420,6 +1440,8 @@ static struct pcie_port_service_driver aerdriver = {
.service= PCIE_PORT_SERVICE_AER,
.probe = aer_probe,
+ .suspend= aer_suspend,
+ .resume = aer_resume,
.remove = aer_remove,
};
--
2.34.1
[PATCH v3 2/4] PCI/AER: Factor out interrupt toggling into helpers
There are many places that enable and disable AER interrput, so move
them into helpers.
Signed-off-by: Kai-Heng Feng
---
v3:
- Correct subject.
v2:
- New patch.
drivers/pci/pcie/aer.c | 45 +-
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index f6c24ded134c..1420e1f27105 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -1227,6 +1227,28 @@ static irqreturn_t aer_irq(int irq, void *context)
return IRQ_WAKE_THREAD;
}
+static void aer_enable_irq(struct pci_dev *pdev)
+{
+ int aer = pdev->aer_cap;
+ u32 reg32;
+
+ /* Enable Root Port's interrupt in response to error messages */
+ pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
+ reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
+ pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
+}
+
+static void aer_disable_irq(struct pci_dev *pdev)
+{
+ int aer = pdev->aer_cap;
+ u32 reg32;
+
+ /* Disable Root's interrupt in response to error messages */
+ pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
+ reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
+ pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
+}
+
/**
* aer_enable_rootport - enable Root Port's interrupts when receiving messages
* @rpc: pointer to a Root Port data structure
@@ -1256,10 +1278,7 @@ static void aer_enable_rootport(struct aer_rpc *rpc)
pci_read_config_dword(pdev, aer + PCI_ERR_UNCOR_STATUS, );
pci_write_config_dword(pdev, aer + PCI_ERR_UNCOR_STATUS, reg32);
- /* Enable Root Port's interrupt in response to error messages */
- pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
- reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
- pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
+ aer_enable_irq(pdev);
}
/**
@@ -1274,10 +1293,7 @@ static void aer_disable_rootport(struct aer_rpc *rpc)
int aer = pdev->aer_cap;
u32 reg32;
- /* Disable Root's interrupt in response to error messages */
- pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
- reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
- pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
+ aer_disable_irq(pdev);
/* Clear Root's error status reg */
pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_STATUS, );
@@ -1372,12 +1388,8 @@ static pci_ers_result_t aer_root_reset(struct pci_dev
*dev)
*/
aer = root ? root->aer_cap : 0;
- if ((host->native_aer || pcie_ports_native) && aer) {
- /* Disable Root's interrupt in response to error messages */
- pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, );
- reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
- pci_write_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, reg32);
- }
+ if ((host->native_aer || pcie_ports_native) && aer)
+ aer_disable_irq(root);
if (type == PCI_EXP_TYPE_RC_EC || type == PCI_EXP_TYPE_RC_END) {
rc = pcie_reset_flr(dev, PCI_RESET_DO_RESET);
@@ -1396,10 +1408,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev
*dev)
pci_read_config_dword(root, aer + PCI_ERR_ROOT_STATUS, );
pci_write_config_dword(root, aer + PCI_ERR_ROOT_STATUS, reg32);
- /* Enable Root Port's interrupt in response to error messages */
- pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, );
- reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
- pci_write_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, reg32);
+ aer_enable_irq(root);
}
return rc ? PCI_ERS_RESULT_DISCONNECT : PCI_ERS_RESULT_RECOVERED;
--
2.34.1
Re: next: powerpc: gpio_mdio.c:(.text+0x13c): undefined reference to `__of_mdiobus_register'
On Thu, Apr 20, 2023, at 12:57, Naresh Kamboju wrote: > Following build failures noticed on Linux next-20230419 for powerpc. > > Regressions found on powerpc: > - build/gcc-8-defconfig > - build/clang-16-defconfig > - build/gcc-12-defconfig > - build/clang-nightly-defconfig > > > Reported-by: Linux Kernel Functional Testing > > Build log: > > powerpc64le-linux-gnu-ld: arch/powerpc/platforms/pasemi/gpio_mdio.o: > in function `gpio_mdio_probe': > gpio_mdio.c:(.text+0x13c): undefined reference to `__of_mdiobus_register' > powerpc64le-linux-gnu-ld: drivers/net/phy/phy_device.o: in function > `phy_probe': > phy_device.c:(.text+0x56ac): undefined reference to > `devm_led_classdev_register_ext' > powerpc64le-linux-gnu-ld: drivers/net/ethernet/pasemi/pasemi_mac.o: in > function `pasemi_mac_open': > pasemi_mac.c:(.text+0x19ac): undefined reference to `of_phy_connect' > make[2]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 1 Same bug as the other one: https://lore.kernel.org/all/20230420084624.3005701-1-a...@kernel.org/ Arnd
[PATCH v8 00/10] arm64: Add framework to turn an IPI as NMI
This is an attempt to resurrect Sumit's old patch series [1] that allowed us to use the arm64 pseudo-NMI to get backtraces of CPUs and also to round up CPUs in kdb/kgdb. The last post from Sumit that I could find was v7, so I called this series v8. I haven't copied all of his old changelongs here, but you can find them from the link. Since v7, I have: * Addressed the small amount of feedback that was there for v7. * Rebased. * Added a new patch that prevents us from spamming the logs with idle tasks. * Added an extra patch to gracefully fall back to regular IPIs if pseudo-NMIs aren't there. Since there appear to be a few different patches series related to being able to use NMIs to get stack traces of crashed systems, let me try to organize them to the best of my understanding: a) This series. On its own, a) will (among other things) enable stack traces of all running processes with the soft lockup detector if you've enabled the sysctl "kernel.softlockup_all_cpu_backtrace". On its own, a) doesn't give a hard lockup detector. b) A different recently-posted series [2] that adds a hard lockup detector based on perf. On its own, b) gives a stack crawl of the locked up CPU but no stack crawls of other CPUs (even if they're locked too). Together with a) + b) we get everything (full lockup detect, full ability to get stack crawls). c) The old Android "buddy" hard lockup detector [3] that I'm considering trying to upstream. If b) lands then I believe c) would be redundant (at least for arm64). c) on its own is really only useful on arm64 for platforms that can print CPU_DBGPCSR somehow (see [4]). a) + c) is roughly as good as a) + b). [1] https://lore.kernel.org/linux-arm-kernel/1604317487-14543-1-git-send-email-sumit.g...@linaro.org/ [2] https://lore.kernel.org/linux-arm-kernel/20220903093415.15850-1-lecopzer.c...@mediatek.com/ [3] https://issuetracker.google.com/172213097 [4] https://issuetracker.google.com/172213129 Changes in v8: - dynamic_ipi_setup() and dynamic_ipi_teardown() no longer take cpu param - dynamic_ipi_setup() and dynamic_ipi_teardown() no longer take cpu param - Add loongarch support, too - Removed "#ifdef CONFIG_SMP" since arm64 is always SMP - "Tag the arm64 idle functions as __cpuidle" new for v8 - "Provide a stub kgdb_nmicallback() if !CONFIG_KGDB" new for v8 - "Fallback to a regular IPI if NMI isn't enabled" new for v8 Douglas Anderson (3): arm64: idle: Tag the arm64 idle functions as __cpuidle kgdb: Provide a stub kgdb_nmicallback() if !CONFIG_KGDB arm64: ipi_nmi: Fallback to a regular IPI if NMI isn't enabled Sumit Garg (7): arm64: Add framework to turn IPI as NMI irqchip/gic-v3: Enable support for SGIs to act as NMIs arm64: smp: Assign and setup an IPI as NMI nmi: backtrace: Allow runtime arch specific override arm64: ipi_nmi: Add support for NMI backtrace kgdb: Expose default CPUs roundup fallback mechanism arm64: kgdb: Roundup cpus using IPI as NMI arch/arm/include/asm/irq.h | 2 +- arch/arm/kernel/smp.c| 3 +- arch/arm64/include/asm/irq.h | 4 ++ arch/arm64/include/asm/nmi.h | 17 + arch/arm64/kernel/Makefile | 2 +- arch/arm64/kernel/idle.c | 4 +- arch/arm64/kernel/ipi_nmi.c | 103 +++ arch/arm64/kernel/kgdb.c | 18 ++ arch/arm64/kernel/smp.c | 8 +++ arch/loongarch/include/asm/irq.h | 2 +- arch/loongarch/kernel/process.c | 3 +- arch/mips/include/asm/irq.h | 2 +- arch/mips/kernel/process.c | 3 +- arch/powerpc/include/asm/nmi.h | 2 +- arch/powerpc/kernel/stacktrace.c | 3 +- arch/sparc/include/asm/irq_64.h | 2 +- arch/sparc/kernel/process_64.c | 4 +- arch/x86/include/asm/irq.h | 2 +- arch/x86/kernel/apic/hw_nmi.c| 3 +- drivers/irqchip/irq-gic-v3.c | 29 ++--- include/linux/kgdb.h | 13 include/linux/nmi.h | 12 ++-- kernel/debug/debug_core.c| 8 ++- 23 files changed, 217 insertions(+), 32 deletions(-) create mode 100644 arch/arm64/include/asm/nmi.h create mode 100644 arch/arm64/kernel/ipi_nmi.c -- 2.40.0.634.g4ca3ef3211-goog
Re: [PATCH 4/33] mm: add utility functions for ptdesc
On Mon, Apr 17, 2023 at 01:50:19PM -0700, Vishal Moola wrote:
> Introduce utility functions setting the foundation for ptdescs. These
> will also assist in the splitting out of ptdesc from struct page.
>
> ptdesc_alloc() is defined to allocate new ptdesc pages as compound
> pages. This is to standardize ptdescs by allowing for one allocation
> and one free function, in contrast to 2 allocation and 2 free functions.
>
> Signed-off-by: Vishal Moola (Oracle)
> ---
> include/asm-generic/tlb.h | 11 ++
> include/linux/mm.h| 44 +++
> include/linux/pgtable.h | 13
> 3 files changed, 68 insertions(+)
>
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index b46617207c93..6bade9e0e799 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -481,6 +481,17 @@ static inline void tlb_remove_page(struct mmu_gather
> *tlb, struct page *page)
> return tlb_remove_page_size(tlb, page, PAGE_SIZE);
> }
>
> +static inline void tlb_remove_ptdesc(struct mmu_gather *tlb, void *pt)
> +{
> + tlb_remove_table(tlb, pt);
> +}
> +
> +/* Like tlb_remove_ptdesc, but for page-like page directories. */
> +static inline void tlb_remove_page_ptdesc(struct mmu_gather *tlb, struct
> ptdesc *pt)
> +{
> + tlb_remove_page(tlb, ptdesc_page(pt));
> +}
> +
> static inline void tlb_change_page_size(struct mmu_gather *tlb,
>unsigned int page_size)
> {
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index b18848ae7e22..ec3cbe2fa665 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2744,6 +2744,45 @@ static inline pmd_t *pmd_alloc(struct mm_struct *mm,
> pud_t *pud, unsigned long a
> }
> #endif /* CONFIG_MMU */
>
> +static inline struct ptdesc *virt_to_ptdesc(const void *x)
> +{
> + return page_ptdesc(virt_to_head_page(x));
> +}
> +
> +static inline void *ptdesc_to_virt(struct ptdesc *pt)
> +{
> + return page_to_virt(ptdesc_page(pt));
> +}
> +
> +static inline void *ptdesc_address(struct ptdesc *pt)
> +{
> + return folio_address(ptdesc_folio(pt));
> +}
> +
> +static inline bool ptdesc_is_reserved(struct ptdesc *pt)
> +{
> + return folio_test_reserved(ptdesc_folio(pt));
> +}
> +
> +static inline struct ptdesc *ptdesc_alloc(gfp_t gfp, unsigned int order)
> +{
> + struct page *page = alloc_pages(gfp | __GFP_COMP, order);
> +
> + return page_ptdesc(page);
> +}
> +
> +static inline void ptdesc_free(struct ptdesc *pt)
> +{
> + struct page *page = ptdesc_page(pt);
> +
> + __free_pages(page, compound_order(page));
> +}
> +
> +static inline void ptdesc_clear(void *x)
> +{
> + clear_page(x);
> +}
> +
> #if USE_SPLIT_PTE_PTLOCKS
> #if ALLOC_SPLIT_PTLOCKS
> void __init ptlock_cache_init(void);
> @@ -2970,6 +3009,11 @@ static inline void mark_page_reserved(struct page
> *page)
> adjust_managed_page_count(page, -1);
> }
>
> +static inline void free_reserved_ptdesc(struct ptdesc *pt)
> +{
> + free_reserved_page(ptdesc_page(pt));
> +}
> +
> /*
> * Default method to free all the __init memory into the buddy system.
> * The freed pages will be poisoned with pattern "poison" if it's within
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 7cc6ea057ee9..7cd803aa38eb 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -97,6 +97,19 @@ TABLE_MATCH(ptl, ptl);
> #undef TABLE_MATCH
> static_assert(sizeof(struct ptdesc) <= sizeof(struct page));
>
> +#define ptdesc_page(pt) (_Generic((pt),
> \
> + const struct ptdesc *: (const struct page *)(pt), \
> + struct ptdesc *:(struct page *)(pt)))
> +
> +#define ptdesc_folio(pt) (_Generic((pt), \
> + const struct ptdesc *: (const struct folio *)(pt), \
> + struct ptdesc *:(struct folio *)(pt)))
> +
> +static inline struct ptdesc *page_ptdesc(struct page *page)
> +{
> + return (struct ptdesc *)page;
> +}
Hi Vishal,
I'm a little curious, why is the page_ptdesc() using inline functions instead
of macro?
If this is any magic, please tell me, thank you very much.
> +
> /*
> * A page table page can be thought of an array like this:
> pXd_t[PTRS_PER_PxD]
> *
>
> --
> 2.39.2
>
next: powerpc: gpio_mdio.c:(.text+0x13c): undefined reference to `__of_mdiobus_register'
Following build failures noticed on Linux next-20230419 for powerpc. Regressions found on powerpc: - build/gcc-8-defconfig - build/clang-16-defconfig - build/gcc-12-defconfig - build/clang-nightly-defconfig Reported-by: Linux Kernel Functional Testing Build log: powerpc64le-linux-gnu-ld: arch/powerpc/platforms/pasemi/gpio_mdio.o: in function `gpio_mdio_probe': gpio_mdio.c:(.text+0x13c): undefined reference to `__of_mdiobus_register' powerpc64le-linux-gnu-ld: drivers/net/phy/phy_device.o: in function `phy_probe': phy_device.c:(.text+0x56ac): undefined reference to `devm_led_classdev_register_ext' powerpc64le-linux-gnu-ld: drivers/net/ethernet/pasemi/pasemi_mac.o: in function `pasemi_mac_open': pasemi_mac.c:(.text+0x19ac): undefined reference to `of_phy_connect' make[2]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 1 Build details: - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230419/testrun/16369015/suite/build/test/gcc-12-defconfig/details/ https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230419/testrun/16369015/suite/build/test/gcc-12-defconfig/log Steps to reproduce: # To install tuxmake on your system globally: # sudo pip3 install -U tuxmake # # See https://docs.tuxmake.org/ for complete documentation. # Original tuxmake command with fragments listed below. tuxmake --runtime podman --target-arch powerpc --toolchain gcc-12 --kconfig defconfig -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v2 4/4] PCI/DPC: Disable DPC interrupt during suspend
On Thu, Apr 20, 2023 at 09:58:30AM +0800, Kai-Heng Feng wrote: > PCIe service that shares IRQ with PME may cause spurious wakeup on > system suspend. > > Since AER is conditionally disabled in previous patch, also apply the > same logic to disable DPC which depends on AER to work. > > PCIe Base Spec 5.0, section 5.2 "Link State Power Management" states > that TLP and DLLP transmission is disabled for a Link in L2/L3 Ready > (D3hot), L2 (D3cold with aux power) and L3 (D3cold), so we don't lose > much here to disable DPC during system suspend. > > This is very similar to previous attempts to suspend AER and DPC [1], > but with a different reason. > > [1] > https://lore.kernel.org/linux-pci/20220408153159.106741-1-kai.heng.f...@canonical.com/ > Link: https://bugzilla.kernel.org/show_bug.cgi?id=216295 > > Signed-off-by: Kai-Heng Feng Reviewed-by: Mika Westerberg
Re: [PATCH v2 3/4] PCI/AER: Disable AER interrupt on suspend
On Thu, Apr 20, 2023 at 09:58:29AM +0800, Kai-Heng Feng wrote: > PCIe service that shares IRQ with PME may cause spurious wakeup on > system suspend. > > PCIe Base Spec 5.0, section 5.2 "Link State Power Management" states > that TLP and DLLP transmission is disabled for a Link in L2/L3 Ready > (D3hot), L2 (D3cold with aux power) and L3 (D3cold), so we don't lose > much here to disable AER during system suspend. > > This is very similar to previous attempts to suspend AER and DPC [1], > but with a different reason. > > [1] > https://lore.kernel.org/linux-pci/20220408153159.106741-1-kai.heng.f...@canonical.com/ > Link: https://bugzilla.kernel.org/show_bug.cgi?id=216295 > > Signed-off-by: Kai-Heng Feng Reviewed-by: Mika Westerberg
Re: [PATCH v2 2/4] PCI/AER: Factor out interrput toggling into helpers
Typo in $subject:
interrput -> interrupt
On Thu, Apr 20, 2023 at 09:58:28AM +0800, Kai-Heng Feng wrote:
> There are many places that enable and disable AER interrput, so move
> them into helpers.
>
> Signed-off-by: Kai-Heng Feng
> ---
> v2:
> - New patch.
>
> drivers/pci/pcie/aer.c | 45 +-
> 1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index f6c24ded134c..1420e1f27105 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -1227,6 +1227,28 @@ static irqreturn_t aer_irq(int irq, void *context)
> return IRQ_WAKE_THREAD;
> }
>
> +static void aer_enable_irq(struct pci_dev *pdev)
> +{
> + int aer = pdev->aer_cap;
> + u32 reg32;
> +
> + /* Enable Root Port's interrupt in response to error messages */
> + pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
> + reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
> + pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
> +}
> +
> +static void aer_disable_irq(struct pci_dev *pdev)
> +{
> + int aer = pdev->aer_cap;
> + u32 reg32;
> +
> + /* Disable Root's interrupt in response to error messages */
> + pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
> + reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
> + pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
> +}
> +
> /**
> * aer_enable_rootport - enable Root Port's interrupts when receiving
> messages
> * @rpc: pointer to a Root Port data structure
> @@ -1256,10 +1278,7 @@ static void aer_enable_rootport(struct aer_rpc *rpc)
> pci_read_config_dword(pdev, aer + PCI_ERR_UNCOR_STATUS, );
> pci_write_config_dword(pdev, aer + PCI_ERR_UNCOR_STATUS, reg32);
>
> - /* Enable Root Port's interrupt in response to error messages */
> - pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
> - reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
> - pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
> + aer_enable_irq(pdev);
> }
>
> /**
> @@ -1274,10 +1293,7 @@ static void aer_disable_rootport(struct aer_rpc *rpc)
> int aer = pdev->aer_cap;
> u32 reg32;
>
> - /* Disable Root's interrupt in response to error messages */
> - pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, );
> - reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
> - pci_write_config_dword(pdev, aer + PCI_ERR_ROOT_COMMAND, reg32);
> + aer_disable_irq(pdev);
>
> /* Clear Root's error status reg */
> pci_read_config_dword(pdev, aer + PCI_ERR_ROOT_STATUS, );
> @@ -1372,12 +1388,8 @@ static pci_ers_result_t aer_root_reset(struct pci_dev
> *dev)
>*/
> aer = root ? root->aer_cap : 0;
>
> - if ((host->native_aer || pcie_ports_native) && aer) {
> - /* Disable Root's interrupt in response to error messages */
> - pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, );
> - reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
> - pci_write_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, reg32);
> - }
> + if ((host->native_aer || pcie_ports_native) && aer)
> + aer_disable_irq(root);
>
> if (type == PCI_EXP_TYPE_RC_EC || type == PCI_EXP_TYPE_RC_END) {
> rc = pcie_reset_flr(dev, PCI_RESET_DO_RESET);
> @@ -1396,10 +1408,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev
> *dev)
> pci_read_config_dword(root, aer + PCI_ERR_ROOT_STATUS, );
> pci_write_config_dword(root, aer + PCI_ERR_ROOT_STATUS, reg32);
>
> - /* Enable Root Port's interrupt in response to error messages */
> - pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, );
> - reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
> - pci_write_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, reg32);
> + aer_enable_irq(root);
> }
>
> return rc ? PCI_ERS_RESULT_DISCONNECT : PCI_ERS_RESULT_RECOVERED;
> --
> 2.34.1
Re: [PATCH v2 0/2] Remove POWER10_CPU dependency and move PPC_MODULE_FEATURE_P10.
On Thu, Apr 13, 2023 at 03:46:23PM -0400, Danny Tsen wrote: > Remove Power10 dependency in Kconfig and detect Power10 feature at runtime. > Move PPC_MODULE_FEATURE_P10 definition to be in > arch/powerpc/include/asm/cpufeature.h. > > Signed-off-by: Danny Tsen > > Danny Tsen (2): > Kconfig: Remove POWER10_CPU dependency. > aes-gcm-p10-glue.c, cpufeature.h: Move Power10 feature, > PPC_MODULE_FEATURE_P10. > > arch/powerpc/crypto/Kconfig| 2 +- > arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 - > arch/powerpc/include/asm/cpufeature.h | 1 + > 3 files changed, 2 insertions(+), 2 deletions(-) > > -- > 2.31.1 All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] powerpc/rtas: Replace one-element arrays with flexible arrays
On Fri, 2023-01-27 at 07:10 -0600, Nathan Lynch wrote: > > > > I see at least one place that consults the size of one of these > > > > structs, > > > > in get_pseries_errorlog(): > > > > > > > > /* Check that we understand the format */ > > > > if (ext_log_length < sizeof(struct > > > > rtas_ext_event_log_v6) > > > > || > > > > ... > > > > > > > > Don't all such sites need to be audited/adjusted for changes > > > > like > > > > this? I did actually see that site, and concluded that for the purposes of that particular check, removing a single extra byte is irrelevant (maybe it makes the check more strictly correct, what if the vendor_log is actually of length 0?) Doing a binary diff, as Kees suggests, over the object files in arch/powerpc: - there's no difference at all caused by changing rtas_ext_event_log_v6.vendor_log, which kind of surprises me given the above. - changing rtas_error_log.buffer does seem to change some code generation in arch/powerpc/platforms/pseries/ras.o, I can't quite see why. Andrew -- Andrew DonnellanOzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited
