linux-kernel - Re: [PATCH 2/2] USB: ehci-platform: Support ehci reset after resume quirk

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: <CAODwPW8N-M0pwg0=gsp8WUkuo+B_Y6LSxWi1DbR1Ynx_u5qDXw@mail.gmail.com>
Date:	Mon, 22 Dec 2014 10:25:43 -0800
From:	Julius Werner <jwerner@...gle.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Wu Liang feng <wulf@...k-chips.com>,
	Heiko Stübner <heiko@...ech.de>,
	Tao Huang <huangtao@...k-chips.com>,
	Kever Yang <kever.yang@...k-chips.com>,
	Eddie Cai <eddie.cai@...k-chips.com>,
	Roy Li <roy.li@...k-chips.com>,
	Chris Zhong <zyw@...k-chips.com>,
	Doug Anderson <dianders@...gle.com>,
	Pawel Osciak <posciak@...gle.com>, tfiga@...gle.com,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 2/2] USB: ehci-platform: Support ehci reset after resume quirk

>> The EHCI controller doesn't properly detect the case when
>
> "The" EHCI controller?  I don't know what EHCI controller you're
> talking about, but my controllers don't have any trouble detecting
> device removal during suspend.

This is similar to other SoC-based controllers that loose state in
suspend, like on Samsung's Exynos. Usually we catch that with the
FLAG_CF check in ehci_resume(). In the case of RK3288 it unfortunately
leaves the CF flag (and other things, like PORTSC[PED] bits) set,
although it doesn't react to any events correctly. If the device
looses its power session the controller won't notice and then on
resume get stuck trying to send resume signals to something that had
been reset (or newly plugged in). I think since we can't trust the
controller to do anything right, the safest thing is to fall back to
the solution of resetting everything (at least we know that works),
and since the FLAG_CF check doesn't work we need another solution to
mark which controllers are affected.

> Isn't this solution too extreme?  What if the device was a flash
> storage drive and it wasn't unplugged during suspend?  This patch would
> force it to be removed, messing up any mounted filesystems, when there
> was no need.
>
> Can you find a better way to work around the problem?

As Doug said, I think persist is the solution. We have essentially the
same case: all we know is that there is now a device connected to the
same port that a device had been connected during suspend... but with
no guarantees whether it is the same device or in the same state. By
forcing people to use persist, we acknowledge that this has the same
risks (e.g. data corruption if a mounted mass storage device was
swapped out for another one), and we benefit from the same safety
checks like comparing the serial number.
--
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/