lkml.org 
[lkml]   [2006]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Bug with USB proc_bulk in 2.4 kernel
    On Mon, 10 Jul 2006 12:58:32 -0700, Benjamin Cherian <benjamin.cherian.kernel@gmail.com> wrote:

    > I understand your decision but this does not follow the USB spec. According
    > to the spec, two threads should be able to perform operations on the same
    > device at the same time.

    This consideration is wholly irrelevant to the pertinent topic,
    because the very issue arises from devices being non-compliant.
    If we want them to operate, we have to apply workarounds, which
    may but us outside of the spec envelope. So I am not even going
    to argue if the spec in fact mandates this behaviour.

    > > But it seems to me that the best approach would be if you made
    > > a special case for bulk+bulk and locked out control transfers somehow.
    >
    > This is exactly what I suggested in my first email. It just involves adding a
    > couple of lines of code, but I'm not sure how the unlock function works in
    > 2.4. In 2.6, the device is unlocked WITHIN proc_bulk before usb_bulk_mesg is
    > called and is locked after usb_bulk_mesg returns. Therefore, the device is
    > still locked during control transfers.

    I explained why this technique is not applicable to 2.4 in the part
    of the message you failed to quote. To recap, if bulk methods were
    simply to drop locks with a "couple of lines of code", they would allow
    control transfers to happen simultaneously with bulk transfers.
    It happens to work in 2.6 only because of its string caching feature.
    Indeed, Stuart Hayes of Dell reported that he can cause TEAC CD-210PU
    to break under 2.6.16 in the same way it did in 2.4.27, simply by doing
    "lsusb -v" instead of "cat /proc/bus/usb/devices". The issue is still
    with us. Greg chose to bypass it in 2.6, instead of fixing it, due
    to the amount of work involved.

    This is a fixable issue, but it's not two lines of code. And its
    impact is very limited. If you, the person who actually suffers, are
    not willing to do the necessary work, then why would anyone else be?
    Still, I would be happy to consider your patch, if it were to emerge.

    -- Pete
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-07-10 22:43    [W:2.303 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site