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]

Message-ID: <1522324644.1746.19.camel@bootlin.com>
Date:   Thu, 29 Mar 2018 13:57:24 +0200
From:   Paul Kocialkowski <paul.kocialkowski@...tlin.com>
To:     Maxime Ripard <maxime.ripard@...tlin.com>
Cc:     linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Bin Liu <b-liu@...com>, Chen-Yu Tsai <wens@...e.org>,
        Paul Kocialkowski <contact@...lk.fr>
Subject: Re: [PATCH] usb: musb: Support gadget mode when the port is set to
 dual role

Hi,

On Thu, 2018-03-29 at 11:23 +0200, Maxime Ripard wrote:
> On Wed, Mar 28, 2018 at 11:52:13PM +0200, Paul Kocialkowski wrote:
> > This allows dual-role ports to be reported as having gadget mode by
> > the
> > musb_has_gadget helper. This is required to enable MUSB at all with
> > MUSB
> > glue layers that set the port mode to MUSB_PORT_MODE_DUAL_ROLE at
> > init.
> > 
> > Most notably, this allows calling musb_start when needed in the
> > virtual
> > MUSB root HUB, regardless of whether the current mode should be
> > gadget
> > or host.
> > 
> > This fixes USB OTG on Allwinner devices that I could test it with,
> > mainly A20 devices.
> > 
> > Signed-off-by: Paul Kocialkowski <contact@...lk.fr>
> 
> Surely there's more to it than that. The gadget mode of A20 boards
> have been working in the past, including when compiling with mUSB
> setup as dual role.
>
> Is this a regression since a particular commit? Or is there another,
> deeper issue overlooked in the commit log?

The root of the issue here is that musb_start is not called at any point
without this patch. My understanding of the flow is the following: when
the PHY detects that there was a VBUS/ID change, it will notify its
listeners (mainly the musb sunxi glue layer). This will then schedule
the driver's work (sunxi_musb_work), which does nothing since the
SUNXI_MUSB_FL_ENABLED bit was never set. This bit is only set after
calling sunxi_musb_enable, which is called from musb_platform_enable,
that originates from musb_start.

Currently I see two places where musb_start is called:
* musb_virthub
* musb_gadget

In the latter case, it is in turn called from udc_start, which should
probably (correct me if I'm wrong) happen later in the call chain than
ID/VBUS change notification time.

In the former case, musb_start is called in the root controller hub
control, when setting the USB_PORT_FEAT_POWER feature. This looks
perfectly legit and IMO this is where it should be initially calling
musb_start in the dual role case. The kernel is indeed setting the
feature, only that it fails to enable musb without this patch.

First, I'd like to make sure that this understanding of the flow is
correct as I may have missed something here. Does it make sense?

Then, it seems that the offending commit is: be9d39881fc4f
("usb: musb: host: rely on port_mode to call musb_start()")

That itself fixed: ae44df2e21b5
("usb: musb: call musb_start() only once in OTG mode")

Still, this commit was authored in June 2015, so almost 3 years ago.
In the meantime, the sunxi driver has received feature improvements, so
it seems hard to believe that it was broken all this time...

Cheers,
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)