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: Wed, 9 Aug 2023 11:01:00 +0200
From: Marco Felsch <m.felsch@...gutronix.de>
To: Rob Herring <robh@...nel.org>
Cc: kernel@...gutronix.de, devicetree@...r.kernel.org, conor+dt@...nel.org,
	mcoquelin.stm32@...il.com, netdev@...r.kernel.org,
	alexandre.torgue@...s.st.com, linux-kernel@...r.kernel.org,
	edumazet@...gle.com, joabreu@...opsys.com,
	krzysztof.kozlowski+dt@...aro.org, peppe.cavallaro@...com,
	kuba@...nel.org, pabeni@...hat.com, davem@...emloft.net,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net-next v4 1/3] dt-bindings: net: snps,dwmac: add
 phy-supply support

Hi Rob,

On 23-07-24, Marco Felsch wrote:
> Hi Rob,
> 
> On 23-07-21, Rob Herring wrote:
> > On Fri, Jul 21, 2023 at 01:03:43PM +0200, Marco Felsch wrote:
> > > Document the common phy-supply property to be able to specify a phy
> > > regulator.
> > 
> > What common property? I don't see any such property in 
> > ethernet-controller.yaml.
> 
> Not in ethernet-controller.yaml but there are at least a few user of
> this binding:
>  - allwinner,sun4i-a10-mdio.yaml
>  - allwinner,sun7i-a20-gmac.yaml
>  - allwinner,sun8i-a83t-emac.yaml
>  - fsl,fec.yaml
>  - rockchip-dwmac.yaml
>  - rockchip,emac.yaml
> 
> Also there is no <vendor>,phy-supply nor <ip-vendor>,phy-supply,
> therefore I thought this is common.

any further comments else I would like to gentle ping this series.

Regards,
  Marco

> > > Signed-off-by: Marco Felsch <m.felsch@...gutronix.de>
> > > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> > > ---
> > > Changelog:
> > > v4:
> > > - no changes
> > > v3:
> > > - no changes
> > > v2
> > > - add ack-by
> > > 
> > >  Documentation/devicetree/bindings/net/snps,dwmac.yaml | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > index ddf9522a5dc23..847ecb82b37ee 100644
> > > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > @@ -160,6 +160,9 @@ properties:
> > >        can be passive (no SW requirement), and requires that the MAC operate
> > >        in a different mode than the PHY in order to function.
> > >  
> > > +  phy-supply:
> > > +    description: PHY regulator
> > 
> > Is this for an serdes, sgmii, etc. type phy or ethernet phy? Either way, 
> > this property belongs in the PHY's node because it is the PHY that has 
> > supply connection. I'm guessing you put this here for the latter case 
> > because ethernet PHYs on MDIO are "discoverable" except for the small 
> > problem that powering them on is not discoverable. 
> 
> All kind of ethernet phys connected to you etherent MAC which need to be
> power controlled by software. You're right this sould belong to the PHY
> node (as Krzysztof already mentioned) but this isn't the case yet. As
> you can see there are at least 6 user of the exact same binding.
> 
> Regards,
>   Marco
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ