On Fri, 6 Sep 2019, Julius Werner wrote:
> FWIW, I found a suitable workaround now to get my use case working
> with existing kernels: I can do the mode switch from userspace, then
> after the device reenumerates I can manually disable any interfaces I
> don't like by writing 0 to their 'authorize
FWIW, I found a suitable workaround now to get my use case working
with existing kernels: I can do the mode switch from userspace, then
after the device reenumerates I can manually disable any interfaces I
don't like by writing 0 to their 'authorized' node, and then I write
the VID/PID to usb-stora
On Tue, 3 Sep 2019, Greg KH wrote:
> On Tue, Sep 03, 2019 at 10:46:14AM +0200, Oliver Neukum wrote:
> > Am Montag, den 02.09.2019, 18:47 +0200 schrieb Greg KH:
> > >
> > > This should work just fine today. Add a new device id to the "new_id"
> > > file and then tell the driver to bind. That's p
On Tue, Sep 03, 2019 at 12:04:03PM +0200, Oliver Neukum wrote:
> Am Dienstag, den 03.09.2019, 11:19 +0200 schrieb Greg KH:
> > On Tue, Sep 03, 2019 at 10:46:14AM +0200, Oliver Neukum wrote:
> > > Am Montag, den 02.09.2019, 18:47 +0200 schrieb Greg KH:
> > > >
> > > > This should work just fine tod
Am Dienstag, den 03.09.2019, 11:19 +0200 schrieb Greg KH:
> On Tue, Sep 03, 2019 at 10:46:14AM +0200, Oliver Neukum wrote:
> > Am Montag, den 02.09.2019, 18:47 +0200 schrieb Greg KH:
> > >
> > > This should work just fine today. Add a new device id to the "new_id"
> > > file and then tell the dri
On Tue, Sep 03, 2019 at 10:46:14AM +0200, Oliver Neukum wrote:
> Am Montag, den 02.09.2019, 18:47 +0200 schrieb Greg KH:
> >
> > This should work just fine today. Add a new device id to the "new_id"
> > file and then tell the driver to bind. That's pretty much the same as a
> > "force_bind", rig
Am Montag, den 02.09.2019, 18:47 +0200 schrieb Greg KH:
>
> This should work just fine today. Add a new device id to the "new_id"
> file and then tell the driver to bind. That's pretty much the same as a
> "force_bind", right?
That looks like a race condition by design to me.
Regards
On Fri, Aug 30, 2019 at 01:43:36PM -0400, Alan Stern wrote:
> > I could instead add a new sysfs node 'force_bind' to the driver core,
> > that would work like 'bind' except for skipping the
> > driver_match_device() call entirely and forcing a probe(). Do you
> > think that would be acceptable? Or
On Thu, 29 Aug 2019, Julius Werner wrote:
> > In fact, there already is a way to do this in the kernel: write to the
> > sysfs "bind" file. The difficulty is that you can't force a driver to
> > bind to an interface if it doesn't believe it is compatible with the
> > interface. And if the driver
> USB drivers only bind to interfaces, are you saying that your device has
> multiple interfaces on it?
Yes, I have a case where the device has two interfaces which both have
interface class 0xff (although they do differ in subclass and
protocol). I only want the usb-storage driver to bind to one
On Wed, 28 Aug 2019, Julius Werner wrote:
> (Thanks for the reviews... I'll get back to the kernel code details
> after double-checking if this can be done from userspace.)
>
> > > Besides, what's wrong with binding to devices that weren't switched
> > > into AOA mode? Would that just provoke a
On Wed, Aug 28, 2019 at 08:26:15PM -0700, Julius Werner wrote:
> Well... okay, let me think through that again. I just found the new_id
> sysfs API that I wasn't aware of before, maybe I could leverage that
> to bind this from userspace after doing the mode switch. But it looks
> like that only ope
(Thanks for the reviews... I'll get back to the kernel code details
after double-checking if this can be done from userspace.)
> > Besides, what's wrong with binding to devices that weren't switched
> > into AOA mode? Would that just provoke a bunch of unnecessary error
> > messages?
It's not ab
On Wed, 2019-08-28 at 12:17 -0400, Alan Stern wrote:
> On Tue, 27 Aug 2019, Julius Werner wrote:
>
> > This patch adds a new "unusual" USB mass storage device driver. This
> > driver will be used for a virtual USB storage device presented by an
> > Android phone running the 'Chrome OS Recovery'* A
On Tue, 27 Aug 2019, Julius Werner wrote:
> This patch adds a new "unusual" USB mass storage device driver. This
> driver will be used for a virtual USB storage device presented by an
> Android phone running the 'Chrome OS Recovery'* Android app. This app
> uses the Android Open Accessory (AOA) AP
On Tue, Aug 27, 2019 at 04:14:09PM -0700, Julius Werner wrote:
> This patch adds a new "unusual" USB mass storage device driver. This
> driver will be used for a virtual USB storage device presented by an
> Android phone running the 'Chrome OS Recovery'* Android app. This app
> uses the Android Ope
16 matches
Mail list logo
