Subject: Re: looking for devices on PCI bus
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 05/02/2001 14:34:17
On Wed, 2 May 2001, Jonathan Stone wrote:
> We seem to be talking at cross-purposes.
> You seem to be considering only the case of PCI LKMs, and seem (to me)
> to be suggesting duplicating lots of the existing PCI machinery to
> handle that case. Whereas I'm thinking of how we could support LKMs
> for arbitrary direct-config buses, with PCI as a specific example.
I am definitly talking just about PCI. I'm not sure how to expand these
ideas to other direct connect busses. Do say TURBOchannel or VME or SBus
support hot-swap? I think I'm talking about duplicating less of the PCI
machinery than you think I am. :-)
> What I'm trying to say is that *if* PCI drivers reserved bus resources
> which correspond to the `device' rahter than PCI resources used by the
> device -- say, slotnumber for the sake of argument--, and if the
That didn't parse for me.
> PCI-bus autoconfig code reserved "slot number" for each device as it
> was matched and attached, then we could re-configure a new PCI bus
> *just* by re-starting autoconfiguration from the node for the
> PCI-bus parent.
> >I am suggesting we add a new structure which essentially would be the pci
> >match arguements. Keeping track of which devices are "new" and "old" is
> >easy - if when we look, the match arguements are what we remember, it is
> I am suggesting that if we need to go scan everything *anyway*, why
> *bother* keeping the locators/match arguments around? Just keep track
> of which devices have already been grabbed by drivers, using an extent
> map for some unique attribute (for PCI, header block address, maybe?).
A map of which devices have been grabbed would work. But it doesn't help
as much with the, "there but unconfigured" case.
> For hotswap, i don't (yet) buy that the inference "new" = "old" is
> acutally valid -- consider swapping out a suspect card for another
> instance of the same card. I think in that case, hotswap really
> requires explicit notification of insertion/removal events.
Yes, that was what I was getting at with the criteria about if we're
rescanning the bus fast enough. We would notice the card go, and the next