Well, still, my two cents here, is it really that if you have UAS in a
module and you don't load it but connect an UAS capable device, this
device is not enumerated rather than downgraded to usb-storage?
2018-03-21 19:10 GMT+01:00 Mike Lothian <mike@xxxxxxxxxxxxxx>:
> So this is a brown paper bag moment, I don't use usb-uas on my laptop,
> so the kernel always does the right thing (I've enabled it now I know
> about it)
>
> The router has usb-uas compiled as a module, but didn't have it
> installed, it's not one of the default ones it seems
>
> After installing kmod-usb-storage-uas everything kicked into life
>
> Sorry for the noise
>
> On 21 March 2018 at 17:55, Mike Lothian <mike@xxxxxxxxxxxxxx> wrote:
>> Lastly here's the lsusb -v and dmesg from 4.9.87 on the router without
>> the quirk added
>>
>> On 21 March 2018 at 17:50, Mike Lothian <mike@xxxxxxxxxxxxxx> wrote:
>>> Also here's the kernel config for the router, it's now 4.9.87
>>>
>>>
>>>
>>> On 21 March 2018 at 17:23, Menion <menion@xxxxxxxxx> wrote:
>>>> Yes that was the point.
>>>> Curious that the device worked fine in 17.01.4 and not in snapshot,
>>>> but in 17.01.4 do you remember if it went in UAS or USB-STORAGE mode?
>>>> I cannot answer here, but I am wondering if it is possible that if the
>>>> kernel is compiled without UAS support, then a device showing UASP
>>>> capability won't get enumerated at all instead of being downgraded to
>>>> usb-storage.
>>>>
>>>> 2018-03-21 18:19 GMT+01:00 Mike Lothian <mike@xxxxxxxxxxxxxx>:
>>>>> Sorry I'm not sure what you mean by that, would you like the output of
>>>>> lsusb -v before and after the quirk is added? And again from my
>>>>> laptop?
>>>>>
>>>>> I'd like to point the device worked fine when running a 4.4 kernel on
>>>>> LEDE 17.01.4
>>>>>
>>>>> On 21 March 2018 at 17:10, Menion <menion@xxxxxxxxx> wrote:
>>>>>> Then it is so strange, it is completely dead from USB host perspective
>>>>>> in UASP mode
>>>>>> What lsusb shows when it is attached in UASP mode?
>>>>>> Can you test it with some "regular" host with USB 3.0, like a PC?
>>>>>>
>>>>>> 2018-03-21 18:07 GMT+01:00 Mike Lothian <mike@xxxxxxxxxxxxxx>:
>>>>>>> Sorry, yes that was me disconnecting the device and reconnecting it,
>>>>>>> just to confirm that it was the quirk that was fixing things (I might
>>>>>>> not have connected it into the same port)
>>>>>>>
>>>>>>> I am changing the quirks in the modules config and reattaching,
>>>>>>> modprobe on this device doesn't seem to let me specify options
>>>>>>>
>>>>>>> It's a USB3 caddy that has its own power supply, that you can put any
>>>>>>> SATA hard disk into, I currently have a 1.5TB drive in it.
>>>>>>>
>>>>>>> On 21 March 2018 at 17:00, Menion <menion@xxxxxxxxx> wrote:
>>>>>>>> I see a disconnect from port 4:1 of some un-enumerated device then
>>>>>>>> connect to port 2:1 with UAS blacklist:
>>>>>>>>
>>>>>>>> [ 281.814757] usb 4-1: USB disconnect, device number 2
>>>>>>>> [ 283.418292] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>>>>>>>> [ 482.153319] usb 2-1: USB disconnect, device number 2
>>>>>>>> [ 484.250856] usb 2-1: UAS is blacklisted for this device, using
>>>>>>>> usb-storage instead
>>>>>>>> [ 484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
>>>>>>>> [ 484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: c00000
>>>>>>>> [ 484.264432] scsi host1: usb-storage 2-1:1.0
>>>>>>>>
>>>>>>>> Are you peraphs changing the quirks in the modules config and reattach
>>>>>>>> the device?
>>>>>>>> Anyhow I see some strange reset from the USB host. What is this
>>>>>>>> device? Perhaps some self-powered external HDD?
>>>>>>>>
>>>>>>>> 2018-03-21 17:56 GMT+01:00 Mike Lothian <mike@xxxxxxxxxxxxxx>:
>>>>>>>>> It had both, as did my follow up, the follow up should be more clear though
>>>>>>>>>
>>>>>>>>> On 21 March 2018 at 16:45, Menion <menion@xxxxxxxxx> wrote:
>>>>>>>>>> You sent the dmesg with quirks :u enabled
>>>>>>>>>> We need the one without quirks :u, when the device takes UAS driver
>>>>>>>>>> Bye
>>>>>>>>>>
>>>>>>>>>> 2018-03-21 17:41 GMT+01:00 Mike Lothian <mike@xxxxxxxxxxxxxx>:
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> Please find attached my dmesg
>>>>>>>>>>>
>>>>>>>>>>> Cheers
>>>>>>>>>>>
>>>>>>>>>>> Mike
>>>>>>>>>>>
>>>>>>>>>>> On 21 March 2018 at 16:12, Oliver Neukum <oneukum@xxxxxxxx> wrote:
>>>>>>>>>>>> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
>>>>>>>>>>>>> > I'm guessing it doesn't quite match up with the rules already in place
>>>>>>>>>>>>> > in uas-detect.h
>>>>>>>>>>>>>
>>>>>>>>>>>>> That device has a quirk already as a "normal" usb-storage device.
>>>>>>>>>>>>> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
>>>>>>>>>>>>> for mandatory READ_CAPACITY_16")
>>>>>>>>>>>>
>>>>>>>>>>>> That should cause different symptoms.
>>>>>>>>>>>>
>>>>>>>>>>>>> > Looks like it's an ASM1053 that can't do UAS
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, it's not a UAS device, is someone trying to recycle device ids to do
>>>>>>>>>>>>> different things now? That's not good :(
>>>>>>>>>>>>
>>>>>>>>>>>> The second interface looks like UAS though. The second interface looks
>>>>>>>>>>>> like UAS though. What exactly does happen when you ennumerate?
>>>>>>>>>>>> Dmesg please.
>>>>>>>>>>>>
>>>>>>>>>>>> We may need some exotic logic for these devices.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Oliver
>>>>>>>>>>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
