I've implemented an shpc controller emulator
in qemu, so I needed a bunch of constants
similar to what drivers/pci/hotplug/shpc.h has.
Any objections to adding a PCI_SHPC_XXXX prefix
so these and moving them to pci_regs.h?
PCI utilities can then use them from /usr/include/linux.
One can see how a utility that looks at slot LED and MRL
states might be useful
(we'd need to export the base offset through sysfs
to make it possible to use such in parallel with shpc).
--
MST
On Thu, 16 Feb 2012 16:54:49 +0200
"Michael S. Tsirkin" <[email protected]> wrote:
> I've implemented an shpc controller emulator
> in qemu, so I needed a bunch of constants
> similar to what drivers/pci/hotplug/shpc.h has.
>
> Any objections to adding a PCI_SHPC_XXXX prefix
> so these and moving them to pci_regs.h?
> PCI utilities can then use them from /usr/include/linux.
>
> One can see how a utility that looks at slot LED and MRL
> states might be useful
> (we'd need to export the base offset through sysfs
> to make it possible to use such in parallel with shpc).
pci_regs.h is generally reserved for architected regs, but maybe a
separate header file makes sense. Or just patch libpciaccess or
pci-utils with your tool.
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, Feb 23, 2012 at 08:50:04AM -0800, Jesse Barnes wrote:
> On Thu, 16 Feb 2012 16:54:49 +0200
> "Michael S. Tsirkin" <[email protected]> wrote:
>
> > I've implemented an shpc controller emulator
> > in qemu, so I needed a bunch of constants
> > similar to what drivers/pci/hotplug/shpc.h has.
> >
> > Any objections to adding a PCI_SHPC_XXXX prefix
> > so these and moving them to pci_regs.h?
> > PCI utilities can then use them from /usr/include/linux.
> >
> > One can see how a utility that looks at slot LED and MRL
> > states might be useful
> > (we'd need to export the base offset through sysfs
> > to make it possible to use such in parallel with shpc).
>
> pci_regs.h is generally reserved for architected regs,
> but maybe a
> separate header file makes sense. Or just patch libpciaccess or
> pci-utils with your tool.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
Fair enough, but out of curiosity,
could you pls clarify what is meant by 'architected'?
SHPC is a PCI-SIG spec after all, not a vecor-specific interface...
On Thu, 23 Feb 2012 21:50:54 +0200
"Michael S. Tsirkin" <[email protected]> wrote:
> On Thu, Feb 23, 2012 at 08:50:04AM -0800, Jesse Barnes wrote:
> > On Thu, 16 Feb 2012 16:54:49 +0200
> > "Michael S. Tsirkin" <[email protected]> wrote:
> >
> > > I've implemented an shpc controller emulator
> > > in qemu, so I needed a bunch of constants
> > > similar to what drivers/pci/hotplug/shpc.h has.
> > >
> > > Any objections to adding a PCI_SHPC_XXXX prefix
> > > so these and moving them to pci_regs.h?
> > > PCI utilities can then use them from /usr/include/linux.
> > >
> > > One can see how a utility that looks at slot LED and MRL
> > > states might be useful
> > > (we'd need to export the base offset through sysfs
> > > to make it possible to use such in parallel with shpc).
> >
> > pci_regs.h is generally reserved for architected regs,
> > but maybe a
> > separate header file makes sense. Or just patch libpciaccess or
> > pci-utils with your tool.
> >
> > --
> > Jesse Barnes, Intel Open Source Technology Center
>
> Fair enough, but out of curiosity,
> could you pls clarify what is meant by 'architected'?
> SHPC is a PCI-SIG spec after all, not a vecor-specific interface...
Sorry that's what I meant; I was thinking it was one of the vendor
ones. Putting the SHPC reg definitions in pci_regs.h is fine.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center