creating PCI-related sysfs entries

[Greg KH]

On Tue, Jan 31, 2006 at 03:08:05PM -0600, linas wrote:
> On Tue, Jan 31, 2006 at 12:34:56PM -0800, Greg KH was heard to remark:
> > On Tue, Jan 31, 2006 at 02:22:14PM -0600, linas wrote:
> > > 
> > > I want to create some sysfs entries in order to report on the 
> > > status of PCI slots.  (If you are guessing that this pertains
> > > to the PCI error recovery code, you'd be right).  I'm having 
> > > trouble figuring out the best way to do this.
> > > 
> > > There are existing entries at /sys/bus/pci/slots/... but these
> > > are for hotplug slots only; none of the soldered-onto-the-MB
> > > devices show up here.  Is this intentional, or is this a bug/
> > > overshight/not-yet-implemented thing?
> > 
> > Not implemented, as it's up to a pci hotplug controller driver to
> > provide those slots.  It sounds like your driver needs to be expanded :)
> 
> Hmm. But these slots are not hot-plugabble; should the arch
> use the hotplug infrastructure even on those slots?

Why not?  It's a good place to put them, right?

> I note that /sys/devices/pciXXXX does have all of the pci 
> slos listed, so perhaps that is where I can place per-slot data.

That's only because your arch might happen to have 1 device per slot,
which is not true for other arches.  And I bet it's also not true for
your non-virtual boxes...

> > > I also want to report some roll-up system-wide statistics
> > > both /sys/module and /sys/class seem reasonable. My code
> > > does not compile as a module. Suggestions?
> > 
> > What kind of statistics?  Is this driver related?  PCI bus related?
> > Device related?
> 
> Related to the PCI error recovery. I'm not sure how to conceptually
> peg this: one could say that it is the driver for a specific type
> of pci-host bridge, although the code is not currently structured 
> as such. Should I try to restructure it as such? If so, I'm not 
> clear on how to proceed; I can't say I've clearly seen a kernel
> abstraction of a pci-host bridge device onto which to staple myself.

People have suggested that they create such a driver for a long time.
Why not just do that?

> I wanted to report a few read-only statistics, and a few writeable 
> parameters:
> 
> Read-only:
> -- total number of PCI device resets due to detected errors
> -- total number of "false positives" (probable errors that weren't)
> -- some other misc related stats.

These are all "per slot" right?

> Most, but not all, of these statistics could be obtained by 
> totalling up the per-slot statistics.
> 
> Writable: 
> -- Number of reset tries to perform before concluding that the 
>    device is hopelessly dead.  Resets are disruptive and intensive,
>    and I don't want to get stuck in an inf loop on a dead device.

Why would you want to change this value?  Just pick one at build time.

thanks,

greg k-h