netdev - Re: [RFC v2 2/2] NET: PHY: lantiq: add LED configuration 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]

Date:	Sun, 29 May 2016 00:03:23 +0200
From:	Andrew Lunn <andrew@...n.ch>
To:	Hauke Mehrtens <hauke@...ke-m.de>
Cc:	f.fainelli@...il.com, alexander.stein@...tec-electronic.com,
	netdev@...r.kernel.org, john@...ozen.org, openwrt@...sin.me,
	hauke.mehrtens@...el.com, daniel.schwierzeck@...il.com,
	eckert.florian@...glemail.com
Subject: Re: [RFC v2 2/2] NET: PHY: lantiq: add LED configuration support

> Do you know for which PHY I could implement this? I only have access to
> the documentation for the Lantiq / Intel PHYs.

Maybe actually implementing them is too far. But you could take a look
at available datasheets and thing about how you would implement the
binding. A quick search found:

http://www.davicom.com.tw/userfile/24247/DM9161-DS-F05_091008.pdf
http://www.o2xygen.com/photo/VSC8201XVZ/VSC8201XVZ_001.pdf
http://www.ti.com.cn/cn/lit/ds/symlink/dp83640.pdf
http://www.ti.com/lit/ds/symlink/dp83848-ep.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/KSZ8081MNX-RNB.pdf

Is what you have defined flexible enough?
 
> Should this documentation file be specific for this PHY driver or
> should I add two files for documentation one describing the generic
> interface and then an additional one describing the concrete
> capabilities of this PHY?

Yes, have a generic document which any PHY should be able to use, and
a specific one per PHY.

> I also thought about this, but as far as I know there is no standard
> interface for these properties. I think setting the max speed is
> standardized by the ieee. Should there be a callback with the
> information needed for the PHY driver? I think having the parsing in the
> generic code will not make the PHY driver much simpler, but we could
> later provide these settings for different places like change the
> configuration from user space.

What we don't want is X PHYs with Y different LED bindings. We should
be aiming to describe a binding which fits the majority of PHYs. And
since it should fit the majority of PHYs we can pull parts of it into
the infrastructure. That itself will prevent people doing something
different.

	Andrew