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

Powered by blists - more mailing lists