public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Gerd Hoffmann <kraxel@redhat.com>
Cc: David Webb <djw@noc.ac.uk>,
	linux-usb@vger.kernel.org, linux-scsi@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] uas: Add a new NO_REPORT_LUNS quirk
Date: Thu, 31 Mar 2016 17:03:03 +0200	[thread overview]
Message-ID: <56FD3C27.2050708@redhat.com> (raw)
In-Reply-To: <1459435682.2958.19.camel@HansenPartnership.com>

Hi,

On 31-03-16 16:48, James Bottomley wrote:
> On Thu, 2016-03-31 at 14:22 +0200, Hans de Goede wrote:
>> Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with
>> an usb-id of: 0bc2:331a, as these will fail to respond to a
>> REPORT_LUNS command.
>
> Actually, if we're sending them a report luns command, they must be
> reporting in at SCSI-3 SPC or higher.  Should we be quirking them down
> to SCSI-2 instead because it reduces the risk of running into something
> else they're not doing from the SPC command set?

These are fairly new devices, so they should really be scsi3, but the
usb <-> sata bridge (presumably) used does not seem to like report_luns.

Note that usb-storage simple sets no_report_luns conditionally for all
usb-storage devices. The scsi people have repeatedly asked me to not
do this kinda blanket blacklisting for uas devices, because they hope
that uas will allow them to more or less do proper scsi over usb, so
we end up with blacklisting specific commands every now and then to
get devices to work.

Regards,

Hans

  reply	other threads:[~2016-03-31 15:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-31 12:22 [PATCH] uas: Add a new NO_REPORT_LUNS quirk Hans de Goede
     [not found] ` <1459426971-11927-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-31 14:17   ` Alan Stern
2016-03-31 14:48 ` James Bottomley
2016-03-31 15:03   ` Hans de Goede [this message]
     [not found]     ` <56FD3C27.2050708-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-31 15:11       ` James Bottomley
2016-03-31 15:23         ` Hans de Goede
     [not found]           ` <56FD40FE.3030302-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-31 17:35             ` David Webb

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=56FD3C27.2050708@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=djw@noc.ac.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=kraxel@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stable@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox