m68k v3.16 status update

[Geert Uytterhoeven]

m68k v3.16 is out!
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git

m68k-queue is getting smaller, but there are still a few commits left:

$ git cherry -v for-3.17 m68k-queue v3.16
- 7e87ff970f7116e46025f226b5aa47bd19e1229b zorro: Use ARRAY_SIZE
- 8e1bf8df8b6db30f2e78c029d488e5482b7d28d4 m68k/sun3: Remove define
statement no longer needed
+ 82560cb180860d93f5b83ac3e4048f53a1989b2d m68k/atari: EtherNAT -
ethernet support (smc91x)
+ 224ce049f71577d6ec380aeb94a4d25c3c4016a7 m68k/atari: EtherNEC -
ethernet support (ne)
+ db69080d04f14fbbd1021ac80916f8889beedab6 m68k/defconfig: Enable
Atari EtherNAT and EtherNEC Ethernet support
+ 87704cc39f16315f64c73afa19631a224322504c m68k/atari: USB - add
ISP1160 USB host controller support
+ 10b42d48867deea3c9b3ec0286e1377fe50ce616 m68k/defconfig: Enable
Atari EtherNAT and NetUSBee USB support
+ 88875720f0391465e2116defd7e050b31083734f fs/fat: Revert "msdos fs:
remove unsettable atari option"
+ 258a402647910eed4081cc23e62e4482467e1d68 fs/fat: Atari FAT updates
+ 84f65eef567df9a147073bcc240f8821af966cef fs/fat: Use correct logical
sector size for Atari GEMDOS FAT

The first two will be in v3.17.

The defconfig commits are blocked on functionality commits above them.

That leaves us with:
- Atari EtherNAT: Should be fairly easy to get in. Is the current driver still
working? If yes, I'm willing to send the patch to netdev myself.
- Atari EtherNEC: idem ditto.
- Atari ISP1160: I'm afraid this one needs a bit more care.
- Atari FAT: No comments ;-)

May I remind you that patches touching areas outside arch/m68k must be
submitted to the appropriate maintainer (use scripts/get_maintainer.pl).

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ***@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[Ingo Jürgensmann]

Post by Geert Uytterhoeven
m68k v3.16 is out!
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git

Hmm, what about the Blizzard 2060 SCSI driver from Michael & Tuomas? It runs since then on Akire...

[John Paul Adrian Glaubitz]

=20

Post by Geert Uytterhoeven
m68k v3.16 is out!
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
m68k-queue is getting smaller, but there are still a few commits le=

=20
Hmm, what about the Blizzard 2060 SCSI driver from Michael & Tuomas? =

It runs since then on Akire...=20

Add to that the X-Surf100 driver that Michael Karcher wrote [1] but
unfortunately he hasn't cleaned up the code yet and submitted it for
inclusion in the mainline kernel.

I'll put Michael in the CC to try to ping him again :).

Cheers,
Adrian

[1] git://z6.physik.fu-berlin.de/xsurf100.git

--=20
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

[Geert Uytterhoeven]

On Tue, Aug 5, 2014 at 10:29 PM, John Paul Adrian Glaubitz

On Tue, Aug 05, 2014 at 09:52:58PM +0200, Ingo J=C3=BCrgensmann wrote=

Post by Geert Uytterhoeven
m68k v3.16 is out!
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
m68k-queue is getting smaller, but there are still a few commits l=

Hmm, what about the Blizzard 2060 SCSI driver from Michael & Tuomas?=

It runs since then on Akire...

Add to that the X-Surf100 driver that Michael Karcher wrote [1] but
unfortunately he hasn't cleaned up the code yet and submitted it for
inclusion in the mainline kernel.

"May I remind you that patches touching areas outside arch/m68k must be
submitted to the appropriate maintainer (use scripts/get_maintainer.pl)=
=2E"

The current policy is to not add drivers to the m68k repository if they=
should
go in through other maintainers.

The Atari ROM Port ISA-based EtherNEC, EtherNAT, and NetUSBee drivers
are there because the Atari ROM Port ISA support originated in the old
Linux/m68k CVS repository.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ***@linux-=
m68k.org

In personal conversations with technical people, I call myself a hacker=
=2E But
when I'm talking to journalists I just say "programmer" or something li=
ke that.
-- Linus Torvalds

[John Paul Adrian Glaubitz]

Post by Geert Uytterhoeven

Post by John Paul Adrian Glaubitz
Add to that the X-Surf100 driver that Michael Karcher wrote [1] but
unfortunately he hasn't cleaned up the code yet and submitted it for
inclusion in the mainline kernel.

"May I remind you that patches touching areas outside arch/m68k must be
submitted to the appropriate maintainer (use scripts/get_maintainer.pl)."
The current policy is to not add drivers to the m68k repository if they should
go in through other maintainers.

I know, I was not implying that, sorry :). I am just still waiting for
the xsurf100 driver to be included in the mainline kernel.

Adrian

[Michael Schmitz]

Hi Ingo,

Post by Ingo Jürgensmann

Post by Geert Uytterhoeven
m68k v3.16 is out!
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git

Hmm, what about the Blizzard 2060 SCSI driver from Michael & Tuomas? It runs since then on Akire...

So it still runs OK - good to know.

I understand Geert's reply to Adrian to please take this patch through
the SCSI maintainer, not m68k. Fair enough. We'll leave it as 2060 only
driver for now and add other boards later.

Cheers,

Michael

[Tuomas Vainikka]

Post by Michael Schmitz
Hi Ingo,

Am 05.08.2014 um 21:40 schrieb Geert Uytterhoeven

Post by Geert Uytterhoeven
m68k v3.16 is out!
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git

Hmm, what about the Blizzard 2060 SCSI driver from Michael & Tuomas?
It runs since then on Akire...

So it still runs OK - good to know.
I understand Geert's reply to Adrian to please take this patch through
the SCSI maintainer, not m68k. Fair enough. We'll leave it as 2060
only driver for now and add other boards later.

I tested it on a Blizzard 1260 with the SCSI-expansion, so it actually
supports two setups; [blz1230-IV, blz1240/60] + SCSI-kit, and blz2040/60.

-Tuomas

[Michael Schmitz]

Hi Geert,

Post by Geert Uytterhoeven
m68k v3.16 is out!
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
$ git cherry -v for-3.17 m68k-queue v3.16
- 7e87ff970f7116e46025f226b5aa47bd19e1229b zorro: Use ARRAY_SIZE
- 8e1bf8df8b6db30f2e78c029d488e5482b7d28d4 m68k/sun3: Remove define
statement no longer needed
+ 82560cb180860d93f5b83ac3e4048f53a1989b2d m68k/atari: EtherNAT -
ethernet support (smc91x)
+ 224ce049f71577d6ec380aeb94a4d25c3c4016a7 m68k/atari: EtherNEC -
ethernet support (ne)
+ db69080d04f14fbbd1021ac80916f8889beedab6 m68k/defconfig: Enable
Atari EtherNAT and EtherNEC Ethernet support
+ 87704cc39f16315f64c73afa19631a224322504c m68k/atari: USB - add
ISP1160 USB host controller support
+ 10b42d48867deea3c9b3ec0286e1377fe50ce616 m68k/defconfig: Enable
Atari EtherNAT and NetUSBee USB support
remove unsettable atari option"
+ 258a402647910eed4081cc23e62e4482467e1d68 fs/fat: Atari FAT updates
+ 84f65eef567df9a147073bcc240f8821af966cef fs/fat: Use correct logical
sector size for Atari GEMDOS FAT
The first two will be in v3.17.
The defconfig commits are blocked on functionality commits above them.
- Atari EtherNAT: Should be fairly easy to get in. Is the current driver still
working? If yes, I'm willing to send the patch to netdev myself.

Last time I had a chance to try this on a non-broken EtherNAT, it was
fine (two years ago IIRC). Need to ask Christian again to test the
current one. There was one change you suggested after that time
(dropping a dodgy cast was part of it) - that bit got never tested. It
should work from what we discussed, but that's not a strong enough
argument.

I'll leave it up to you to decide whether this is fit to submit.

Post by Geert Uytterhoeven
- Atari EtherNEC: idem ditto.

That one's fine. Paul had objections to the way I handled the shared
interrupt and polling issue but that has been resolved a while ago.

Time for me to resubmit that one.

Post by Geert Uytterhoeven
- Atari ISP1160: I'm afraid this one needs a bit more care.

Agreed - it works but there has to be a cleaner way to do this. I need
to sit down and understand how it is that the current code works. (Last
time I tried, the USB chip still worked on my EtherNAT so I can keep
handling this.)

Post by Geert Uytterhoeven
- Atari FAT: No comments ;-)

I have a hard time remembering what these were about. Setting the
'atari' option to either no or yes makes no difference, the mount works
either way on my GEMDOS partition. The other two I suspect are needed
(can be merged into one, anyway). I'll try to drop them and see where
that leaves me.

I don't think I still have the test disk image I got from Petr to test
these patches on. The patches were needed in 2009 so probably are still
needed now. What were the objections from the FAT maintainers here?

Post by Geert Uytterhoeven
May I remind you that patches touching areas outside arch/m68k must be
submitted to the appropriate maintainer (use scripts/get_maintainer.pl).

There's still the Amiga Zorro ESP patch out in limbo - DaveM suggested a
change to enable SCSI-2 features to help with extended message bytes but
that did not work as intended. Haven't had time to follow that one up.
Tuomas' fix to the driver to bypass DMA for message in works OK though -
do you want it submitted back to linux-scsi as is, or wait for a perfect
solution (pun on me ...)?

Support for more Amiga ESP cards needs to be added (got dropped in
overlapping edits between Tuomas and me, better to make a clean break
there). More testers needed at any rate.
Conclusion - I see good chances on the EtherNEC one, ditto on the
EtherNAT if we can get it tested. Need to go back and check the FAT
stuff but would suspect it is still needed - if no one but me needs this
it could keep living in my local tree though.

Leaves USB to clean up, and SCSI stuff (which is what I have mostly been
working on (Atari), if any).

Not much help, I know. I need a clone or two.

Cheers,

Michael

Post by Geert Uytterhoeven
Thanks!
Gr{oetje,eeting}s,
Geert
--
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Christian T. Steigies]

Post by Michael Schmitz
Last time I had a chance to try this on a non-broken EtherNAT, it
was fine (two years ago IIRC). Need to ask Christian again to test
the current one.

Ask me again when the summer is over. Last I tried I had troubles to power
on the Falcon. Plus I had problems transfering the booting image from the
IDE-CF card to a real-harddisk so that I could actually use the Falcon
again. When it is getting cooler, I may want to sit in the attic again and
should find some time for playing with the Falcon (and the Blizzard2060).

Christian

[Michael Schmitz]

Hi Christian,

Post by Christian T. Steigies

Post by Michael Schmitz
Last time I had a chance to try this on a non-broken EtherNAT, it
was fine (two years ago IIRC). Need to ask Christian again to test
the current one.

Ask me again when the summer is over. Last I tried I had troubles to power
on the Falcon. Plus I had problems transfering the booting image from the
IDE-CF card to a real-harddisk so that I could actually use the Falcon
again. When it is getting cooler, I may want to sit in the attic again and
should find some time for playing with the Falcon (and the Blizzard2060).

I'll do that - right now it's a bit cool in my basement so I try to
avoid anything that needs access to the hardware reset button :-) Though
a Raspberry Pi digital I/O board should be suitable to remote control
even that :-)

I need to get a IDE-CF card pretty soon now, too. I'll send a detailed
description on how to transfer the image over (probably using ARAnyM)
when I've figured it out.

Enjoy your summer,

Cheers,

Michael

[Tuomas Vainikka]

Post by Michael Schmitz
There's still the Amiga Zorro ESP patch out in limbo - DaveM suggested
a change to enable SCSI-2 features to help with extended message bytes
but that did not work as intended. Haven't had time to follow that one
up. Tuomas' fix to the driver to bypass DMA for message in works OK
though - do you want it submitted back to linux-scsi as is, or wait
for a perfect solution (pun on me ...)?
Support for more Amiga ESP cards needs to be added (got dropped in
overlapping edits between Tuomas and me, better to make a clean break
there). More testers needed at any rate.
Conclusion - I see good chances on the EtherNEC one, ditto on the
EtherNAT if we can get it tested. Need to go back and check the FAT
stuff but would suspect it is still needed - if no one but me needs
this it could keep living in my local tree though.

Just to refresh your memory, the final fix was not to bypass DMA at any
level (I did that for the command transfer, but that didn't help), but
to have a dedicated slave_configure() function in the Amiga Zorro ESP
driver that would not enable TCQ.

-Tuomas

[Michael Schmitz]

Hi Tuomas,

Post by Tuomas Vainikka

Post by Michael Schmitz
There's still the Amiga Zorro ESP patch out in limbo - DaveM
suggested a change to enable SCSI-2 features to help with extended
message bytes but that did not work as intended. Haven't had time to
follow that one up. Tuomas' fix to the driver to bypass DMA for
message in works OK though - do you want it submitted back to
linux-scsi as is, or wait for a perfect solution (pun on me ...)?

Just to refresh your memory, the final fix was not to bypass DMA at
any level (I did that for the command transfer, but that didn't help),
but to have a dedicated slave_configure() function in the Amiga Zorro
ESP driver that would not enable TCQ.

You guessed right about memory failing me - it wasn't about DMA in the
end (for some reason, I seem to have DMA stuck in my mind at the
moment), Do you see any other avenues to try and enable tagged commands
in the ESP chip? We tried one config register only so far...

Cheers,

Michael

[Tuomas Vainikka]

Post by Michael Schmitz
Hi Tuomas,

Post by Tuomas Vainikka

Post by Michael Schmitz
There's still the Amiga Zorro ESP patch out in limbo - DaveM
suggested a change to enable SCSI-2 features to help with extended
message bytes but that did not work as intended. Haven't had time to
follow that one up. Tuomas' fix to the driver to bypass DMA for
message in works OK though - do you want it submitted back to
linux-scsi as is, or wait for a perfect solution (pun on me ...)?

Just to refresh your memory, the final fix was not to bypass DMA at
any level (I did that for the command transfer, but that didn't
help), but to have a dedicated slave_configure() function in the
Amiga Zorro ESP driver that would not enable TCQ.

You guessed right about memory failing me - it wasn't about DMA in the
end (for some reason, I seem to have DMA stuck in my mind at the
moment), Do you see any other avenues to try and enable tagged
commands in the ESP chip? We tried one config register only so far...

I think I've tested almost all possible register settings for the chip,
but it occurred to me that it is not enough to enable some chip features
by flipping bits. The code in esp_scsi would need to be modified to
handle the behaviour of these enabled features also.

So, rethinking the code in esp_scsi would be one option.

The second possibility is that I have a buggy chip in my setup. Removing
a sticker from my SCSI-board revealed the chip to be an AMD AM53CF94.
There are different versions of the SCSI-boards out there with different
chips; NCR, AMD, and QLogic, so if we had more people testing the driver
we would find out if the chip is actually the problem. (Is anyone even
testing the ISA/PCI cards that use esp_scsi?)

Those are my suggestions at the TCQ problem.

But do we really need TCQ?

-Tuomas

[Michael Schmitz]

Tuomas,

Post by Tuomas Vainikka

Post by Michael Schmitz
You guessed right about memory failing me - it wasn't about DMA in
the end (for some reason, I seem to have DMA stuck in my mind at the
moment), Do you see any other avenues to try and enable tagged
commands in the ESP chip? We tried one config register only so far...

I think I've tested almost all possible register settings for the
chip, but it occurred to me that it is not enough to enable some chip
features by flipping bits. The code in esp_scsi would need to be
modified to handle the behaviour of these enabled features also.
So, rethinking the code in esp_scsi would be one option.

Other versions of ESP SCSI cards do appear to handle TCQ correctly with
the default configuration of the chip, i.e. pass on the additional
message bytes without any problem. From that I'd guess reading the tag
message works OK in the current esp_scsi code. Other features (target
mode) we are not really interested in, and without a second initiator on
the bus, nothing should ever try to select our ESP host. What else is
there to look out for?

Post by Tuomas Vainikka
The second possibility is that I have a buggy chip in my setup.
Removing a sticker from my SCSI-board revealed the chip to be an AMD
AM53CF94.
There are different versions of the SCSI-boards out there with
different chips; NCR, AMD, and QLogic, so if we had more people
testing the driver we would find out if the chip is actually the
problem. (Is anyone even testing the ISA/PCI cards that use esp_scsi?)

Some Macs/PowerMacs use esp_scsi IIRC - I suspect we would have heard if
the driver was broken altogether.

Post by Tuomas Vainikka
Those are my suggestions at the TCQ problem.
But do we really need TCQ?

Maybe not - if no one's missed the feature in the original Amiga ESP
drivers, we probably shouldn't worry.

Cheers,

Michael

[Michael Schmitz]

Hi Geert,

Post by Michael Schmitz

Post by Geert Uytterhoeven
- Atari EtherNAT: Should be fairly easy to get in. Is the current driver still
working? If yes, I'm willing to send the patch to netdev myself.

Last time I had a chance to try this on a non-broken EtherNAT, it was
fine (two years ago IIRC). Need to ask Christian again to test the
current one. There was one change you suggested after that time
(dropping a dodgy cast was part of it) - that bit got never tested. It
should work from what we discussed, but that's not a strong enough
argument.

I should clarify - the current code does detect the SMC chip OK, it just
doesn't receive any MII interrupts on my card. I probably fried my MII
interface. I am quite confident it will still work on a fully functional
EtherNAT.

Cheers,

Michael