[PATCH] remove a wrong release_region in eexpress.c

[PATCH] remove a wrong release_region in eexpress.c

[Gianluca Anzolin]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

Hello,

I was trying the eexpress.c driver for my Intel EtherExpress 16 NIC
(isa) and I got some errors when I unloaded the module (kernel
2.4.18-pre7).

The problem was that it was trying to release an already released i/o
region. I'm attaching a patch to remove that release_region.

I have also a question: I'm reading Rubini's Linux Device Drivers (2nd
edition) and he writes that irq and regions should be registered when
the device is open (and not in the hw-probe function). Why network
drivers should register the resources they use only on open and not on
probe (like other drivers do) ? 

I don't know if this is related but I had a problem few months ago when 
the ISDN card (a pci one) tried to share the same IRQ of the Network 
Card (isa). The result was the nic didn't work (the NIC was a 3c509b 
ISA PNP card) and I had to explicitly change the nic irq via a kernel parameter 
on boot. Now I wonder if this could have happened if the driver had 
registered its irq on probe and not on open (i.e. after that the hisax
module was loaded).

Greeting, 

	Gianluca Anzolin

[-- Attachment #2: eexpress.patch --]
[-- Type: text/plain, Size: 242 bytes --]

--- eexpress.c.old	Mon Jan 28 13:47:44 2002
+++ eexpress.c	Mon Jan 28 13:48:19 2002
@@ -1674,7 +1674,6 @@
 			unregister_netdev(dev);
 			kfree(dev->priv);
 			dev->priv = NULL;
-			release_region(dev->base_addr, EEXP_IO_EXTENT);
 		}
 	}
 }

Re: [PATCH] remove a wrong release_region in eexpress.c

[Alan Cox]

> edition) and he writes that irq and regions should be registered when
> the device is open (and not in the hw-probe function). Why network
> drivers should register the resources they use only on open and not on
> probe (like other drivers do) ? 

In the general case you want to claim resources when the hardware is using 
them. For most things that means at module load time. However many ISA
devices you can avoid the IRQ and DMA channels unless the device is active.
By deferring that you can allow people to use one or other of two clashing
devices in awkward cases.

For PCI devices the problem really doesn't arise since the resource allocations
are done for you when you use pci_enable_device, or by the pci hot plug layer
and/or BIOS as appropriate