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]
Message-ID: <20140926165919.GA3518@sysresccd>
Date:	Fri, 26 Sep 2014 11:59:19 -0500
From:	Michael Welling <mwelling@...cinc.com>
To:	Florian Fainelli <f.fainelli@...il.com>
Cc:	linux-kernel@...r.kernel.org, grant.likely@...aro.org,
	linus.walleij@...aro.org, rjw@...ysocki.net,
	gregkh@...uxfoundation.org, Nicolas Ferre <nicolas.ferre@...el.com>
Subject: Re: GPIO registration for external Ethernet PHY oscillator
 enable/disable

On Thu, Sep 25, 2014 at 12:56:34PM -0700, Florian Fainelli wrote:
> So, PHY drivers are allowed to provide specialized implementations for
> suspend/resume operations that are called by phy_suspend() and
> phy_resume(), the current Micrel PHY driver uses the generic
> suspend/resume implementation and it is best if we can keep doing that.
>

In my situation the defualt phy_suspend is not sufficient. We are
looking to use the board for an application that requires a low sleep
current. The KZS8081 has a slow oscillator low power mode that is 
required to meet the requirements.

So I have already overwritten the suspend/resume to send the required
commands to the PHY to achieve the slow clock mode.

If you are interested the sequence is explained in the datasheet pg 34:
http://www.micrel.com/_PDF/Ethernet/datasheets/KSZ8081MNX-RNB.pdf

> > Can it be handled outside of the PHY driver?
> 
> I see a few possible options:
> 
> - hook a pm_runtime callbacks for your platform, check the device
> pointer to make sure this is the PHY device, and when that is the case,
> toggle the GPIO accordingly

Not too familiar with the pm_runtime callbacks.

Can you point me to a similar example that is already in the kernel?

> 
> - add an additional "osc_gpio" configuration parameter passed to the
> Ethernet MAC driver (presumably drivers/net/ethernet/cadence/macb.c?)
> and toggle the GPIO before and after the calls to the PHY state machine
> (phy_suspend, phy_resume, phy_start, phy_stop), that might be simpler
>

This seems the wrong place as the oscillator is specific to the PHY.

> - last but not least, make the PHY driver aware of that optional GPIO,
> create customized PHY suspend/resume/config_aneg callbacks
> 

This to me feels like the path of least resistance. Though the driver
does not appear to be a platform driver so I am not sure how to pass
GPIOs to it. Maybe I am missing something.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ