Messages in this thread | | | Date | Fri, 29 Sep 2000 09:07:32 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH] esssolo1.c: get rid of check_region |
| |
On Fri, 29 Sep 2000, Alan Cox wrote:
> > In solo1_probe, an FM interface is registered. > > > > So, IMHO there is a bug somewhere... Why register an FM interface in > > probe, and then check_region for another FM driver in _open? Is this > > intentional or really a bug? > > The I/O port range is only activated in open
Which is almost certainly a mis-feature.
The IO port ranges (along with the IO memory ranges) should generally be allocated and requested as soon as they are known. Now, that _may_ be at open() time - there are cards that actually shut down completely and do not react to IO etc until actually enabled through some magic means (*) and potentially you could allocate the IO range dynamically at open() time and make them shut up at any other time.
But usually, you tend to know the IO port range at init time, and allocating the port early rather than late at least gives other drivers the _potential_ to be able to avoid clashes etc. No, it doesn't work all that well with modules etc, but on the whole it's nice to make old ISA drivers etc aware of the fact that there is a driver that already claimed the region.
No, it doesn't matter in the case of the esssolo1 driver. It's a PCI controller, and the PCI layer will have registered the ports anyway, so you won't have the issue with ISA probes etc. But it's still a nice rule to follow: tell the rest of the world early rather than late that you're interested in a particular region.
But even for PCI drivers, it's a nice way to tell another PCI driver that might be able to handle the same hardware that it's already taken care of. This actually happens for some stuff - like the SCSI drivers where you have a "new" and an "old" driver that can potentially both handle the same controller. If they use request_region() early, there is never any chance of confusion.
(The same holds for irq lines, at least the ones that can be shared, but there are performance reasons why people might hold off from this, so it's not as obvious any more).
Linus
(*) Any PCI card is the obvious example, but they don't have this issue due to the generic PCI layer knowing about them and initializing them properly anyway. I'm more talking about the ISA PnP kind of things, or the vendor-specific magic sequences.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |