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, 20 Jan 2022 07:52:01 +0000
From:   Holger Brunck <holger.brunck@...achienergy.com>
To:     Marek BehĂșn <kabel@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Andrew Lunn <andrew@...n.ch>
Subject: RE: [v3 2/2] dsa: mv88e6xxx: make serdes SGMII/Fiber output amplitude
 configurable

Hi Marek,

> >
> > > > This gets interesting when PCIe and USB needs to use this
> > > > property, what names are used, and if it is possible to combine
> > > > two different lists?
> > >
> > > I don't think it is possible, I tried that once and couldn't get it to work.
> > >
> > > I am going to try write the proposal. But unfortunately PHY binding
> > > is not converted to YAML yet :(
> > >
> >
> > I saw you recent patches to convert this. Thanks!
> >
> > This make my serdes.yaml obsolete then, correct? Should I then only
> > re-post my driver code, once your patches are accepted?
> 
> Yes, please let's do it this way. It may take some time for Rob to review this,
> though, and he may require some changes.
> 

I saw your v3 patch for the bindings and I would adapt then my patch
accordingly to tx-p2p-microvolt. 

> Also I was thinking whether it wouldn't be better to put the property into a
> separate SerDes PHY node, i.e.
> 
>   switch {
>     compatible = "marvell,mv88e6085";
>     ...
> 
>     ports {
>       port@6 {
>         reg = <0x6>;
>         phy-handle = <&switch_serdes_phy>;
>       };
> 
>       ...
>     };
> 
>     mdio {
>       switch_serdes_phy: ethernet-phy@f {
>         reg = <0xf>;
>         tx-amplitude-microvolt = <1234567>;
>       };
> 
>       ...
>     };
>   };

this would mean in regard to my patch instead of checking directly for the
property in mv88e6xxx_setup_port  I would parse for the phy-handle first
and then for the property? 

Should I wait until your patch is accepted and merged?

Best regards
Holger

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ