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, 22 Dec 2014 10:25:43 -0800
From:	Julius Werner <>
To:	Alan Stern <>
Cc:	Wu Liang feng <>,
	Heiko Stübner <>,
	Tao Huang <>,
	Kever Yang <>,
	Eddie Cai <>,
	Roy Li <>,
	Chris Zhong <>,
	Doug Anderson <>,
	Pawel Osciak <>,,
	LKML <>,
	"" <>
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
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists