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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:54 EST