Michael, William,
On Sun, 13 Aug 2023, Michael Schmitz wrote:
Am 28.07.23 um 11:47 schrieb Finn Thain:
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.
Haven't seen anything yet, so I've just sent a patch switching
pata_falcon.c to use the IO resources instead of the memory resources.
Thanks for sending that.
Survived compile and ARAnyM boot tests only so far. I've checked and
confirmed the entire 0xffxxxxx range is mapped transparent in head.S for
Q40 so I don't see what else might be missing.
In the message that Geert originally forwarded, William was quoted as
saying it was necessary to "fix up the pata_falcon_data_xfer function". He
also said that using the IO port resources "causes the ioread8/iowrite8
functions to complain loudly".
https://lore.kernel.org/linux-m68k/CAMuHMdUU62jjunJh9cqSqHT87B0H0A4udOOPs=WN7WZKpcagVA@xxxxxxxxxxxxxx/
I think your patch is taking the same approach and may run into the same
issues... I guess we shall see when William tests it.
Please have a look and test if possible. Haven't yet bothered
linux-block or linux-ide... the patch still needs a Fixes: and other
trimmings so isn't ready for submission anyway.
Right. You'll want to run checkpatch.pl on it at some stage.
