From: Bjorn Helgaas <helgaas@kernel.org>
To: Zhangfei Gao <zhangfei.gao@linaro.org>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
"Baolu Lu" <baolu.lu@linux.intel.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Joerg Roedel" <joro@8bytes.org>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
iommu@lists.linux.dev, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] PCI: Declare quirk_huawei_pcie_sva() as pci_fixup_header
Date: Sat, 15 Mar 2025 13:45:23 -0500 [thread overview]
Message-ID: <20250315184523.GA848225@bhelgaas> (raw)
In-Reply-To: <20250315101319.5269-1-zhangfei.gao@linaro.org>
On Sat, Mar 15, 2025 at 10:13:19AM +0000, Zhangfei Gao wrote:
> The commit bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper
> probe path") changes the arm_smmu_probe_device() sequence.
> The arm_smmu_probe_device() is now called earlier via pci_device_add(),
> which calls pci_fixup_device() at the "pci_fixup_header" phase, while
> originally it was called from the pci_bus_add_device(), which called
> pci_fixup_device() at the "pci_fixup_final" phase.
>
> The callstack before:
> [ 1121.314405] arm_smmu_probe_device+0x48/0x450
> [ 1121.314410] __iommu_probe_device+0xc4/0x3c8
> [ 1121.314412] iommu_probe_device+0x40/0x90
> [ 1121.314414] acpi_dma_configure_id+0xb4/0x100
> [ 1121.314417] pci_dma_configure+0xf8/0x108
> [ 1121.314421] really_probe+0x78/0x278
> [ 1121.314425] __driver_probe_device+0x80/0x140
> [ 1121.314427] driver_probe_device+0x48/0x130
> [ 1121.314430] __device_attach_driver+0xc0/0x108
> [ 1121.314432] bus_for_each_drv+0x8c/0xf8
> [ 1121.314435] __device_attach+0x104/0x1a0
> [ 1121.314437] device_attach+0x1c/0x30
> [ 1121.314440] pci_bus_add_device+0xb8/0x1f0
> [ 1121.314442] pci_iov_add_virtfn+0x2ac/0x300
>
> And after:
> [ 215.072859] arm_smmu_probe_device+0x48/0x450
> [ 215.072871] __iommu_probe_device+0xc0/0x468
> [ 215.072875] iommu_probe_device+0x40/0x90
> [ 215.072877] iommu_bus_notifier+0x38/0x68
> [ 215.072879] notifier_call_chain+0x80/0x148
> [ 215.072886] blocking_notifier_call_chain+0x50/0x80
> [ 215.072889] bus_notify+0x44/0x68
> [ 215.072896] device_add+0x580/0x768
> [ 215.072898] pci_device_add+0x1e8/0x568
> [ 215.072906] pci_iov_add_virtfn+0x198/0x300
The stacktraces definitely help connect the dots but don't integrate
the fixup phases and the timestamps are unnecessary distraction.
I would omit all the above except the first paragraph and include
something like this instead, which shows how arm_smmu_probe_device()
was previously after final fixups and is now between header and final
fixups:
pci_iov_add_virtfn
pci_device_add
pci_fixup_device(pci_fixup_header) <--
device_add
bus_notify
iommu_bus_notifier
+ iommu_probe_device
+ arm_smmu_probe_device
pci_bus_add_device
pci_fixup_device(pci_fixup_final) <--
device_attach
driver_probe_device
really_probe
pci_dma_configure
acpi_dma_configure_id
- iommu_probe_device
- arm_smmu_probe_device
This is the pci_iov_add_virtfn(). The non-SR-IOV case is similar in
that pci_device_add() is called from pci_scan_single_device() in the
generic enumeration path, and pci_bus_add_device() is called later,
after all a host bridge has been enumerated.
> Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path")
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> [kwilczynski: commit log]
> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
You should never include somebody else's Signed-off-by below yours.
You should only add *your own* Signed-off-by:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=v6.13#n396
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
>
> v2: Modify commit log
>
> drivers/pci/quirks.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index f840d611c450..a9759889ff5e 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -1991,12 +1991,12 @@ static void quirk_huawei_pcie_sva(struct pci_dev *pdev)
> device_create_managed_software_node(&pdev->dev, properties, NULL))
> pci_warn(pdev, "could not add stall property");
> }
> -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0xa250, quirk_huawei_pcie_sva);
> -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0xa251, quirk_huawei_pcie_sva);
> -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0xa255, quirk_huawei_pcie_sva);
> -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0xa256, quirk_huawei_pcie_sva);
> -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0xa258, quirk_huawei_pcie_sva);
> -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0xa259, quirk_huawei_pcie_sva);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HUAWEI, 0xa250, quirk_huawei_pcie_sva);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HUAWEI, 0xa251, quirk_huawei_pcie_sva);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HUAWEI, 0xa255, quirk_huawei_pcie_sva);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HUAWEI, 0xa256, quirk_huawei_pcie_sva);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HUAWEI, 0xa258, quirk_huawei_pcie_sva);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HUAWEI, 0xa259, quirk_huawei_pcie_sva);
>
> /*
> * It's possible for the MSI to get corrupted if SHPC and ACPI are used
> --
> 2.25.1
>
next prev parent reply other threads:[~2025-03-15 18:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-14 7:10 [PATCH] PCI: declare quirk_huawei_pcie_sva as FIXUP_HEADER Zhangfei Gao
2025-03-14 7:42 ` Krzysztof Wilczyński
2025-03-14 7:45 ` Zhangfei Gao
2025-03-14 16:28 ` Bjorn Helgaas
2025-03-15 1:29 ` Zhangfei Gao
2025-03-15 4:22 ` Krzysztof Wilczyński
2025-03-15 10:10 ` [PATCH v2] PCI: Declare quirk_huawei_pcie_sva() as pci_fixup_header Zhangfei Gao
2025-03-17 1:13 ` [PATCH v3] " Zhangfei Gao
2025-03-20 14:07 ` Zhangfei Gao
2025-04-07 11:56 ` Zhangfei Gao
2025-04-07 18:22 ` Bjorn Helgaas
2025-03-15 10:13 ` [PATCH v2] " Zhangfei Gao
2025-03-15 11:33 ` Krzysztof Wilczyński
2025-03-15 18:45 ` Bjorn Helgaas [this message]
2025-03-16 4:15 ` Zhangfei Gao
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=20250315184523.GA848225@bhelgaas \
--to=helgaas@kernel.org \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=zhangfei.gao@linaro.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.