On Mon, Dec 08, 2003 at 02:15:38PM +0100, [EMAIL PROTECTED] wrote: > > I have a more fundamental question: Why do we need lun detection? > > You wrote > > info->lun = srb->device->lun; > > and maybe that would work. These are two very different animals > in principle, but maybe it is true that if the datafab is used > for two devices the usb 0,1 are mapped this way, randomly, to > the datafab 0,1. While if the datafab is used for one device > maybe it does not matter which lun is used. > > That last sentence expresses my uncertainty: it is conceivable > that datafab.c is called with srb->device->lun == 1 while > only datafab lun 0 works. That would be a case where we need > detection.
Forgive me, it's been a long time since I've looked at this USB stuff and I've just now been CC'd on this conversation. The "LUN" stuff is a hack at best and I am by no means convinced that it was the right thing to do. It was added back when the driver was in development in order to help an early user get his multi-slot reader to function. I no longer have his USB traffic dump files but it appeared that his windows driver was probing LUNs prior to doing anything useful with the device. In his case, the CF slot corresponded to second LUN probed. The first LUN was presumably his smartmedia slot which spoke some entirely different protocol and refused to acknowledge the identify device query. An unwanted side effect of this code, as you've noted, was that for single slot CF readers, the LUN code ends up detecting phantom devices. That is, the device would respond successfully to an identify device query regardless of which LUN it was sent to. My hardware doesn't behave this way but then it's a fairly old reader. I was never able to nail down a particular query issued by a windows driver that indicates whether or not additional LUNs should be probed. I, perhaps incorrectly, assumed that these probes were enabled at compile-time by companies only if the company's hardware required them. Obviously this would be difficult to do in the Linux driver where one driver must work for everybody with a reader based on this chipset so the probes were enabled all the time. It's not pretty code and I would have much preferred something more intelligent but I was out of ideas and looking at the windows driver traffic didn't lend any additional insight. Jimmie -- Jimmie Mayfield http://www.sackheads.org/mayfield email: [EMAIL PROTECTED] My mail provider does not welcome UCE -- http://www.sackheads.org/uce ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
