Message-ID: <CAK8P3a1ytpYNNGkoJJGXf669TxOuzC9_Txn7c593YCCL=ATJ0Q@mail.gmail.com>
Date:   Sun, 16 May 2021 11:27:09 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Networking <netdev@...r.kernel.org>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Doug Berger <opendmb@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Sam Creasey <sammy@...my.net>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Finn Thain <fthain@...egraphics.com.au>,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        Andrew Lunn <andrew@...n.ch>,
        Alexei Starovoitov <ast@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Andrii Nakryiko <andriin@...com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        linux-kernel@...r.kernel.org, bcm-kernel-feedback-list@...adcom.com
Subject: Re: [RFC 00/13] [net-next] drivers/net/Space.c cleanup

On Sun, May 16, 2021 at 2:06 AM Maciej W. Rozycki <macro@...am.me.uk> wrote:
>
> On Sun, 16 May 2021, Arnd Bergmann wrote:
>
> > For the ISA drivers, there is usually no way to probe multiple devices
> > at boot time other than the netdev= arguments, so all that logic is left
> > in place for the moment, but centralized in a single file that only gets
> > included in the kernel build if one or more of the drivers are built-in.
>
>  As I recall at least some ISA drivers did probe multiple interfaces in
> their monolithic configuration; I used a configuration with as many as
> five ne2k clones for a bridge machine for a fairly large network (~300
> machines) and as I recall it required no command-line parameters (but then
> it was some 25 years ago, so I may well not remember correctly anymore).
> It may have been with ISA PnP though (damn!).
>
>  For modular drivers it was deemed too dangerous, for obvious reasons, and
> explicit parameters were the only way.

I did use two ne2k compatible pre-PnP cards in a router, by loading two
copies of the same driver module, and I'm fairly sure that would still work,
but it's obviously not how it was meant to be used. ;-)

To clarify: the code drivers/net/Space.c logic can probe these drivers
both with and without explicit configuration. Using the netdev= arguments
will result in reliable assignment of device names and prevent drivers
from poking ports that may be used by other devices, but drivers can
also implement their own device detection, in case of
drivers/net/ethernet/8390/ne.c, it can find devices at up to six addresses:
static unsigned int netcard_portlist[] __initdata = {
    0x300, 0x280, 0x320, 0x340, 0x360, 0x380, 0
};

> > * Most of ISA drivers could be trivially converted to use the module_init()
> >   entry point, which would slightly change the command line syntax and
> >   still support a single device of that type, but not more than one. We
> >   could decide that this is fine, as few users remain that have any of
> >   these devices, let alone more than one.
> >
> > * Alternatively, the fact that the ISA drivers have never been cleaned
> >   up can be seen as an indication that there isn't really much remaining
> >   interest in them. We could move them to drivers/staging along with the
> >   consolidated contents of drivers/net/Space.c and see if anyone still
> >   uses them and eventually remove the ones that nobody has.
>
>  I have a 3c509b interface in active use (although in the EISA mode, so no
> need for weird probing, but it can be reconfigured),

The 3c509 driver already doesn't use the drivers/net/Space.c probing,
Marc Zyngier addressed this when he added EISA support in 2003.
It also supports multiple non-PnP cards with module parameters
as well as pre-standard jumperless autoconfiguration. My only change
to this driver was to remove a few lines of dead code that I guess Marc
missed at the time.

I probably should have listed the drivers that still use Space.c after
my series. Here is the list I'm talking about:

3com:
    3c515/corkscrew: supports PnP mode, ignores command line and
        module parameters but scans for devices on all ports
8390:
   wd80x3: supports module parameters up to four cards, no PnP
   smc-ultra: supports up to four devices with module parameters, plus PnP
   ne2k/iosa: supports up to four devices with module parameters, plus PnP
amd
   lance: supports up to eight devices with module parameters, no PnP
   ni65: supports only one device as loadable module, no PnP
smsc
   smc9194: supports only one device as loadable module, no PnP
cirrus
   cs89x0 (supports only one device as loadable module, plus custom
        PnP-like probing in built-in mode)

> and I have an ne2k clone in storage, so I could do some run-time
> verification if there is no one else available.  I'll see if I can do some driver
> polishing for these devices, but given the number of other tasks on my
> table this is somewhat low priority for me.

I don't think it's necessary to validate the changes I did to the
ne2k driver specifically, though it might be nice to see that I didn't
break the overall logic in Space.c.

        Arnd

Powered by blists - more mailing lists