Hi,
ok here is my result.
I tested it with the actual 2.6.2 kernel. It works fine :-) with my
little entry in unusual_devs.h -> I was very proud to see my email
address in the newest linux kernel :-).
However, without this entry it doesn't work. But :-) with the new entry
from Alan and without my entry in unusual_devs.h it works too.
If anyone want to have a look in the syslog file -> i can attach it.
Many greets from Karlsruhe Germany,
Matthias
> On Thu, 5 Feb 2004, James Courtier-Dutton wrote:
>
> > I thought that all this was fixed by a patch for transport.c from Alan
> > Stern, see quoted email.
> >
> > With the patch, no unusual dev entries are needed for Pentax cameras.
> > Was it rejected for some reason?
>
> It's not quite so simple.
>
> First, that patch you tested was just a preliminary test version. I've
> since submitted (what I think is a) reasonable production version, but it
> hasn't been accepted yet (hint, hint -- Matt). There's a copy of the
> patch (as169) below, with slight improvements to some comments.
>
> Also, the patch was written for 2.6. Once it is accepted and has proved
> itself among the users, it could be applied to 2.4. In the meantime, the
> unusual_devs entries are still required.
>
> Finally, the issue Matthias and Per are discussing involves not only the
> FIX_INQUIRY flag, which is what the patch addresses. Some of the earlier
> cameras may have inaccurate USB descriptors, in which case the entry would
> still be needed so that the driver would know not to use the wrong
> transport.
>
> My hope is that with this patch, not just the Pentax but many digital
> cameras will no longer need unusual_devs entries. The only way to find
> out is try it and see.
>
> Matthias and Per, this patch will probably apply to 2.4 as well as 2.6. I
> would appreciate it if you could try adding the patch and then see if your
> cameras would work with no unusual_devs entry at all.
>
> Alan Stern
>
>
>
> --- 2.6/drivers/usb/storage/transport.c.orig Mon Jan 12 14:45:38 2004
> +++ 2.6/drivers/usb/storage/transport.c Mon Jan 12 14:48:57 2004
> @@ -561,23 +561,14 @@
>
> /*
> * If we're running the CB transport, which is incapable
> - * of determining status on it's own, we need to auto-sense almost
> - * every time.
> + * of determining status on its own, we will auto-sense
> + * unless the operation involved a data-in transfer. Devices
> + * can signal most data-in errors by stalling the bulk-in pipe.
> */
> - if (us->protocol == US_PR_CB || us->protocol == US_PR_DPCM_USB) {
> + if ((us->protocol == US_PR_CB || us->protocol == US_PR_DPCM_USB) &&
> + srb->sc_data_direction != SCSI_DATA_READ) {
> US_DEBUGP("-- CB transport device requiring auto-sense\n");
> need_auto_sense = 1;
> -
> - /* There are some exceptions to this. Notably, if this is
> - * a UFI device and the command is REQUEST_SENSE or INQUIRY,
> - * then it is impossible to truly determine status.
> - */
> - if (us->subclass == US_SC_UFI &&
> - ((srb->cmnd[0] == REQUEST_SENSE) ||
> - (srb->cmnd[0] == INQUIRY))) {
> - US_DEBUGP("** no auto-sense for a special command\n");
> - need_auto_sense = 0;
> - }
> }
>
> /*
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
