linux-kernel - Re: [PATCH] usb: musb: Support gadget mode when the port is set to dual role

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 22 Mar 2019 08:44:18 -0500
From:   Bin Liu <b-liu@...com>
To:     Paul Kocialkowski <paul.kocialkowski@...tlin.com>
CC:     Maxime Ripard <maxime.ripard@...tlin.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        <linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>,
        Chen-Yu Tsai <wens@...e.org>
Subject: Re: [PATCH] usb: musb: Support gadget mode when the port is set to
 dual role

On Fri, Mar 22, 2019 at 02:34:41PM +0100, Paul Kocialkowski wrote:
> Le vendredi 22 mars 2019 à 08:28 -0500, Bin Liu a écrit :
> > Again, think about an embedded product, if dr_mode is 'otg' which
> > indicates the peripheral mode will be used at some point, when and how
> > to load the gadget driver if it is not loaded automatically when Linux
> > boots up? the end user doesn't have access to the console.
> 
> Why should we think of an embedded product where the end user doesn't
> have access to the console? Unless I'm mistaken, the Linux kernel
> doesn't target commercial products where users are powerless in
> particular, and leaves out all other use cases (which may or may not be
> commercial).

Okay, this will lead to an endless argument as well, so I will only
explain why I mentioned embedded - AFAIK musb is only used in embedded
processors. then we can stop arguing on this point...

> I don't think this assumption makes any sense in Linux as a project (or
> that it's sane in any context of software development for that matter,
> but that's beside the point).
> 
> > > Because no other controller requires it and therefore it's not
> > > standard and violates the principle of least surprise?
> > 
> > I know no other controller does this, but this doesn't mean it is not
> > standard.
> > 
> > > And even without taking this into account, there's also the fact that
> > > while the *hardware* can do dual role, the software might decide
> > > otherwise. If I don't want to have support for any gadget (at all) in
> > > the end system, then why should I be forced to compile and load
> > > something I don't even want to use in the first place?
> > 
> > then dr_mode should be set to 'host' instead, you don't have to load a
> > gadget if peripheral mode will never be used.
> 
> I disagree: dr_mode describes the hardware capabilities, not what the
> software does with it.

I have different understanding, dr_mode describles the use case, not the
hardware capabilities. And software operates the hardware accordingly
based on dr_mode.

Regards,
-Bin.