netdev - Re: smsc911x suspend/resume

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]

Date:	Mon, 08 Feb 2010 15:55:59 +0200
From:	Mike Rapoport <mike@...pulab.co.il>
To:	Steve.Glendinning@...c.com
CC:	Daniel Mack <daniel@...aq.de>,
	LAKML <linux-arm-kernel@...ts.infradead.org>,
	netdev@...r.kernel.org, Ian.Saturley@...c.com,
	Vlad.Lyalikov@...c.com, davem@...emloft.net
Subject: Re: smsc911x suspend/resume

Steve.Glendinning@...c.com wrote:
> Hi Mike,
> 
>>>> I'm trying to make suspend/resume work on OMAP3-based system and I'm
>>>> encountering issues with resume of SMSC 9220 chip.
>>>> After resume the interface is unusable unless I do 'ifconfig eth0 
> down'
>>>> and 'ifconfig eth0 up'.
>>>> I would expect that 'ping <some host>' would work right after resume
>>>> without need to bring the interface down and up, but probably I miss
>>>> something.
>>>> Any help would be appreciated.
>>> What happens to your supply voltages when going to suspend? When I
>>> implemented the code for the smsc driver, I could only test scenarios
>>> where AVDD remains stable during suspend. So the driver might need 
> some
>>> tweaks if that assumption is not true in your case. The SMSC datasheet
>>> is quite comprehensive about this topic IIRC.
>> By AVDD you mean VDD33A?
>> Anyway, I have all the supplies except VDDVARIO shut down...
>> And the datasheet is indeed comprehensively describes chip power states
>> but I haven't found there anything about supplies required to stay on
>> during suspend...
> 
> I don't have the code in front of me (I'm travelling today) but IIRC
> the driver doesn't place the LAN9220 in a specific power saving state,
> so as far as the LAN9220 is concerned it's not actually suspended.
> 
> It's hard to do this in a "generic" way: some people expect their link
> to stay up during suspend, some want suspend to completely power down
> the ethernet chip, and some want to use one of several WoL modes. 

Indeed a "generic" implementation may be tough task... Probably we can
add some platform_data flags for suspend modes and use them to decide
what low power mode should be selected?

> David: What's the "done thing" here for similar non-pci drivers?
> Obviously "doesn't work after suspend" isn't the intended behaviour, so
> there's definitely room for improvement!
> 
>>> Also have a look at the Raumfeld device patches which use exactly this
>>> chip and which can suspend and resume just fine. You'll need to check
>>> out Eric's devel branch for that.
> 
> Daniel: I haven't seen this, do you have a location for the git tree?
> 
> Thanks,
> Steve


-- 
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