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:	Mon, 14 Dec 2015 21:31:10 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Rob Herring <robh@...nel.org>,
	Gregory CLEMENT <gregory.clement@...e-electrons.com>
CC:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	devicetree@...r.kernel.org, netdev@...r.kernel.org,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	linux-kernel@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2] net/macb: add support for resetting PHY using GPIO

On December 14, 2015 2:56:34 PM PST, Rob Herring <robh@...nel.org> wrote:
>On Fri, Dec 11, 2015 at 11:34:53AM +0100, Gregory CLEMENT wrote:
>> With device tree it is no more possible to reset the PHY at board
>> level. Furthermore, doing in the driver allow to power down the PHY
>when
>> the network interface is no more used.
>> 
>> This reset can't be done at the PHY driver level. The PHY must be
>able to
>> answer the to the mii bus scan to let the kernel creating a PHY
>device.
>> 
>> The patch introduces a new optional property "phy-reset-gpios"
>inspired
>> from the one use for the FEC.
>> 
>> Signed-off-by: Gregory CLEMENT <gregory.clement@...e-electrons.com>
>> ---
>> 
>> Since the v1, I used the gpiod functions. It allows to simplify the
>> code and to not introduce any #ifdef.
>> 
>> I also rename the property in phy-reset-gpios, even if actually the
>> gpiod will match both phy-reset-gpios and phy-reset-gpio.
>> 
>> 
>>  Documentation/devicetree/bindings/net/macb.txt | 3 +++
>>  drivers/net/ethernet/cadence/macb.c            | 8 ++++++++
>>  drivers/net/ethernet/cadence/macb.h            | 1 +
>>  3 files changed, 12 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/net/macb.txt
>b/Documentation/devicetree/bindings/net/macb.txt
>> index b5d7976..4a7fb6c 100644
>> --- a/Documentation/devicetree/bindings/net/macb.txt
>> +++ b/Documentation/devicetree/bindings/net/macb.txt
>> @@ -19,6 +19,9 @@ Required properties:
>>  	Optional elements: 'tx_clk'
>>  - clocks: Phandles to input clocks.
>>  
>> +Optional properties:
>> +- phy-reset-gpios : Should specify the gpio for phy reset
>> +
>
>This alone is simple enough, but I worry that this doesn't really
>scale. 
>What if you need to enable clocks or regulators for the same reason?
>The 
>mmc folks did a pwrseq binding for similar reasons. I don't think I'd 
>recommend that here as I think it is kind of ugly. We really need a 
>pre-probe/scan hook for drivers. This is also needed for USB devices 
>mounted on boards.

In this particular case, the way Ethernet MAC drivers register their MDIO buses and therefore PHYs, there is always a good way to deassert the PHY GPIO line without requiring major core device driver changes. Worst case, there is the MDIO bus reset callback which could used for that matter.

In the case of PCI, USB etc. I do agree having a way to twiddle things before scanning/probing would be awesome. I have some boards here which have GPIO controlled regulator and hacking the RC driver to deal with that is suboptimal... 

>
>But I'm not going to hold up something simple to do all that, so:
>
>Acked-by: Rob Herring <robh@...nel.org>
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@...ts.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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