On Mon, 2014-03-17 at 17:12 -0400, Alan Stern wrote:
> On Thu, 13 Mar 2014, Alan Stern wrote:
> > This reasoning suggests that when QUIRK_RESET is present, we should
> > always skip reset-resume and go directly to logical disconnect.
>
> So Oliver, what do you think about this patch?
Looks perfe
On Thu, 13 Mar 2014, Alan Stern wrote:
> Ah, now I understand. We are talking about mode-switching devices that
> revert to their default mode following a reset, as opposed to losing
> their firmware contents (although the mode switch may involve a change
> to the descriptors too). This sort of
On Thu, 13 Mar 2014, Oliver Neukum wrote:
> On Thu, 2014-03-13 at 10:11 -0400, Alan Stern wrote:
> > On Thu, 13 Mar 2014, Oliver Neukum wrote:
> >
> > > On Wed, 2014-03-12 at 15:18 +, Poulain, Loic wrote:
> > > > My thought was to fix the usbcore rebind issue (with pm_runtime)
> > > > to let
On Thu, 2014-03-13 at 10:11 -0400, Alan Stern wrote:
> On Thu, 13 Mar 2014, Oliver Neukum wrote:
>
> > On Wed, 2014-03-12 at 15:18 +, Poulain, Loic wrote:
> > > My thought was to fix the usbcore rebind issue (with pm_runtime)
> > > to let the core unbind and rebind the device's interfaces for
On Thu, 13 Mar 2014, Oliver Neukum wrote:
> On Thu, 2014-03-13 at 08:05 +, Peter Chen wrote:
> > >
> > > On Wed, 2014-03-12 at 15:18 +, Poulain, Loic wrote:
>
> > > > Implementing the btusb reset_resume seems risky, a patch implementing
> > > > this callback has been previously reverted
On Thu, 13 Mar 2014, Oliver Neukum wrote:
> On Wed, 2014-03-12 at 15:18 +, Poulain, Loic wrote:
> > My thought was to fix the usbcore rebind issue (with pm_runtime)
> > to let the core unbind and rebind the device's interfaces for drivers
> > with no reset_resume callback (not only btusb).
>
On Thu, 2014-03-13 at 08:05 +, Peter Chen wrote:
> >
> > On Wed, 2014-03-12 at 15:18 +, Poulain, Loic wrote:
> > > Implementing the btusb reset_resume seems risky, a patch implementing
> > > this callback has been previously reverted due to HID dual mode device
> > > regression. (cf http
>
> On Wed, 2014-03-12 at 15:18 +, Poulain, Loic wrote:
> > My thought was to fix the usbcore rebind issue (with pm_runtime) to
> > let the core unbind and rebind the device's interfaces for drivers
> > with no reset_resume callback (not only btusb).
>
> Those functions seem to be independe
On Wed, 2014-03-12 at 15:18 +, Poulain, Loic wrote:
> My thought was to fix the usbcore rebind issue (with pm_runtime)
> to let the core unbind and rebind the device's interfaces for drivers
> with no reset_resume callback (not only btusb).
Those functions seem to be independent. Even if you
erted due to
HID dual mode device regression. (cf https://lkml.org/lkml/2013/11/26/347)
Regards,
Loic Poulain
From: Oliver Neukum [oneu...@suse.de]
Sent: Wednesday, March 12, 2014 12:03 PM
To: Poulain, Loic
Cc: linux-usb@vger.kernel.org
Subject: reset_resume(
Hi,
I still think it makes little sense to support reset_resume()
in btusb, but if you really want to, you can try this patch.
HTH
Oliver
>From 3776765dbd08701c30f45c1849691a16c1077cc3 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Wed, 12 Mar 2014 12:01:13 +0100
Subj
11 matches
Mail list logo
