From: Bjorn Helgaas <helgaas@kernel.org>
To: Niklas Cassel <cassel@kernel.org>
Cc: "Jingoo Han" <jingoohan1@gmail.com>,
"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Damien Le Moal" <dlemoal@kernel.org>,
linux-pci@vger.kernel.org
Subject: Re: [PATCH 1/3] PCI: dwc: ep: Add dw_pcie_ep_deinit_notify()
Date: Tue, 28 May 2024 14:55:39 -0500 [thread overview]
Message-ID: <20240528195539.GA458945@bhelgaas> (raw)
In-Reply-To: <ZlYt1DvhcK-ePwXU@ryzen.lan>
On Tue, May 28, 2024 at 09:17:40PM +0200, Niklas Cassel wrote:
> On Tue, May 28, 2024 at 10:55:34AM -0500, Bjorn Helgaas wrote:
> > On Tue, May 28, 2024 at 03:00:37PM +0200, Niklas Cassel wrote:
> > > Add a DWC specific wrapper function (dw_pcie_ep_deinit_notify()) around
> > > pci_epc_deinit_notify(), similar to how we have a wrapper function
> > > (dw_pcie_ep_init_notify()) around pci_epc_init_notify().
> > >
> > > This will allow the DWC glue drivers to use the same API layer for init
> > > and deinit notification.
> > >
> > > Signed-off-by: Niklas Cassel <cassel@kernel.org>
> > > ---
> > > drivers/pci/controller/dwc/pcie-designware-ep.c | 13 +++++++++++++
> > > drivers/pci/controller/dwc/pcie-designware.h | 5 +++++
> > > 2 files changed, 18 insertions(+)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > index 2063cf2049e5..3c9079651dff 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > @@ -39,6 +39,19 @@ void dw_pcie_ep_init_notify(struct dw_pcie_ep *ep)
> > > }
> > > EXPORT_SYMBOL_GPL(dw_pcie_ep_init_notify);
> > >
> > > +/**
> > > + * dw_pcie_ep_deinit_notify - Notify EPF drivers about EPC deinitialization
> > > + * complete
> > > + * @ep: DWC EP device
> > > + */
> > > +void dw_pcie_ep_deinit_notify(struct dw_pcie_ep *ep)
> > > +{
> > > + struct pci_epc *epc = ep->epc;
> > > +
> > > + pci_epc_deinit_notify(epc);
> > > +}
> > > +EXPORT_SYMBOL_GPL(dw_pcie_ep_deinit_notify);
> >
> > What is the value of this wrapper?
> >
> > I see that dw_pcie_ep_deinit_notify() would be parallel to
> > dw_pcie_ep_init_notify() and dw_pcie_ep_linkup(), but none of these
> > has any DWC-specific content other than the fact that
> > pcie-designware.h provides stubs for the non-CONFIG_PCIE_DW_EP case.
>
> Exactly what you are saying, consistency with the existing design.
>
> To me, it seems a bit weird to use:
> dw_pcie_ep_init_notify() to notify init completion, and then to use
> pci_epc_deinit_notify() to notify deinit completion.
>
> deinit notify callback should basically undo what the init notify callback
> did, so it would make sense that the naming of the API calls are similar.
>
> > What if we added stubs to pci-epc.h pci_epc_init_notify(),
> > pci_epc_deinit_notify(), pci_epc_linkup(), and pci_epc_linkdown() for
> > the non-CONFIG_PCI_ENDPOINT case instead? Then we might be able to
> > drop all these DWC-specific wrappers.
>
> The PCI endpoint subsystem currently does not provide any stubs at all,
> so that would be a bigger change compared to this small patch.
> (And considering that the pci/endpoint branch does not build, I opted
> for the smaller patch.)
> Your suggestion would of course work as well, but if we go that route,
> then we should probably add stubs for all functions in both
> include/linux/pci-epc.h and include/linux/pci-epf.h.
> As long as the DWC glue drivers use the same "API layer" for init and
> deinit notification, I'm happy :)
The cadence, rcar, and rockchip drivers use pci_epc_init_notify() with
no wrapper.
A bunch of DWC-based drivers (artpec6, dra7xx, imx6, keembay, ks, ls,
qcom, rcar_gen4, etc) use the dw_pcie_ep_init_notify() wrapper.
ls and qcom even use *both*: pci_epc_linkdown() but
dw_pcie_ep_linkup().
Personally I would drop the dw_*() wrappers. It's a bigger patch but
not any more complicated, and the result is consistency across both
DWC and the non-DWC drivers.
I don't know if we need to add stubs for *all* the functions. I'd
probably defer that until we trip over them.
Bjorn
next prev parent reply other threads:[~2024-05-28 19:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-28 13:00 [PATCH 0/3] Make pci/endpoint branch build Niklas Cassel
2024-05-28 13:00 ` [PATCH 1/3] PCI: dwc: ep: Add dw_pcie_ep_deinit_notify() Niklas Cassel
2024-05-28 15:55 ` Bjorn Helgaas
2024-05-28 19:17 ` Niklas Cassel
2024-05-28 19:55 ` Bjorn Helgaas [this message]
2024-05-29 7:35 ` Niklas Cassel
2024-05-29 14:16 ` Manivannan Sadhasivam
2024-05-29 14:54 ` Niklas Cassel
2024-05-29 15:40 ` Manivannan Sadhasivam
2024-05-29 17:25 ` Bjorn Helgaas
2024-05-29 17:48 ` Niklas Cassel
2024-05-28 13:00 ` [PATCH 2/3] PCI: qcom-ep: Make use of dw_pcie_ep_deinit_notify() Niklas Cassel
2024-05-28 13:00 ` [PATCH 3/3] PCI: tegra194: " Niklas Cassel
2024-05-28 14:44 ` [PATCH 0/3] Make pci/endpoint branch build Bjorn Helgaas
2024-05-28 18:57 ` Niklas Cassel
2024-05-28 19:29 ` [PATCH 0/3] Make pci/endpoint branch buildgg Bjorn Helgaas
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=20240528195539.GA458945@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=jingoohan1@gmail.com \
--cc=kw@linux.com \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=robh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox