netdev - Re: MDIO Debug Interface

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: <C42SX4V16JRA.2YZ27ZW6U2CUL@wkz-x280>
Date:   Fri, 10 Jul 2020 10:29:47 +0200
From:   "Tobias Waldekranz" <tobias@...dekranz.com>
To:     "Florian Fainelli" <f.fainelli@...il.com>, <netdev@...r.kernel.org>
Cc:     <andrew@...n.ch>, <hkallweit1@...il.com>,
        "Vladimir Oltean" <olteanv@...il.com>
Subject: Re: MDIO Debug Interface

On Thu Jul 9, 2020 at 5:36 PM CEST, Florian Fainelli wrote:
> Certainly, the current interface clearly has deficiencies and since
> mdio_device instances were introduced, we should have an interface to
> debug those from user-space ala i2c-dev or spidev.
>
> Can you post the kernel code for review? Would you entertain having mdio

Certainly. I just linked to the repo to show how the userspace part
would look in combination with the netlink interface, and to see if I
was in ice-cube-in-hell territory or slightly better :)

> as an user-space command being part of ethtool for instance (just to
> ease the distribution)?

If by "ethtool" you mean the project, then yes. But I think it should
be a separate binary as ethtool is very interface centric.

We might not want to restrict ourselves to a single tool either. A
binary that can do basic register read/write seems like a good fit for
shipping alongside ethtool. But a tool to read/write the LinkCrypt
registers of a Marvell PHY, as an example, might be too specific and
better managed in a separate repo.

> --
> Florian