> To "turn on" the camera i do this:
> w9968cf_set_reg(0xbf10, 0x);
>
> The kernel message is:
> usb-uhci.c: interrupt, status 3, frame# 486
> W996[87]CF: w9968cf_set_reg() failed (value BF10, index
> 00, error -110).
Hi,
The camera must be powered on first before some of the
registers work.
This patch removes the (often troublesome) usb_stor_transfer_length()
function. Greg, please apply.
We've finally gotten all the command initiators to send the correct values
in the srb->request_bufflen field, so this is no longer needed.
There are probably some sanity checks that can also be re
Hello, i am writing an usb driver for my webcam and i need to know
why usb_control_msg() fails when i try to set a register.
Specifications say:
"Vendor-Specific requests:
The W9968CF supports two vendor-specific requests for the control registers
In/Out transfers on the default pipe (endpoi
Welcome
I have to write an usb2.0 driver in Linux (slackware distribution) for
Cypress chip cy7c68013-100ac. Anyone could help me ? In forward reply I will
describe my work more precisely...
Best regards from Poland
---
This sf.net email is spo
[EMAIL PROTECTED] wrote:
There are at least four replies:
The factual: It seems you are unaware of the present USB storage code.
For many devices the INQUIRY response is entirely fabricated.
I'm aware of this, but you were complaining of a new device
which you got, so I assumed the INQUIRY res
Zwane Mwaikambo writes:
> This looks related to something i also bumped into
>
> scsi scan: host 2 channel 0 id 0 lun 0 identifier too long
Sounds familiar. Please try the below (on 2.5.54).
Andries
diff -u --recursive --new-file -X /linux/dontdiff a/drivers/scsi/scsi_scan.c
b/drivers/scsi/sc
[EMAIL PROTECTED] wrote:
>
> The SCSI code has no means of knowing the actual length transferred,
> so has no choice but to believe the length byte in the reply.
> But the USB code does the transferring itself, and knows precisely
> how many bytes were transferred. If 36 by
On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote:
> The SCSI code has no means of knowing the actual length transferred,
> so has no choice but to believe the length byte in the reply.
> But the USB code does the transferring itself, and knows precisely
> how many bytes were transferred. If 36 bytes wer
[EMAIL PROTECTED] wrote:
The SCSI code has no means of knowing the actual length transferred,
so has no choice but to believe the length byte in the reply.
But the USB code does the transferring itself, and knows precisely
how many bytes were transferred. If 36 bytes were transferred and
the addi
Matthew Dharm writes:
> Instead of fixing this in usb-storage, I think I would rather make
> scsi_scan.c just assume a minimum of 36.
No, because (for SCSI-1) the minimum is 5.
> Or, put another way, if the first request indicates less than 36, why
> should we do a second request? We already ha
10 matches
Mail list logo
