On Thu, 1 Nov 2007, Steven King wrote:
> > The real question is why 2.6.24-rc1 doesn't like the second
> > configuration descriptor. To answer it, you should see what shows up
> > in the dmesg log when you first plug in the device on a kernel with
> > CONFIG_USB_DEBUG enabled.
>
> ?!? As I wrote at the top of the message you quoted, I rebuilt with
> CONFIG_USB_DEBUG enabled and loaded the modules with debug=1, thats how I was
> able to see the 'wrong number of endpoints' message.
But you didn't post the log messages, so I haven't seen them.
In addition, that "wrong number of endpoints" message occurs long after
the underlying problem; it's probably not connected.
> Given that the dongle works correctly with a stock 2.6.24-rc1 with commit
> 063a2da8f01806906f7d7b1a1424b9afddebc443 reversed,
Can you post the /proc/bus/usb/devices entry under that kernel? Do
both configurations show up?
> I'm reasonably confident
> that with that commit in place, the usb core is working correctly (or atleast
> as expected) in initially parsing the device descriptor, then usb-serial
> attempts to match the interface descriptor on the first configuration, and
> using the new more strict matching code, fails when the device reports for
> the only interface on the first configuration it has only a single bulk_out
> endpoint while the ti_usb_3410_5052 driver is expecting an interrupt_in and a
> bulk_in. It never gets to the second configuration descriptor.
Why shouldn't the core ever get to parse the second configuration
descriptor? Config descriptor parsing happens before driver matching
and binding. It has to; otherwise the core wouldn't know which
configuration to install by default.
In the "working" 2.6.23 kernel there were two configurations and Config
#2 was installed. What happens if you install Config #1 under that
kernel (echo 1 >/sys/bus/usb/devices/.../bConfigurationValue)?
Presumably if Config #2 was present and installed in the "non-working"
2.6.24-rc1 kernel, the driver would bind correctly.
> for me the only question is whether ti_usb_3410_5052 should
> have .num_interrupt_in and .num_bulk_in set to NUM_DONT_CARE or set to 0.
Then you're concerned about the wrong question. It's more important to
find out why Config #2 disappeared under 2.6.24-rc1. The commit you
are focused on would not have caused it.
> Are there versions of the dongle that have different device descriptors?
> Before I bricked (sticked?) my TI eZ430-rf2500 dongle, it reported a
> different idProduct even though as far as I can tell they are almost the
> exact same hardware, so that shouldnt be a problem...
I have no idea what versions of your dongle are available. In fact, I
never heard of it before reading your email messages. However if you
have had two different dongles that report different idProduct values,
it's a safe bet that _something_ has changed between them. The
firmware, if nothing else.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
