Re: scsi-sd fails with error "Invalid field in cdb" for SATA-to-USB adapter JMicron

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 17 Nov 2015, Dmitry Katsubo wrote:

> 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);

That line is completely inappropriate for uas; it applies only to 
usb-storage.  Don't add it.

> > 
> >         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) {

Here you need to test devinfo->flags & 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.

The code that sets devinfo->flags is in uas_probe().  The flags value 
comes from uas_use_uas_driver() in uas_detect.h.  The table used by uas 
is stored in unusual_uas.h, not unusual_devs.h, so you'll have to add a 
completely new entry there.

Actually, you should modify both unusual_*.h files, because someone 
might want to use that device with the usb-storage driver rather than 
the uas driver.

Alan Stern

--
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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux