Re: [PATCHv2 0/4] m68k: coldfire: fix non-standard readX()/writeX() functions

[Greg Ungerer]

Hi Paolo,

On 13/6/26 19:22, Paolo Abeni wrote:
> On 6/9/26 4:12 PM, Greg Ungerer wrote:
> > This odd collection of patches is aimed at fixing the non-standard ColdFire
> > set of readX()/writeX() IO access functions. Instead switching to using the
> > asm-generic definitions in include/asm-generic/io.h. The difficulty comes
> > in trying not to break any drivers with this change.
> >
> > The implementation of the readX()/writeX() family of IO access functions
> > is non-standard on ColdFire platforms. They either return big-endian (that
> > is native endian) data, or on platforms with PCI bus support check the
> > supplied address and return either big or little endian data based on that
> > check. This is non-standard, they are expected to always return
> > little-endian byte ordered data. Unfortunately this behavior also means
> > that ioreadX()/iowroteX() and their big-endian counter parts
> > ioreadXbe()/iowriteXbe() are currently broken because they are implemented
> > using the readX()/writeX() functions.
> >
> > Patches 1, 2 and 3 in this series are specific driver changes that can be
> > made independently of the final ColdFire readX()/writeX() change.
> >
> > Patch 4 is the actual switch to ColdFire building using asm-generic
> > readX()/writeX(), but also contains three driver fixes that are not easily
> > handled independently.
> >
> > Note that I don't have access to all supported hardware needed to fully
> > test all these changes. I have tested what I have, a bunch of the standard
> > Freescale ColdFire eval boards, and inspected generated code for differences.
> >
> > Note also that patch 3 relies on changes that are currently only in
> > linux-next, and are scheduled to hit mainline during the next v7.2
> > merge window. Those changes are also available in an immutable git tree
> > at git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git
> > cf-internal-io branch.
>
> I understand that with this series you are targeting the m68K tree, am I
> correct?

All the changes are targeted at fixing an m68k issue, yes.


> A possibly better option would be, after that the pre-req patches land
> into Linus's tree, to share an immutable branch for this series, so that
> both m68k and net-next could pull it.

I can certainly do that. All pre-requisite changes are now in Linus' tree.
My preference would be for subsystem maintainers to pick up their respective
changes (so patches 1, 2 and 3). I expect I will push patch 4 via the m68knommu
git tree, with appropriate sign offs from affected subsystems.

Regards
Greg