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
