linux-kernel - Re: [PATCH 2/2] net: phy: adin: implement cable-test 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+U=DsrZM4gRpmez6KqT8XTEBYwA-gwHjHQWa3Pn+G1nsYD3CA@mail.gmail.com>
Date:   Wed, 21 Oct 2020 17:16:03 +0300
From:   Alexandru Ardelean <ardeleanalex@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Alexandru Ardelean <alexandru.ardelean@...log.com>,
        netdev@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Heiner Kallweit <hkallweit1@...il.com>, linux@...linux.org.uk,
        David Miller <davem@...emloft.net>, kuba@...nel.org
Subject: Re: [PATCH 2/2] net: phy: adin: implement cable-test support

On Wed, Oct 21, 2020 at 5:09 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@...log.com>
>

removed my typo-ed email

> Hi Alexandru
>
> Overall, this looks good.
>
> > +static int adin_cable_test_report_trans(int result)
> > +{
> > +     int mask;
> > +
> > +     if (result & ADIN1300_CDIAG_RSLT_GOOD)
> > +             return ETHTOOL_A_CABLE_RESULT_CODE_OK;
> > +     if (result & ADIN1300_CDIAG_RSLT_OPEN)
> > +             return ETHTOOL_A_CABLE_RESULT_CODE_OPEN;
> > +
> > +     /* short with other pairs */
> > +     mask = ADIN1300_CDIAG_RSLT_XSHRT3 |
> > +            ADIN1300_CDIAG_RSLT_XSHRT2 |
> > +            ADIN1300_CDIAG_RSLT_XSHRT1;
> > +     if (result & mask)
> > +             return ETHTOOL_A_CABLE_RESULT_CODE_CROSS_SHORT;
>
> The nice thing about the netlink API is that it is extendable without
> breaking backwards compatibility. You could if you want add another
> attribute, indicating what pair it is shorted to.

That would be an idea.

Actually, I'd also be interested [for this PHY], to report a
"significance impedance" detection, which is similar to the
short-detection that is already done.
At first, this report would sound like it could be interesting; but
feel free to disagree with me.

And there's also some "busy" indicator; as-in "unknown activity during
diagnostics"; to-be-honest, I don't know what this is yet.
I'd need to check, but odds are that I'd need to also ask about it.
So, I don't think I'd implement this.

>
>         Andrew