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:	Thu, 22 Aug 2013 08:34:48 +0200
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	Olof Johansson <olof@...om.net>
Cc:	dinguyen@...era.com, dinh.linux@...il.com, netdev@...r.kernel.org,
	Richard Cochran <richardcochran@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Felipe Balbi <balbi@...com>,
	"David S. Miller" <davem@...emloft.net>,
	Giuseppe Cavallaro <peppe.cavallaro@...com>,
	Rob Herring <rob.herring@...xeda.com>,
	devicetree@...r.kernel.org
Subject: Re: [RFC] phy: micrel: Convert micrel PHY driver to use OF

On Wed, Aug 21, 2013 at 10:13:47PM -0700, Olof Johansson wrote:
> (adding devicetree@...r.kernel.org)
> 
> 
> On Tue, Aug 13, 2013 at 11:42:36AM -0500, dinguyen@...era.com wrote:
> > ---
> > Hello,
> > 
> > I would like to solicit comments on the need to convert the ethernet PHY
> > drivers to use OF/device trees? For the platform that I'm interested in,
> > SOCFPGA, it is using the stmicro ethernet driver. It has a Micrel PHY
> > on the board. The only way that I know of how to change the skew settings
> > for the phy is through a board level initialization.
> > 
> > One of the ARM maintainers suggested that perhaps refactoring the ethernet
> > driver to use device tree would be nice. But that would not help me with
> > configuring the PHY settings.
> > 
> > So a little investigation led me to believe that refactoring the /net/phy
> > drivers into a device tree implementation would help greatly. I was thinking
> > it could be done like the pinctrl or some of the usb/phy driver.
> > 
> > Since I am only familiar with the ARM SoC space, I want to make sure that
> > this idea is right approach. I can start with the micrel PHY driver
> > first, as that is the only HW I have access to.
> 
> Hi,
> 
> Sorry for the slow reply here.
> 
> I don't think this is quite the right approach.
> 
> What you want to do is to make the phy devices register based on device tree
> contents, which also means removing the run function, or rather moving it to
> a generic run function in the phy subsystem that acts based on device tree
> contents instead of a hard-coded per-board run function.
> 
> It sounds like defining that binding might end up getting complicated.
> I suggest you consider recruiting some of the more seasoned devicetree folks on
> this endeavor.
> 
> It's possible that you'll mostly have per-vendor/phy type properties to tune
> the various settings, but it's also likely that you will have some generic and
> shared (optional) properties such as gpios for resetting, or regulators for
> powering, the phy.

This patch recently was merged:

http://patchwork.ozlabs.org/patch/268661/

It solves exactly the same problem of specifying the skew settings.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ