Subject: Re: looking for devices on PCI bus
To: None <jonathan@DSG.Stanford.EDU, wrstuden@zembu.com>
From: None <eeh@netbsd.org>
List: tech-kern
Date: 05/02/2001 21:38:09
	>For hot-swap, when we re-scan, if we find the device we found

	What does "found" mean? Sounds like you're assuming we add some new
	structure, a copy of the PCI config-space registers, and machinery to
	keep track of which devices are "found" and which are "new".

You need to re-probe every device on the bus to see if it has been
added, removed, or *replaced* with something different.  For that,
we need to keep around the locator information used during the original
attach(*).

	that's the moral equivalent to using extents to mark the PCI
	configuration-space for "already configured" devices as having been
	"already configured".

"already configured" devices can be removed or replaced, so they need
to be re-probed, at least enough to determine they are still the same
as last time.

	apart from pci-pci-bridges, that sounds like it's pretty much a
	duplicate of what we already have to scan PCI config-space. Or is that
	too abstract?

	for bridges: I was acutallly thinking of heterogenous bridges:
	say, turbochannel-VMe or something equally horrible.

A bridge is a bus driver attached to another bus driver.  Nothing
original there.

All bus drivers (that support hotplug of any sort) need a method
of determining what devices are attached to them, and that requires
a reprobe.  If the bus hardware can inform the driver that the state
of a specific slot has changed, then the reprobe can be limited to that
slot.  Otherwise the entire bus needs to be re-probed.

The simplest way to handle re-probing the bus is to keep the original
locator information around.  If that has not changed for that slot then
the installed driver should be o.k.  That information can be kept in
many forms, but the easiest would be as properties attached to the device
nodes.

This whole concept breaks down for indirect-config buses.  But I don't
think it is at all possible to reconfigure indirect-config buses, so 
this issue is moot.

* One problem with drivers loaded from an LKM is if the device
can be managed by multiple drivers and you need to select the
most appropriate one.  If another, less apropriate driver has 
already attached to that device, things get complicated.  Do
you unconfigure the device and then reprobe and reconfigure, or
just forget about the whole thing and use the old driver?

Eduardo