From: Hannes Reinecke <hare@suse.de>
To: Oliver Neukum <oneukum@suse.de>
Cc: Alan Stern <stern@rowland.harvard.edu>, linux-scsi@vger.kernel.org
Subject: Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
Date: Thu, 12 Sep 2013 07:56:02 +0200 [thread overview]
Message-ID: <52315772.8040402@suse.de> (raw)
In-Reply-To: <1378821408.13541.26.camel@linux-fkkt.site>
On 09/10/2013 03:56 PM, Oliver Neukum wrote:
> Hi Hannes,
>
> you objected to this patch saying there's a possibilty that
> HS devices may also need this feature, which would require
> a quirk. Does this mean that the patch is acceptable only
> with an additional predefined quirk, or do you insist that all
> devices be handled with quirks?
>
> Regards
> Oliver
>
> +++ b/drivers/usb/storage/scsiglue.c
> @@ -211,8 +211,11 @@ static int slave_configure(struct
> scsi_device0*sdev)
> /*
> * Many devices do not respond properly to READ_CAPACITY_16.
> * Tell the SCSI layer to try READ_CAPACITY_10 first.
> + * However some USB 3.0 drive enclosures return capacity
> + * modulo 2TB
> */
> - sdev->try_rc_10_first = 1;
> + if (us->pusb_dev->speed < USB_SPEED_SUPER)
> + sdev->try_rc_10_first = 1;
>
> /* assume SPC3 or latter devices support sense size > 18 */
> if (sdev->scsi_level > SCSI_SPC_2)
>
Predefined quirks is okay.
My main objection here is that the original issue most likely is a
buggy firmware, so there is a _very_ good chance that it'll be
resolved in firmware in the near future.
At the same time, other firmwares might continue to not support
READ_CAPACITY_16 while enabling HS.
So both issues really should be kept separate, which'll warrant a
new flag.
Which of course could be set to on per default on HS devices.
As long as we can switch is off again ...
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
prev parent reply other threads:[~2013-09-12 5:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-10 13:56 READ_CAPACITY_16 vs. READ_CAPACITY_10 Oliver Neukum
2013-09-10 17:25 ` Alan Stern
2013-09-10 20:44 ` Oliver Neukum
2013-09-11 14:14 ` Alan Stern
2013-09-11 15:05 ` Oliver Neukum
2013-09-11 15:42 ` Alan Stern
2013-09-11 15:56 ` Steve Magnani
2013-09-12 5:47 ` Hannes Reinecke
2013-09-16 12:41 ` Oliver Neukum
2013-09-12 5:56 ` Hannes Reinecke [this message]
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=52315772.8040402@suse.de \
--to=hare@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=oneukum@suse.de \
--cc=stern@rowland.harvard.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).