[lkml]   [2000]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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).


(*) 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
Please read the FAQ at

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