Amiga PCMCIA 100 MBit card support
Subsystems (3)
PATCH 1/1 Amiga PCMCIA 100 MBit card support
This adds an option to change the (10 MBit only) "apne" driver to support the 10/100 Mbit cards (e.g. Netgear FA411, CNet Singlepoint) instead.
A new configure option is added as a bool to the apne driver to change the behaviour to support some new cards instead.
The option can be only enabled if no other 8390 driver is active because the 8390 library is modified when activated.
The patch is initially from http://www.g-mb.de/pcmcia_e.html and adapted by me from the 2.6 version.
The contained reset fix is required to use a pcmcia card after a reset/reboot, and is also only activated with new option. (Background, as far as I understood it: The pcmcia reset line is not connected and after a reset/reboot the pcmcia card is in an undefined state and needs a manual reset.) This reset patch is probably useful to all Amiga pcmcia drivers (network and other) but since I do not own any other card I can't verify that.
drivers/net/ethernet/8390/8390.h +17 -0
@@ -222,4 +222,21 @@ struct ei_device {#define ENTSR_CDH 0x40/* The collision detect "heartbeat" signal was lost. */ #define ENTSR_OWC 0x80/* There was an out-of-window collision. */ +/* Change the driver to support word access instead of byte access. +* Cards that work with byte access will not work with word access. +*/ +#ifdef CONFIG_APNE100MBIT +/* redefine inb to do word accesses */ +#undef inb +#define inb (x) ((x) & 1 ? inw((x) - 1) & 0xff : inw(x) >> 8) +#undef inb_p +#define inb_p (x) inb(x) + +/* The following redefinition of outb isn't necessary, but may be faster on +* slow processors. +*/ +#undef outb +#define outb (x, y) raw_outb(x, (y) + GAYLE_IO + (((y) & 1) ? GAYLE_ODD : 0)) +#endif +#endif /* _8390_h */
Only in linux-4.18.7-patched/drivers/net/ethernet/8390/: 8390.h.orig
drivers/net/ethernet/8390/Kconfig +16 -0
@@ -142,6 +142,22 @@ config APNE To compile this driver as a module, choose M here: the module will be called apne. +if APNE +config APNE100MBIT + bool "PCMCIA NE2000 100MBit support" + default n + depends on ARM_ETHERH=n && AX88796=n && HYDRA=n && MAC8390=n + depends on MCF8390=n && NE2000=n && NE2K_PCI=n && PCMCIA_AXNET=n + depends on PCMCIA_PCNET=n && STNIC=n && ULTRA=n && WD80x3=n + depends on XSURF100=n && ZORRO8390=n + ---help--- + This changes the driver to support ONLY 10/100Mbit cards (e.g. Netgear + FA411, CNet Singlepoint). + Cards that worked with the original version won't with this version. + + Say N, unless you absolutely know what you are doing. +endif + config PCMCIA_PCNET tristate "NE2000 compatible PCMCIA support" depends on PCMCIA
drivers/net/ethernet/8390/apne.c +10 -0
@@ -590,6 +590,16 @@ static int init_pcmcia(void)#endif u_long offset; +#ifdef CONFIG_APNE100MBIT +/* reset card (idea taken from CardReset by Artur Pogoda) */ + { +u_char tmp = gayle.intreq; + + gayle.intreq =0xff ;mdelay (1 ); + gayle.intreq = tmp;mdelay (300 ); + } +#endif +pcmcia_reset ();pcmcia_program_voltage (PCMCIA_0V );pcmcia_access_speed (PCMCIA_SPEED_250NS );
David Miller
maintainerFrom: ALeX Kazik <[email protected]>
Date: Wed, 19 Dec 2018 23:24:32 +0100
drivers/net/ethernet/8390/Kconfig config APNE · line 153
Quoted 7 lines
drivers/net/ethernet/8390/Kconfig +7
-0+ bool "PCMCIA NE2000 100MBit support" + default n + depends on ARM_ETHERH=n && AX88796=n && HYDRA=n && MAC8390=n + depends on MCF8390=n && NE2000=n && NE2K_PCI=n && PCMCIA_AXNET=n + depends on PCMCIA_PCNET=n && STNIC=n && ULTRA=n && WD80x3=n + depends on XSURF100=n && ZORRO8390=n + ---help---
Generally I'm not too happy with these changes, they are all very hackish.
And in particular this huge complicated Kconfig construct is not maintainable at all.
Sorry.
Dave,
Am 21.12.2018 um 13:10 schrieb David Miller:
Quoted 12 lines
From: ALeX Kazik <[email protected]>
Date: Wed, 19 Dec 2018 23:24:32 +0100drivers/net/ethernet/8390/Kconfig config APNE · line 153
Quoted 7 lines
drivers/net/ethernet/8390/Kconfig +7
-0+ bool "PCMCIA NE2000 100MBit support" + default n + depends on ARM_ETHERH=n && AX88796=n && HYDRA=n && MAC8390=n + depends on MCF8390=n && NE2000=n && NE2K_PCI=n && PCMCIA_AXNET=n + depends on PCMCIA_PCNET=n && STNIC=n && ULTRA=n && WD80x3=n + depends on XSURF100=n && ZORRO8390=n + ---help---Generally I'm not too happy with these changes, they are all very hackish.
I see only one option to address that: rewrite apne.c to include lib8390.c directly.
Moving the inb() and outb() redefines into the m68k version of io.h (which Geert is likely to veto because of its hackishness) would still require a Kconfig hack.
Quoted 2 lines
And in particular this huge complicated
Kconfigconstruct is not maintainable at all.
We can trim this down a bit (for reasons I've outlined before):
+if APNE
+config APNE100MBIT
+ bool "PCMCIA NE2000 100MBit support"
+ default n
+ depends on NE2000=n && PCMCIA_AXNET=n
+ depends on PCMCIA_PCNET=n && STNIC=n && ULTRA=n && WD80x3=n
In all honesty, I doubt anyone could ever use the stnic, ultra and wd drivers on m68k (Geert?) so these could be omitted as well. Not sure pcnet_cs or axnet_cs are possible to use on the Amiga PCMCIA slot, so all that remains in practice is the ne driver (which is used on Atari).
Still too ugly?
Cheers,
Michael
Quoted 3 lines
Sorry.
David Miller
maintainerFrom: Michael Schmitz <[email protected]>
Date: Sat, 22 Dec 2018 10:30:58 +1300
Quoted 13 lines
Am 21.12.2018 um 13:10 schrieb David Miller:
Quoted 2 lines
And in particular this huge complicated
Kconfigconstruct is not maintainable at all.We can trim this down a bit (for reasons I've outlined before):
drivers/net/ethernet/8390/Kconfig +6
-0+if APNE +config APNE100MBIT + bool "PCMCIA NE2000 100MBit support" + default n + depends on NE2000=n && PCMCIA_AXNET=n + depends on PCMCIA_PCNET=n && STNIC=n && ULTRA=n && WD80x3=n
Quoted 7 lines
In all honesty, I doubt anyone could ever use the stnic, ultra and wd drivers on m68k (Geert?) so these could be omitted as well. Not sure
pcnet_csoraxnet_csare possible to use on the Amiga PCMCIA slot, so all that remains in practice is the ne driver (which is used on Atari).Still too ugly?
I'm sorry, maybe I didn't express my concern clearly.
Any sizable list of exceptions in a Kconfig conditional has long term maintainence costs. If, for some reason, a new variant of support for this chip arrives there will be a new Kconfig setting that would need to be added here to your expressions.
That is insanely error prone, and I can guarantee it will get missed.
Having so many front end drivers for a chipset should be done in a more modular manner, so that in fact they could all coexist if necessary.
Hi Dave,
Am 29.12.2018 um 09:43 schrieb David Miller:
Quoted 16 lines
From: Michael Schmitz <[email protected]>
Date: Sat, 22 Dec 2018 10:30:58 +1300Quoted 13 lines
Am 21.12.2018 um 13:10 schrieb David Miller:
Quoted 2 lines
And in particular this huge complicated
Kconfigconstruct is not maintainable at all.We can trim this down a bit (for reasons I've outlined before):
drivers/net/ethernet/8390/Kconfig +6
-0+if APNE +config APNE100MBIT + bool "PCMCIA NE2000 100MBit support" + default n + depends on NE2000=n && PCMCIA_AXNET=n + depends on PCMCIA_PCNET=n && STNIC=n && ULTRA=n && WD80x3=n
Quoted 5 lines
Quoted 5 lines
In all honesty, I doubt anyone could ever use the stnic, ultra and wd drivers on m68k (Geert?) so these could be omitted as well. Not sure
pcnet_csoraxnet_csare possible to use on the Amiga PCMCIA slot, so all that remains in practice is the ne driver (which is used on Atari).
STNIC can indeed be dropped from the list of exceptions, but I forgot about ISA support on Q40.
Quoted 4 lines
Quoted 2 lines
Still too ugly?
I'm sorry, maybe I didn't express my concern clearly.
I understood your concerns - my hope was that the exception list might be possible to trim right down to a single driver. Alas, that's not the case.
Quoted 10 lines
Any sizable list of exceptions in a
Kconfigconditional has long term maintainence costs. If, for some reason, a new variant of support for this chip arrives there will be a newKconfigsetting that would need to be added here to your expressions.That is insanely error prone, and I can guarantee it will get missed.
Having so many front end drivers for a chipset should be done in a more modular manner, so that in fact they could all coexist if necessary.
Not sure I follow your meaning ... are you suggesting to allow the back end driver to use run-time selectable IO accessors and other generic helper functions, so the drivers currenlty including lib8390.c directly could use the core code from the 8390 module instead?
Cheers,
Michael
Quoted 8 lines
Quoted 3 lines
Having so many front end drivers for a chipset should be done in a more modular manner, so that in fact they could all coexist if necessary.
Not sure I follow your meaning ... are you suggesting to allow the back end driver to use run-time selectable IO accessors and other generic helper functions, so the drivers currenlty including
lib8390.cdirectly could use the core code from the 8390 module instead?
Yes, David is suggesting you abstract the code so it can be built once to support all the different interfaces and architectures.
Andrew
Hi Andrew,
Quoted 9 lines · Andrew Lunn
Quoted 7 lines
Quoted 3 lines
Having so many front end drivers for a chipset should be done in a more modular manner, so that in fact they could all coexist if necessary.
Not sure I follow your meaning ... are you suggesting to allow the back end driver to use run-time selectable IO accessors and other generic helper functions, so the drivers currenlty including
lib8390.cdirectly could use the core code from the 8390 module instead?Yes, David is suggesting you abstract the code so it can be built once to support all the different interfaces and architectures.
Thanks for clarifying - I'll see what I can come up with.
I can only test on ne.c and xsurf100.c though.
Cheers,
Michael
Quoted 1 line
Andrew