linux-kernel - Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

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: <CAL_JsqJ0pWV6mX2Nf-ccEvMg6jd+G76qZg0EVdRFu8obCLkHvw@mail.gmail.com>
Date:	Mon, 2 Nov 2015 11:16:28 -0600
From:	Rob Herring <robh+dt@...nel.org>
To:	Doug Anderson <dianders@...omium.org>
Cc:	John Youn <johnyoun@...opsys.com>, Felipe Balbi <balbi@...com>,
	Heiko Stübner <heiko@...ech.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	lyz <lyz@...k-chips.com>, wulf <wulf@...k-chips.com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Paul Zimmerman <paulz@...opsys.com>,
	Gregory Herrero <gregory.herrero@...el.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux USB List <linux-usb@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when
 waking up

On Mon, Nov 2, 2015 at 10:22 AM, Doug Anderson <dianders@...omium.org> wrote:
> Rob,
>
> On Mon, Nov 2, 2015 at 8:12 AM, Rob Herring <robh+dt@...nel.org> wrote:
>> On Fri, Oct 30, 2015 at 3:17 PM, Douglas Anderson <dianders@...omium.org> wrote:
>>> From: Doug Anderson <dianders@...omium.org>

>>> We can get the PHY out of its bad state by asserting its "port reset",
>>> but unfortunately that seems to assert a reset onto the USB bus so it
>>> could confuse things if we don't actually deenumerate / reenumerate the
>>> device.
>>>
>>> We can also get the PHY out of its bad state by fully resetting it using
>>> the reset from the CRU (clock reset unit), which does a more full
>>> reset.  The CRU-based reset appears to actually cause devices on the bus
>>> to be removed and reinserted, which fixes the problem (albeit in a hacky
>>> way).
>>
>> The reset from the CRU goes to the PHY, correct? Therefore, the
>> binding should reflect that. Connecting it to the host controller is a
>> hack.
>>
>> So describe the reset connection properly and then add a .phy_reset()
>> hook to the phy subsystem. Then call that when flag property you added
>> is set.
>
> As per previous email, I disagree.  The fact that there may be more
> than one reset exposed from the PHY and that there is not a tightly
> coupled relationship between a PHY driver and a USB driver means that
> we would need to re-invent the reset API on top of the PHY API.  In my
> case I am exposing a single reset at the moment, but there may be
> reasons to expose additional "PHY" resets in the future.

Your previous approach was completely different. I was not arguing
that the PHY driving reset to the host was wrong use of reset binding,
just that it was an overkill. Now, it is just flat wrong unless you
convince me that SRST_USBHOST1_PHY is a connection to the host rather
than the PHY.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/