NE2000 driver updates
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Riley Williams
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
0x0300through0x031Fwhich 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.
Quoted 11 lines · Alan Cox
Quoted 6 lines · Riley Williams
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
0x0300through0x031Fwhich are almost universal in their use !!!!!!!
Quoted 6 lines
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
0x300isnt an NE2000 its generally safe to probe there, before that its a very bad idea.Space.cknows 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
Quoted 11 lines · Riley Williams
Hi Jeff.
Quoted 8 lines
Attached is the rough beginnings of a patch that does this.
Basically it adds ISA bus support and uses it in
ne.c.ISA Bus Support
--
The bus uses ioaddr as thebus_idbecause I don't think we have anything else unique to use.
Quoted 6 lines
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
0x0300through0x031Fwhich are almost universal in their use !!!!!!!
This is a problem that already exists, if two devices are at the same io address there is not much we can do. Autoprobe will pick up one first and the second is out of luck. (or are you confusing bus_id with device_id?)
Quoted 15 lines
Quoted 6 lines
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.Quoted 8 lines
ne.c
---ne_probe(the function called bySpace.c) autoprobes for ne2000 devices and then as it finds them it callsisa_register_device. It always returns-ENODEV. (eventually if all the net drivers get moved to this model, some of this stuff could be moved intoSpace.c) Later on, during module init the driver registers itself with ISA bus and thenne_isa_probeis called appropriately.
Quoted 6 lines
According to what I've been told and have seen for myself in the past, having this autoprobe at address
0x0300is VERY likely to lock the machine up solid because of the number of other devices using that range. However, autoprobing the other addresses that this card can be at is apparently far less dangerous.
Nothing is being changed as far as this concerned. If you compile ne.c into your kernel you get autoprobe at 0x300.
-Jeff