RFC: export constants from shpc.h?
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).
Signature · 1 line
MST
Quoted 4 lines · 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 whatdrivers/pci/hotplug/shpc.hhas.
Quoted 8 lines
Any objections to adding a
PCI_SHPC_XXXXprefix so these and moving them topci_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.
Signature · 1 line
Jesse Barnes, Intel Open Source Technology Center
Quoted 16 lines · Jesse Barnes
Quoted 4 lines · 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 whatdrivers/pci/hotplug/shpc.hhas.Quoted 8 lines
Any objections to adding a
PCI_SHPC_XXXXprefix so these and moving them topci_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).
Quoted 7 lines
pci_regs.his generally reserved for architected regs, but maybe a
separate header file makes sense. Or just patch libpciaccess or pci-utils with your tool.Signature · 1 line
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...
Quoted 22 lines · On Thu, 23 Feb 2012 21:50:54 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
Quoted 21 lines · Jesse Barnes
Quoted 4 lines · 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 whatdrivers/pci/hotplug/shpc.hhas.Quoted 8 lines
Any objections to adding a
PCI_SHPC_XXXXprefix so these and moving them topci_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.his generally reserved for architected regs, but maybe a
separate header file makes sense. Or just patch libpciaccess or pci-utils with your tool.
Quoted 6 lines
Quoted 2 lines
Signature · 1 line
Jesse Barnes, Intel Open Source Technology CenterFair 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,
Signature · 1 line
Jesse Barnes, Intel Open Source Technology Center