linux-kernel - RE: [PATCH v2 5/5] usb:cdns3 Add Cadence USB3 DRD Driver

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:   Thu, 27 Dec 2018 09:36:40 +0000
From:   Pawel Laszczak <pawell@...ence.com>
To:     Peter Chen <hzpeterchen@...il.com>
CC:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "hdegoede@...hat.com" <hdegoede@...hat.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        "andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "rogerq@...com" <rogerq@...com>,
        lkml <linux-kernel@...r.kernel.org>,
        Alan Douglas <adouglas@...ence.com>,
        "jbergsagel@...com" <jbergsagel@...com>,
        "nsekhar@...com" <nsekhar@...com>, "nm@...com" <nm@...com>,
        Suresh Punnoose <sureshp@...ence.com>,
        "peter.chen@....com" <peter.chen@....com>,
        Pawel Jez <pjez@...ence.com>, Rahul Kumar <kurahul@...ence.com>
Subject: RE: [PATCH v2 5/5] usb:cdns3 Add Cadence USB3 DRD Driver

Hi,

>> > +
>> > +       if (ret)
>> > +               return ret;
>> > +
>> > +       state = readl(&cdns->otg_regs->sts);
>> > +       if (OTGSTS_OTG_NRDY(state) != 0) {
>> > +               dev_err(cdns->dev, "Cadence USB3 OTG device not ready\n");
>> > +               return -ENODEV;
>> > +       }
>> > +
>> > +       ret = cdns3_drd_update_mode(cdns);
>> > +
>>
>> Calling this function, it is timeout for waiting OTGSTS_XHCI_READY at otgsts,
>> do you know possible reasons?  After commenting out this function, my
>> xHCI function
>> works.
>>
>
>Pawel, since OTG compliance (Known as HNP/SRP)  has not been used
>widely, Linux kernel does not
>maintain it from some time ago (maybe 1-2 years). In software design,
>we do not need to consider it from
>hardware point, eg, kinds of OTG timer. For dual-role switch on the
>fly,  through /sys is enough.
>
>Through the debug, we find it needs to wait 1s after setting de-select
>the host or gadget before request
>XHCI at otg_regs->cmd, and enable fast simulate can reduce delay to
>2-3ms. Would you please help
>to check with your hardware team this behavior. With below changes, I
>can get OTGSTS_XHCI_READY at otgsts.
>
>@@ -141,6 +143,7 @@ static int cdns3_drd_switch_host(struct cdns3 *cdns, int on)
>                writel(OTGCMD_HOST_BUS_DROP | OTGCMD_DEV_BUS_DROP |
>                       OTGCMD_DEV_POWER_OFF | OTGCMD_HOST_POWER_OFF,
>                       &cdns->otg_regs->cmd);
>+               usleep_range(3000, 4000);
>        }
>
>        return 0;
>@@ -178,6 +181,7 @@ static int cdns3_drd_switch_gadget(struct cdns3
>*cdns, int on)
>                writel(OTGCMD_HOST_BUS_DROP | OTGCMD_DEV_BUS_DROP |
>                       OTGCMD_DEV_POWER_OFF | OTGCMD_HOST_POWER_OFF,
>                       &cdns->otg_regs->cmd);
>+               usleep_range(3000, 4000);
>        }
>
>@@ -299,6 +306,7 @@ int cdns3_drd_init(struct cdns3 *cdns)
>                cdns->version  = CDNS3_CONTROLLER_V0;
>                cdns->otg_v1_regs = NULL;
>                cdns->otg_regs = regs;
>+               writel(0x1, &cdns->otg_v0_regs->simulate);
>                dev_info(cdns->dev, "DRD version v0 (%08x)\n",
>                         readl(&cdns->otg_v0_regs->version));
>        } else {

I have confirmation from HW team that time that driver should wait after de-selecting mode 
is 2-3ms for simulate mode. It's time when FSM is in DRD_H_WAIT_VBUS_FAIL. 
Driver cannot re-enable the host/device mode before this time has elapsed. 

3 ms is the maximum time. Additionally, you can confirm the current FSM state by reading the
host_otg_state (bit 5:3) or dev_otg_state (2:0)  from OTGSTATE register. 

If bit 0 in simulate register is cleared the time is exactly 1s.

Cheers,
Pawel