[lkml]   [2003]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/4] NE2000 driver updates
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.
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

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.032 / U:0.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site