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]

Message-ID: <qppxhhlbjqmop2vmaa6b5zjesgry75hapllokcmllgfwti4tbo@55aeewwp23cq>
Date: Sun, 11 Feb 2024 22:37:43 +0300
From: Serge Semin <fancer.lancer@...il.com>
To: Bjorn Helgaas <helgaas@...nel.org>, 
	Mrinmay Sarkar <quic_msarkar@...cinc.com>, Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Manivannan Sadhasivam <mani@...nel.org>, vkoul@...nel.org, 
	jingoohan1@...il.com, conor+dt@...nel.org, konrad.dybcio@...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 Fri, Feb 09, 2024 at 11:10:32AM -0600, Bjorn Helgaas wrote:
> 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.

Em, the review comment and the resultant patches were my own private
researches and developments. Is Google now blocking even individual
contributors?

In anyway if you are agree with the changes suggested above you can
set to the patches any author you think would be acceptable. My only
concern was to maintain the cleanness of the driver code developed by
me and which is going to be affected in the framework of this series.

-Serge(y)

> 
> Bjorn