Re: [PATCH 14/14] m68k/atari: USB - Add ISP1160 USB host controller support
Michael Schmitz <[email protected]> Sat, 18 Jul 2026 02:35:22 +1200
| Newsgroups | gmane.linux.debian.ports.68k,gmane.linux.ports.m68k |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------Hc12U707DTEz7eJLf0VllPe3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Miro, On 18/07/2026 1:49 AM, Miro Kropáček wrote: > Hi Michael, > > On Mon, 25 Mar 2013 at 11:36, Michael Schmitz <[email protected]> > 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 > <[email protected]> (MiNT driver author). > > Signed-off-by: Michael Schmitz <[email protected]> > > 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/[email protected] > (interestingly, it wasn't CC'ed to debian-m68k) where you explicitly > asked (https://lore.kernel.org/linux-m68k/[email protected]) to > skip > https://lore.kernel.org/linux-m68k/[email protected] > and > https://lore.kernel.org/linux-m68k/[email protected] > (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 > > -- > http://mikro.atari.org --------------Hc12U707DTEz7eJLf0VllPe3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p>Miro,</p> <div class="moz-cite-prefix">On 18/07/2026 1:49 AM, Miro Kropáček wrote:<br> </div> <blockquote type="cite" cite="mid:CAN5rfbQMfUDDu6jUJaR=u0o-_SeVGA+6FQ-SwBShtq3rN3APCQ@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div dir="ltr"> <div><span style="background-color:transparent">Hi Michael,</span></div> <div><span style="background-color:transparent"><br> </span></div> <div dir="ltr"><span style="background-color:transparent">On Mon, 25 Mar 2013 at 11:36, Michael Schmitz <<a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> wrote:</span></div> <div class="gmail_quote gmail_quote_container"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Add Atari specific support code for isp116x-hcd driver used by EtherNAT<br> and NetUSBee adapters. Both use a 16-bit data bus wiring that is byte-swapped<br> in hardware. The EtherNAT adapter also has quirks relating to interrupts<br> and needs interrupts disabled until after the chip has been reset.<br> <br> Debugging of FIFO register access code and NetUSBee support by David Galvez<br> <<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> (MiNT driver author).<br> <br> Signed-off-by: Michael Schmitz <<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>><br> </blockquote> <div>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: <a href="https://lore.kernel.org/linux-m68k/[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">https://lore.kernel.org/linux-m68k/[email protected]</a> (interestingly, it wasn't CC'ed to debian-m68k) where you explicitly asked (<a href="https://lore.kernel.org/linux-m68k/[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">https://lore.kernel.org/linux-m68k/[email protected]</a>) to skip <a href="https://lore.kernel.org/linux-m68k/[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">https://lore.kernel.org/linux-m68k/[email protected]</a> and <a href="https://lore.kernel.org/linux-m68k/[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">https://lore.kernel.org/linux-m68k/[email protected]</a> (this one) patches.</div> <div><br> </div> <div>"I don't mind for it to live in m68k-queue for a while" ... s<span style="background-color:transparent">o, 13 years later ;), what prevents merging NetUSBee support upstream?</span></div> </div> </div> </blockquote> <p>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. </p> <p>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.</p> <p>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.</p> <p>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!</p> <p>Cheers,</p> <p> Michael</p> <p><br> </p> <blockquote type="cite" cite="mid:CAN5rfbQMfUDDu6jUJaR=u0o-_SeVGA+6FQ-SwBShtq3rN3APCQ@mail.gmail.com"> <div dir="ltr"> <div><br> </div> <span class="gmail_signature_prefix">-- </span><br> <div dir="ltr" class="gmail_signature"> <div dir="ltr"> <div><a href="http://mikro.atari.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">http://mikro.atari.org</a></div> </div> </div> </div> </blockquote> </body> </html> --------------Hc12U707DTEz7eJLf0VllPe3--