Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time

Finn Thain
2023-07-27T23:47:36Z

On Thu, 27 Jul 2023, Michael Schmitz wrote:

> >
> >> And yes, I'm painfully aware the m68k low level IO code is becoming a
> >> bit of a maintainance legacy, in no small part due to my hacks around
> >> Atari EtherNEC.
> >>
> >
> > I guess you and I both can share the blame for 44b1fbc0f5f30e66...
> >
> > Anyway, you make a good point about on-going maintenance. Do you think
> > that by supporting standard ISA drivers we might actually reduce the
> > ideosyncracies in m68k IO code?
>
> You and DaveM ought to have a chat about that - abstracting the legacy
> drivers from the ISA constraints was his preferred option when I last
> attempted to get the Gayle network driver patches merged. When I say
> 'preferred', I'm probably understating a little.
>

A discussion with maintainers probably won't get far without working code
to look at. Perhaps William will send an RFC patch to illustrate his
approach.

> I had toyed with that using the EtherNEC driver as test case but never
> got very far (this would have been splitting the driver into a core
> lib8390 module and a platform-specific module that allows to hook a
> variety of IO accessors as hooks, not static defines, and I wasn't too
> certain about performance impacts of such a change, the performance of
> the EtherNEC being so shitty it won't make any impact there),
>
> The only other option (that I can see) would be creating a bus driver
> for the ISA bus, with platforms allowed to register their particular IO
> accessors for IO and memory accesses - again, performance impacts to
> consider and getting test coverage on legacy ISA hardware a nightmare.
> This would allow to use legacy driver code more or less unchanged.
> Haven't given that much thought at all (the idea pretty much originated
> from this present mess, but that's all).
>
> There may be other approaches that can be considered, if none of this is
> what you had in mind.
>

What I had in mind is probably unacceptable because drivers end up having
to do byteswapping as happens in pata_falcon (or falconide and q40ide).
Perhaps your bus driver idea would probabably find more acceptance. OTOH
if the aim of the exercise is to use standard drivers (like pata_legacy)
there would probably be driver changes either way.

It might be helpful to look for some precedent for this kind of thing
among the other big-endian platforms with ISA. MIPS Magnum is dual-endian
but Linux only runs in little-endian mode and the problem doesn't arise.
But there must be other examples. Maybe CHRP?