linux-kernel - Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

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: <87r1vdx0w4.fsf@kernel.org>
Date:   Thu, 21 May 2020 09:22:51 +0300
From:   Felipe Balbi <balbi@...nel.org>
To:     Thinh Nguyen <Thinh.Nguyen@...opsys.com>, Jun Li <jun.li@....com>,
        Jun Li <lijun.kernel@...il.com>
Cc:     John Stultz <john.stultz@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Yu Chen <chenyu56@...wei.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        ShuFan Lee <shufan_lee@...htek.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Chunfeng Yun <chunfeng.yun@...iatek.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Valentin Schneider <valentin.schneider@....com>,
        Jack Pham <jackp@...eaurora.org>,
        Linux USB List <linux-usb@...r.kernel.org>,
        "open list\:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, Peter Chen <peter.chen@....com>
Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller


Hi Jun,

Felipe Balbi <balbi@...nel.org> writes:
>> In any case, increasing the timeout should be fine with me. It maybe 
>> difficult to determine the max timeout base on the slowest clock rate 
>> and number of cycles. Different controller and controller versions 
>> behave differently and may have different number of clock cycles to 
>> complete a command.
>>
>> The RTL engineer recommended timeout to be at least 1ms (which maybe 
>> more than the polling rate of this patch). I'm fine with either the rate 
>> provided by this tested patch or higher.
>
> A whole ms waiting for a command to complete? Wow, that's a lot of time
> blocking the CPU. It looks like, perhaps, we should move to command
> completion interrupts. The difficulty here is that we issue commands
> from within the interrupt handler and, as such, can't
> wait_for_completion().
>
> Meanwhile, we will take the timeout increase I guess, otherwise NXP
> won't have a working setup.

patch 1 in this series doesn't apply to testing/next. Care to rebase and
resend?

Thank you

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)