linux-kernel - Re: [PATCH 0/3] USB Mux support for Chipidea

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, 17 Jul 2017 12:18:47 -0500
From:   Rob Herring <robh@...nel.org>
To:     Stephen Boyd <stephen.boyd@...aro.org>
Cc:     Andy Gross <andy.gross@...aro.org>,
        Peter Chen <Peter.Chen@....com>, Peter Rosin <peda@...ntia.se>,
        linux-usb@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, Rob Clark <robdclark@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 0/3] USB Mux support for Chipidea

On Thu, Jul 13, 2017 at 03:35:02PM -0700, Stephen Boyd wrote:
> Quoting Peter Rosin (2017-07-11 22:04:46)
> > On 2017-07-12 03:02, Stephen Boyd wrote:
> > > This patchset adds support for the TC7USB40MU usb mux found on 
> > > db410c 96boards platforms via the new multiplexer framework and
> > > hooks that into the chipidea driver. This allows us to properly
> > > control host or device mode on this board via the sysfs knob.
> > > 
> > > So far I've only tested this on db410c, and there are some rough
> > > edges to finish off before it can merge. Also I'm experiencing
> > > odd behavior with switching the role while gadget is enabled and
> > > the micro-usb cable is kept connected. Not sure what's wrong but
> > > it seems like the gadget never gets disconnected? I'll investigate
> > > more.
> > > 
> > > TODO:
> > > 
> > >  1. The mux framework has to be selected for consumers to use it. We'll
> > >     need some stubs in the consumer header file to allow compilation to
> > >     continue without mux always enabled by consumers.
> > 
> > Instead of "depends on MULTIPLEXER", just add "select MULTIPLEXER"
> > to the Kconfig. Otherwise, you'll have to convince Linus that we
> > really do need a Kconfig question for the subsystem :-)
> > 
> > https://lkml.org/lkml/2017/7/4/118
> 
> Ok. I'll add a select to the chipidea driver.
> 
> > 
> > >  2. We probably need some sort of mux_control_get_optional() API so that
> > >     we know if there was an error getting the mux control, instead of just
> > >     ignoring errors. For now I can pass up EPROBE_DEFER errors and ignore
> > >     other errors and consider it "missing from DT".
> > 
> > Yes, mux_control_get_optional should be easy to add.
> > 
> > >  3. Maybe we can get rid of the mux driver and just use mux-gpio.c with
> > >     a compatible string update? I split it off because we may want to
> > >     support the "S" pin on the TC7USB40MU one day that shuts off both
> 
> Oh this is a typo. I mean "OE" pin.
> 
> > >     mux outputs.
> > 
> > Maybe no need for a compatible update either, if it works to do something
> > like this in the DT?

Please keep the compatible. Use "gpio-mux" as a fallback if you wish.

Rob