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:   Tue, 1 May 2018 07:25:33 -0500
From:   Bin Liu <b-liu@...com>
To:     Paul Kocialkowski <contact@...lk.fr>
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

On Mon, Apr 30, 2018 at 11:08:42PM +0200, Paul Kocialkowski wrote:
> 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.

This is the case I called it "in a engineering lab", not a real product.

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

If a tablet has a dual-role usb port, it is designed to use a gadget
driver, which has to be loaded at some point. In the case you described
above, when the gadget driver will be loaded? and how?

If a gadget driver will never be used, a host-only port should be on
the board, not a dual-role port.

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

As I explained above, I don't think so.

> 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

Much more than what I have ;)

> devices in my collection though, but I would be willing to test fixes to
> this issue on the ones I have.

Appreciated it, but someone has to make the patches first. The one you
posted might be a good start, but it is not complete. The first problem
I see is that musb_start() will be called twice, one in the place you
patched, the other is when the gadget driver is bound to the UDC.

Regards,
-Bin.