Re: [PATCH 0/4] NE2000 driver updates

[Jeff Muizelaar <muizelaar@rogers.com>]

Alan Cox wrote:

>On Mer, 2003-05-14 at 08:29, Riley Williams wrote:
>
>  
>
>>If there's going to be any problems, it's with devices claiming the
>>same IOaddr as each other - and certain addresses are far too common
>>where that's concerned - especially 0x0300 through 0x031F which are
>>almost universal in their use !!!!!!!
>>    
>>
>
>This is why you have to get the ordering right. Specifically you have to
>deal with probe unsafe hardware (ie ne2000) early. Once you've checked
>0x300 isnt an NE2000 its generally safe to probe there, before that its
>a very bad idea. Space.c knows about this and a vast amount more.
>  
>
With the patch none of the ordering gets changed, with the following 
exceptions, afaik:

1. When request_region would prevent something from probing over top of 
something else. This is a bug with my current patch, but a tough one to 
avoid because we normally don't request_resource until the probe 
function is called...

2. Any breakage that results from spliting probe1 into detect and setup:
    device on 0x300.
    driver x, and driver y.
    old:
       probe1 from driver x fails late in the routine. (after the place 
where the detect/setup split would occur)
       driver y probe1 succeds and it gets the device

    new:
       driver x detect succeceds.
       all other driver detects at 0x300 thus fail.
       driver x setup fails.
       nobody gets the device.
   
This is a driver issue and as long as the split of probe1 to 
detect/setup is done right there should be no problems.

Also ethX numbering could change because of the alloc/register_netdev is 
happening at module init time and not at autoprobe time.

-Jeff