From: Rob Herring <robh@kernel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Vidya Sagar <vidyas@nvidia.com>,
Jingoo Han <jingoohan1@gmail.com>,
Gustavo Pimentel <gustavo.pimentel@synopsys.com>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Krzysztof Wilczynski <kw@linux.com>,
Bjorn Helgaas <bhelgaas@google.com>,
PCI <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Krishna Thota <kthota@nvidia.com>,
Manikanta Maddireddy <mmaddireddy@nvidia.com>,
sagar.tv@gmail.com, Xiaowei Bao <xiaowei.bao@nxp.com>,
Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Subject: Re: [PATCH V1] PCI: designware-ep: Fix DBI access before core init
Date: Wed, 10 Aug 2022 12:16:18 -0600 [thread overview]
Message-ID: <20220810181618.GD200295-robh@kernel.org> (raw)
In-Reply-To: <20220802140738.GA115652@thinkpad>
On Tue, Aug 02, 2022 at 07:37:38PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Aug 02, 2022 at 12:54:37PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, Aug 01, 2022 at 02:27:14PM -0600, Rob Herring wrote:
> > > On Sat, Jul 30, 2022 at 8:50 AM Manivannan Sadhasivam
> > > <manivannan.sadhasivam@linaro.org> wrote:
> > > >
> > > > On Fri, Jul 29, 2022 at 05:44:04PM -0500, Bjorn Helgaas wrote:
> > > > > [+cc Xiaowei (author of 6bfc9c3a2c70), Hou (author of 8bcca2658558)]
> > > > >
> > > > > On Thu, Jul 28, 2022 at 05:56:28PM +0530, Vidya Sagar wrote:
> > > > > > On 7/28/2022 3:44 AM, Bjorn Helgaas wrote:
> > > > > > > On Wed, Jun 22, 2022 at 09:31:33AM +0530, Vidya Sagar wrote:
> > > > > > > > Platforms that cannot support their core initialization without the
> > > > > > > > reference clock from the host, implement the feature 'core_init_notifier'
> > > > > > > > to indicate the DesignWare sub-system about when their core is getting
> > > > > > > > initialized. Any accesses to the core (Ex:- DBI) would result in system
> > > > > > > > hang in such systems (Ex:- tegra194). This patch moves any access to the
> > > > > > > > core to dw_pcie_ep_init_complete() API which is effectively called only
> > > > > > > > after the core initialization.
> > >
> > > > > 6) What's going on with the CORE_INIT and LINK_UP notifiers?
> > > > > dw_pcie_ep_init_notify() is only called by qcom and tegra.
> > > > > dw_pcie_ep_linkup() is only called by dra7xx, qcom, and tegra.
> > > > > As far as I can tell, nobody at all registers to handle those
> > > > > events except a test. I think it's pointless to have that code
> > > > > if nobody uses it.
> > > > >
> > > >
> > > > I have submitted an actual driver that makes use of these notifiers:
> > > > https://lore.kernel.org/lkml/20220502060611.58987-9-manivannan.sadhasivam@linaro.org/
> > >
> > > Notifiers aren't the best interface in the kernel. I think they are
> > > best used if there's no real linkage between the sender and receiver.
> > > For an EPC and EPF that's a fixed interface, so define a proper
> > > interface.
> > >
> >
> > Fair point! The use of notifiers also suffer from an issue where the notifier
> > chain in EPC is atomic but the EPF calls some of the functions like
> > pci_epc_write_header() could potentially sleep.
> >
> > I'll try to come up with an interface.
> >
>
> I thought about using a new set of callbacks that define the EPC events and
> have the EPF drivers populate them during probe time. Like below,
>
> ```
> diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
> index e03c57129ed5..45247802d6f7 100644
> --- a/include/linux/pci-epf.h
> +++ b/include/linux/pci-epf.h
> @@ -74,6 +74,20 @@ struct pci_epf_ops {
> struct config_group *group);
> };
>
> +/**
> + * struct pci_epf_events - Callbacks for capturing the EPC events
> + * @init_complete: Callback for the EPC initialization complete event
> + * @link_up: Callback for the EPC link up event
> + */
> +struct pci_epc_events {
pci_epc_event_ops
> + void (*init_complete)(struct pci_epf *epf);
> + void (*link_up)(struct pci_epf *epf);
link down?
> +};
> +
> /**
> * struct pci_epf_driver - represents the PCI EPF driver
> * @probe: ops to perform when a new EPF device has been bound to the EPF driver
> @@ -172,6 +186,7 @@ struct pci_epf {
> unsigned int is_vf;
> unsigned long vfunction_num_map;
> struct list_head pci_vepf;
> + struct pci_epc_events *events;
*event_ops
And 'const'
> };
>
> /**
> ```
>
> When each of the event is received by the EPC driver, it will use the EPC API
> to call the relevant event callback for _each_ EPF. Like below:
>
> ```
> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index 6ad9b38b63a9..4b0b30b91403 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c
> @@ -724,10 +724,15 @@ EXPORT_SYMBOL_GPL(pci_epc_linkdown);
> */
> void pci_epc_init_notify(struct pci_epc *epc)
> {
> + struct pci_epf *epf;
> +
> if (!epc || IS_ERR(epc))
> return;
>
> - blocking_notifier_call_chain(&epc->notifier, CORE_INIT, NULL);
> + list_for_each_entry(epf, &epc->pci_epf, list) {
> + if (epf->events->init_complete)
> + epf->events->init_complete(epf);
> + }
> }
> EXPORT_SYMBOL_GPL(pci_epc_init_notify);
> ```
>
> Does this look good to you? I can spin up an RFC series, but wanted to check the
> interface design beforehand.
I guess. Honestly, the I'm not all that familiar with the endpoint
stuff.
Rob
next prev parent reply other threads:[~2022-08-10 18:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-22 4:01 [PATCH V1] PCI: designware-ep: Fix DBI access before core init Vidya Sagar
2022-07-07 9:09 ` Vidya Sagar
2022-07-07 16:00 ` Bjorn Helgaas
2022-07-07 16:31 ` Vidya Sagar
2022-07-07 16:55 ` Manivannan Sadhasivam
2022-07-27 22:14 ` Bjorn Helgaas
2022-07-28 12:26 ` Vidya Sagar
2022-07-28 14:17 ` Bjorn Helgaas
2022-07-29 22:44 ` Bjorn Helgaas
2022-07-30 14:50 ` Manivannan Sadhasivam
2022-08-01 20:27 ` Rob Herring
2022-08-02 7:24 ` Manivannan Sadhasivam
2022-08-02 14:07 ` Manivannan Sadhasivam
2022-08-10 18:16 ` Rob Herring [this message]
2022-08-16 14:15 ` Lorenzo Pieralisi
2022-08-16 14:35 ` Vidya Sagar
2022-08-19 8:35 ` Manivannan Sadhasivam
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=20220810181618.GD200295-robh@kernel.org \
--to=robh@kernel.org \
--cc=Zhiqiang.Hou@nxp.com \
--cc=bhelgaas@google.com \
--cc=gustavo.pimentel@synopsys.com \
--cc=helgaas@kernel.org \
--cc=jingoohan1@gmail.com \
--cc=kthota@nvidia.com \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mmaddireddy@nvidia.com \
--cc=sagar.tv@gmail.com \
--cc=vidyas@nvidia.com \
--cc=xiaowei.bao@nxp.com \
/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.