creating PCI-related sysfs entries

[linas]

On Tue, Jan 31, 2006 at 01:26:24PM -0800, Greg KH was heard to remark:
> On Tue, Jan 31, 2006 at 03:08:05PM -0600, linas wrote:
> > 
> > ... 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?

OK. Let me get this straight, then. Create a generic 
struct pci_host_bridge, which encapsulates  some (all?)
of the functions that Grant Grundler mentions in his email:

Grant Grundler <grundler at parisc-linux.org>:
<> Each arch deals with pci-host bridges as it sees fit.
<>
<>But access methods to some PCI features are abstracted:
<>o method access to CFG space
<>o method to register IRQs
<>o advertise MMIO/IO Port routing.

At the risk of over-engineering, maybe there should be a 
struct bus_host_bridge, and struct pci_host_bridge would 
derive from that?

--linas

p.s. rest of message:

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

Right. I'll keep them that way.

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

OK.

--linas