On 2 May 2001 eeh@netbsd.org wrote:

> 
> 	>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(*).

Right, though my suggestion is to keep around the info from the original
match, not just attach. :-) That way things work even for unsupported
drivers. My definition of "fast enough" scanning was an effort to try and
keep things to just having to deal with add & removed items.

> 	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.

Exactly.

[snip]

> 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.

See my other note for a different way to handle this. Essentially the same
thing...

> 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.

Agreed.

> * 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?

I was hoping no one would bring this up. :-)

Probably the best thing to do would be when we are scanning for existing
devices which are matched by the new LKM to note if the device is attached
or not. If it's not attached, things are easy. If it is matched, then
either the LKM driver needs to ignore the device, or decide to get the
existing driver to detach, and then have the new driver attach. Oh, and to
be nice, it should probably gain as much state info before detach as
possible.

Oh, and the routine which adds match routines should be told if it should
add the new routine to the front or the back, so that future scans will
favor either the LKM or an in-kernel driver.

Take care,

Bill