On Tue, May 14, 2002 at 12:57:08PM +0200, [EMAIL PROTECTED] wrote:
An EE would have disassembled the device long before now
In fact I opened it. The outside had no markings at all.
Inside there were strings HT B 94V-O with fat HT,
and 190N01417V102. The chip has 44 pins and was
covered
You must be a CompSci guy.
Even worse: a mathematician.
Not by chance working on a digital camera kiosk project ???
An EE would have disassembled the device long before now
In fact I opened it. The outside had no markings at all.
Inside there were strings HT B 94V-O with fat HT,
and
On Sun, May 12, 2002 at 08:37:49PM -0400, Johannes Erdfelt wrote:
On Mon, May 13, 2002, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Playing with some strange device with vendor protocol,
I find that alt-uhci crashes the kernel without any messages
or information. (No oops, just dead.)
On
But, you're absolutely right about an error message being preferable to
a dead system. The patch is simple enough and I've attached it to the
bottom of this message.
Well, since 0 is not an illegal value as specified in the USB spec, I
think we should do this check in the
On Mon, May 13, 2002 at 10:24:04AM +0200, [EMAIL PROTECTED] wrote:
Hmm. So arbitrary. Why only this single test?
uhci_submit_urb() starts with several sanity checks.
Only one of those checks needs to be done in uhci_submit_urb(), the
urb-dev-bus-hcpriv one, as the others are already
Well, since 0 is not an illegal value as specified in the USB spec, I
think we should do this check in the usb_submit_urb() call, not force it
to be duplicated in all host drivers.
In fact there are a lot of checks in the hcd framework
already -- hcd.c has hcd_submit_urb() checking quite
a
Why does the kernel die?
The host controller authors can answer this one
Looking at the source we see in uhci.c:uhci_submit_bulk()
the loop
do {
...
len -= maxsze;
...
} while (len 0);
When maxsze is zero this loop will take a
On Sun, May 12, 2002, Greg KH [EMAIL PROTECTED] wrote:
Well, since 0 is not an illegal value as specified in the USB spec, I
think we should do this check in the usb_submit_urb() call, not force it
to be duplicated in all host drivers. So how about the patch below?
I'm fine with moving it
The next step is making this device actually do something.
Well, if you need to talk to that endpoint, then you'll need to kludge
it by hacking the core to ignore the wMaxPacketSize value and hardcoding
it to another value.
It is not wMaxPacketSize that is zero, it is
On Mon, May 13, 2002, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The next step is making this device actually do something.
Well, if you need to talk to that endpoint, then you'll need to kludge
it by hacking the core to ignore the wMaxPacketSize value and hardcoding
it
On Mon, May 13, 2002 at 02:44:19AM -0700, David Brownell wrote:
Well, since 0 is not an illegal value as specified in the USB spec, I
think we should do this check in the usb_submit_urb() call, not force it
to be duplicated in all host drivers.
In fact there are a lot of checks in the
On Mon, May 13, 2002 at 11:09:08AM -0400, Johannes Erdfelt wrote:
Also, your patch on 2.5 would cause urbs to leak if that if () call was
ever true.
How so?
The call to usb_get_urb() was right before that if statement, and you
didn't have a matching usb_put_urb() in the error path.
On Mon, May 13, 2002 at 11:35:56AM -0400, Johannes Erdfelt wrote:
Hmm, I wonder what else has changed in the 2.5 version.
The addition of int mem_flags to uhci_submit_urb() and a bit of logic
changes for the low speed pipe, and the usb_get_urb() logic is all the
differences that I see.
On Mon, May 13, 2002, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
But, you're absolutely right about an error message being preferable to
a dead system. The patch is simple enough and I've attached it to the
bottom of this message.
Well, since 0 is not an illegal value as
Are you using an invalid endpoint? You're right, MxPS is not zero in
any of those, but since it parsed alright, there's no reason why
dev-exmaxpacketin/out should be 0.
It is not clear at all why dev-epmaxpacketin/out should be
anything but 0. This array is never initialized as far as
I can
Well, since 0 is not an illegal value as specified in the USB spec, I
think we should do this check in the usb_submit_urb() call, not force it
to be duplicated in all host drivers.
In fact there are a lot of checks in the hcd framework
already -- hcd.c has hcd_submit_urb()
If the plan is to make all of the HCD's use hcd.c, then why do we have
hcd_submit_urb and usb_submit_urb?
We should be able to move a variety of checks into usb_submit_urb.
That'd be one way to handle this particular set of issues, yes.
And in fact the one I'd been assuming I'd do before
On Mon, May 13, 2002, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Are you using an invalid endpoint? You're right, MxPS is not zero in
any of those, but since it parsed alright, there's no reason why
dev-exmaxpacketin/out should be 0.
It is not clear at all why dev-epmaxpacketin/out
On Mon, May 13, 2002, David Brownell [EMAIL PROTECTED] wrote:
If the plan is to make all of the HCD's use hcd.c, then why do we have
hcd_submit_urb and usb_submit_urb?
We should be able to move a variety of checks into usb_submit_urb.
That'd be one way to handle this particular set of
Are you using an invalid endpoint? You're right, MxPS is not zero in
any of those, but since it parsed alright, there's no reason why
dev-exmaxpacketin/out should be 0.
It is not clear at all why dev-epmaxpacketin/out should be
anything but 0. This array is never initialized as far as
Wow... old code.
The SDDR-09 driver is, well, not one of our finest works. :)
We call usb_set_configuration() to change to a specific alternate
configuration for this device. Is there some sort of problem with calling
that function?
Matt
On Mon, May 13, 2002 at 01:40:59PM -0400, Johannes
On Mon, May 13, 2002, Matthew Dharm [EMAIL PROTECTED] wrote:
Wow... old code.
The SDDR-09 driver is, well, not one of our finest works. :)
We call usb_set_configuration() to change to a specific alternate
configuration for this device. Is there some sort of problem with calling
that
usb_new_device - usb_set_configuration - usb_set_maxpacket
Yes, for config 0.
wonder if usb-storage is using a different configuration
without calling usb_set_configuration?
Yes, that is what happens.
Andries
___
Have big pipes?
The SDDR-09 driver is, well, not one of our finest works. :)
We call usb_set_configuration() to change to a specific alternate
configuration for this device. Is there some sort of problem with
calling that function?
It is almost the opposite, there is some sort of problem with
On Mon, May 13, 2002 at 10:23:48PM +0200, [EMAIL PROTECTED] wrote:
Question number two is the code that selects the endpoint:
Thus, among all endpoints, one will get the last endpoints that are
bulk-in, bulk-out and interrupt, respectively.
To me that sounds fairly random.
But maybe there
Good lord! What the hell is this!
This is completely like any usb-storage device I've ever seen
Unlike?
My conjecture about the origin is this:
A company perhaps called PrimeFilm, or perhaps Carry, or perhaps
something else, made the USB chip for a 6-in-1 Compact Flash,
SmartMedia,
On Mon, May 13, 2002 at 10:43:13PM +0200, [EMAIL PROTECTED] wrote:
Good lord! What the hell is this!
This is completely like any usb-storage device I've ever seen
Unlike?
That looks a lot like a Cypress/Anchor Chips device that needs firmware
downloaded to it before it will work
On Tue, 14 May 2002 06:30, Matthew Dharm wrote:
On Mon, May 13, 2002 at 10:23:48PM +0200, [EMAIL PROTECTED] wrote:
T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1
P: Vendor=07cc ProdID=0003 Rev= 0.00
C:*
: That looks a lot like a Cypress/Anchor Chips device
: that needs firmware downloaded to it before it will work properly.
: Is that what this device needs?
Yes.
= Looks like a Cypress EZUSB or FX (or FX2 maybe), without any firmware
Indeed.
Now that the two of you mention this, I looked at
29 matches
Mail list logo
