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
| ||
|
Date: Tue, 9 Apr 2019 14:14:54 +0200 From: Andrew Lunn <andrew@...n.ch> To: Miquel Raynal <miquel.raynal@...tlin.com> Cc: Pavel Machek <pavel@....cz>, Vivien Didelot <vivien.didelot@...il.com>, Florian Fainelli <f.fainelli@...il.com>, "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Thomas Petazzoni <thomas.petazzoni@...tlin.com>, Gregory Clement <gregory.clement@...tlin.com>, Antoine Tenart <antoine.tenart@...tlin.com>, Maxime Chevallier <maxime.chevallier@...tlin.com>, Nadav Haklai <nadavh@...vell.com> Subject: Re: [PATCH net-next v3] net: dsa: mv88e6xxx: Prevent suspend to RAM On Tue, Apr 09, 2019 at 09:06:43AM +0200, Miquel Raynal wrote: > Hi Pavel, > > Pavel Machek <pavel@....cz> wrote on Mon, 8 Apr 2019 23:55:41 +0200: > > > On Tue 2019-02-05 12:07:28, Miquel Raynal wrote: > > > On one hand, the mv88e6xxx driver has a work queue called in loop > > > which will attempt register accesses after MDIO bus suspension, that > > > entirely freezes the platform during suspend. > > > > > > On the other hand, the DSA core is not ready yet to support suspend to > > > RAM operation because so far there is no way to recover reliably the > > > switch configuration. > > > > > > To avoid the kernel to freeze when suspending with a switch driven by > > > the mv88e6xxx driver, we choose to prevent the driver suspension and > > > in the same way, the whole platform. > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com> > > > > Could we at least do printk() so that user knows what went wrong? > > > > Debugging s2ram is usually not easy :-(. > > I suppose you will be told that suspend was refused by a driver > (probably without stating which one though). You may send a patch to add > a trace if you think it is important, as this change as already been > merged. Hi Miquel, Pavel I don't know the s2ram code at all, but this seems like a generic problem. The core should be reporting which driver returned an error, not the driver itself. Andrew
Powered by blists - more mailing lists