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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 22 Mar 2019 14:34:41 +0100
From:   Paul Kocialkowski <paul.kocialkowski@...tlin.com>
To:     Bin Liu <b-liu@...com>, Maxime Ripard <maxime.ripard@...tlin.com>
Cc:     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

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).

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.

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com