netdev - PHY hardware reset

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

Date:	Sun, 6 Mar 2016 01:09:40 +0300
From:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To:	Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org
Subject: PHY hardware reset

Hello.

    I have a need to de-assert the active-low PHY hardware reset signal 
(mapped to a GPIO) before the MDIO bus scansince it's left asserted by the 
bootloader (U-Boot). I have a device tree probed MAX driver (ravb) and I'm 
somewhat at a loss about where and how to do this. The existing example 
(Freescale FEC) has DT props controlling the PHY reset GPIO in the MAC device 
node but it doesn't seem correct at all since this signal has nothing to do 
with the MAC, only with PHY! I therefore would like this "phy-reset-gpios" 
property to be defined under the PHY node but this way I'll have to add the 
handling of this prop to the phylib (it would be too late if I did that in a a 
PHY driver method since that). I'm also seeing the mii_bus::reset() method and 
it seems a good place but I'm not sure if my PHY's reset signal can be treated 
as the reset signal for the whole bus; if it would, the DT prop should be 
placed under the MAC node anyway...
    Florian (and everybody), what's your thoughts on this matter?

MBR, Sergei