From: Douglas Gilbert <dougg@torque.net>
To: Matthew Wilcox <willy@debian.org>
Cc: Greg KH <greg@kroah.com>,
martins@au.ibm.com, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org
Subject: Re: VPD in sysfs
Date: Tue, 17 Aug 2004 14:12:32 +1000 [thread overview]
Message-ID: <412185B0.4080105@torque.net> (raw)
In-Reply-To: <20040814182932.GT12936@parcelfarce.linux.theplanet.co.uk>
Matthew Wilcox wrote:
> I've been sent a patch that reads some VPD from the Symbios NVRAM and
> displays it in sysfs. I'm not sure whether the way the author chose
> to present it is the best. They put it in 0000:80:01.0/host0/vpd_name
> which seems a bit too scsi-specific and insufficiently forward-looking
> (I bet we want to expose more VPD data than that in the future, so we
> should probably use a directory).
>
> I actually have a feeling (and please don't kill me for saying this), that
> we should add a struct vpd * to the struct device. Then we need something
> like the drivers/base/power/sysfs.c file (probably drivers/base/vpd.c)
> that takes care of adding vpd to each device that wants it.
>
> Thoughts? Since there's at least four and probably more ways of getting
> at VPD, we either need to fill in some VPD structs at initialisation or
> have some kind of vpd_ops that a driver can fill in so the core can get
> at the data.
Vital Product Data (VPD) seems to be an ever increasing
area for all sorts of data. Here is a list (from sg_inq
in sg3_utils) of existing and proposed VPD pages for SCSI
targets and LUs:
struct vpd_name {
int number;
int peri_type;
char * name;
};
static struct vpd_name vpd_name_arr[] = {
{0x0, 0, "Supported VPD pages"},
{0x80, 0, "Unit serial number"},
{0x82, 0, "ASCII implemented operating definition"},
{0x83, 0, "Device identification"},
{0x84, 0, "Software interface identification"},
{0x85, 0, "Management network addresses"},
{0x86, 0, "Extended INQUIRY data"},
{0x87, 0, "Mode page policy"},
{0x88, 0, "SCSI ports"},
{0x89, 0, "ATA information"},
{0xb0, 0, "Block limits (sbc2)"},
{0xb0, 0x1, "SSC device capabilities (ssc3)"},
{0xb0, 0x11, "OSD information (osd)"},
{0xb1, 0x11, "Security token (osd)"},
};
The most interesting one in the above list is the
"Device identification" VPD page (0x83) which may contain
multiple descriptors each identifying either a:
- SCSI port (of a target)
- SCSI target
- SCSI logical unit
And here is a selection of possible identifier formats:
- naa (2,5 or 6)
- eui-64
- t10 vendor
- SCSI name string (iSCSI here)
- MD5 logical unit identifier
- vendor specific
amongst others.
["The great thing about standards is that there are so many
to choose from."]
And your patch is about attaching VPD data to a SCSI HBA (host)
via sysfs.
"struct vpd" should be interesting ...
Doug Gilbert
next prev parent reply other threads:[~2004-08-17 8:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-14 18:29 VPD in sysfs Matthew Wilcox
2004-08-16 6:14 ` Martin Schwenke
2004-08-16 14:11 ` Luben Tuikov
2004-08-17 4:12 ` Douglas Gilbert [this message]
2004-08-20 14:21 ` Matthew Wilcox
2004-08-20 19:45 ` Dave C Boutcher
2004-08-24 19:09 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=412185B0.4080105@torque.net \
--to=dougg@torque.net \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martins@au.ibm.com \
--cc=willy@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.