* [PATCHv7 0/3] Display EVPD pages in sysfs
@ 2014-02-13 10:07 Hannes Reinecke
2014-02-13 10:07 ` [PATCH 1/3] scsi_sysfs: Implement 'is_visible' callback Hannes Reinecke
` (2 more replies)
0 siblings, 3 replies; 24+ messages in thread
From: Hannes Reinecke @ 2014-02-13 10:07 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-scsi, Christoph Hellwig, Hannes Reinecke
Hi all,
After discussion with jejb I've dropped the EVPD parsing.
So with this version we're just displaying the EVPD page
0x80 and 0x83 as hexdumps; no parsing is attempted.
This drastically simplifies the patch, and we don't
have to worry about any parsing errors in kernel space.
Hannes Reinecke (3):
scsi_sysfs: Implement 'is_visible' callback
Add EVPD page 0x83 to sysfs
Add EVPD page 0x80 to sysfs
drivers/scsi/scsi.c | 104 ++++++++++++++++++--
drivers/scsi/scsi_scan.c | 3 +
drivers/scsi/scsi_sysfs.c | 229 +++++++++++++++++++++++++++------------------
include/scsi/scsi.h | 4 +-
include/scsi/scsi_device.h | 5 +
5 files changed, 245 insertions(+), 100 deletions(-)
--
1.7.12.4
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH 1/3] scsi_sysfs: Implement 'is_visible' callback 2014-02-13 10:07 [PATCHv7 0/3] Display EVPD pages in sysfs Hannes Reinecke @ 2014-02-13 10:07 ` Hannes Reinecke 2014-02-13 10:07 ` [PATCH 2/3] Add EVPD page 0x83 to sysfs Hannes Reinecke 2014-02-13 10:07 ` [PATCH 3/3] Add EVPD page 0x80 " Hannes Reinecke 2 siblings, 0 replies; 24+ messages in thread From: Hannes Reinecke @ 2014-02-13 10:07 UTC (permalink / raw) To: James Bottomley; +Cc: linux-scsi, Christoph Hellwig, Hannes Reinecke Instead of modifying attributes after the device has been created we should be using the 'is_visible' callback to avoid races. Signed-off-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Christoph Hellwig <hch@infradead.org> --- drivers/scsi/scsi_sysfs.c | 184 +++++++++++++++++++++++----------------------- 1 file changed, 93 insertions(+), 91 deletions(-) diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index 9117d0b..196e59a 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -579,7 +579,6 @@ static int scsi_sdev_check_buf_bit(const char *buf) * Create the actual show/store functions and data structures. */ sdev_rd_attr (device_blocked, "%d\n"); -sdev_rd_attr (queue_depth, "%d\n"); sdev_rd_attr (device_busy, "%d\n"); sdev_rd_attr (type, "%d\n"); sdev_rd_attr (scsi_level, "%d\n"); @@ -723,7 +722,37 @@ show_queue_type_field(struct device *dev, struct device_attribute *attr, return snprintf(buf, 20, "%s\n", name); } -static DEVICE_ATTR(queue_type, S_IRUGO, show_queue_type_field, NULL); +static ssize_t +store_queue_type_field(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count) +{ + struct scsi_device *sdev = to_scsi_device(dev); + struct scsi_host_template *sht = sdev->host->hostt; + int tag_type = 0, retval; + int prev_tag_type = scsi_get_tag_type(sdev); + + if (!sdev->tagged_supported || !sht->change_queue_type) + return -EINVAL; + + if (strncmp(buf, "ordered", 7) == 0) + tag_type = MSG_ORDERED_TAG; + else if (strncmp(buf, "simple", 6) == 0) + tag_type = MSG_SIMPLE_TAG; + else if (strncmp(buf, "none", 4) != 0) + return -EINVAL; + + if (tag_type == prev_tag_type) + return count; + + retval = sht->change_queue_type(sdev, tag_type); + if (retval < 0) + return retval; + + return count; +} + +static DEVICE_ATTR(queue_type, S_IRUGO | S_IWUSR, show_queue_type_field, + store_queue_type_field); static ssize_t show_iostat_counterbits(struct device *dev, struct device_attribute *attr, char *buf) @@ -797,46 +826,9 @@ DECLARE_EVT(soft_threshold_reached, SOFT_THRESHOLD_REACHED_REPORTED) DECLARE_EVT(mode_parameter_change_reported, MODE_PARAMETER_CHANGE_REPORTED) DECLARE_EVT(lun_change_reported, LUN_CHANGE_REPORTED) -/* Default template for device attributes. May NOT be modified */ -static struct attribute *scsi_sdev_attrs[] = { - &dev_attr_device_blocked.attr, - &dev_attr_type.attr, - &dev_attr_scsi_level.attr, - &dev_attr_device_busy.attr, - &dev_attr_vendor.attr, - &dev_attr_model.attr, - &dev_attr_rev.attr, - &dev_attr_rescan.attr, - &dev_attr_delete.attr, - &dev_attr_state.attr, - &dev_attr_timeout.attr, - &dev_attr_eh_timeout.attr, - &dev_attr_iocounterbits.attr, - &dev_attr_iorequest_cnt.attr, - &dev_attr_iodone_cnt.attr, - &dev_attr_ioerr_cnt.attr, - &dev_attr_modalias.attr, - REF_EVT(media_change), - REF_EVT(inquiry_change_reported), - REF_EVT(capacity_change_reported), - REF_EVT(soft_threshold_reached), - REF_EVT(mode_parameter_change_reported), - REF_EVT(lun_change_reported), - NULL -}; - -static struct attribute_group scsi_sdev_attr_group = { - .attrs = scsi_sdev_attrs, -}; - -static const struct attribute_group *scsi_sdev_attr_groups[] = { - &scsi_sdev_attr_group, - NULL -}; - static ssize_t -sdev_store_queue_depth_rw(struct device *dev, struct device_attribute *attr, - const char *buf, size_t count) +sdev_store_queue_depth(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count) { int depth, retval; struct scsi_device *sdev = to_scsi_device(dev); @@ -859,10 +851,10 @@ sdev_store_queue_depth_rw(struct device *dev, struct device_attribute *attr, return count; } +sdev_show_function(queue_depth, "%d\n"); -static struct device_attribute sdev_attr_queue_depth_rw = - __ATTR(queue_depth, S_IRUGO | S_IWUSR, sdev_show_queue_depth, - sdev_store_queue_depth_rw); +static DEVICE_ATTR(queue_depth, S_IRUGO | S_IWUSR, sdev_show_queue_depth, + sdev_store_queue_depth); static ssize_t sdev_show_queue_ramp_up_period(struct device *dev, @@ -890,40 +882,73 @@ sdev_store_queue_ramp_up_period(struct device *dev, return period; } -static struct device_attribute sdev_attr_queue_ramp_up_period = - __ATTR(queue_ramp_up_period, S_IRUGO | S_IWUSR, - sdev_show_queue_ramp_up_period, - sdev_store_queue_ramp_up_period); +static DEVICE_ATTR(queue_ramp_up_period, S_IRUGO | S_IWUSR, + sdev_show_queue_ramp_up_period, + sdev_store_queue_ramp_up_period); -static ssize_t -sdev_store_queue_type_rw(struct device *dev, struct device_attribute *attr, - const char *buf, size_t count) +static umode_t scsi_sdev_attr_is_visible(struct kobject *kobj, + struct attribute *attr, int i) { + struct device *dev = container_of(kobj, struct device, kobj); struct scsi_device *sdev = to_scsi_device(dev); - struct scsi_host_template *sht = sdev->host->hostt; - int tag_type = 0, retval; - int prev_tag_type = scsi_get_tag_type(sdev); - if (!sdev->tagged_supported || !sht->change_queue_type) - return -EINVAL; - if (strncmp(buf, "ordered", 7) == 0) - tag_type = MSG_ORDERED_TAG; - else if (strncmp(buf, "simple", 6) == 0) - tag_type = MSG_SIMPLE_TAG; - else if (strncmp(buf, "none", 4) != 0) - return -EINVAL; + if (attr == &dev_attr_queue_depth.attr && + !sdev->host->hostt->change_queue_depth) + return S_IRUGO; - if (tag_type == prev_tag_type) - return count; + if (attr == &dev_attr_queue_ramp_up_period.attr && + !sdev->host->hostt->change_queue_depth) + return 0; - retval = sht->change_queue_type(sdev, tag_type); - if (retval < 0) - return retval; + if (attr == &dev_attr_queue_type.attr && + !sdev->host->hostt->change_queue_type) + return S_IRUGO; - return count; + return attr->mode; } +/* Default template for device attributes. May NOT be modified */ +static struct attribute *scsi_sdev_attrs[] = { + &dev_attr_device_blocked.attr, + &dev_attr_type.attr, + &dev_attr_scsi_level.attr, + &dev_attr_device_busy.attr, + &dev_attr_vendor.attr, + &dev_attr_model.attr, + &dev_attr_rev.attr, + &dev_attr_rescan.attr, + &dev_attr_delete.attr, + &dev_attr_state.attr, + &dev_attr_timeout.attr, + &dev_attr_eh_timeout.attr, + &dev_attr_iocounterbits.attr, + &dev_attr_iorequest_cnt.attr, + &dev_attr_iodone_cnt.attr, + &dev_attr_ioerr_cnt.attr, + &dev_attr_modalias.attr, + &dev_attr_queue_depth.attr, + &dev_attr_queue_type.attr, + &dev_attr_queue_ramp_up_period.attr, + REF_EVT(media_change), + REF_EVT(inquiry_change_reported), + REF_EVT(capacity_change_reported), + REF_EVT(soft_threshold_reached), + REF_EVT(mode_parameter_change_reported), + REF_EVT(lun_change_reported), + NULL +}; + +static struct attribute_group scsi_sdev_attr_group = { + .attrs = scsi_sdev_attrs, + .is_visible = scsi_sdev_attr_is_visible, +}; + +static const struct attribute_group *scsi_sdev_attr_groups[] = { + &scsi_sdev_attr_group, + NULL +}; + static int scsi_target_add(struct scsi_target *starget) { int error; @@ -946,10 +971,6 @@ static int scsi_target_add(struct scsi_target *starget) return 0; } -static struct device_attribute sdev_attr_queue_type_rw = - __ATTR(queue_type, S_IRUGO | S_IWUSR, show_queue_type_field, - sdev_store_queue_type_rw); - /** * scsi_sysfs_add_sdev - add scsi device to sysfs * @sdev: scsi_device to add @@ -1003,25 +1024,6 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev) transport_add_device(&sdev->sdev_gendev); sdev->is_visible = 1; - /* create queue files, which may be writable, depending on the host */ - if (sdev->host->hostt->change_queue_depth) { - error = device_create_file(&sdev->sdev_gendev, - &sdev_attr_queue_depth_rw); - error = device_create_file(&sdev->sdev_gendev, - &sdev_attr_queue_ramp_up_period); - } - else - error = device_create_file(&sdev->sdev_gendev, &dev_attr_queue_depth); - if (error) - return error; - - if (sdev->host->hostt->change_queue_type) - error = device_create_file(&sdev->sdev_gendev, &sdev_attr_queue_type_rw); - else - error = device_create_file(&sdev->sdev_gendev, &dev_attr_queue_type); - if (error) - return error; - error = bsg_register_queue(rq, &sdev->sdev_gendev, NULL, NULL); if (error) -- 1.7.12.4 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-02-13 10:07 [PATCHv7 0/3] Display EVPD pages in sysfs Hannes Reinecke 2014-02-13 10:07 ` [PATCH 1/3] scsi_sysfs: Implement 'is_visible' callback Hannes Reinecke @ 2014-02-13 10:07 ` Hannes Reinecke 2014-02-28 17:01 ` Christoph Hellwig 2014-02-13 10:07 ` [PATCH 3/3] Add EVPD page 0x80 " Hannes Reinecke 2 siblings, 1 reply; 24+ messages in thread From: Hannes Reinecke @ 2014-02-13 10:07 UTC (permalink / raw) To: James Bottomley Cc: linux-scsi, Christoph Hellwig, Hannes Reinecke, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara EVPD page 0x83 is used to uniquely identify the device. So instead of having each and every program issue a separate SG_IO call to retrieve this information it does make far more sense to display it in sysfs. Cc: Jeremy Linton <jlinton@tributary.com> Cc: Kay Sievers <kay@vrfy.org> Cc: Doug Gilbert <dgilbert@interlog.com> Cc: Kai Makisara <kai.makisara@kolumbus.fi> Signed-off-by: Hannes Reinecke <hare@suse.de> --- drivers/scsi/scsi.c | 79 ++++++++++++++++++++++++++++++++++++++++++---- drivers/scsi/scsi_scan.c | 3 ++ drivers/scsi/scsi_sysfs.c | 39 ++++++++++++++++++++++- include/scsi/scsi.h | 4 ++- include/scsi/scsi_device.h | 3 ++ 5 files changed, 119 insertions(+), 9 deletions(-) diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c index d8afec8..e4cd88d 100644 --- a/drivers/scsi/scsi.c +++ b/drivers/scsi/scsi.c @@ -954,7 +954,7 @@ EXPORT_SYMBOL(scsi_track_queue_full); * This is an internal helper function. You probably want to use * scsi_get_vpd_page instead. * - * Returns 0 on success or a negative error number. + * Returns size of the vpg page on success or a negative error number. */ static int scsi_vpd_inquiry(struct scsi_device *sdev, unsigned char *buffer, u8 page, unsigned len) @@ -962,6 +962,9 @@ static int scsi_vpd_inquiry(struct scsi_device *sdev, unsigned char *buffer, int result; unsigned char cmd[16]; + if (len < 4) + return -EINVAL; + cmd[0] = INQUIRY; cmd[1] = 1; /* EVPD */ cmd[2] = page; @@ -982,7 +985,7 @@ static int scsi_vpd_inquiry(struct scsi_device *sdev, unsigned char *buffer, if (buffer[1] != page) return -EIO; - return 0; + return (buffer[2] << 8) + buffer[3] + 4; } /** @@ -1009,18 +1012,18 @@ int scsi_get_vpd_page(struct scsi_device *sdev, u8 page, unsigned char *buf, /* Ask for all the pages supported by this device */ result = scsi_vpd_inquiry(sdev, buf, 0, buf_len); - if (result) + if (result < 4) goto fail; /* If the user actually wanted this page, we can skip the rest */ if (page == 0) return 0; - for (i = 0; i < min((int)buf[3], buf_len - 4); i++) - if (buf[i + 4] == page) + for (i = 4; i < min(result, buf_len); i++) + if (buf[i] == page) goto found; - if (i < buf[3] && i >= buf_len - 4) + if (i < result && i >= buf_len) /* ran off the end of the buffer, give us benefit of doubt */ goto found; /* The device claims it doesn't support the requested page */ @@ -1028,7 +1031,7 @@ int scsi_get_vpd_page(struct scsi_device *sdev, u8 page, unsigned char *buf, found: result = scsi_vpd_inquiry(sdev, buf, page, buf_len); - if (result) + if (result < 0) goto fail; return 0; @@ -1039,6 +1042,68 @@ int scsi_get_vpd_page(struct scsi_device *sdev, u8 page, unsigned char *buf, EXPORT_SYMBOL_GPL(scsi_get_vpd_page); /** + * scsi_attach_vpd - Attach Vital Product Data to a SCSI device structure + * @sdev: The device to ask + * + * Attach the 'Device Identification' VPD page (0x83) to a SCSI device + * structure. This information can be used to identify the device + * uniquely. + */ +void scsi_attach_vpd(struct scsi_device *sdev) +{ + int result, i; + int vpd_len = 255; + int pg83_supported = 0; + unsigned char *vpd_buf; + + if (sdev->skip_vpd_pages) + return; +retry_pg0: + vpd_buf = kmalloc(vpd_len, GFP_KERNEL); + if (!vpd_buf) + return; + + /* Ask for all the pages supported by this device */ + result = scsi_vpd_inquiry(sdev, vpd_buf, 0, vpd_len); + if (result < 0) { + kfree(vpd_buf); + return; + } + if (result > vpd_len) { + vpd_len = result; + kfree(vpd_buf); + goto retry_pg0; + } + + for (i = 4; i < result; i++) { + if (vpd_buf[i] == 0x83) { + pg83_supported = 1; + } + } + kfree(vpd_buf); + + if (pg83_supported) { +retry_pg83: + vpd_buf = kmalloc(vpd_len, GFP_KERNEL); + if (!vpd_buf) + return; + + result = scsi_vpd_inquiry(sdev, vpd_buf, 0x83, vpd_len); + if (result < 0) { + kfree(vpd_buf); + return; + } + if (result > vpd_len) { + vpd_len = result; + kfree(vpd_buf); + goto retry_pg83; + } + sdev->vpd_pg83_len = result; + sdev->vpd_pg83 = vpd_buf; + } +} + +/** * scsi_report_opcode - Find out if a given command opcode is supported * @sdev: scsi device to query * @buffer: scratch buffer (must be at least 20 bytes long) diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 307a811..154bb5e 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -929,6 +929,9 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned char *inq_result, if (*bflags & BLIST_SKIP_VPD_PAGES) sdev->skip_vpd_pages = 1; + if (sdev->scsi_level >= SCSI_3) + scsi_attach_vpd(sdev); + transport_configure_device(&sdev->sdev_gendev); if (sdev->host->hostt->slave_configure) { diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index 196e59a..ca19448 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -415,6 +415,7 @@ static void scsi_device_dev_release_usercontext(struct work_struct *work) scsi_target_reap(scsi_target(sdev)); + kfree(sdev->vpd_pg83); kfree(sdev->inquiry); kfree(sdev); @@ -755,7 +756,38 @@ static DEVICE_ATTR(queue_type, S_IRUGO | S_IWUSR, show_queue_type_field, store_queue_type_field); static ssize_t -show_iostat_counterbits(struct device *dev, struct device_attribute *attr, char *buf) +show_vpd_pg(const unsigned char *pg_buf, int pg_len, char *buf) +{ + int len = 0, i; + + if (!pg_buf) + return -EINVAL; + + len = 0; + for (i = 0; i < pg_len; i += 16) { + hex_dump_to_buffer(pg_buf + i, pg_len, 16, 1, + buf + len, PAGE_SIZE, false); + strcat(buf + len, "\n"); + len += strlen(buf + len); + } + return len; +} + +#define sdev_vpd_pg_attr(page) \ +static ssize_t \ +show_vpd_##page(struct device *dev, struct device_attribute *attr, \ + char *buf) \ +{ \ + struct scsi_device *sdev = to_scsi_device(dev); \ + return show_vpd_pg(sdev->vpd_##page, sdev->vpd_##page##_len, buf); \ +} \ +static DEVICE_ATTR(vpd_##page, S_IRUGO, show_vpd_##page, NULL); + +sdev_vpd_pg_attr(pg83); + +static ssize_t +show_iostat_counterbits(struct device *dev, struct device_attribute *attr, + char *buf) { return snprintf(buf, 20, "%d\n", (int)sizeof(atomic_t) * 8); } @@ -905,6 +937,10 @@ static umode_t scsi_sdev_attr_is_visible(struct kobject *kobj, !sdev->host->hostt->change_queue_type) return S_IRUGO; + if (attr == &dev_attr_vpd_pg83.attr && + !sdev->vpd_pg83) + return 0; + return attr->mode; } @@ -930,6 +966,7 @@ static struct attribute *scsi_sdev_attrs[] = { &dev_attr_queue_depth.attr, &dev_attr_queue_type.attr, &dev_attr_queue_ramp_up_period.attr, + &dev_attr_vpd_pg83.attr, REF_EVT(media_change), REF_EVT(inquiry_change_reported), REF_EVT(capacity_change_reported), diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h index 0a4edfe..8fd13bb 100644 --- a/include/scsi/scsi.h +++ b/include/scsi/scsi.h @@ -334,7 +334,7 @@ static inline int scsi_status_is_good(int status) #define TYPE_OSD 0x11 #define TYPE_NO_LUN 0x7f -/* SCSI protocols; these are taken from SPC-3 section 7.5 */ +/* SCSI protocols; these are taken from SPC-4 section 7.6 */ enum scsi_protocol { SCSI_PROTOCOL_FCP = 0, /* Fibre Channel */ SCSI_PROTOCOL_SPI = 1, /* parallel SCSI */ @@ -345,6 +345,8 @@ enum scsi_protocol { SCSI_PROTOCOL_SAS = 6, SCSI_PROTOCOL_ADT = 7, /* Media Changers */ SCSI_PROTOCOL_ATA = 8, + SCSI_PROTOCOL_UAS = 9, + SCSI_PROTOCOL_SOP = 0xa, SCSI_PROTOCOL_UNSPEC = 0xf, /* No specific protocol */ }; diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h index dcb2b73..b99ed35 100644 --- a/include/scsi/scsi_device.h +++ b/include/scsi/scsi_device.h @@ -113,6 +113,8 @@ struct scsi_device { const char * vendor; /* [back_compat] point into 'inquiry' ... */ const char * model; /* ... after scan; point to static string */ const char * rev; /* ... "nullnullnullnull" before scan */ + unsigned char vpd_pg83_len; + unsigned char *vpd_pg83; struct scsi_target *sdev_target; /* used only for single_lun */ unsigned int sdev_bflags; /* black/white flags as also found in @@ -308,6 +310,7 @@ extern int scsi_add_device(struct Scsi_Host *host, uint channel, extern int scsi_register_device_handler(struct scsi_device_handler *scsi_dh); extern void scsi_remove_device(struct scsi_device *); extern int scsi_unregister_device_handler(struct scsi_device_handler *scsi_dh); +void scsi_attach_vpd(struct scsi_device *sdev); extern int scsi_device_get(struct scsi_device *); extern void scsi_device_put(struct scsi_device *); -- 1.7.12.4 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-02-13 10:07 ` [PATCH 2/3] Add EVPD page 0x83 to sysfs Hannes Reinecke @ 2014-02-28 17:01 ` Christoph Hellwig 2014-03-05 7:38 ` Hannes Reinecke 0 siblings, 1 reply; 24+ messages in thread From: Christoph Hellwig @ 2014-02-28 17:01 UTC (permalink / raw) To: Hannes Reinecke Cc: James Bottomley, linux-scsi, Christoph Hellwig, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On Thu, Feb 13, 2014 at 11:07:11AM +0100, Hannes Reinecke wrote: > EVPD page 0x83 is used to uniquely identify the device. > So instead of having each and every program issue a separate > SG_IO call to retrieve this information it does make far more > sense to display it in sysfs. This just shows binary data from the protocol, so shouldn't it be a binary sysfs attribute? In general I have to I prefer the actual text attributes, but this is still better than having to do all the SG_IO inquirys. > - * Returns 0 on success or a negative error number. > + * Returns size of the vpg page on success or a negative error number. > */ > static int scsi_vpd_inquiry(struct scsi_device *sdev, unsigned char *buffer, > u8 page, unsigned len) > @@ -962,6 +962,9 @@ static int scsi_vpd_inquiry(struct scsi_device *sdev, unsigned char *buffer, > int result; > unsigned char cmd[16]; > > + if (len < 4) > + return -EINVAL; Seems the change in calling conventions for these existing functions should be split into a separate patch? > /** > + * scsi_attach_vpd - Attach Vital Product Data to a SCSI device structure > + * @sdev: The device to ask > + * > + * Attach the 'Device Identification' VPD page (0x83) to a SCSI device > + * structure. This information can be used to identify the device > + * uniquely. > + */ > +void scsi_attach_vpd(struct scsi_device *sdev) > +{ > + int result, i; > + int vpd_len = 255; > + int pg83_supported = 0; > + unsigned char *vpd_buf; > + > + if (sdev->skip_vpd_pages) > + return; > +retry_pg0: > + vpd_buf = kmalloc(vpd_len, GFP_KERNEL); > + if (!vpd_buf) > + return; > + > + /* Ask for all the pages supported by this device */ > + result = scsi_vpd_inquiry(sdev, vpd_buf, 0, vpd_len); > + if (result < 0) { > + kfree(vpd_buf); > + return; > + } > + if (result > vpd_len) { > + vpd_len = result; > + kfree(vpd_buf); > + goto retry_pg0; > + } > + > + for (i = 4; i < result; i++) { > + if (vpd_buf[i] == 0x83) { > + pg83_supported = 1; > + } > + } > + kfree(vpd_buf); Given how many checks all over the place we have which EVPD pages are suppored shouldn't we have query for evpd 0, and then set flags in the scsi device which are present? Either way I think the call to query evpd 0 should be a separate function, so even if we don't store the information it's abstracted out. Also the ses code has another query for 0x83, which now could use the one attached to the scsi_device. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-02-28 17:01 ` Christoph Hellwig @ 2014-03-05 7:38 ` Hannes Reinecke 2014-03-05 19:42 ` Christoph Hellwig 0 siblings, 1 reply; 24+ messages in thread From: Hannes Reinecke @ 2014-03-05 7:38 UTC (permalink / raw) To: Christoph Hellwig Cc: James Bottomley, linux-scsi, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On 02/28/2014 06:01 PM, Christoph Hellwig wrote: > On Thu, Feb 13, 2014 at 11:07:11AM +0100, Hannes Reinecke wrote: >> EVPD page 0x83 is used to uniquely identify the device. >> So instead of having each and every program issue a separate >> SG_IO call to retrieve this information it does make far more >> sense to display it in sysfs. > > This just shows binary data from the protocol, so shouldn't it be a > binary sysfs attribute? > > In general I have to I prefer the actual text attributes, but this is > still better than having to do all the SG_IO inquirys. > Binary sysfs attributes have a rather special handling, and IIRC they should be used for direct hardware interaction only. Also the hexdump is easier to parse for the unsuspecting user. >> - * Returns 0 on success or a negative error number. >> + * Returns size of the vpg page on success or a negative error number. >> */ >> static int scsi_vpd_inquiry(struct scsi_device *sdev, unsigned char *buffer, >> u8 page, unsigned len) >> @@ -962,6 +962,9 @@ static int scsi_vpd_inquiry(struct scsi_device *sdev, unsigned char *buffer, >> int result; >> unsigned char cmd[16]; >> >> + if (len < 4) >> + return -EINVAL; > > Seems the change in calling conventions for these existing functions > should be split into a separate patch? > Ok. >> /** >> + * scsi_attach_vpd - Attach Vital Product Data to a SCSI device structure >> + * @sdev: The device to ask >> + * >> + * Attach the 'Device Identification' VPD page (0x83) to a SCSI device >> + * structure. This information can be used to identify the device >> + * uniquely. >> + */ >> +void scsi_attach_vpd(struct scsi_device *sdev) >> +{ >> + int result, i; >> + int vpd_len = 255; >> + int pg83_supported = 0; >> + unsigned char *vpd_buf; >> + >> + if (sdev->skip_vpd_pages) >> + return; >> +retry_pg0: >> + vpd_buf = kmalloc(vpd_len, GFP_KERNEL); >> + if (!vpd_buf) >> + return; >> + >> + /* Ask for all the pages supported by this device */ >> + result = scsi_vpd_inquiry(sdev, vpd_buf, 0, vpd_len); >> + if (result < 0) { >> + kfree(vpd_buf); >> + return; >> + } >> + if (result > vpd_len) { >> + vpd_len = result; >> + kfree(vpd_buf); >> + goto retry_pg0; >> + } >> + >> + for (i = 4; i < result; i++) { >> + if (vpd_buf[i] == 0x83) { >> + pg83_supported = 1; >> + } >> + } >> + kfree(vpd_buf); > > Given how many checks all over the place we have which EVPD pages are > suppored shouldn't we have query for evpd 0, and then set flags in the > scsi device which are present? > > Either way I think the call to query evpd 0 should be a separate > function, so even if we don't store the information it's abstracted out. > Hmm. That would work if we were just asking for a single page; but when we're checking several pages (like 0x83 and 0x80) we'd need either to pass in a page array or querying page 0 several times. Neither of which is very appealing. However, specifying additional flags for the individual pages might work. I'll see what I can come up with. > > Also the ses code has another query for 0x83, which now could use the > one attached to the scsi_device. > Ah. Missed that one. Will be converting it. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-05 7:38 ` Hannes Reinecke @ 2014-03-05 19:42 ` Christoph Hellwig 2014-03-06 9:01 ` Hannes Reinecke 0 siblings, 1 reply; 24+ messages in thread From: Christoph Hellwig @ 2014-03-05 19:42 UTC (permalink / raw) To: Hannes Reinecke Cc: Christoph Hellwig, James Bottomley, linux-scsi, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On Wed, Mar 05, 2014 at 08:38:01AM +0100, Hannes Reinecke wrote: > > Either way I think the call to query evpd 0 should be a separate > > function, so even if we don't store the information it's abstracted out. > > > Hmm. That would work if we were just asking for a single page; but > when we're checking several pages (like 0x83 and 0x80) we'd need > either to pass in a page array or querying page 0 several times. > Neither of which is very appealing. > > However, specifying additional flags for the individual pages might > work. I'll see what I can come up with. Passing in a bitmask or flags seems useful. Even better storing it in the scsi_device. Note that I expect the place that need to know the EVPD patch to grow slowly but steadily over time. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-05 19:42 ` Christoph Hellwig @ 2014-03-06 9:01 ` Hannes Reinecke 2014-03-07 10:11 ` Christoph Hellwig ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Hannes Reinecke @ 2014-03-06 9:01 UTC (permalink / raw) To: Christoph Hellwig Cc: James Bottomley, linux-scsi, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On 03/05/2014 08:42 PM, Christoph Hellwig wrote: > On Wed, Mar 05, 2014 at 08:38:01AM +0100, Hannes Reinecke wrote: >>> Either way I think the call to query evpd 0 should be a separate >>> function, so even if we don't store the information it's abstracted out. >>> >> Hmm. That would work if we were just asking for a single page; but >> when we're checking several pages (like 0x83 and 0x80) we'd need >> either to pass in a page array or querying page 0 several times. >> Neither of which is very appealing. >> >> However, specifying additional flags for the individual pages might >> work. I'll see what I can come up with. > > Passing in a bitmask or flags seems useful. Even better storing it in the > scsi_device. Note that I expect the place that need to know the EVPD > patch to grow slowly but steadily over time. > I am somewhat reluctant here. Adding separate flags like 'support_vpd_pg83' is a bit pointless, given that we might as well check for vpg_pg83. So the only 'proper' solution would be to add a bitmap of supported pages; however, this would be 256 bits = 32 bytes of additional space required for struct sdev. Which I'm a bit reluctant do to, as it'll be a sparse array in most cases, adding to quite some wasted space. Thoughts? Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-06 9:01 ` Hannes Reinecke @ 2014-03-07 10:11 ` Christoph Hellwig 2014-03-07 10:35 ` Hannes Reinecke 2014-03-07 10:39 ` James Bottomley 2014-03-07 10:40 ` James Bottomley 2 siblings, 1 reply; 24+ messages in thread From: Christoph Hellwig @ 2014-03-07 10:11 UTC (permalink / raw) To: Hannes Reinecke Cc: Christoph Hellwig, James Bottomley, linux-scsi, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On Thu, Mar 06, 2014 at 10:01:05AM +0100, Hannes Reinecke wrote: > I am somewhat reluctant here. > > Adding separate flags like 'support_vpd_pg83' is a bit pointless, > given that we might as well check for vpg_pg83. > > So the only 'proper' solution would be to add a bitmap of supported > pages; however, this would be 256 bits = 32 bytes of additional > space required for struct sdev. > Which I'm a bit reluctant do to, as it'll be a sparse array in most > cases, adding to quite some wasted space. Might want to keep it a local bitmap for now, but I suspect we'll want it exposed sooner or later. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-07 10:11 ` Christoph Hellwig @ 2014-03-07 10:35 ` Hannes Reinecke 2014-03-07 10:44 ` Christoph Hellwig 0 siblings, 1 reply; 24+ messages in thread From: Hannes Reinecke @ 2014-03-07 10:35 UTC (permalink / raw) To: Christoph Hellwig Cc: James Bottomley, linux-scsi, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On 03/07/2014 11:11 AM, Christoph Hellwig wrote: > On Thu, Mar 06, 2014 at 10:01:05AM +0100, Hannes Reinecke wrote: >> I am somewhat reluctant here. >> >> Adding separate flags like 'support_vpd_pg83' is a bit pointless, >> given that we might as well check for vpg_pg83. >> >> So the only 'proper' solution would be to add a bitmap of supported >> pages; however, this would be 256 bits = 32 bytes of additional >> space required for struct sdev. >> Which I'm a bit reluctant do to, as it'll be a sparse array in most >> cases, adding to quite some wasted space. > > Might want to keep it a local bitmap for now, but I suspect we'll > want it exposed sooner or later. > Agree. But for now I'd like to keep it as it is (ie without bitmap); there is no real benefit for just the two pages we're exposing right now. Or, to be precise, we _might_ be exporting if those patches ever go upstream :-( Having any indication here would be good. Can't we have a patch handling session at LSF? It really is no fun, having tons of patches and no idea whether they ever make it upstream. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-07 10:35 ` Hannes Reinecke @ 2014-03-07 10:44 ` Christoph Hellwig 0 siblings, 0 replies; 24+ messages in thread From: Christoph Hellwig @ 2014-03-07 10:44 UTC (permalink / raw) To: Hannes Reinecke Cc: Christoph Hellwig, James Bottomley, linux-scsi, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On Fri, Mar 07, 2014 at 11:35:34AM +0100, Hannes Reinecke wrote: > Agree. But for now I'd like to keep it as it is (ie without bitmap); > there is no real benefit for just the two pages we're exposing right > now. Feel free to go ahead as-is. We'll probably have to change it again soon, but we might aswell just keep it for now. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-06 9:01 ` Hannes Reinecke 2014-03-07 10:11 ` Christoph Hellwig @ 2014-03-07 10:39 ` James Bottomley 2014-03-07 10:51 ` Hannes Reinecke 2014-03-07 10:40 ` James Bottomley 2 siblings, 1 reply; 24+ messages in thread From: James Bottomley @ 2014-03-07 10:39 UTC (permalink / raw) To: hare; +Cc: linux-scsi, hch, jlinton, dgilbert, kay, kai.makisara On Thu, 2014-03-06 at 10:01 +0100, Hannes Reinecke wrote: > So the only 'proper' solution would be to add a bitmap of supported > pages; however, this would be 256 bits = 32 bytes of additional > space required for struct sdev. > Which I'm a bit reluctant do to, as it'll be a sparse array in most > cases, adding to quite some wasted space. Why per sdev? Isn't it per target? The supported EVPD page list shouldn't really vary for luns of the same target unless something very strange is happening in the array. James ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-07 10:39 ` James Bottomley @ 2014-03-07 10:51 ` Hannes Reinecke 2014-03-07 11:01 ` James Bottomley 0 siblings, 1 reply; 24+ messages in thread From: Hannes Reinecke @ 2014-03-07 10:51 UTC (permalink / raw) To: James Bottomley; +Cc: linux-scsi, hch, jlinton, dgilbert, kay, kai.makisara On 03/07/2014 11:39 AM, James Bottomley wrote: > On Thu, 2014-03-06 at 10:01 +0100, Hannes Reinecke wrote: >> So the only 'proper' solution would be to add a bitmap of supported >> pages; however, this would be 256 bits = 32 bytes of additional >> space required for struct sdev. >> Which I'm a bit reluctant do to, as it'll be a sparse array in most >> cases, adding to quite some wasted space. > > Why per sdev? Isn't it per target? The supported EVPD page list > shouldn't really vary for luns of the same target unless something very > strange is happening in the array. > Spec says it's per LUN: 7.8.16 Supported VPD Pages VPD page The Supported VDP Pages VPD page contains a list of the VPD page codes supported by the logical unit (see table 637). so we shouldn't really make any assumptions about what might be sensible or strange. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-07 10:51 ` Hannes Reinecke @ 2014-03-07 11:01 ` James Bottomley 2014-03-07 11:18 ` Douglas Gilbert 2014-03-07 13:39 ` Hannes Reinecke 0 siblings, 2 replies; 24+ messages in thread From: James Bottomley @ 2014-03-07 11:01 UTC (permalink / raw) To: hare; +Cc: linux-scsi, hch, jlinton, dgilbert, kay, kai.makisara On Fri, 2014-03-07 at 11:51 +0100, Hannes Reinecke wrote: > On 03/07/2014 11:39 AM, James Bottomley wrote: > > On Thu, 2014-03-06 at 10:01 +0100, Hannes Reinecke wrote: > >> So the only 'proper' solution would be to add a bitmap of supported > >> pages; however, this would be 256 bits = 32 bytes of additional > >> space required for struct sdev. > >> Which I'm a bit reluctant do to, as it'll be a sparse array in most > >> cases, adding to quite some wasted space. > > > > Why per sdev? Isn't it per target? The supported EVPD page list > > shouldn't really vary for luns of the same target unless something very > > strange is happening in the array. > > > Spec says it's per LUN: Specs say a lot of "interesting" things. The question is what's common practise in the field. > 7.8.16 Supported VPD Pages VPD page > The Supported VDP Pages VPD page contains a list of the VPD page > codes supported by the logical unit (see > table 637). > > so we shouldn't really make any assumptions about what might be > sensible or strange. The cardreader case is the one I think causes problems for this. Going completely the opposite direction, why do we need to cache this at all? ... it's fairly simple to request each time and it avoids worrying about the data changing because of a change in the array. James ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-07 11:01 ` James Bottomley @ 2014-03-07 11:18 ` Douglas Gilbert 2014-03-07 13:39 ` Hannes Reinecke 1 sibling, 0 replies; 24+ messages in thread From: Douglas Gilbert @ 2014-03-07 11:18 UTC (permalink / raw) To: James Bottomley, hare; +Cc: linux-scsi, hch, jlinton, kay, kai.makisara On 14-03-07 12:01 PM, James Bottomley wrote: > On Fri, 2014-03-07 at 11:51 +0100, Hannes Reinecke wrote: >> On 03/07/2014 11:39 AM, James Bottomley wrote: >>> On Thu, 2014-03-06 at 10:01 +0100, Hannes Reinecke wrote: >>>> So the only 'proper' solution would be to add a bitmap of supported >>>> pages; however, this would be 256 bits = 32 bytes of additional >>>> space required for struct sdev. >>>> Which I'm a bit reluctant do to, as it'll be a sparse array in most >>>> cases, adding to quite some wasted space. >>> >>> Why per sdev? Isn't it per target? The supported EVPD page list >>> shouldn't really vary for luns of the same target unless something very >>> strange is happening in the array. >>> >> Spec says it's per LUN: > > Specs say a lot of "interesting" things. The question is what's common > practise in the field. I have a SAS controller (not from a major) that in jbod mode sends through different physical SAS and SATA disks as different LUNs in the _same_ target. Needless to say on a target from that controller there is not a lot of commonality between its LUN's VPD page sets. Would it be possible in a sysfs VPD info directory to have a timestamp (e.g. CLOCK_MONOTONIC) of when the VPD info was read? Doug Gilbert ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-07 11:01 ` James Bottomley 2014-03-07 11:18 ` Douglas Gilbert @ 2014-03-07 13:39 ` Hannes Reinecke 1 sibling, 0 replies; 24+ messages in thread From: Hannes Reinecke @ 2014-03-07 13:39 UTC (permalink / raw) To: James Bottomley; +Cc: linux-scsi, hch, jlinton, dgilbert, kay, kai.makisara On 03/07/2014 12:01 PM, James Bottomley wrote: > On Fri, 2014-03-07 at 11:51 +0100, Hannes Reinecke wrote: >> On 03/07/2014 11:39 AM, James Bottomley wrote: >>> On Thu, 2014-03-06 at 10:01 +0100, Hannes Reinecke wrote: >>>> So the only 'proper' solution would be to add a bitmap of supported >>>> pages; however, this would be 256 bits = 32 bytes of additional >>>> space required for struct sdev. >>>> Which I'm a bit reluctant do to, as it'll be a sparse array in most >>>> cases, adding to quite some wasted space. >>> >>> Why per sdev? Isn't it per target? The supported EVPD page list >>> shouldn't really vary for luns of the same target unless something very >>> strange is happening in the array. >>> >> Spec says it's per LUN: > > Specs say a lot of "interesting" things. The question is what's common > practise in the field. > >> 7.8.16 Supported VPD Pages VPD page >> The Supported VDP Pages VPD page contains a list of the VPD page >> codes supported by the logical unit (see >> table 637). >> >> so we shouldn't really make any assumptions about what might be >> sensible or strange. > > The cardreader case is the one I think causes problems for this. Going > completely the opposite direction, why do we need to cache this at > all? ... it's fairly simple to request each time and it avoids worrying > about the data changing because of a change in the array. > Storage arrays more often than not do this, too. Especially those which export a management device. (block-device specific VPD pages really do not make sense on a management device) Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-06 9:01 ` Hannes Reinecke 2014-03-07 10:11 ` Christoph Hellwig 2014-03-07 10:39 ` James Bottomley @ 2014-03-07 10:40 ` James Bottomley 2014-03-07 10:43 ` Christoph Hellwig 2 siblings, 1 reply; 24+ messages in thread From: James Bottomley @ 2014-03-07 10:40 UTC (permalink / raw) To: Hannes Reinecke Cc: Christoph Hellwig, linux-scsi, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On Thu, 2014-03-06 at 10:01 +0100, Hannes Reinecke wrote: > So the only 'proper' solution would be to add a bitmap of supported > pages; however, this would be 256 bits = 32 bytes of additional > space required for struct sdev. > Which I'm a bit reluctant do to, as it'll be a sparse array in most > cases, adding to quite some wasted space. Why per sdev? Isn't it per target? The supported EVPD page list shouldn't really vary for luns of the same target unless something very strange is happening in the array. James ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-07 10:40 ` James Bottomley @ 2014-03-07 10:43 ` Christoph Hellwig 2014-03-07 10:57 ` James Bottomley 0 siblings, 1 reply; 24+ messages in thread From: Christoph Hellwig @ 2014-03-07 10:43 UTC (permalink / raw) To: James Bottomley Cc: Hannes Reinecke, Christoph Hellwig, linux-scsi, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On Fri, Mar 07, 2014 at 02:40:00PM +0400, James Bottomley wrote: > On Thu, 2014-03-06 at 10:01 +0100, Hannes Reinecke wrote: > > So the only 'proper' solution would be to add a bitmap of supported > > pages; however, this would be 256 bits = 32 bytes of additional > > space required for struct sdev. > > Which I'm a bit reluctant do to, as it'll be a sparse array in most > > cases, adding to quite some wasted space. > > Why per sdev? Isn't it per target? The supported EVPD page list > shouldn't really vary for luns of the same target unless something very > strange is happening in the array. It might very well vary. For one difference device types support different EVPD patches and a target might mix and match device types for LUNs. Also software targets might use individual LUNs as passthrough to physical devices, in which case they might support different EVPD pages even for the same device type. E.g. the pscsi backend for the in-kernel target might behave like that. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-07 10:43 ` Christoph Hellwig @ 2014-03-07 10:57 ` James Bottomley 0 siblings, 0 replies; 24+ messages in thread From: James Bottomley @ 2014-03-07 10:57 UTC (permalink / raw) To: Christoph Hellwig Cc: Hannes Reinecke, linux-scsi, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On Fri, 2014-03-07 at 02:43 -0800, Christoph Hellwig wrote: > On Fri, Mar 07, 2014 at 02:40:00PM +0400, James Bottomley wrote: > > On Thu, 2014-03-06 at 10:01 +0100, Hannes Reinecke wrote: > > > So the only 'proper' solution would be to add a bitmap of supported > > > pages; however, this would be 256 bits = 32 bytes of additional > > > space required for struct sdev. > > > Which I'm a bit reluctant do to, as it'll be a sparse array in most > > > cases, adding to quite some wasted space. > > > > Why per sdev? Isn't it per target? The supported EVPD page list > > shouldn't really vary for luns of the same target unless something very > > strange is happening in the array. > > It might very well vary. For one difference device types support > different EVPD patches and a target might mix and match device types for > LUNs. Yes, cardreaders can do this, I suppose, but they're not a usual case > Also software targets might use individual LUNs as passthrough > to physical devices, in which case they might support different EVPD > pages even for the same device type. E.g. the pscsi backend for the > in-kernel target might behave like that. This is a bit of a stretch too. However, I can't see an easy way of supporting the common case (same EVPD array per lun) simply and allowing for the more complex one, so I suppose if we do it it will have to be per sdev. James ^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 3/3] Add EVPD page 0x80 to sysfs 2014-02-13 10:07 [PATCHv7 0/3] Display EVPD pages in sysfs Hannes Reinecke 2014-02-13 10:07 ` [PATCH 1/3] scsi_sysfs: Implement 'is_visible' callback Hannes Reinecke 2014-02-13 10:07 ` [PATCH 2/3] Add EVPD page 0x83 to sysfs Hannes Reinecke @ 2014-02-13 10:07 ` Hannes Reinecke 2 siblings, 0 replies; 24+ messages in thread From: Hannes Reinecke @ 2014-02-13 10:07 UTC (permalink / raw) To: James Bottomley Cc: linux-scsi, Christoph Hellwig, Hannes Reinecke, Doug Gilbert, Jeremy Linton Some older devices (most notably tapes) will only report reliable information in page 0x80 (Unit Serial Number). So export this in the sysfs attribute 'vpd_pg80'. Cc: Doug Gilbert <dgilbert@interlog.com> Cc: Jeremy Linton <jlinton@tributary.com> Signed-off-by: Hannes Reinecke <hare@suse.de> --- drivers/scsi/scsi.c | 27 ++++++++++++++++++++++++++- drivers/scsi/scsi_sysfs.c | 6 ++++++ include/scsi/scsi_device.h | 2 ++ 3 files changed, 34 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c index e4cd88d..0615d94 100644 --- a/drivers/scsi/scsi.c +++ b/drivers/scsi/scsi.c @@ -1045,7 +1045,8 @@ EXPORT_SYMBOL_GPL(scsi_get_vpd_page); * scsi_attach_vpd - Attach Vital Product Data to a SCSI device structure * @sdev: The device to ask * - * Attach the 'Device Identification' VPD page (0x83) to a SCSI device + * Attach the 'Device Identification' VPD page (0x83) and the + * 'Unit Serial Number' VPD page (0x80) to a SCSI device * structure. This information can be used to identify the device * uniquely. */ @@ -1053,6 +1054,7 @@ void scsi_attach_vpd(struct scsi_device *sdev) { int result, i; int vpd_len = 255; + int pg80_supported = 0; int pg83_supported = 0; unsigned char *vpd_buf; @@ -1076,12 +1078,35 @@ retry_pg0: } for (i = 4; i < result; i++) { + if (vpd_buf[i] == 0x80) { + pg80_supported = 1; + } if (vpd_buf[i] == 0x83) { pg83_supported = 1; } } kfree(vpd_buf); + if (pg80_supported) { +retry_pg80: + vpd_buf = kmalloc(vpd_len, GFP_KERNEL); + if (!vpd_buf) + return; + + result = scsi_vpd_inquiry(sdev, vpd_buf, 0x80, vpd_len); + if (result < 0) { + kfree(vpd_buf); + return; + } + if (result > vpd_len) { + vpd_len = result; + kfree(vpd_buf); + goto retry_pg80; + } + sdev->vpd_pg80_len = result; + sdev->vpd_pg80 = vpd_buf; + } + if (pg83_supported) { retry_pg83: vpd_buf = kmalloc(vpd_len, GFP_KERNEL); diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index ca19448..03f97ab 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -784,6 +784,7 @@ show_vpd_##page(struct device *dev, struct device_attribute *attr, \ static DEVICE_ATTR(vpd_##page, S_IRUGO, show_vpd_##page, NULL); sdev_vpd_pg_attr(pg83); +sdev_vpd_pg_attr(pg80); static ssize_t show_iostat_counterbits(struct device *dev, struct device_attribute *attr, @@ -941,6 +942,10 @@ static umode_t scsi_sdev_attr_is_visible(struct kobject *kobj, !sdev->vpd_pg83) return 0; + if (attr == &dev_attr_vpd_pg80.attr && + !sdev->vpd_pg80) + return 0; + return attr->mode; } @@ -966,6 +971,7 @@ static struct attribute *scsi_sdev_attrs[] = { &dev_attr_queue_depth.attr, &dev_attr_queue_type.attr, &dev_attr_queue_ramp_up_period.attr, + &dev_attr_vpd_pg80.attr, &dev_attr_vpd_pg83.attr, REF_EVT(media_change), REF_EVT(inquiry_change_reported), diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h index b99ed35..96e63c6 100644 --- a/include/scsi/scsi_device.h +++ b/include/scsi/scsi_device.h @@ -115,6 +115,8 @@ struct scsi_device { const char * rev; /* ... "nullnullnullnull" before scan */ unsigned char vpd_pg83_len; unsigned char *vpd_pg83; + unsigned char vpd_pg80_len; + unsigned char *vpd_pg80; struct scsi_target *sdev_target; /* used only for single_lun */ unsigned int sdev_bflags; /* black/white flags as also found in -- 1.7.12.4 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCHv7 0/3][Resend] Display EVPD pages in sysfs @ 2014-02-13 10:27 Hannes Reinecke 2014-02-13 10:28 ` [PATCH 2/3] Add EVPD page 0x83 to sysfs Hannes Reinecke 0 siblings, 1 reply; 24+ messages in thread From: Hannes Reinecke @ 2014-02-13 10:27 UTC (permalink / raw) To: James Bottomley; +Cc: linux-scsi, Christoph Hellwig, Hannes Reinecke Hi all, After discussion with jejb I've dropped the EVPD parsing. So with this version we're just displaying the EVPD page 0x80 and 0x83 as hexdumps; no parsing is attempted. This drastically simplifies the patch, and we don't have to worry about any parsing errors in kernel space. Of course we'll need a parser in userspace, but that doesn't need to do any I/O. So it's still a very nice gain. (I had to redo the patchset as it no longer applied to -rc2. Hence the resend. Sorry for that.) Hannes Reinecke (3): scsi_sysfs: Implement 'is_visible' callback Add EVPD page 0x83 to sysfs Add EVPD page 0x80 to sysfs drivers/scsi/scsi.c | 104 ++++++++++++++++++-- drivers/scsi/scsi_scan.c | 3 + drivers/scsi/scsi_sysfs.c | 229 +++++++++++++++++++++++++++------------------ include/scsi/scsi_device.h | 5 + 4 files changed, 242 insertions(+), 99 deletions(-) -- 1.7.12.4 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-02-13 10:27 [PATCHv7 0/3][Resend] Display EVPD pages in sysfs Hannes Reinecke @ 2014-02-13 10:28 ` Hannes Reinecke 2014-03-02 8:34 ` Bart Van Assche 2014-03-02 8:36 ` Bart Van Assche 0 siblings, 2 replies; 24+ messages in thread From: Hannes Reinecke @ 2014-02-13 10:28 UTC (permalink / raw) To: James Bottomley Cc: linux-scsi, Christoph Hellwig, Hannes Reinecke, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara EVPD page 0x83 is used to uniquely identify the device. So instead of having each and every program issue a separate SG_IO call to retrieve this information it does make far more sense to display it in sysfs. Cc: Jeremy Linton <jlinton@tributary.com> Cc: Kay Sievers <kay@vrfy.org> Cc: Doug Gilbert <dgilbert@interlog.com> Cc: Kai Makisara <kai.makisara@kolumbus.fi> Signed-off-by: Hannes Reinecke <hare@suse.de> --- drivers/scsi/scsi.c | 79 ++++++++++++++++++++++++++++++++++++++++++---- drivers/scsi/scsi_scan.c | 3 ++ drivers/scsi/scsi_sysfs.c | 39 ++++++++++++++++++++++- include/scsi/scsi_device.h | 3 ++ 4 files changed, 116 insertions(+), 8 deletions(-) diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c index d8afec8..57105e0 100644 --- a/drivers/scsi/scsi.c +++ b/drivers/scsi/scsi.c @@ -954,7 +954,7 @@ EXPORT_SYMBOL(scsi_track_queue_full); * This is an internal helper function. You probably want to use * scsi_get_vpd_page instead. * - * Returns 0 on success or a negative error number. + * Returns size of the vpg page on success or a negative error number. */ static int scsi_vpd_inquiry(struct scsi_device *sdev, unsigned char *buffer, u8 page, unsigned len) @@ -962,6 +962,9 @@ static int scsi_vpd_inquiry(struct scsi_device *sdev, unsigned char *buffer, int result; unsigned char cmd[16]; + if (len < 4) + return -EINVAL; + cmd[0] = INQUIRY; cmd[1] = 1; /* EVPD */ cmd[2] = page; @@ -982,7 +985,7 @@ static int scsi_vpd_inquiry(struct scsi_device *sdev, unsigned char *buffer, if (buffer[1] != page) return -EIO; - return 0; + return (buffer[2] << 8) + buffer[3] + 4; } /** @@ -1009,18 +1012,18 @@ int scsi_get_vpd_page(struct scsi_device *sdev, u8 page, unsigned char *buf, /* Ask for all the pages supported by this device */ result = scsi_vpd_inquiry(sdev, buf, 0, buf_len); - if (result) + if (result < 4) goto fail; /* If the user actually wanted this page, we can skip the rest */ if (page == 0) return 0; - for (i = 0; i < min((int)buf[3], buf_len - 4); i++) - if (buf[i + 4] == page) + for (i = 4; i < min(result, buf_len); i++) + if (buf[i] == page) goto found; - if (i < buf[3] && i >= buf_len - 4) + if (i < result && i >= buf_len) /* ran off the end of the buffer, give us benefit of doubt */ goto found; /* The device claims it doesn't support the requested page */ @@ -1028,7 +1031,7 @@ int scsi_get_vpd_page(struct scsi_device *sdev, u8 page, unsigned char *buf, found: result = scsi_vpd_inquiry(sdev, buf, page, buf_len); - if (result) + if (result < 0) goto fail; return 0; @@ -1039,6 +1042,68 @@ int scsi_get_vpd_page(struct scsi_device *sdev, u8 page, unsigned char *buf, EXPORT_SYMBOL_GPL(scsi_get_vpd_page); /** + * scsi_attach_vpd - Attach Vital Product Data to a SCSI device structure + * @sdev: The device to ask + * + * Attach the 'Device Identification' VPD page (0x83) to a SCSI device + * structure. This information can be used to identify the device + * uniquely. + */ +void scsi_attach_vpd(struct scsi_device *sdev) +{ + int result, i; + int vpd_len = 255; + int pg83_supported = 0; + unsigned char *vpd_buf; + + if (sdev->skip_vpd_pages) + return; +retry_pg0: + vpd_buf = kmalloc(vpd_len, GFP_KERNEL); + if (!vpd_buf) + return; + + /* Ask for all the pages supported by this device */ + result = scsi_vpd_inquiry(sdev, vpd_buf, 0, vpd_len); + if (result < 0) { + kfree(vpd_buf); + return; + } + if (result > vpd_len) { + vpd_len = result; + kfree(vpd_buf); + goto retry_pg0; + } + + for (i = 4; i < result; i++) { + if (vpd_buf[i] == 0x83) { + pg83_supported = 1; + } + } + kfree(vpd_buf); + + if (pg83_supported) { +retry_pg83: + vpd_buf = kmalloc(vpd_len, GFP_KERNEL); + if (!vpd_buf) + return; + + result = scsi_vpd_inquiry(sdev, vpd_buf, 0x83, vpd_len); + if (result < 0) { + kfree(vpd_buf); + return; + } + if (result > vpd_len) { + vpd_len = result; + kfree(vpd_buf); + goto retry_pg83; + } + sdev->vpd_pg83_len = result; + sdev->vpd_pg83 = vpd_buf; + } +} + +/** * scsi_report_opcode - Find out if a given command opcode is supported * @sdev: scsi device to query * @buffer: scratch buffer (must be at least 20 bytes long) diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 307a811..154bb5e 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -929,6 +929,9 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned char *inq_result, if (*bflags & BLIST_SKIP_VPD_PAGES) sdev->skip_vpd_pages = 1; + if (sdev->scsi_level >= SCSI_3) + scsi_attach_vpd(sdev); + transport_configure_device(&sdev->sdev_gendev); if (sdev->host->hostt->slave_configure) { diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index 196e59a..ca19448 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -415,6 +415,7 @@ static void scsi_device_dev_release_usercontext(struct work_struct *work) scsi_target_reap(scsi_target(sdev)); + kfree(sdev->vpd_pg83); kfree(sdev->inquiry); kfree(sdev); @@ -755,7 +756,38 @@ static DEVICE_ATTR(queue_type, S_IRUGO | S_IWUSR, show_queue_type_field, store_queue_type_field); static ssize_t -show_iostat_counterbits(struct device *dev, struct device_attribute *attr, char *buf) +show_vpd_pg(const unsigned char *pg_buf, int pg_len, char *buf) +{ + int len = 0, i; + + if (!pg_buf) + return -EINVAL; + + len = 0; + for (i = 0; i < pg_len; i += 16) { + hex_dump_to_buffer(pg_buf + i, pg_len, 16, 1, + buf + len, PAGE_SIZE, false); + strcat(buf + len, "\n"); + len += strlen(buf + len); + } + return len; +} + +#define sdev_vpd_pg_attr(page) \ +static ssize_t \ +show_vpd_##page(struct device *dev, struct device_attribute *attr, \ + char *buf) \ +{ \ + struct scsi_device *sdev = to_scsi_device(dev); \ + return show_vpd_pg(sdev->vpd_##page, sdev->vpd_##page##_len, buf); \ +} \ +static DEVICE_ATTR(vpd_##page, S_IRUGO, show_vpd_##page, NULL); + +sdev_vpd_pg_attr(pg83); + +static ssize_t +show_iostat_counterbits(struct device *dev, struct device_attribute *attr, + char *buf) { return snprintf(buf, 20, "%d\n", (int)sizeof(atomic_t) * 8); } @@ -905,6 +937,10 @@ static umode_t scsi_sdev_attr_is_visible(struct kobject *kobj, !sdev->host->hostt->change_queue_type) return S_IRUGO; + if (attr == &dev_attr_vpd_pg83.attr && + !sdev->vpd_pg83) + return 0; + return attr->mode; } @@ -930,6 +966,7 @@ static struct attribute *scsi_sdev_attrs[] = { &dev_attr_queue_depth.attr, &dev_attr_queue_type.attr, &dev_attr_queue_ramp_up_period.attr, + &dev_attr_vpd_pg83.attr, REF_EVT(media_change), REF_EVT(inquiry_change_reported), REF_EVT(capacity_change_reported), diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h index d65fbec..d209f04 100644 --- a/include/scsi/scsi_device.h +++ b/include/scsi/scsi_device.h @@ -113,6 +113,8 @@ struct scsi_device { const char * vendor; /* [back_compat] point into 'inquiry' ... */ const char * model; /* ... after scan; point to static string */ const char * rev; /* ... "nullnullnullnull" before scan */ + unsigned char vpd_pg83_len; + unsigned char *vpd_pg83; unsigned char current_tag; /* current tag */ struct scsi_target *sdev_target; /* used only for single_lun */ @@ -309,6 +311,7 @@ extern int scsi_add_device(struct Scsi_Host *host, uint channel, extern int scsi_register_device_handler(struct scsi_device_handler *scsi_dh); extern void scsi_remove_device(struct scsi_device *); extern int scsi_unregister_device_handler(struct scsi_device_handler *scsi_dh); +void scsi_attach_vpd(struct scsi_device *sdev); extern int scsi_device_get(struct scsi_device *); extern void scsi_device_put(struct scsi_device *); -- 1.7.12.4 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-02-13 10:28 ` [PATCH 2/3] Add EVPD page 0x83 to sysfs Hannes Reinecke @ 2014-03-02 8:34 ` Bart Van Assche 2014-03-05 7:56 ` Hannes Reinecke 2014-03-02 8:36 ` Bart Van Assche 1 sibling, 1 reply; 24+ messages in thread From: Bart Van Assche @ 2014-03-02 8:34 UTC (permalink / raw) To: Hannes Reinecke, James Bottomley Cc: linux-scsi, Christoph Hellwig, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On 02/13/14 11:28, Hannes Reinecke wrote: > static ssize_t > -show_iostat_counterbits(struct device *dev, struct device_attribute *attr, char *buf) > +show_vpd_pg(const unsigned char *pg_buf, int pg_len, char *buf) > +{ > + int len = 0, i; > + > + if (!pg_buf) > + return -EINVAL; > + > + len = 0; > + for (i = 0; i < pg_len; i += 16) { > + hex_dump_to_buffer(pg_buf + i, pg_len, 16, 1, > + buf + len, PAGE_SIZE, false); > + strcat(buf + len, "\n"); > + len += strlen(buf + len); > + } > + return len; > +} It might be a good idea to add the output buffer length as an argument in show_vpd_pg() and to check explicitly whether or not there is sufficient space left in the output buffer. Bart. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-02 8:34 ` Bart Van Assche @ 2014-03-05 7:56 ` Hannes Reinecke 0 siblings, 0 replies; 24+ messages in thread From: Hannes Reinecke @ 2014-03-05 7:56 UTC (permalink / raw) To: Bart Van Assche, James Bottomley Cc: linux-scsi, Christoph Hellwig, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On 03/02/2014 09:34 AM, Bart Van Assche wrote: > On 02/13/14 11:28, Hannes Reinecke wrote: >> static ssize_t >> -show_iostat_counterbits(struct device *dev, struct device_attribute *attr, char *buf) >> +show_vpd_pg(const unsigned char *pg_buf, int pg_len, char *buf) >> +{ >> + int len = 0, i; >> + >> + if (!pg_buf) >> + return -EINVAL; >> + >> + len = 0; >> + for (i = 0; i < pg_len; i += 16) { >> + hex_dump_to_buffer(pg_buf + i, pg_len, 16, 1, >> + buf + len, PAGE_SIZE, false); >> + strcat(buf + len, "\n"); >> + len += strlen(buf + len); >> + } >> + return len; >> +} > > It might be a good idea to add the output buffer length as an argument > in show_vpd_pg() and to check explicitly whether or not there is > sufficient space left in the output buffer. > Good point. Will be doing so. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-02-13 10:28 ` [PATCH 2/3] Add EVPD page 0x83 to sysfs Hannes Reinecke 2014-03-02 8:34 ` Bart Van Assche @ 2014-03-02 8:36 ` Bart Van Assche 2014-03-05 7:56 ` Hannes Reinecke 1 sibling, 1 reply; 24+ messages in thread From: Bart Van Assche @ 2014-03-02 8:36 UTC (permalink / raw) To: Hannes Reinecke, James Bottomley Cc: linux-scsi, Christoph Hellwig, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On 02/13/14 11:28, Hannes Reinecke wrote: > - return 0; > + return (buffer[2] << 8) + buffer[3] + 4; Has it been considered to use get_unaligned_be16() instead of open coding this function ? Bart. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/3] Add EVPD page 0x83 to sysfs 2014-03-02 8:36 ` Bart Van Assche @ 2014-03-05 7:56 ` Hannes Reinecke 0 siblings, 0 replies; 24+ messages in thread From: Hannes Reinecke @ 2014-03-05 7:56 UTC (permalink / raw) To: Bart Van Assche, James Bottomley Cc: linux-scsi, Christoph Hellwig, Jeremy Linton, Kay Sievers, Doug Gilbert, Kai Makisara On 03/02/2014 09:36 AM, Bart Van Assche wrote: > On 02/13/14 11:28, Hannes Reinecke wrote: >> - return 0; >> + return (buffer[2] << 8) + buffer[3] + 4; > > Has it been considered to use get_unaligned_be16() instead of open > coding this function ? > Ok. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2014-03-07 13:39 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-13 10:07 [PATCHv7 0/3] Display EVPD pages in sysfs Hannes Reinecke 2014-02-13 10:07 ` [PATCH 1/3] scsi_sysfs: Implement 'is_visible' callback Hannes Reinecke 2014-02-13 10:07 ` [PATCH 2/3] Add EVPD page 0x83 to sysfs Hannes Reinecke 2014-02-28 17:01 ` Christoph Hellwig 2014-03-05 7:38 ` Hannes Reinecke 2014-03-05 19:42 ` Christoph Hellwig 2014-03-06 9:01 ` Hannes Reinecke 2014-03-07 10:11 ` Christoph Hellwig 2014-03-07 10:35 ` Hannes Reinecke 2014-03-07 10:44 ` Christoph Hellwig 2014-03-07 10:39 ` James Bottomley 2014-03-07 10:51 ` Hannes Reinecke 2014-03-07 11:01 ` James Bottomley 2014-03-07 11:18 ` Douglas Gilbert 2014-03-07 13:39 ` Hannes Reinecke 2014-03-07 10:40 ` James Bottomley 2014-03-07 10:43 ` Christoph Hellwig 2014-03-07 10:57 ` James Bottomley 2014-02-13 10:07 ` [PATCH 3/3] Add EVPD page 0x80 " Hannes Reinecke 2014-02-13 10:27 [PATCHv7 0/3][Resend] Display EVPD pages in sysfs Hannes Reinecke 2014-02-13 10:28 ` [PATCH 2/3] Add EVPD page 0x83 to sysfs Hannes Reinecke 2014-03-02 8:34 ` Bart Van Assche 2014-03-05 7:56 ` Hannes Reinecke 2014-03-02 8:36 ` Bart Van Assche 2014-03-05 7:56 ` Hannes Reinecke
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.