On Thu, 11 Sep 2003, anand lalgondar wrote:

> Now for considering an example the way mentioned in kernel configuration
> file:
> C3 at P1 memaddr 0x8000

You won't see the difference with that kind of config line. Your config
line doesn't make sense for a number of direct busses, so you're
pre-limiting yourself to too small a device space.

[snip]

> >Some busses can _not_ detect the presence of a particular child device
> >on a particular "address", e.g. ISA.
> Now my question is why cant a bus driver detect a device specified at a
> particular address. Since the bus driver has to simply read the address
> specified by the locator and validate it. Is there any solid reason for the
> bus driver not able to recognize the child device.

Here's an example:

In PCI, you can make configuration space accesses. Configuration space is
a separate address space from memory and i/o. When a card is told a
configuration access is happening to its configuration space (via the
IDSEL pin), it is to respond with info about its device(s). So the host
processor goes out and asks each potential pci connection (slot which may
be empty) what is there. If a card or chip is there, it answers. It says,
"I am a FOO". For PCI, there is a 2-byte device ID and a 2-byte vendor ID.
For other busses, say Nubus, there are other tags. For ISA-PNP, there is
the ISA PNP tag. Like PNP0501 for a com port, PNP0400 for an lpt, etc.

At that point, autoconf then has to match what it knows is there with a
driver. That's why all the config_match() routines are called.

The important point here is that the PCI driver (direct-config bus driver)
knows which device(s) it has, it just has to find a driver.

Compare that with the ISA bus driver (NOT PNP!). It has no clue what is on
its bus. So it has to go to each driver and ask the driver, "did you find
a device matching this setup"? i.e. there is no way to tell if your
"C3 at P1 memaddr 0x8000" is there or not other than going out and trying
to access it. Also, the "best" driver matching that can happen for a
direct-config bus can't happen for an indirect bus. Once you get a match,
you immediately attach.

One of the original reasons for bus_space was that once a driver attaches,
it registers itself with the bus. For ISA, we keep track of what i/o port
space is in use. The driver also registers itself in its match routine. If
it can't register its i/o space (because something else has already
matched), chances are that its hardware is _not_ there so it shouldn't
match. :-) (*)

Take care,

Bill

(*) There are some ISA driver match methods which will match something
other than that card, since "matching" really is just a huristic. In some
cases, the "bad" match will in fact wipe out the card (like scribble all
over its EEPROM so bad that the card's diagnostic routines won't find it
and it's now a piece of junk).