On 2015-11-12 13:09, Dmitry Katsubo wrote:
> On 2015-11-11 16:16, Alan Stern wrote:
>>> Bus 001 Device 007: ID 152d:0567 JMicron Technology Corp. / JMicron USA
>>> Technology Corp.
>>> Device Descriptor:
>>> bLength 18
>>> bDescriptorType 1
>>> bcdUSB 2.10
>>> bDeviceClass 0 (Defined at Interface level)
>>> bDeviceSubClass 0
>>> bDeviceProtocol 0
>>> bMaxPacketSize0 64
>>> idVendor 0x152d JMicron Technology Corp. / JMicron USA
>>> Technology Corp.
>>> idProduct 0x0567
>>> bcdDevice 1.16
>>
>> Yes, that's the problem. The blacklist entry only covers bcdDevice =
>> 1.14. The line in unusual_devs.h should be changed from
>>
>> UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0114,
>>
>> to
>>
>> UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0116,
>>
>> Would you like to write a patch to do this?
>
> Thanks for pointing that: after you have mentioned bcdDevice writing a
> patch becomes trivial, however I also would like to test it. I will post
> a patch once I confirm the fix is working. I think the whole cycle will
> take me a week.
>
> Should I create a patch against master
> (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)?
> (unlikely there will be conflicts in unusual_devs.h).
Alan, I have difficulties with making it working. The patch that was
supposed to be trivial, does not work. The problem is that given USB
adapter is detected as "uas" device (so, driven by uas.ko module). It
took me few days to understand that, because I literally got lost in
code trying to understand why scsiglue.c:slave_configure():114 is not
called (if it would be called, then the job is done).
> scsi host7: uas
> scsi 7:0:0:0: Direct-Access JMicron Generic 0116 PQ: 0 ANSI: 6
> sd 7:0:0:0: Attached scsi generic sg4 type 0
I have added the following code, which I copied from scsiglue.c:
> --- uas.c.orig 2015-10-27 01:53:59.000000000 +0100
> +++ uas.c 2015-11-17 12:32:52.976121206 +0100
> @@ -792,10 +792,21 @@
> static int uas_slave_configure(struct scsi_device *sdev)
> {
> struct uas_dev_info *devinfo = sdev->hostdata;
> + struct us_data *us = host_to_us(sdev->host);
>
> if (devinfo->flags & US_FL_NO_REPORT_OPCODES)
> sdev->no_report_opcodes = 1;
>
> + printk(KERN_ERR "uas: " ">> uas_slave_configure(): sdev->type: 0x%02X us->fflags: 0x%02X\n", sdev->type, us->fflags);
> +
> + if (sdev->type == TYPE_DISK) {
> + /* A few buggy USB-ATA bridges don't understand FUA */
> + if (us->fflags & US_FL_BROKEN_FUA) {
> + sdev->broken_fua = 1;
> + printk(KERN_ERR "uas: " ">> fua: set sdev->broken_fua = 1\n");
> + }
> + }
> +
> scsi_change_queue_depth(sdev, devinfo->qdepth - 2);
> return 0;
> }
>
It outputs the following to dmesg:
uas: >> uas_slave_configure(): sdev->type: 0x00 us->fflags: 0x00
The show-stopper for me is to know, how the us->fflags is initialized
from list of "unusual devices". There is some magic in there, at least
this is not something on the surface. I can't get how the definition of
these unusual devices is shared between scsiglue.c and uas.c, basically,
where is the code that matches the USB vendor/product and sets
us->fflags. That code should be called before uas.c:
uas_slave_configure():792.
Many thanks.
--
With best regards,
Dmitry
--
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
