Re: [PATCH 0/4] NE2000 driver updates

Jeff Muizelaar
2003-05-14T22:58:51Z

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