Re: Fwd: Composite USB devices

Alan Stern <[email protected]>
Newsgroups gmane.linux.usb.user
Message-ID <[email protected]>
On Sun, 30 Sep 2007, The Almighty Pegasus Epsilon wrote:

> On 9/30/07, Alan Stern <[email protected]> wrote:
> > Strictly speaking, "character" and "block" are properties of the
> > driver, not of the device.  It's perfectly possible to have both a
> > character driver and a block driver for the same device (although they
> > better not both be loaded at the same time!).
> >
> > Anyway, only SCSI devices get sg nodes; HID devices don't.  In thie
> > case sg0 refers to the mass-storage interface of the WD MyBook device,
> > not the HID interface.  (The HID interface corresponds to the
> > /class/input/input1 device, as you can see in the log.)  sg1 refers to
> > the other, working USB device.  But this isn't particularly helpful for
> > solving your main problem.
> 
> I was under the impression that sg meant SCSI generic, ie, any kind of
> device you'd like to hook to a SCSI bus.

That's right.

> For example, I'm pretty sure
> there are SCSI keyboards, which would absolutely be a character device
> by nature, not just by driver.

True.  Although if somebody wanted to, they _could_ write a block
device driver for a keyboard.  It wouldn't be very useful.

> > But only the other device worked with the SCSI disk driver.  It's
> > undoubtedly because the other device (sg1) reports itself as type 0 =
> > disk drive and the WD device (sg0) reports itself as type 13 =
> > enclosure -- I don't know what that's supposed to mean.  Whatever it
> > is, the SCSI disk driver doesn't accept it.
> >
> > Now I don't know if this will work or if it's the right thing to do,
> > but you can try it.  Edit the kernel source file drivers/scsi/sd.c.
> > Near the beginning is a line saying
> >
> > MODULE_ALIAS_SCSI_DEVICE(TYPE_DISK);
> >
> > You can add a line saying
> >
> > MODULE_ALIAS_SCSI_DEVICE(TYPE_ENCLOSURE);
> >
> > Also, at the start of the sd_probe() function is this line:
> >
> >         if (sdp->type != TYPE_DISK && sdp->type != TYPE_MOD && sdp->type != TYPE_RBC)
> >
> > You should add into that an extra test:
> >
> >         if (sdp->type != TYPE_DISK && sdp->type != TYPE_MOD && sdp->type != TYPE_RBC
> >                         && sdp->type != TYPE_ENCLOSURE)
> >
> > That will allow the SCSI disk driver to recognize the WD device.
> > Whether it will end up working correctly is a different question...
> >
> > Alan Stern
> 
> An interesting idea, for the hell of it I tried it. It did not work,
> it simply created a "block" device node that "cat /dev/sda" (yes, it
> usurped the old sda, which is now sdb) gives no output for. Correct me
> if I'm wrong, but if it were working, it should dump a terabyte of
> random gibberish to my screen.

Yes.  Well maybe not random gibberish, but the idea is right.

> If you check the output from /proc/bus/usb/devices, it very clearly
> shows 1) the hub, 2) the external enclosure that works, and 3) the one
> that doesn't, but the one that doesn't work has two "I" lines, while
> everything else has only one:
> 
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
> 
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
> 
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> 
> the Sub=00 Prot=00 Driver=usbhid gets registered fine, and with the
> patch, it makes a corresponding (but non-functional) block node to go
> with it. but the Sub=06 Prot=50 Driver=usb-storage never makes it
> through to my /dev and that's exactly the problem.

No, you are confused.  First, you have this hangup regarding the extra
HID interface.  The fact is, it doesn't affect the mass-storage aspect
of the device at all.  The two are quite independent.

Second, the non-functional block node you saw with the patch
corresponds to interface 0, the "enclosure" driven by usb-storage --
not to the HID interface.  This probably would be easy to see from
the dmesg log, but you failed to include it.

> I think what's missing is another layer of abstraction. Are other
> Enclosures properly handled by linux-usb (as opposed to the obviously
> functional Direct-Access)?

"Enclosure" is a SCSI concept; it has nothing to do with usb-storage.  
The plain truth is that usb-storage is working fine; the difficulty you 
are encountering lies in the SCSI stack, not in the USB stack.

> Possibly of interest is the result of the patch you suggested:
> 
> sd 0:0:0:0: [sda] READ CAPACITY failed
> sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
> sd 0:0:0:0: [sda] Sense Key : 0x5 [current]
> sd 0:0:0:0: [sda] ASC=0x20 ASCQ=0x0
> sd 0:0:0:0: [sda] Test WP failed, assume Write Enabled
> sd 0:0:0:0: [sda] Asking for cache data failed
> sd 0:0:0:0: [sda] Assuming drive cache: write through
> sd 0:0:0:0: [sda] Attached SCSI disk
> 
> The old drive works the same, as far as I can tell, but other than it
> being moved down to sdb:
> 
> sd 1:0:0:0: [sdb] 156301488 512-byte hardware sectors (80026 MB)
> sd 1:0:0:0: [sdb] Write Protect is off
> sd 1:0:0:0: [sdb] Mode Sense: 27 00 00 00
> sd 1:0:0:0: [sdb] Assuming drive cache: write through
> sd 1:0:0:0: [sdb] 156301488 512-byte hardware sectors (80026 MB)
> sd 1:0:0:0: [sdb] Write Protect is off
> sd 1:0:0:0: [sdb] Mode Sense: 27 00 00 00
> sd 1:0:0:0: [sdb] Assuming drive cache: write through

Right.  This proves that my suggestion wasn't the right thing to do.

> Solved:
> Turn on CONFIG_SCSI_MULTI_LUN
> 
> Presto, works.

Proving my point that this was a SCSI problem, not a USB problem.

> Thanks to Matthew Dharm (the guy that maintains the usb goodness) for
> helping me work it out off-list.

Could you summarize your off-list discussion for the benefit of the
rest of us?

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.