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  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, 16 Jan 2017 08:32:45 +0100
From:   Rafał Miłecki <>
To:     Mathias Nyman <>,
        Jon Mason <>,
        Florian Fainelli <>,
        BCM Kernel Feedback <>
Cc:     Mathias Nyman <>,
        Greg Kroah-Hartman <>,
        Hauke Mehrtens <>,
        Rob Herring <>,
        Mark Rutland <>,
        "" <>,
        "" <>,
        Linux Kernel Mailing List <>,
        Rafał Miłecki <>
Subject: Re: [PATCH V2] usb: xhci: add support for performing fake doorbell

On 21 November 2016 at 16:31, Mathias Nyman
<> wrote:
> On 21.11.2016 09:57, Rafał Miłecki wrote:
>> Hi Mathias,
>> On 17 October 2016 at 22:30, Rafał Miłecki <> wrote:
>>> From: Rafał Miłecki <>
>>> Broadcom's Northstar XHCI controllers seem to need a special start
>>> procedure to work correctly. There isn't any official documentation of
>>> this, the problem is that controller doesn't detect any connected
>>> devices with default setup. Moreover connecting USB device to controller
>>> that doesn't run properly can cause SoC's watchdog issues.
>>> A workaround that was successfully tested on multiple devices is to
>>> perform a fake doorbell. This patch adds code for doing this and enables
>>> it on BCM4708 family.
>>> Signed-off-by: Rafał Miłecki <>
>>> ---
>>> V2: Enable quirk for brcm,bcm4708 machines instead of adding separated
>>> binding
>>>      for it. Thanks Rob for your comment on this.
>> Do you think you can pick & push this one? V2 follows Rob's suggestion
>> and he has some DT knowledge for sure, so I guess it should be OK.
>> --
> Is there some more background information on this?
> I don't have any contacts to Broadcom myself, adding the BMC Kernel Feedback
> list to CC.
> Maybe someone over there has an errata, documentation or just general
> feedback.
> How was this workaround even figured out? ringing the doorbell for the first
> device doesn't seem like something found by trial and error,  especially
> when
> xhci specs state that:
> "Software shall not write the Doorbell of an endpoint until after it has
> issued a
> Configure Endpoint Command for the endpoint and received a successful
> Command
> Completion Event."
> The whole workaround is a bit intrusive, allocating a fake device, ring a
> doorbell for a
> fake device in the wrong state, clearing off HSE (host system error) which
> should only be set
> when things really go bad, some random usleeps, and possible calling
> xhci_start() twice.
> I can't take this as is without some more info.

Hi (ping) Broadcom guys, could you help us with this USB workaround, please?


Powered by blists - more mailing lists