From: Marc Zyngier <maz@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>,
Geert Uytterhoeven <geert+renesas@glider.be>
Cc: "Alyssa Rosenzweig" <alyssa@rosenzweig.io>,
"Rob Herring" <robh@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Will Deacon" <will@kernel.org>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Conor Dooley" <conor.dooley@microchip.com>,
"Daire McNamara" <daire.mcnamara@microchip.com>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI: host-generic: Set driver_data before calling gen_pci_init()
Date: Wed, 25 Jun 2025 08:42:13 +0100 [thread overview]
Message-ID: <875xgkfesq.wl-maz@kernel.org> (raw)
In-Reply-To: <774290708a6f0f683711914fda110742c18a7fb2.1750787223.git.geert+renesas@glider.be>
On Tue, 24 Jun 2025 18:50:10 +0100,
Geert Uytterhoeven <geert+renesas@glider.be> wrote:
>
> On MicroChip MPFS Icicle:
>
> microchip-pcie 2000000000.pcie: host bridge /soc/pcie@2000000000 ranges:
> microchip-pcie 2000000000.pcie: Parsing ranges property...
> microchip-pcie 2000000000.pcie: MEM 0x2008000000..0x2087ffffff -> 0x0008000000
> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000368
> Current swapper/0 pgtable: 4K pagesize, 39-bit VAs, pgdp=0x00000000814f1000
> [0000000000000368] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
> Oops [#1]
> Modules linked in:
> CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.15.0-rc1-icicle-00003-gafc0a570bb61 #232 NONE
> Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
> [...]
> [<ffffffff803fb8a4>] plda_pcie_setup_iomems+0xe/0x78
> [<ffffffff803fc246>] mc_platform_init+0x80/0x1d2
> [<ffffffff803f9c88>] pci_ecam_create+0x104/0x1e2
> [<ffffffff8000adbe>] pci_host_common_init+0x120/0x228
> [<ffffffff8000af42>] pci_host_common_probe+0x7c/0x8a
>
> The initialization of driver_data was moved after the call to
> gen_pci_init(), while the pci_ecam_ops.init() callback
> mc_platform_init() expects it has already been initialized.
>
> Fix this by moving the initialization of driver_data up.
>
> Fixes: afc0a570bb613871 ("PCI: host-generic: Extract an ECAM bridge creation helper from pci_host_common_probe()")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Notes:
> 1. Before, driver_data was initialized before calling
> of_pci_check_probe_only(), but the latter doesn't rely on that,
> 2. drivers/pci/controller/plda/pcie-microchip-host.c seems to be the
> only driver relying on driver_data being set.
> ---
> drivers/pci/controller/pci-host-common.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/pci-host-common.c b/drivers/pci/controller/pci-host-common.c
> index b0992325dd65f0da..b37052863847162d 100644
> --- a/drivers/pci/controller/pci-host-common.c
> +++ b/drivers/pci/controller/pci-host-common.c
> @@ -64,13 +64,13 @@ int pci_host_common_init(struct platform_device *pdev,
>
> of_pci_check_probe_only();
>
> + platform_set_drvdata(pdev, bridge);
> +
> /* Parse and map our Configuration Space windows */
> cfg = gen_pci_init(dev, bridge, ops);
> if (IS_ERR(cfg))
> return PTR_ERR(cfg);
>
> - platform_set_drvdata(pdev, bridge);
> -
> bridge->sysdata = cfg;
> bridge->ops = (struct pci_ops *)&ops->pci_ops;
> bridge->enable_device = ops->enable_device;
This is going to break what was introduced in 4900454b4f819 ("PCI:
ecam: Allow cfg->priv to be pre-populated from the root port device").
The Apple PCIe driver uses drvdata to pass a pointer to its root port
structure from its probe routine to the .init ECAM callback. If we
overwrite drvdata with the bridge *before* calling pci_ecam_create(),
this data is lost, and drama follows.
Obviously, multi-purpose private fields are not great...
If we are going down the road of going back to the previous situation,
two things need to be done:
- the Apple PCIe driver needs to grow some form of root port
registration in order to map a 'struct device' back to the pcie
tracking structure
- 4900454b4f819 needs to be reverted, because it obviously doesn't
serve any purpose anymore.
I'll look into the first point.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>,
Geert Uytterhoeven <geert+renesas@glider.be>
Cc: "Alyssa Rosenzweig" <alyssa@rosenzweig.io>,
"Rob Herring" <robh@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Will Deacon" <will@kernel.org>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Conor Dooley" <conor.dooley@microchip.com>,
"Daire McNamara" <daire.mcnamara@microchip.com>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI: host-generic: Set driver_data before calling gen_pci_init()
Date: Wed, 25 Jun 2025 08:42:13 +0100 [thread overview]
Message-ID: <875xgkfesq.wl-maz@kernel.org> (raw)
In-Reply-To: <774290708a6f0f683711914fda110742c18a7fb2.1750787223.git.geert+renesas@glider.be>
On Tue, 24 Jun 2025 18:50:10 +0100,
Geert Uytterhoeven <geert+renesas@glider.be> wrote:
>
> On MicroChip MPFS Icicle:
>
> microchip-pcie 2000000000.pcie: host bridge /soc/pcie@2000000000 ranges:
> microchip-pcie 2000000000.pcie: Parsing ranges property...
> microchip-pcie 2000000000.pcie: MEM 0x2008000000..0x2087ffffff -> 0x0008000000
> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000368
> Current swapper/0 pgtable: 4K pagesize, 39-bit VAs, pgdp=0x00000000814f1000
> [0000000000000368] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
> Oops [#1]
> Modules linked in:
> CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.15.0-rc1-icicle-00003-gafc0a570bb61 #232 NONE
> Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
> [...]
> [<ffffffff803fb8a4>] plda_pcie_setup_iomems+0xe/0x78
> [<ffffffff803fc246>] mc_platform_init+0x80/0x1d2
> [<ffffffff803f9c88>] pci_ecam_create+0x104/0x1e2
> [<ffffffff8000adbe>] pci_host_common_init+0x120/0x228
> [<ffffffff8000af42>] pci_host_common_probe+0x7c/0x8a
>
> The initialization of driver_data was moved after the call to
> gen_pci_init(), while the pci_ecam_ops.init() callback
> mc_platform_init() expects it has already been initialized.
>
> Fix this by moving the initialization of driver_data up.
>
> Fixes: afc0a570bb613871 ("PCI: host-generic: Extract an ECAM bridge creation helper from pci_host_common_probe()")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Notes:
> 1. Before, driver_data was initialized before calling
> of_pci_check_probe_only(), but the latter doesn't rely on that,
> 2. drivers/pci/controller/plda/pcie-microchip-host.c seems to be the
> only driver relying on driver_data being set.
> ---
> drivers/pci/controller/pci-host-common.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/pci-host-common.c b/drivers/pci/controller/pci-host-common.c
> index b0992325dd65f0da..b37052863847162d 100644
> --- a/drivers/pci/controller/pci-host-common.c
> +++ b/drivers/pci/controller/pci-host-common.c
> @@ -64,13 +64,13 @@ int pci_host_common_init(struct platform_device *pdev,
>
> of_pci_check_probe_only();
>
> + platform_set_drvdata(pdev, bridge);
> +
> /* Parse and map our Configuration Space windows */
> cfg = gen_pci_init(dev, bridge, ops);
> if (IS_ERR(cfg))
> return PTR_ERR(cfg);
>
> - platform_set_drvdata(pdev, bridge);
> -
> bridge->sysdata = cfg;
> bridge->ops = (struct pci_ops *)&ops->pci_ops;
> bridge->enable_device = ops->enable_device;
This is going to break what was introduced in 4900454b4f819 ("PCI:
ecam: Allow cfg->priv to be pre-populated from the root port device").
The Apple PCIe driver uses drvdata to pass a pointer to its root port
structure from its probe routine to the .init ECAM callback. If we
overwrite drvdata with the bridge *before* calling pci_ecam_create(),
this data is lost, and drama follows.
Obviously, multi-purpose private fields are not great...
If we are going down the road of going back to the previous situation,
two things need to be done:
- the Apple PCIe driver needs to grow some form of root port
registration in order to map a 'struct device' back to the pcie
tracking structure
- 4900454b4f819 needs to be reverted, because it obviously doesn't
serve any purpose anymore.
I'll look into the first point.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-06-25 9:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 17:50 [PATCH] PCI: host-generic: Set driver_data before calling gen_pci_init() Geert Uytterhoeven
2025-06-24 17:50 ` Geert Uytterhoeven
2025-06-24 22:28 ` Bjorn Helgaas
2025-06-24 22:28 ` Bjorn Helgaas
2025-06-25 7:42 ` Marc Zyngier [this message]
2025-06-25 7:42 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875xgkfesq.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=alyssa@rosenzweig.io \
--cc=bhelgaas@google.com \
--cc=conor.dooley@microchip.com \
--cc=daire.mcnamara@microchip.com \
--cc=geert+renesas@glider.be \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=robh@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.