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
| ||
|
Message-ID: <CAD=FV=VgYU8sZfSkbNbbOFpb-nt=Yy9NjybxADBnAiQXfasDpw@mail.gmail.com> Date: Sat, 24 Oct 2015 17:22:22 -0400 From: Doug Anderson <dianders@...omium.org> To: Rob Herring <robh@...nel.org> Cc: Heiko Stübner <heiko@...ech.de>, Kishon Vijay Abraham I <kishon@...com>, John Youn <johnyoun@...opsys.com>, Felipe Balbi <balbi@...com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, lyz <lyz@...k-chips.com>, wulf <wulf@...k-chips.com>, Mark Rutland <mark.rutland@....com>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, Russell King <linux@....linux.org.uk>, Pawel Moll <pawel.moll@....com>, Ian Campbell <ijc+devicetree@...lion.org.uk>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>, "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>, Rob Herring <robh+dt@...nel.org>, Kumar Gala <galak@...eaurora.org>, "Herrero, Gregory" <gregory.herrero@...el.com>, paulz <paulz@...opsys.com>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCH 0/4] Patches to fix remote wakeup on rk3288 dwc2 "host" port Rob, On Sat, Oct 24, 2015 at 11:10 AM, Rob Herring <robh@...nel.org> wrote: > On 10/23/2015 01:28 PM, Douglas Anderson wrote: >> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288 >> has a hardware errata that causes everything to get confused when we get >> a remote wakeup. It appears that the "port reset" bit that's in the USB >> phy (located in the rk3288 GRF) fixes things up and appears safe to do. >> >> This series of patches exports the "port reset" from the PHY and then >> hooks it up to dwc2 through a quirk. >> >> I've tested this series atop a bit of a conglomeration of Heiko's github >> "somewhat stable" branch (v4.3-rc3-876-g6509232) but with Greg KH's >> usb-next merged in. >> >> These patches currently conflict with patches that I posted previously >> to enable USB wakeup from S3, specifically: >> * https://patchwork.kernel.org/patch/6727081/ >> * https://patchwork.kernel.org/patch/6727121/ >> ...those patches no longer apply anyway, so presumably they need to be >> reposted and I can do so later atop these patches. >> >> >> Douglas Anderson (4): >> phy: rockchip-usb: Support the PHY's "port reset" >> usb: dwc2: optionally assert phy "port reset" when waking up >> ARM: dts: rockchip: Enable the USB phys as reset providers on rk3288 >> ARM: dts: rockchip: Point rk3288 dwc2 usb at phy port reset >> >> .../devicetree/bindings/phy/rockchip-usb-phy.txt | 6 ++ >> Documentation/devicetree/bindings/usb/dwc2.txt | 7 ++ >> arch/arm/boot/dts/rk3288.dtsi | 8 +++ >> drivers/phy/phy-rockchip-usb.c | 74 ++++++++++++++++++++++ >> drivers/usb/dwc2/core.h | 5 ++ >> drivers/usb/dwc2/core_intr.c | 7 ++ >> drivers/usb/dwc2/platform.c | 13 ++++ >> 7 files changed, 120 insertions(+) > > A DT reset controller seems like a bit of an overkill here. I think this > would be much more simple if we just add a phy reset hook to the phy > subsystem. Adding a reset hook in the PHY subsystem does seem like a reasonable idea to me. I was considering it in an earlier version of this series that actually used a reset of the PHY to the fix the stuck dwc2. ...but I think that even if the phy subsystem had a reset hook it wouldn't be the ideal solution here. When we assert the PHY "port reset" we're not actually fully resetting the PHY. We're instead doing some sort of a more minor "state machine" reset in the PHY. This appears better (in my case) than resetting the whole PHY because it doesn't force a de-enumeration / re-enumeration. Exposing this more minor reset as a PHY reset seems wrong to me. ...and it also precludes us later also exposing the more full reset through the PHY framework if that later becomes useful. ...we could, of course, re-invent the reset framework (with string or integral IDs so we can assert different types of resets) within the PHY framework. That doesn't seem ideal to me, but if that's what others want to do then I guess it would be OK... -Doug -- 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/
Powered by blists - more mailing lists