linux-kernel - Re: [PATCH v1 3/6] PCI: dwc: Add HDMA support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 9 Feb 2024 11:10:32 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: Serge Semin <fancer.lancer@...il.com>
Cc: Mrinmay Sarkar <quic_msarkar@...cinc.com>, vkoul@...nel.org,
	jingoohan1@...il.com, conor+dt@...nel.org, konrad.dybcio@...aro.org,
	manivannan.sadhasivam@...aro.org, robh+dt@...nel.org,
	quic_shazhuss@...cinc.com, quic_nitegupt@...cinc.com,
	quic_ramkri@...cinc.com, quic_nayiluri@...cinc.com,
	dmitry.baryshkov@...aro.org, quic_krichai@...cinc.com,
	quic_vbadigan@...cinc.com, quic_parass@...cinc.com,
	quic_schintav@...cinc.com, quic_shijjose@...cinc.com,
	Gustavo Pimentel <gustavo.pimentel@...opsys.com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kw@...ux.com>,
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
	Kishon Vijay Abraham I <kishon@...nel.org>,
	dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	mhi@...ts.linux.dev
Subject: Re: [PATCH v1 3/6] PCI: dwc: Add HDMA support

On Sat, Feb 03, 2024 at 12:40:39AM +0300, Serge Semin wrote:
> On Fri, Jan 19, 2024 at 06:30:19PM +0530, Mrinmay Sarkar wrote:
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> > 
> > Hyper DMA (HDMA) is already supported by the dw-edma dmaengine driver.
> > Unlike it's predecessor Embedded DMA (eDMA), HDMA supports only the
> > unrolled mapping format. So the platform drivers need to provide a valid
> > base address of the CSRs. Also, there is no standard way to auto detect
> > the number of available read/write channels in a platform. So the platform
> > drivers has to provide that information as well.
> ...

> Basically this change defines two versions of the eDMA info
> initialization procedure:
> 1. use pre-defined CSRs mapping format and amount of channels,
> 2. auto-detect CSRs mapping and the amount of channels.
> The second version also supports the optional CSRs mapping format
> detection procedure by means of the DW_PCIE_CAP_EDMA_UNROLL flag
> semantics. Thus should this patch is accepted there will be the
> functionality duplication. I suggest to make things a bit more
> flexible than that. Instead of creating the two types of the
> init-methods selectable based on the mapping format, let's split up
> the already available DW eDMA engine detection procedure into the next
> three stages:
> 1. initialize DW eDMA data,
> 2. auto-detect the CSRs mapping format,
> 3. auto-detect the amount of channels.
> and convert the later two to being optional. They will be skipped in case
> if the mapping format or the amount of channels have been pre-defined
> by the platform drivers. Thus we can keep the eDMA data init procedure
> more linear thus easier to read, drop redundant DW_PCIE_CAP_EDMA_UNROLL flag
> and use the new functionality for the Renesas R-Car S4-8's PCIe
> controller (for which the auto-detection didn't work), for HDMA with compat
> and _native_ CSRs mapping. See the attached patches for details:

I am still bound by the opinion of Google's legal team that I cannot
accept the code changes that were attached here.  I think it's fair to
read the review comments (thank you for those), but I suggest not
reading the patches that were attached.

Bjorn