Re: [PATCH 0/4] NE2000 driver updates

[Adam Belay]

On Tue, May 13, 2003 at 10:01:12PM -0400, Jeff Muizelaar wrote:
> Attached is the rough beginings of a patch that does this.
>
> Basically it adds isa bus support and uses it ne.c.
> 
> ISA Bus Support
> --
> The bus uses ioaddr as the bus_id because I don't think we have anything 
> else unique to use.
> 
> Drivers are responsible for adding devices to the bus, through 
> isa_device_register(). Once added, devices stay around forever, even 
> after driver unload.
> Right now I use the device id's stolen from eisa, but I can't see any 
> reason not to just make ids up as necessary.
>
>
> ne.c
> ---
> ne_probe (the function called by Space.c) will autoprobe for ne2000
> devices and then as it finds them it calls isa_register_device. It
> always returns -ENODEV. (eventually if all the net drivers get moved to
> this model, some of this stuff could be moved into Space.c)
> Later on, during module init the driver registers itself with with isa
> bus and then ne_isa_probe is called appropriately.
>
> Moving to doing things this way, should make it possible to merge pci
> support back in and get rid of ne2k-pci.c, because all buses will use
> the same model. Eventually ne2k_cbus.c could probably be added merged as
> well.
>
> Any comments or suggestions?
>
> -Jeff

Hi Jeff,

I agree that an isa interface with sysfs would be useful.  This patch looks like 
a great start.  I'm considering the following aditional changes...

1.) Perhaps the contents of /drivers/eisa and /drivers/isa should be held in the 
same directory.  Comments?

2.) Some collaboration between isapnp, eisa, and isa would be nice.  This is 
because all three of these interfaces could potentially be detecting the same 
devices, resulting in nasty conflicts.

3.) A sysfs interface that would export isa information would be useful.

4.) Perhaps the isa drivers could match against the name of the legacy probing 
driver or maybe the system should be designed to not use device_ids at all.

Also a few things to consider...

Is isa limited to one dma, one irq, and one ioport?  I haven't seen more then 
this anywere but it would be nice to know for registration purposes.

What is the best action to take if a legacy probing technique detects an area 
that conflicts with a previous legacy probe from another driver.  At the very 
least, it would be nice if isa was aware of such things.

Best Regards,
Adam