netdev - Re: [PATCH] phy: power management support

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] [day] [month] [year] [list]

Message-ID: <20081203032505.GA13484@xw6200.broadcom.net>
Date:	Tue, 2 Dec 2008 19:25:05 -0800
From:	"Matt Carlson" <mcarlson@...adcom.com>
To:	"Giuseppe CAVALLARO" <peppe.cavallaro@...com>
cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] phy: power management support

A while ago Andy Fleming had replied to one of my patches expressing an
interest in implementing WOL (which I expanded to mean "more control of
the lifetime of the phy") within the phylib.  I responded that there
were two problems with that approach.  Very briefly, the problems were
that the phylib did not have enough information available to determine
what power state to put the phy into (think management firmware), and
that turning off the phy might interfere with the normal operation of
some MAC registers.  I'm sorry that thread died so abruptly.

My concerns remain though.  At the time the phy is initially probed,
there is no way to gather enough information to determine whether or not
it is safe to power down the phy.  The earliest such information can be
communicated is through the flags parameter of the phy_connect()
function.

I can't speak for the other uses of the phylib, but for tg3 it makes a
lot of sense to place phy power management in the hands of the driver
that controls it.  If you agree, can we devise a way to bypass the
suspend callback?

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