linux-kernel - Re: [PATCH] usb: chipidea: fix ci

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:   Wed, 1 Jul 2020 08:32:22 +0000
From:   Philippe Schenker <philippe.schenker@...adex.com>
To:     "peter.chen@....com" <peter.chen@....com>
CC:     Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        Stefan Agner <stefan.agner@...adex.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: chipidea: fix ci_irq for role-switching use-case

On Wed, 2020-07-01 at 02:52 +0000, Peter Chen wrote:
> On 20-06-30 11:59:49, Philippe Schenker wrote:
> > On Tue, 2020-06-30 at 00:43 +0000, Peter Chen wrote:
> > > On 20-06-29 10:04:13, Philippe Schenker wrote:
> > > > On Mon, 2020-06-29 at 07:26 +0000, Peter Chen wrote:
> > > > > On 20-06-26 13:03:11, Philippe Schenker wrote:
> > > > > > If the hardware is in low-power-mode and one plugs in device
> > > > > > or
> > > > > > host
> > > > > > it did not switch the mode due to the early exit out of the
> > > > > > interrupt.
> > > > > 
> > > > > Do you mean there is no coming call for role-switch? Could you
> > > > > please
> > > > > share
> > > > > your dts changes? Try below patch:
> > > > 
> > > > Here are my DTS changes:
> > > > 
> > > > diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > > > b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > > > index 97601375f2640..c424f707a1afa 100644
> > > > --- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > > > +++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > > > @@ -13,6 +13,13 @@
> > > >                 stdout-path = "serial0:115200n8";
> > > >         };
> > > >  
> > > > +       extcon_usbc_det: usbc_det {
> > > > +               compatible = "linux,extcon-usb-gpio";
> > > > +               id-gpio = <&gpio7 14 GPIO_ACTIVE_HIGH>;
> > > > +               pinctrl-names = "default";
> > > > +               pinctrl-0 = <&pinctrl_usbc_det>;
> > > > +       };
> > > > +
> > > >         /* fixed crystal dedicated to mpc258x */
> > > >         clk16m: clk16m {
> > > >                 compatible = "fixed-clock";
> > > > @@ -174,6 +181,7 @@
> > > >  };
> > > >  
> > > >  &usbotg1 {
> > > > +       extcon = <&extcon_usbc_det>, <&extcon_usbc_det>;
> > > 
> > > If you have only ID extcon, but no VBUS extcon, you only need to
> > > add only phandle, see dt-binding for detail please.
> > 
> > You where right again! Thanks, this actually solves the RNDIS issue
> > for
> > our colibri-imx7 board:
> > 
> > +       extcon = <0>, <&extcon_usbc_det>;
> > 
> > Howevever on this iMX7 board we have VBUS hooked up to the SoC,
> > that's
> > why it works only with ID.
> > 
> > On Colibri-iMX6ULL we do not have VBUS hooked up.
> 
> So, there is no any events for connecting to Host? If it is, the
> workaround for this board is disable runtime pm. And you only need to
> write one extcon phandle for ID since you have external event for ID,
> but no event for VBUS. ID event is not the same with VBUS, for
> example,
> if you plug cable into host, you will not get the ID event, you could
> only get VBUS event if there is an event (eg, through GPIO) for it.
> 
> Peter

No we don't have extra Host events. We have one GPIO, if it is high USB
should be in gadget mode and if the GPIO is low USB should be in host
mode.

Is there no way we can achieve this on mainline without disabling
runtime PM?

Philippe

> 
> > So device/host
> > switching works only with 'extcon = <&extcon_usbc_det>,
> > <&extcon_usbc_det>;' but then RNDIS and also a normal thumb-drive
> > does
> > not work. How could I work around this fact? A dummy-gpio that would
> > always read "high" for vbus would be a solution for me.
> > 
> > Philippe
> >