From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: kishon@kernel.org, lpieralisi@kernel.org, bhelgaas@google.com,
kvijayab@amd.com
Cc: 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 v4 0/5] PCI: endpoint: Rework the EPC to EPF notification
Date: Sat, 5 Nov 2022 12:23:37 +0530 [thread overview]
Message-ID: <20221105065337.GA109545@thinkpad> (raw)
In-Reply-To: <20221025145101.116393-1-manivannan.sadhasivam@linaro.org>
Hi Kishon,
On Tue, Oct 25, 2022 at 08:20:56PM +0530, Manivannan Sadhasivam wrote:
> Hello,
>
> During the review of the patch that fixes DBI access in PCI EP, Rob
> suggested [1] using a fixed interface for passing the events from EPC to
> EPF instead of the in-kernel notifiers.
>
> This series introduces a simple callback based mechanism for passing the
> events from EPC to EPF. This interface is chosen for satisfying the below
> requirements:
>
> 1. The notification has to reach the EPF drivers without any additional
> latency.
> 2. The context of the caller (EPC) needs to be preserved while passing the
> notifications.
>
> With the existing notifier mechanism, the 1st case can be satisfied since
> notifiers aren't adding any huge overhead. But the 2nd case is clearly not
> satisfied, because the current atomic notifiers forces the EPF
> notification context to be atomic even though the caller (EPC) may not be
> in atomic context. In the notification function, the EPF drivers are
> required to call several EPC APIs that might sleep and this triggers a
> sleeping in atomic bug during runtime.
>
> The above issue could be fixed by using a blocking notifier instead of
> atomic, but that proposal was not accepted either [2].
>
> So instead of working around the issues within the notifiers, let's get rid
> of it and use the callback mechanism.
>
> NOTE: DRA7xx and TEGRA194 drivers are only compile tested. Testing this series
> on the real platforms is greatly appreciated.
>
Any feedback on this series?
Thanks,
Mani
> Thanks,
> Mani
>
> [1] https://lore.kernel.org/all/20220802072426.GA2494@thinkpad/T/#mfa3a5b3a9694798a562c36b228f595b6a571477d
> [2] https://lore.kernel.org/all/20220228055240.24774-1-manivannan.sadhasivam@linaro.org
>
> Changes in v4:
>
> * Added check for the presence of event_ops before involing the callbacks (Kishon)
> * Added return with IRQ_WAKE_THREAD when link_up event is found in the hard irq
> handler of tegra194 driver (Vidya)
> * Collected review tags
>
> Changes in v3:
>
> * As Kishon spotted, fixed the DRA7xx driver and also the TEGRA194 driver to
> call the LINK_UP callback in threaded IRQ handler.
>
> Changes in v2:
>
> * Introduced a new "list_lock" for protecting the epc->pci_epf list and
> used it in the callback mechanism.
>
> Manivannan Sadhasivam (5):
> PCI: dra7xx: Use threaded IRQ handler for "dra7xx-pcie-main" IRQ
> PCI: tegra194: Move dw_pcie_ep_linkup() to threaded IRQ handler
> PCI: endpoint: Use a separate lock for protecting epc->pci_epf list
> PCI: endpoint: Use callback mechanism for passing events from EPC to
> EPF
> PCI: endpoint: Use link_up() callback in place of LINK_UP notifier
>
> drivers/pci/controller/dwc/pci-dra7xx.c | 2 +-
> drivers/pci/controller/dwc/pcie-tegra194.c | 9 ++++-
> drivers/pci/endpoint/functions/pci-epf-test.c | 38 ++++++-------------
> drivers/pci/endpoint/pci-epc-core.c | 32 ++++++++++++----
> include/linux/pci-epc.h | 10 +----
> include/linux/pci-epf.h | 19 ++++++----
> 6 files changed, 59 insertions(+), 51 deletions(-)
>
> --
> 2.25.1
>
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2022-11-05 6:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 14:50 [PATCH v4 0/5] PCI: endpoint: Rework the EPC to EPF notification Manivannan Sadhasivam
2022-10-25 14:50 ` [PATCH v4 1/5] PCI: dra7xx: Use threaded IRQ handler for "dra7xx-pcie-main" IRQ Manivannan Sadhasivam
2022-10-25 14:50 ` [PATCH v4 2/5] PCI: tegra194: Move dw_pcie_ep_linkup() to threaded IRQ handler Manivannan Sadhasivam
2022-11-14 11:06 ` Manivannan Sadhasivam
2022-11-14 11:08 ` Manivannan Sadhasivam
2022-11-22 13:49 ` Manivannan Sadhasivam
2022-12-05 6:49 ` Manivannan Sadhasivam
2022-10-25 14:50 ` [PATCH v4 3/5] PCI: endpoint: Use a separate lock for protecting epc->pci_epf list Manivannan Sadhasivam
2022-10-25 14:51 ` [PATCH v4 4/5] PCI: endpoint: Use callback mechanism for passing events from EPC to EPF Manivannan Sadhasivam
2022-11-08 5:52 ` Kishon Vijay Abraham I
2022-10-25 14:51 ` [PATCH v4 5/5] PCI: endpoint: Use link_up() callback in place of LINK_UP notifier Manivannan Sadhasivam
2022-11-08 5:55 ` Kishon Vijay Abraham I
2022-11-05 6:53 ` Manivannan Sadhasivam [this message]
2022-11-07 20:28 ` [PATCH v4 0/5] PCI: endpoint: Rework the EPC to EPF notification Bjorn Helgaas
2022-11-08 12:14 ` Manivannan Sadhasivam
2022-11-08 12:56 ` Bjorn Helgaas
2022-11-14 7:33 ` Manivannan Sadhasivam
2022-11-14 10:05 ` Lorenzo Pieralisi
2022-11-14 10:20 ` 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=20221105065337.GA109545@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=bhelgaas@google.com \
--cc=kishon@kernel.org \
--cc=kvijayab@amd.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 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.