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: Mon, 08 Feb 2010 17:10:16 +0200 From: Mike Rapoport <mike@...pulab.co.il> To: Daniel Mack <daniel@...aq.de> CC: Steve Glendinning <steve.glendinning@...c.com>, netdev@...r.kernel.org, LAKML <linux-arm-kernel@...ts.infradead.org> Subject: Re: smsc911x suspend/resume Daniel Mack wrote: > On Mon, Feb 08, 2010 at 04:42:25PM +0200, Mike Rapoport wrote: >> Daniel Mack wrote: >>> In fact the datasheet doesn't really state that, and the chip seems >>> to expect the power domains to remain switched on during suspend, and >>> all power switching is done internally. Also the table in "7.4 Power >>> Consumption (Device and System Components)" describes it like that. >>> >>> So it all comes down to the question of how low-power you need to be, >>> and whether you need wake-on-lan or not. What's currently implemented is >>> D1, but adding support for D2 should be easy. >> I did some brute force save/restore of smsc9220 registers and it seems >> to wake up now. >> The question now is how to make it in a "generic" way ... >> Thanks for the help anyway :) > > Hmm, be careful about switching off power supplies that aren't supposed > to be switched off while others are still powered. You can easily > destroy hardware with that. Depending on how things are wired up > internally, voltages can leak from one unit block to the other. Maybe > Steve can can give a statement from official SMSC source about whether > it is safe to switch off VDD33A in this case. > > Anyway, from what's written in the datasheet, I wouldn't dare just > blindly doing it. I haven't dig too much in the datasheet, but I cannot remember anything about keeping certain power supplies on during suspend. The only clue is your comment in the driver that states "/* This implementation assumes the devices remains powered on its VDDVARIO * pins during suspend. */" And the platform I have either disables all supplies but VDDVARIO or keeps them all up. Anyway, I'll leave it running sleep/resume/ping cycle overnight to see in the morning what have burned :) > Daniel -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists