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:   Mon, 30 Apr 2018 23:08:42 +0200
From:   Paul Kocialkowski <contact@...lk.fr>
To:     Bin Liu <b-liu@...com>
Cc:     Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Chen-Yu Tsai <wens@...e.org>
Subject: Re: [PATCH] usb: musb: Support gadget mode when the port is set to
 dual role

Hi,

Le samedi 21 avril 2018 à 09:34 -0500, Bin Liu a écrit :
> Okay, this came down to an argument that whether we should require
> loading a gadget driver on a dual-role port to work in host mode,
> which is currently required on musb since a long long time ago.
> 
> I understand the requirement is kinda unnecessary, but since it
> already
> exists on musb stack for a long time, I don't plan to change it.
> Because I
> cannot think of a use case in real products that doesn't automatically
> load a gadget function on the dual-role port.
> 
> If you can explain a use case in real world (not a engineering lab)
> that the gadget driver will not be loaded at linux booting up, but
> later based on user's input, I will reconsider my decision. To remove
> this requirement from musb stack, the work is more than this patch.

My use case here is to support common GNU/Linux-based distributions, not
use-case-specific varieties of GNU/Linux-based rootfs. So my point here
would be that most distros will (and probably should) ship g_ether as a
module but without any particular reason to autoload it, or any other
gadget module in particular, since the system is general-purpose.

Then, imagine a user wants to plug a USB device through OTG (say,
because it's the only USB port available at all on the tablet they're
using), it simply won't work. It won't be obvious to that user that this
is because no gadget is loaded, since what they want to do does not
involve using gadget mode at any point.

Do you think this is a valid use case? It surely is a common one and
perfectly depicts my situation.

Note that in addition to Allwinner devices, I also have omap3/4/5
devices for testing things. I don't think I have other MUSB-enabled
devices in my collection though, but I would be willing to test fixes to
this issue on the ones I have.

Cheers,

-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)