Ok it appears older kernels do not recognize the cash drawer at all. At
least not with the hid driver.
The current kernel 2.4.22 does and I can access the driver via the hid
driver and /dev/usb/hiddev*.
I can send write events and open the cash drawer with no problems or
errors.
However it seems
Hello,
I am in the middle of writing a driver for the Cypress M8. This is a
way-too-goofy USB to serial converter.
I have a fairly clear understanding of what I need to do to make it work,
but here is where I run into issues...
The device is a 'USB to serial converter' but it is in the HID class..
From [EMAIL PROTECTED] Mon Sep 22 21:29:06 2003
On Mon, 2003-09-22 at 13:55, [EMAIL PROTECTED] wrote:
> if (sdkp->media_present) {
> sd_read_capacity(sdkp, disk->disk_name, sreq, buffer);
> if (sdp->removable)
>
Barrister Dike Ene
# 3 Allen Ave,Ikeja
Lagos-Nigeria.
Tel: 234-1-4733445
Direct Email: [EMAIL PROTECTED]
Attn: Mikal
INTRODUCTION: I am Barrister Dike Ene a
Solicitor,l know this proposal will come to you as a
surprise because we have not met before either
physically or through correspondence.
On Mon, 22 Sep 2003 [EMAIL PROTECTED] wrote:
> I have seen proposals around here for flags that are far too specific
> (like "do not ask for mode page 8"). If we go to that level of detail
> then we'll soon have fifty flags.
> Black lists, and flags that describe various ways of being broken
> are
On Mon, Sep 22, 2003 at 09:56:38PM +0200, [EMAIL PROTECTED] wrote:
> A scsi device declares its level of scsi compliance.
> Most USB storage devices are not very scsi compliant at all,
> and report 0 there.
Not exactly. The reporting of 0, 1, 2, or something random in that field
appears to be com
On Mon, 22 Sep 2003, David Brownell wrote:
> Alan Stern wrote:
> >
> > Well, the code path is easy enough to find. If you look at suspend() in
> > arch/i386/kernel/apm.c, you'll see calls to pm_send_all() and
> > device_suspend(). They both end up filtering down to the USB HC drivers.
> > The
Hi,
On Mon, Sep 22, 2003 at 12:33:05PM -0700, Greg KH wrote:
> On Mon, Sep 22, 2003 at 04:52:53PM +0200, Henning Meier-Geinitz wrote:
> > @@ -961,6 +962,7 @@
> >
> > if (interface[0].desc.bInterfaceClass != USB_CLASS_VENDOR_SPEC &&
> > interface[0].desc.bInterfaceClass != USB_CLASS_
On 22 Sep 2003, James Bottomley wrote:
>
> I think we could try 4 bytes for this (even to avoid wide residue
> problems) and see how it goes.
How about just trusting the size (and as far as I can tell from the SCSI
specs, the size is the size _without_ the header and block descriptors),
and ca
On Mon, Sep 22, 2003 at 04:52:53PM +0200, Henning Meier-Geinitz wrote:
> @@ -961,6 +962,7 @@
>
> if (interface[0].desc.bInterfaceClass != USB_CLASS_VENDOR_SPEC &&
> interface[0].desc.bInterfaceClass != USB_CLASS_PER_INTERFACE &&
> +interface[0].desc.bInterfaceClass !=
On Mon, 2003-09-22 at 13:55, [EMAIL PROTECTED] wrote:
> if (sdkp->media_present) {
> sd_read_capacity(sdkp, disk->disk_name, sreq, buffer);
> if (sdp->removable)
> sd_read_write_protect_flag(sdkp, disk->disk_name,
>
On Mon, 22 Sep 2003, Linus Torvalds wrote:
> Yes. Additional testing (making the code just increase the size of the
> transfer until it fails) shows that a size of 63 still works, but a size
> of 64 bytes fails.
>
> Actually - with a 64-byte transfer, we appear to get the 64 bytes ok, but
> th
On Mon, 22 Sep 2003, Christoph Hellwig wrote:
> If we want drivers to mess with blist flags that's the more general
> solution, yes. But the blist flags really are a target thing and
> I'd prefer to keep host drivers a bit away from this. Of course
> this doesn't really work for the usb case whe
> Basically, Andries Brouwer's strategy of making sd.c more conservative has
> been a very successful one in the past. Why not continue on that?
% I would be interested in hearing what Andries has to say. ...
% The variety of ways in which these things fail is truly amazing.
Yes.
We have just se
On Llu, 2003-09-22 at 17:09, Linus Torvalds wrote:
> - page len=1538 (pretty obviously crap)
> - header len=8 (correct)
> - block descriptor len=0 (correct)
1538 smells like they forgot to clear the top byte
---
This sf.net email is sponsor
On Mon, 22 Sep 2003, David Brownell wrote:
> > Again, this case worked fine with the sd.c changes, so it does seem to be
> > all related to "big" transfers out of the mode page.
>
> Or at any rate, "big enough" to confuse the device.
Yes. Additional testing (making the code just increase the si
On Mon, 2003-09-22 at 12:41, Linus Torvalds wrote:
> Ok, thanks. In particular, it seems to be pointless to read anything past
> byte 20 - nothing past there is even defined.
>
> What's the general sense of things - for a random SCSI device with bugs
> (and they all have _some_ sort of bugs, let
Linus Torvalds wrote:
On Mon, 22 Sep 2003, David Brownell wrote:
In this case, because it's not "EHCI + USB 2.0 hub", it's still using
the OHCI companion controller. So that wasn't a new case.
Ok. Here's the broken case with an added usb-2 hub in between. It is
indeed a bit different.
Yes. In
On Mon, 22 Sep 2003, Patrick Mansfield wrote:
> On Mon, Sep 22, 2003 at 09:09:47AM -0700, Linus Torvalds wrote:
> >
> > (Btw, where are the different mode sense pages documented?)
>
> The latest SCSI 3 draft standards are online as follows, the SCSI 2 specs
> are also online at www.t10.org (.ORG
On Mon, 22 Sep 2003, David Brownell wrote:
>
> In this case, because it's not "EHCI + USB 2.0 hub", it's still using
> the OHCI companion controller. So that wasn't a new case.
Ok. Here's the broken case with an added usb-2 hub in between. It is
indeed a bit different.
Again, this case worked
On Mon, Sep 22, 2003 at 09:09:47AM -0700, Linus Torvalds wrote:
>
> (Btw, where are the different mode sense pages documented?)
>
The latest SCSI 3 draft standards are online as follows, the SCSI 2 specs
are also online at www.t10.org (.ORG!).
For block (applies to some USB mass storage) speci
On Mon, Sep 22, 2003 at 09:44:04AM -0700, Patrick Mansfield wrote:
> The current code allows us to set or clear a given bit, but not both. So
> if we set them in slave_alloc, they can't be cleared without adding
> other flags or code.
If we want drivers to mess with blist flags that's the more gen
Martin Diehl wrote:
Unfortunately I don't see an easy way to check the sourced packed size on
the wire - except using a bus analyzer of course.
Right. There are not-easy ways to do this, involving tricked out
host controller drivers usable only to debug things like this, but
I wouldn't want to g
Linus Torvalds wrote:
On Mon, 22 Sep 2003, David Brownell wrote:
Linus Torvalds wrote:
Interesting data-point: the device is a happy EHCI camper, and is
totally able to read codepage 8 on EHCI.
However, if I put it behind a USB-1 hub on the EHCI port, I see the
same problems I saw with OHCI.
Can
On Mon, 22 Sep 2003, David Brownell wrote:
> > So it is somehow related to USB-1 vs USB-2. I don't understand why the
> > device would make a difference for something like mode page 8, but it
> > looks like it transfers data fine for _small_ mode page requests under
> > USB-1, and under USB-2 i
On Mon, Sep 22, 2003 at 05:37:32PM +0100, Christoph Hellwig wrote:
>
> What I meant is not adding a blist flags member at all but rather
> setting skip_ms_page_8 and skip_ms_page_3f from ->slave_alloc.
>
> But I probably missed something obvious :)
The current code allows us to set or clear a gi
On Mon, 22 Sep 2003, Linus Torvalds wrote:
>
> [ Andries added to the cc ]
>
> On Mon, 22 Sep 2003, Patrick Mansfield wrote:
> >
> > I can modify the patch for that.
>
> How about just making the sd.c layer more robust? That has worked well in
> the past, and it seems wrong to have to add mor
On Mon, Sep 22, 2003 at 11:50:47AM -0400, Alan Stern wrote:
> Interestingly, my original patch was a lot like you describe. It can be
> found in
>
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106340167723122&w=2
Yupp, that's what I meant. Much less complicated :)
-
On Mon, Sep 22, 2003 at 08:49:30AM -0700, Patrick Mansfield wrote:
> On Mon, Sep 22, 2003 at 04:11:04PM +0100, Christoph Hellwig wrote:
> > On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote:
> > > Patch looks mostly fine to me, but please all flags should be unsigned instead
> > > o
On Mon, 22 Sep 2003, David Brownell wrote:
>
> Linus Torvalds wrote:
> > Interesting data-point: the device is a happy EHCI camper, and is
> > totally able to read codepage 8 on EHCI.
> >
> > However, if I put it behind a USB-1 hub on the EHCI port, I see the
> > same problems I saw with OHCI.
>
On Mon, 22 Sep 2003, Patrick Mansfield wrote:
> On Mon, Sep 22, 2003 at 11:50:47AM -0400, Alan Stern wrote:
>
> > I don't care which version of the patch gets accepted, so long as
> > _something_ is done. Patrick, what do you think?
>
> I would rather we can modify the flags for any broken devi
Linus Torvalds wrote:
On Mon, 22 Sep 2003, Alan Stern wrote:
This problem has been cropping up with many, many USB storage devices.
Interesting data-point: the device is a happy EHCI camper, and is totally
able to read codepage 8 on EHCI.
However, if I put it behind a USB-1 hub on the EHCI p
[ Andries added to the cc ]
On Mon, 22 Sep 2003, Patrick Mansfield wrote:
>
> I can modify the patch for that.
How about just making the sd.c layer more robust? That has worked well in
the past, and it seems wrong to have to add more and more flags.
In particular, while hunting down the usb-1
Alan Stern wrote:
On Sun, 21 Sep 2003, David Brownell wrote:
Why was this routine called twice? (Don't be fooled by the timestamps; I
think the "suspend D4 --> D3" message was created during the suspend but
not read by syslogd until after the resume.)
That's happened for as long as I remember (
On Mon, Sep 22, 2003 at 11:50:47AM -0400, Alan Stern wrote:
> Interestingly, my original patch was a lot like you describe. It can be
> found in
>
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106340167723122&w=2
>
> Patrick Mansfield later beefed it up to the version you were looking at.
>
On Mon, 22 Sep 2003, Christoph Hellwig wrote:
> On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote:
> > Patch looks mostly fine to me, but please all flags should be unsigned instead
> > of signed and scsi_devinfo.h needs some inclusion guards.
>
> Actually I think it could be made
On Mon, Sep 22, 2003 at 04:11:04PM +0100, Christoph Hellwig wrote:
> On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote:
> > Patch looks mostly fine to me, but please all flags should be unsigned instead
> > of signed and scsi_devinfo.h needs some inclusion guards.
>
> Actually I th
Linus Torvalds wrote:
I'll try to change that max size thing (maybe it really always wants to
transfer just the header, or then the full page?), but regardless it looks
like OHCI is a bit fragile.
Usually this sort of stuff is the device being fragile. OHCI can
only report that the USB protocol
On Mon, 22 Sep 2003, Alan Stern wrote:
>
> This problem has been cropping up with many, many USB storage devices.
Interesting data-point: the device is a happy EHCI camper, and is totally
able to read codepage 8 on EHCI.
However, if I put it behind a USB-1 hub on the EHCI port, I see the same
On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote:
> Patch looks mostly fine to me, but please all flags should be unsigned instead
> of signed and scsi_devinfo.h needs some inclusion guards.
Actually I think it could be made much simpler by killing the per-template
bflags and just
On Sun, 21 Sep 2003, David Brownell wrote:
> Alan Stern wrote:
> > Here's a piece from my system log, when I did "apm --suspend". The
> > usb_device_suspend/resume messages are things I added for debugging.
>
> > Why was this routine called twice? (Don't be fooled by the timestamps; I
> > thi
Hi,
Added test for USB_CLASS_CDC_DATA which is used by some fingerprint
scanners.
Bye,
Henning
--- linux-2.6.0-test5.newids9/drivers/usb/image/scanner.c 2003-09-22
11:12:50.0 +0200
+++ linux-2.6.0-test5.device_class/drivers/usb/image/scanner.c 2003-09-22
11:30:05.0 +0
Hi,
Added vendor/product ids for Canon, HP, Microtek, Mustek, Siemens,
UMAX, and Visioneer scanners.
Bye,
Henning
diff -u -r linux-2.6.0-test5.dereg/drivers/usb/image/scanner.c
linux-2.6.0-test5.newids9/drivers/usb/image/scanner.c
--- linux-2.6.0-test5.dereg/drivers/usb/image/scanner.c 2003-
Hi,
Balancing usb_register_dev/usb_deregister_dev in probe_scanner when a
fail condition occours (Daniele Bellucci).
Bye,
Henning
--- linux-2.6.0-test5.ret_val/drivers/usb/image/scanner.c 2003-09-12
19:09:14.0 +0200
+++ linux-2.6.0-test5.dereg/drivers/usb/image/scanner.c 2003-09
Hi,
Report back return codes of usb_register and usb_usbmit_urb instead of
-1 or -ENONMEM (Daniele Bellucci).
Bye,
Henning
--- linux-2.6.0-test5.static/drivers/usb/image/scanner.c2003-09-12
18:58:12.0 +0200
+++ linux-2.6.0-test5.ret_val/drivers/usb/image/scanner.c 2003-0
Hi,
Use static declarations for usb_scanner_init/usb_scanner_exit
(Daniele Bellucci).
Bye,
Henning
--- linux-2.6.0-test5/drivers/usb/image/scanner.c 2003-09-08 21:49:58.0
+0200
+++ linux-2.6.0-test5.static/drivers/usb/image/scanner.c2003-09-12
18:58:12.0 +0200
This problem has been cropping up with many, many USB storage devices.
They just don't handle MODE-SENSE page 8 correctly. Some devices are okay
with a 128-byte transfer and others aren't. Some are okay with a 64-byte
transfer and others aren't. Some are okay transferring the actual size of
th
On Mon, Sep 22, 2003 at 10:25:28AM -0400, Alan Stern wrote:
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106366112221507&w=2
>
> At the moment, this MODE-SENSE page 8 is probably the most severe
> outstanding problem with the usb-storage driver. I'm all in favor of the
> patch being adopted (
On Mon, 22 Sep 2003, Matthew Dharm wrote:
>
> You say this worked with UHCI 'some time ago'? Perhaps that was before all
> this mode page 8 stuff got settled?
Quite possible. But it definitely works with EHCI today, so it's still a
HC issue..
Linus
-
At http://www.linux-usb.org/ .
--
/+-\
|Stephen J. Gowdy | SLAC, MailStop 34, |
|http://www.slac.stanford.edu/~gowdy/ | 2575 Sand Hill Road, |
|http://calendar.yahoo.com/gowdy | Menlo Park CA 94025, USA
On Mon, Sep 22, 2003 at 02:02:38AM -0700, Pier Paolo Glave wrote:
> After a long session of debugging with printk, I found
> out that in those cases one of the calls to
> schedule_timeout() (issued when waiting for an URB
> response in usb.c) never returns.
> I can avoid this situation by removing
Hi all,
I have a problem of deadlock at kernel startup,
related to USB keyboard and mouse handling.
I'm working on 2.4.18-rmk6 on a board based on Samsung
S3C2800X, which is an ARM CPU.
My USB controller is a VIA VT6202 (UHCI interface).
The system hangs in most times when I boot my system
with k
On Sun, Sep 21, 2003 at 09:57:06PM -0700, Linus Torvalds wrote:
>
> On Sun, 21 Sep 2003, Linus Torvalds wrote:
> > >
> > > Odd... why do we ask for the first 8 bytes of page 8? The header alone is
> > > 8 bytes anyway, the response looks good.
> >
> > It tries to read the cache type. It tri
Hello Niels,
I reported this problems (together with an other guy)
some months ago on 2.4.20. It was quite reproducible by copy large files
during
webcam (e.g. cp /dev/hda1 /dev/null)
I did not understand all details, but as far as I know the bug is not fixed.
I changed to
the 2.6.0 test kernel f
54 matches
Mail list logo
