From: Niklas Cassel <Niklas.Cassel@wdc.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: "Krzysztof Wilczyński" <kw@linux.com>,
"jingoohan1@gmail.com" <jingoohan1@gmail.com>,
"gustavo.pimentel@synopsys.com" <gustavo.pimentel@synopsys.com>,
"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
"robh@kernel.org" <robh@kernel.org>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"quic_bjorande@quicinc.com" <quic_bjorande@quicinc.com>,
"fancer.lancer@gmail.com" <fancer.lancer@gmail.com>,
"vidyas@nvidia.com" <vidyas@nvidia.com>
Subject: Re: [PATCH v7 0/2] PCI: designware-ep: Fix DBI access before core init
Date: Wed, 10 Jan 2024 10:01:08 +0000 [thread overview]
Message-ID: <ZZ5q4oPEj0N1mQED@x1-carbon> (raw)
In-Reply-To: <20240110031137.GA2630@thinkpad>
Hello Mani,
On Wed, Jan 10, 2024 at 08:41:37AM +0530, Manivannan Sadhasivam wrote:
> On Tue, Jan 09, 2024 at 05:58:53PM +0000, Niklas Cassel wrote:
> > On Sun, Jan 07, 2024 at 04:27:07PM +0900, Krzysztof Wilczyński wrote:
> >
> > Considering that we know that this series introduces new problems
> > for drivers with a .core_init_notifier (i.e. tegra and qcom), see:
> > https://lore.kernel.org/linux-pci/ZWYmX8Y%2F7Q9WMxES@x1-carbon/
> >
> > Do we really want to apply this series as is?
> >
> >
>
> Niklas, I think I explained it in this thread itself. Let me reiterate here
> again.
>
> The fact that you are seeing the dmaengine warnings is due to function drivers
> not releasing the channels properly. It is not the job of the DWC driver to
> release the channels. The channels are requested by the function drivers [1]
> and they _should_ release them when the channels are no longer required.
Sure, the function driver should release the channels.
>
> I know that the PCI_EPF_TEST driver is not doing so and so you are seeing the
> warnings. But I do not have a device to test that function driver. Qcom
> platforms use a dedicated function driver and that releases the channels when it
> gets the LINK_DOWN event from EPC [2].
>
> So my conclusion is that the issue is there even without this series. If you
> still want me to fix the EPF_TEST driver, I can submit a change, but someone has
> to test it.
That conclusion is not fully correct.
Let's take e.g. these error messages that this series introduces:
[ 1000.714355] debugfs: File 'mf' in directory '/' already present!
[ 1000.714890] debugfs: File 'wr_ch_cnt' in directory '/' already present!
[ 1000.715476] debugfs: File 'rd_ch_cnt' in directory '/' already present!
[ 1000.716061] debugfs: Directory 'registers' with parent '/' already present!
These come from dw_edma_core_debugfs_on(), which is called by dw_edma_probe().
This is a direct result from your patch:
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=controller/dwc-ep&id=9ab5c8bb7a305135b1b6c65cb8db92b4acbef79d
Which moves dw_pcie_edma_detect() from dw_pcie_ep_init_complete() to
dw_pcie_ep_late_init() (since dw_pcie_edma_detect() calls dw_edma_probe()).
So without your patch, those debugfs error messages are not seen.
Thus, I do not think that it is sufficient to only modify the pci-epf-test
driver to release the dma channels, as I don't see how that will avoid e.g.
the debugfs error messages introduced by this patch.
Kind regards,
Niklas
next prev parent reply other threads:[~2024-01-10 10:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-20 8:40 [PATCH v7 0/2] PCI: designware-ep: Fix DBI access before core init Manivannan Sadhasivam
2023-11-20 8:40 ` [PATCH v7 1/2] " Manivannan Sadhasivam
2024-01-09 21:12 ` Bjorn Helgaas
2023-11-20 8:40 ` [PATCH v7 2/2] PCI: designware-ep: Move pci_epc_init_notify() inside dw_pcie_ep_init_complete() Manivannan Sadhasivam
2024-01-07 7:27 ` [PATCH v7 0/2] PCI: designware-ep: Fix DBI access before core init Krzysztof Wilczyński
2024-01-07 7:34 ` Krzysztof Wilczyński
2024-01-09 17:58 ` Niklas Cassel
2024-01-10 3:11 ` Manivannan Sadhasivam
2024-01-10 10:01 ` Niklas Cassel [this message]
2024-01-10 15:27 ` 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=ZZ5q4oPEj0N1mQED@x1-carbon \
--to=niklas.cassel@wdc.com \
--cc=bhelgaas@google.com \
--cc=fancer.lancer@gmail.com \
--cc=gustavo.pimentel@synopsys.com \
--cc=jingoohan1@gmail.com \
--cc=kw@linux.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=quic_bjorande@quicinc.com \
--cc=robh@kernel.org \
--cc=vidyas@nvidia.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