Linux USB
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Aaron Dewes <aaron.dewes@web.de>
Cc: Greg KH <gregkh@linuxfoundation.org>, linux-usb@vger.kernel.org
Subject: Re: A question about UAS
Date: Sat, 6 Mar 2021 13:25:31 -0500	[thread overview]
Message-ID: <20210306182531.GA77074@rowland.harvard.edu> (raw)
In-Reply-To: <e5c24520-bc6d-8eec-4e51-6cbc30dd59a6@web.de>

On Sat, Mar 06, 2021 at 06:27:06PM +0100, Aaron Dewes wrote:
> 
> > On Sat, Mar 06, 2021 at 05:34:32PM +0100, Aaron Dewes wrote:
> > > Hello!
> > > 
> > > Sorry if this suggestion/question sounds stupid, I don't have experience
> > > with the kernel code and this mailing list.
> > > 
> > > I'm a contributor to Umbrel (getumbrel.com), and we provide a software
> > > that allows to run a bitcoin node easily, and we've run into many people
> > > having UAS issues
> > What specific UAS issues?  And why not just fix those instead?
> 
> Sorry, I should've been more specific. When I said UAS issues, I meant
> that we've had many users who used drives that were incompatible with
> UAS, and that script is our way to detect that and fix it, because the
> kernel apparently often doesn't detect that, and I think that way would
> be a way to actually automatically detect such issues.

The kernel _does_ autodetect drives that don't claim to support uas.  
Are you saying that your users have drives which claim to support uas 
but don't actually support it?  If that's so, can you tell us what 
drives they are so we can put this information into the kernel?

And can you tell us what errors the users encounter?

Also, how can you be sure that the drives don't support uas at all, as 
opposed to supporting uas in general but not a few specific commands?

> Currently, drivers/usb/storage/unusual_devs.h disables UAS for a few
> devices, but autodetecting would be better in my opinion.

Autodetecting the way you want wouldn't really work very well.  It would 
require the user to plug in the drive and initiate some actiity on it 
which would generate a flurry of errors, so that the kernel could see 
that it should try usb-storage instead.  Then the user would have to 
unplug the drive and plug it in a second time so that usb-storage could 
manage it.

Alan Stern

  reply	other threads:[~2021-03-06 18:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-06 16:34 A question about UAS Aaron Dewes
2021-03-06 17:02 ` Greg KH
2021-03-06 17:20   ` Alan Stern
2021-03-06 17:27   ` Aaron Dewes
2021-03-06 18:25     ` Alan Stern [this message]
     [not found]       ` <1e60a591-7b7e-ca80-41cf-16fa440d7248@web.de>
2021-03-06 18:39         ` Aaron Dewes
2021-03-06 18:54           ` Greg KH
2021-03-08 13:39 ` Oliver Neukum

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=20210306182531.GA77074@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=aaron.dewes@web.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@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