[PATCH v2 14/14] powerpc/pseries/iommu: Rename "direct window" to "dma window"
Leonardo Bras
leobras.c at gmail.com
Tue Apr 13 16:03:44 AEST 2021
On Wed, 2020-09-30 at 17:29 +1000, Alexey Kardashevskiy wrote:
>
> On 30/09/2020 06:54, Leonardo Bras wrote:
> > On Tue, 2020-09-29 at 13:55 +1000, Alexey Kardashevskiy wrote:
> > >
> > > On 12/09/2020 03:07, Leonardo Bras wrote:
> > > > Cc: linuxppc-dev at lists.ozlabs.org, linux-kernel at vger.kernel.org,
> > > >
> > > > A previous change introduced the usage of DDW as a bigger indirect DMA
> > > > mapping when the DDW available size does not map the whole partition.
> > > >
> > > > As most of the code that manipulates direct mappings was reused for
> > > > indirect mappings, it's necessary to rename all names and debug/info
> > > > messages to reflect that it can be used for both kinds of mapping.
> > > >
> > > > Also, defines DEFAULT_DMA_WIN as "ibm,dma-window" to document that
> > > > it's the name of the default DMA window.
> > >
> > > "ibm,dma-window" is so old so it does not need a macro (which btw would
> > > be DMA_WIN_PROPNAME to match the other names) :)
> >
> > Thanks for bringing that to my attention!
> > In fact, DMA_WIN_PROPNAME makes more sense, but it's still generic and
> > doesn't look to point to a generic one.
> >
> > Would that be ok to call it DEFAULT_WIN_PROPNAME ?
>
>
> I would not touch it at all, the property name is painfully known and
> not going to change ever. Does anyone else define it as a macro? I do
> not see any:
Ok then, reverting define :)
Thanks!
>
> [fstn1-p1 kernel-dma-bypass]$ git grep "ibm,dma-window" | wc -l
> 8
> [fstn1-p1 kernel-dma-bypass]$ git grep "define.*ibm,dma-window" | wc -l
> 0
>
>
>
> >
> >
> > >
> > >
> > > > Those changes are not supposed to change how the code works in any
> > > > way, just adjust naming.
> > >
> > > I simply have this in my .vimrc for the cases like this one:
> > >
> > > ===
> > > This should cause no behavioural change.
> > > ===
> >
> > Great tip! I will make sure to have this saved here :)
> >
> > Thank you!
> >
>
More information about the Linuxppc-dev
mailing list