All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Hannes Reinecke <hare@suse.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
	linux-scsi@vger.kernel.org,
	James Bottomley <james.bottomley@hansenpartnership.com>
Subject: Re: [PATCH] scsi: vpd pages are mandatory for SPC-2
Date: Wed, 16 Mar 2016 08:47:30 +0100	[thread overview]
Message-ID: <56E90F92.8090105@suse.de> (raw)
In-Reply-To: <56E90D7F.7080106@suse.com>

On 03/16/2016 08:38 AM, Hannes Reinecke wrote:
> On 03/15/2016 10:36 PM, Martin K. Petersen wrote:
>>>>>>> "Hannes" == Hannes Reinecke <hare@suse.de> writes:
>>
>>>> I wonder how many non-compliant devices we would have to blacklist as
>>>> a result of this change...
>>
>> Hannes> But it feels even sillier having to whitelist every
>> Hannes> standards-conformant device here; I certainly was when I figured
>> Hannes> that EMC Clariion won't work properly without this patch.
>>
>> Hannes> And the idea was to mark off _misbehaving_ drives, not the other
>> Hannes> way round.
>>
>> I understand. But my concern is that the number of broken USB doodad
>> model strings far outnumber enterprise storage vendor ditto. And there
>> is no point in reversing the polarity if it increases the maintenance
>> burden.
>>
>> So I would be more comfortable with just widening the VPD whitelist and
>> assume that everything with an EMC, Dell, NetApp, whatever vendor ID is
>> compliant.
>>
> Well, yes, that's the bugger. You never know until you try.
> 
> But we have been asking for VPD pages per default for quite some
> time now from userspace (thanks to udev), and so far have had only a
> few bug reports for misbehaving devices.
> 
> And again, it just feels wrong to punish every well-behaved device
> out there, for the sake of some buggy USB implementation of a few
> bucks worth.
> 
And incidentally, for most USB drives VPD pages are already blanked out:

drivers/usb/storage/scsiglue.c:slave_configure()
[ .. ]
		/* Some devices don't handle VPD pages correctly */
		sdev->skip_vpd_pages = 1;


So it looks we're dealing with a non-issue here.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (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

  reply	other threads:[~2016-03-16  7:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-11 13:46 [PATCH] scsi: vpd pages are mandatory for SPC-2 Hannes Reinecke
2016-03-14 23:37 ` Martin K. Petersen
2016-03-15  7:28   ` Hannes Reinecke
2016-03-15  7:42     ` Christoph Hellwig
2016-03-15 17:19       ` Douglas Gilbert
2016-03-16  8:12         ` Hannes Reinecke
2016-03-15 21:36     ` Martin K. Petersen
2016-03-16  7:38       ` Hannes Reinecke
2016-03-16  7:47         ` Hannes Reinecke [this message]
2016-03-23 21:02 ` Martin K. Petersen

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=56E90F92.8090105@suse.de \
    --to=hare@suse.de \
    --cc=hare@suse.com \
    --cc=hch@lst.de \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /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.