From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: kishon@kernel.org, lpieralisi@kernel.org, bhelgaas@google.com,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kw@linux.com, robh@kernel.org, vidyas@nvidia.com,
vigneshr@ti.com
Subject: Re: [PATCH v3 4/5] PCI: endpoint: Use callback mechanism for passing events from EPC to EPF
Date: Tue, 25 Oct 2022 17:09:33 +0530 [thread overview]
Message-ID: <20221025113933.GC221610@thinkpad> (raw)
In-Reply-To: <b6001af6-4c41-a678-b3cb-4c1d874425bf@ti.com>
HI Kishon,
On Tue, Oct 11, 2022 at 06:27:37PM +0530, Kishon Vijay Abraham I wrote:
> Hi Mani,
>
> On 06/10/22 7:19 pm, Manivannan Sadhasivam wrote:
> > Instead of using the notifiers for passing the events from EPC to EPF,
> > let's introduce a callback based mechanism where the EPF drivers can
> > populate relevant callbacks for EPC events they want to subscribe.
> >
> > The use of notifiers in kernel is not recommended if there is a real link
> > between the sender and receiver, like in this case. Also, the existing
> > atomic notifier forces the notification functions to be in atomic context
> > while the caller may be in non-atomic context. For instance, the two
> > in-kernel users of the notifiers, pcie-qcom and pcie-tegra194, both are
> > calling the notifier functions in non-atomic context (from threaded IRQ
> > handlers). This creates a sleeping in atomic context issue with the
> > existing EPF_TEST driver that calls the EPC APIs that may sleep.
> >
> > For all these reasons, let's get rid of the notifier chains and use the
> > simple callback mechanism for signalling the events from EPC to EPF
> > drivers. This preserves the context of the caller and avoids the latency
> > of going through a separate interface for triggering the notifications.
> >
> > As a first step of the transition, the core_init() callback is introduced
> > in this commit, that'll replace the existing CORE_INIT notifier used for
> > signalling the init complete event from EPC.
> >
> > During the occurrence of the event, EPC will go over the list of EPF
> > drivers attached to it and will call the core_init() callback if available.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > ---
> > drivers/pci/endpoint/functions/pci-epf-test.c | 13 ++++++-------
> > drivers/pci/endpoint/pci-epc-core.c | 11 ++++++++++-
> > include/linux/pci-epf.h | 11 ++++++++++-
> > 3 files changed, 26 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> > index a6f906a96669..868de17e1ad2 100644
> > --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> > @@ -826,20 +826,17 @@ static int pci_epf_test_core_init(struct pci_epf *epf)
> > return 0;
> > }
> > +static const struct pci_epc_event_ops pci_epf_test_event_ops = {
> > + .core_init = pci_epf_test_core_init,
> > +};
> > +
> > static int pci_epf_test_notifier(struct notifier_block *nb, unsigned long val,
> > void *data)
> > {
> > struct pci_epf *epf = container_of(nb, struct pci_epf, nb);
> > struct pci_epf_test *epf_test = epf_get_drvdata(epf);
> > - int ret;
> > switch (val) {
> > - case CORE_INIT:
> > - ret = pci_epf_test_core_init(epf);
> > - if (ret)
> > - return NOTIFY_BAD;
> > - break;
> > -
> > case LINK_UP:
> > queue_delayed_work(kpcitest_workqueue, &epf_test->cmd_handler,
> > msecs_to_jiffies(1));
> > @@ -1010,6 +1007,8 @@ static int pci_epf_test_probe(struct pci_epf *epf, const struct pci_epf_device_i
> > INIT_DELAYED_WORK(&epf_test->cmd_handler, pci_epf_test_cmd_handler);
> > + epf->event_ops = &pci_epf_test_event_ops;
>
> Doesn't this ignore epc_features input from the controller driver?
Sorry I don't get it! epc_features from the controller is acuquired during
pci_epf_test_bind(). EPF probe doesn't have any visibility of the controller
driver.
> > +
> > epf_set_drvdata(epf, epf_test);
> > return 0;
> > }
> > diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> > index 6cce430d431b..ba54f17ae06f 100644
> > --- a/drivers/pci/endpoint/pci-epc-core.c
> > +++ b/drivers/pci/endpoint/pci-epc-core.c
> > @@ -707,10 +707,19 @@ EXPORT_SYMBOL_GPL(pci_epc_linkup);
> > */
> > void pci_epc_init_notify(struct pci_epc *epc)
> > {
> > + struct pci_epf *epf;
> > +
> > if (!epc || IS_ERR(epc))
> > return;
> > - atomic_notifier_call_chain(&epc->notifier, CORE_INIT, NULL);
> > + mutex_lock(&epc->list_lock);
> > + list_for_each_entry(epf, &epc->pci_epf, list) {
> > + mutex_lock(&epf->lock);
> > + if (epf->event_ops->core_init)
>
> This would result in abort if the endpoint function driver is not bound to
> endpoint device and the notify is called.
>
I don't think so. We are iterating the "epc->pci_epf" list, which will only be
populated if a EPF driver gets bind to an endpoint device.
> This would also require all function drivers to have event_ops populated.
> IOW this could break pci-epf-ntb.c.
>
This I missed. I will add a check for the "epf->event_ops" existence first.
Thanks,
Mani
> Thanks,
> Kishon
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2022-10-25 11:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-06 13:49 [PATCH v3 0/5] PCI: endpoint: Rework the EPC to EPF notification Manivannan Sadhasivam
2022-10-06 13:49 ` [PATCH v3 1/5] PCI: dra7xx: Use threaded IRQ handler for "dra7xx-pcie-main" IRQ Manivannan Sadhasivam
2022-10-11 12:37 ` Kishon Vijay Abraham I
2022-10-06 13:49 ` [PATCH v3 2/5] PCI: tegra194: Move dw_pcie_ep_linkup() to threaded IRQ handler Manivannan Sadhasivam
2022-10-10 14:23 ` Vidya Sagar
2022-10-25 14:32 ` Manivannan Sadhasivam
2022-10-06 13:49 ` [PATCH v3 3/5] PCI: endpoint: Use a separate lock for protecting epc->pci_epf list Manivannan Sadhasivam
2022-10-11 12:40 ` Kishon Vijay Abraham I
2022-10-06 13:49 ` [PATCH v3 4/5] PCI: endpoint: Use callback mechanism for passing events from EPC to EPF Manivannan Sadhasivam
2022-10-11 12:57 ` Kishon Vijay Abraham I
2022-10-25 11:39 ` Manivannan Sadhasivam [this message]
2022-11-03 9:54 ` Kishon Vijay Abraham I
2022-10-06 13:49 ` [PATCH v3 5/5] PCI: endpoint: Use link_up() callback in place of LINK_UP notifier 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=20221025113933.GC221610@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=bhelgaas@google.com \
--cc=kishon@kernel.org \
--cc=kishon@ti.com \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=robh@kernel.org \
--cc=vidyas@nvidia.com \
--cc=vigneshr@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).