This has already been fixed in a later kernel. Matt
On Mon, Oct 11, 2004 at 12:03:22AM +0400, Michael Tokarev wrote: > I noticied my minolta dimage 7hi digital camera stopped > working again in 2.6.8. I'm not alone -- see this > http://sourcefrog.net/weblog/software/linux-kernel/usb/dimage7-patch.html > page, at the bottom of it -- looks like Martin also isn't > happy with it. > > While digging into the issue, I found several other problems. > > The situation with this digicam in 2.6.8 is due to changes in > usb_stor_Bulk_max_lun() and usb_stor_acquire_resources() routines. > Before, the former always returned 0 (aka "No LUNs") in case of > any errors, while now it may return -1, which is being checked > in the latter. The result is: > > usb-storage: GetMaxLUN command result is 0, data is 0 > usb-storage: probe of 1-2:1.0 failed with error -1 > > That to say: usb_stor_control_msg(US_BULK_GET_MAX_LUN), as used > in usb_stor_Bulk_max_lun(), for whatever reason returns 0 for > this device. Comment in that routine says: > > /* An answer or a STALL are the only valid responses. If we get > * something else, return an indication of error */ > > (with additional possibility of result being -EPIPE which is > handled above that comment). > > For this very camera, which does not have any LUNs anyway, > skipping a call to usb_stor_Bulk_max_lun() cures the problem. > > So I went ahead and added unusual_devs entry: > > UNUSUAL_DEV( 0x686, 0x400f, 0x0001, 0x0001, > "Minolta", "Dimage 7Hi", > US_SC_SCSI, US_PR_DEVICE, NULL, US_FL_SINGLE_LUN ), > > But it turned out this does not work, because US_FL_SINGLE_LUN is > ignored for US_PR_BULK transport, in usb_stor_acquire_resources(), > in the same place where a change has been made during 2.6.7->2.6.8 > cycle: > > if (us->protocol == US_PR_BULK) { > p = usb_stor_Bulk_max_lun(us); > if (p < 0) { > up(&us->dev_semaphore); > return p; > } > us->max_lun = p; > } > > > Looks like the condition should really be: > > (us->protocol == US_PR_BULK && !(us->flags & US_FL_SINGLE_LUN)) > > for the US_FL_SINGLE_LUN flag together with US_PR_BULK or US_PR_DEVICE > transports. Note there are severl such entries in unusual_devs.h, like > Mitsumi USB FDD, Epson 785EPX Storage, Shuttle eUSB MMC Adapter and > others, which should break similar way too. It'd be nice for the > unusual_devs file to contain descriptions as of *why* exactly the > entry has been added (e.g. device fails on US_BULK_GET_MAX_LUN > returning 0 or something). > > So, with the two above-mentioned changes (fixing US_FL_SINGLE_LUN > case in usb_stor_acquire_resources() and adding unusual_devs > entry -- btw, it seems it should be safe to add generic entry > for the whole line of 0x686 devices with this flag) fixes the > prob with Minolta Dimage 7Hi camera. But I'm not sure as of > why the change in usb_stor_Bulk_max_lun() and > usb_stor_acquire_resources() routines has been made in the first > place. Maybe we should relax usb_stor_Bulk_max_lun() a bit? > Or, maybe I don't understand what's going on (I don't pretend > I understand - this the first time i'm digging into usb internals), > and fix is different... Either way, US_BULK_GET_MAX_LUN shouldn't > return 0, it seems... > > /mjt > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver You are needink to look more evil. You likink very strong coffee? -- Pitr to Dust Puppy User Friendly, 10/16/1998
pgpcv5jPlGHCQ.pgp
Description: PGP signature
