Re: [patch]addition of blacklist for whole device quirks

Hi,

excuse me but instead of following your suggestions I read how to use 
git-bisect and found this out:

ee49fb5dc89d34f1794ac9362fa97c1a640f7ddd is first bad commit
commit ee49fb5dc89d34f1794ac9362fa97c1a640f7ddd
Author: Alan Stern <[email protected]>
Date:   Wed Nov 22 16:55:54 2006 -0500

    USB: keep count of unsuspended children

    This patch (as818b) simplifies autosuspend processing by keeping track
    of the number of unsuspended children of each USB hub.  This will
    permit us to avoid a good deal of unnecessary work all the time; we
    will no longer have to create a bunch of workqueue entries to carry
    out autosuspend requests, only to have them fail because one of the
    hub's children isn't suspended.

    The basic idea is simple.  There already is a usage counter in the
    usb_device structure for preventing autosuspends.  The patch just
    increments that counter for every unsuspended child.  There's only one
    tricky part: When a device disconnects we need to remember whether it
    was suspended at the time (leave the counter alone) or not (decrement
    the counter).

    Signed-off-by: Alan Stern <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

:040000 040000 a03bd42d6fabc54063b2594871177e512292357b 
1a8a55cfe216f428f450c87167cd00108a7bbc5b M      drivers
:040000 040000 6c5c086110209f8752719a47a8b6436f70eec3d4 
1ae2122e85fdd1446387d2ffd18c6408a5bf692d M      include



So does this really point to broken hw or a broken patch? Where can I get that 
patch as standalone? So I could revert it in rc6 and test...


Am Samstag 27 Januar 2007 schrieb Alan Stern:
> On Sat, 27 Jan 2007, Prakash Punnoor wrote:
> > usb 1-1.3: USB disconnect, address 16
> > usb 1-1.3: new full speed USB device using ehci_hcd and address 17
> > usb 1-1.3: configuration #1 chosen from 1 choice
> >
> > every time I call sane-find-scanner. Above message refers to my hub, as
> > my scanner is
> >
> > usb 2-2: new full speed USB device using ohci_hcd and address 4
> > usb 2-2: configuration #1 chosen from 1 choice
> >
> > So, if you want something to blacklist, it should be the hub and not the
> > scanner.
>
> Let me get this straight.  The scanner works fine so long as it isn't
> connected through the hub, right?  And some other device connected through
> the hub (what is 1-1.3 above?) also fails?

It is the empty hub. Remember the scanner is 2-2, which brings me to my next 
question: Why does the kernel poke the hub, when I want to communicate with 
my scanner (which is directly connected in above scenario)?

Cheers,
-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel