linux-kernel - Re: [PATCH v3] i2c: tegra: Share same DMA channel for RX and TX

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:   Thu, 23 Mar 2023 10:50:17 +0100
From:   Thierry Reding <thierry.reding@...il.com>
To:     Akhil R <akhilrajeev@...dia.com>
Cc:     Jonathan Hunter <jonathanh@...dia.com>,
        "christian.koenig@....com" <christian.koenig@....com>,
        "digetx@...il.com" <digetx@...il.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        "sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
        "wsa@...nel.org" <wsa@...nel.org>
Subject: Re: [PATCH v3] i2c: tegra: Share same DMA channel for RX and TX

On Thu, Mar 23, 2023 at 09:26:00AM +0000, Akhil R wrote:
> > On 22/03/2023 12:00, Akhil R wrote:
> > >> On 22/03/2023 10:24, Akhil R wrote:
> > >>> Allocate only one DMA channel for I2C and share it for both TX and RX
> > >>> instead of using two different DMA hardware channels with the same
> > >>> slave ID. Since I2C supports only half duplex, there is no impact on
> > >>> perf with this.
> > >>>
> > >>> Signed-off-by: Akhil R <akhilrajeev@...dia.com>
> > >>
> > >> Just to confirm. This impacts all Tegra devices from Tegra20 to the
> > >> latest. Does this work for all Tegra and the different DMA controllers
> > >> that they have?
> > >>
> > > Yes, It should. I could see in the APB DMA driver that the same channel
> > > could be used for TX and RX and the direction is configured only during
> > > dma_prep_*() calls.
> > > I did not test it on a Tegra with APB DMA, but since it works very similar
> > > to GPC DMA there should not be any impact.
> > 
> > 
> > OK. BTW, this does not apply cleanly on top of -next. It appears that
> > this is based on top "i2c: tegra: Fix PEC support for SMBUS block read"
> > and that one needs to be applied first. This can be avoided if you send
> > as a series.
> > 
> Oh. Okay. I used 'git am --3way' when I tried, and the conflict went unnoticed.
> Shall I send a new version on top of -next?
> The two patches were added in different contexts and that’s why I did not
> combine them as a series.

It's usually best to combine them in a series even if they are in
slightly different contexts. This is especially true if they cause
conflicts between one another. If you send them as a series, you can
resolve the conflicts yourself (you may not even have conflicts locally
if you create the patches in the same branch), but if you send them
separately the maintainer will end up having to resolve the conflicts
(or apply in the right order).

It's best if you resolve the conflicts because you know better than the
maintainer (usually) or specify any dependencies to make it easier for
the maintainer to do the right thing.

But again, in the vast majority of cases, it's best to combine all the
work on one driver in a single series before sending out.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)