Miro,
Hi Michael,
On Mon, 25 Mar 2013 at 11:36, Michael Schmitz <schmitzmic@gmail.com> wrote:Add Atari specific support code for isp116x-hcd driver used by EtherNAT
and NetUSBee adapters. Both use a 16-bit data bus wiring that is byte-swapped
in hardware. The EtherNAT adapter also has quirks relating to interrupts
and needs interrupts disabled until after the chip has been reset.
Debugging of FIFO register access code and NetUSBee support by David Galvez
<dgalvez75@gmail.com> (MiNT driver author).
Signed-off-by: Michael Schmitz <schmitz@debian.org>
Sorry to necro-bump this email thread but this specific commit is quite interesting. As far as I understand it, this patch was proposed and merged on top of Geert's m68k-queue branch. However five hours later there was another set of patches meant for upstream/debian merge: https://lore.kernel.org/linux-m68k/1364193464-3890-1-git-send-email-schmitz@debian.org (interestingly, it wasn't CC'ed to debian-m68k) where you explicitly asked (https://lore.kernel.org/linux-m68k/5152996E.50800@gmail.com) to skip https://lore.kernel.org/linux-m68k/1364193464-3890-3-git-send-email-schmitz@debian.org and https://lore.kernel.org/linux-m68k/1364193464-3890-12-git-send-email-schmitz@debian.org (this one) patches.
"I don't mind for it to live in m68k-queue for a while" ... so, 13 years later ;), what prevents merging NetUSBee support upstream?
The register access logic was far too hacky for my taste (and I'm sure, Geert's). Unless a way can be found to handle the endianness issues and required byte swapping transparently, this patch just isn't up to the expected standards.
I never tried to submit these patches to linux-usb but I had interactions with the netdev and scsi maintainers, and despite my best efforts, some patches that were a lot cleaner than this one never got accepted.
These days, my EtherNAT board is broken (PHY dead as far as I can tell, never generates an interrupt when probing for carrier), and the CT60 boots up with broken video mode, so I even if I could improve on this patch, I can't test the USB code anymore. Haven't had much time for kernel hacking either recently.
Anyone with access to the hardware and an inclination to get their hands dirty is welcome to take over these patches and have a little fun with the code review!
Cheers,
Michael