Messages in this thread | | | Date | Mon, 16 Aug 2004 16:14:00 +1000 | Subject | Re: VPD in sysfs | From | "Martin Schwenke" <> |
| |
[I'll reply to this quickly even though I'm 1/2 asleep... travelling and not sure when I'll get to email again...]
>>>>> "Willy" == Matthew Wilcox <willy@debian.org> writes:
Willy> I've been sent a patch that reads some VPD from the Symbios Willy> NVRAM and displays it in sysfs. I'm not sure whether the Willy> way the author chose to present it is the best. They put Willy> it in 0000:80:01.0/host0/vpd_name which seems a bit too Willy> scsi-specific and insufficiently forward-looking (I bet we Willy> want to expose more VPD data than that in the future, so we Willy> should probably use a directory).
Does the patch expose the VPD as text? Either way, what's the format?
Willy> I actually have a feeling (and please don't kill me for Willy> saying this), that we should add a struct vpd * to the Willy> struct device. Then we need something like the Willy> drivers/base/power/sysfs.c file (probably Willy> drivers/base/vpd.c) that takes care of adding vpd to each Willy> device that wants it.
Sounds good to me... I like the idea of a consistent way of getting at VPD. Perhaps then HAL would get at it too.
Willy> Thoughts? Since there's at least four and probably more Willy> ways of getting at VPD, we either need to fill in some VPD Willy> structs at initialisation or have some kind of vpd_ops that Willy> a driver can fill in so the core can get at the data.
For PCI 2.0/2.1 VPD in expansion ROMs the recent patch to expose the ROMs in sysfs is probably enough. The likely brokenness of ROMs and the VPD means that trying to special-case around brokenness should probably be done outside the kernel.
However, I could be wrong: there is something to be said for consistency...
peace & happiness, martin
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |