On Mon, Dec 03, 2007 at 04:47:37PM -0800, Sarah Sharp wrote:
> Set the reset resume quirk for all pl2303 chips. Later, remove the
> quirk if we know it's an HX chip, since that works fine without the
> reset resume. Tested on ATEN HX and type_1 converters (0557:2008).
>
> Signed-off-by: Sarah Sh
Am Dienstag, 4. Dezember 2007 00:03:40 schrieb Alan Stern:
> On Mon, 3 Dec 2007, Oliver Neukum wrote:
> > > unbound! So I wanted to be conservative and keep the kernel's current
> > > behavior: The suspend/resume/reset happens and the user-level driver is
> > > blissfully igorant of it.
> >
> > In
On Tue, 4 Dec 2007, Oliver Neukum wrote:
> > Perhaps. But there are devices for which being reset is unlikely to
> > cause any problems. Do we want userspace drivers for these devices to
> > start failing unnecessarily?
>
> Which devices are these? If the tradeoff is between that and undefined
Greg KH wrote:
On Mon, Dec 03, 2007 at 06:19:53PM +, Phil Endecott wrote:
Dear Experts,
Can anyone suggest the best way to determine the speed (low/full/high) at
which a device is operating from user-space?
usbdevice_fs has 'connectinfo', which seems to return a flag for low-speed
opera
Attempting to answer my own question...
Phil Endecott wrote:
Greg KH wrote:
On Mon, Dec 03, 2007 at 06:19:53PM +, Phil Endecott wrote:
Dear Experts,
Can anyone suggest the best way to determine the speed (low/full/high) at
which a device is operating from user-space?
usbdevice_fs has '
On Tue, Dec 04, 2007 at 04:32:44PM +, Phil Endecott wrote:
> Greg KH wrote:
>> On Mon, Dec 03, 2007 at 06:19:53PM +, Phil Endecott wrote:
>>> Dear Experts,
>>>
>>> Can anyone suggest the best way to determine the speed (low/full/high) at
>>> which a device is operating from user-space?
>>>
Greg KH wrote:
Ah, it's the "busnum" and "devnum" sysfs files, that should be all you
need to go from sysfs to the usbfs file name.
I don't seem to have "busnum" on this box; I guess it's relatively new?
Phil.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the b
Am Dienstag, 4. Dezember 2007 16:42:23 schrieb Alan Stern:
> On Tue, 4 Dec 2007, Oliver Neukum wrote:
> > > Perhaps. But there are devices for which being reset is unlikely to
> > > cause any problems. Do we want userspace drivers for these devices to
> > > start failing unnecessarily?
> >
> > Wh
Greg,
Attached is a patch to fix the addition of the new product ids I sent.
It is against 2.6.24-rc4, as Linus included the broken version of the
patch I sent you in that tree. :(
Not sure if this is the right method to go about this, but hopefully I got
it right this time.
Andrew
Signed-off-
On Tue, 4 Dec 2007, Oliver Neukum wrote:
> The device would have to have two interfaces and the driver on the other
> interface would have to issue resets.
Not true. You can reset a USB device via usbfs without binding to an
interface.
> The only devices that come to my mind
> are mice with fi
This patch (as1022b) adds stub methods for suspend and resume to the
usbfs driver. There isn't much they can do since there's no way to
inform a user task about the events. But it's important to have the
stubs, because an upcoming change to usbcore will automatically unbind
drivers that don't hav
On Tue, Dec 04, 2007 at 05:56:34PM +, Phil Endecott wrote:
> Greg KH wrote:
>> Ah, it's the "busnum" and "devnum" sysfs files, that should be all you
>> need to go from sysfs to the usbfs file name.
>
> I don't seem to have "busnum" on this box; I guess it's relatively new?
what kernel version
Greg KH wrote:
On Tue, Dec 04, 2007 at 05:56:34PM +, Phil Endecott wrote:
Greg KH wrote:
Ah, it's the "busnum" and "devnum" sysfs files, that should be all you
need to go from sysfs to the usbfs file name.
I don't seem to have "busnum" on this box; I guess it's relatively new?
what kern
13 matches
Mail list logo
