netdev - Re: [PATCH net-next v3 0/6] provide generic net selftest 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: <6416c580-0df9-7d36-c42d-65293c40aa25@gmail.com>
Date:   Tue, 27 Apr 2021 09:40:50 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Joakim Zhang <qiangqing.zhang@....com>,
        Oleksij Rempel <o.rempel@...gutronix.de>
Cc:     Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Fugang Duan <fugang.duan@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        Fabio Estevam <festevam@...il.com>,
        David Jander <david@...tonic.nl>,
        Russell King <linux@...linux.org.uk>,
        Philippe Schenker <philippe.schenker@...adex.com>
Subject: Re: [PATCH net-next v3 0/6] provide generic net selftest support



On 4/26/2021 9:48 PM, Joakim Zhang wrote:
> 
>> -----Original Message-----
>> From: Oleksij Rempel <o.rempel@...gutronix.de>
>> Sent: 2021年4月23日 12:37
>> To: Joakim Zhang <qiangqing.zhang@....com>
>> Cc: Shawn Guo <shawnguo@...nel.org>; Sascha Hauer
>> <s.hauer@...gutronix.de>; Andrew Lunn <andrew@...n.ch>; Florian Fainelli
>> <f.fainelli@...il.com>; Heiner Kallweit <hkallweit1@...il.com>; Fugang
>> Duan <fugang.duan@....com>; kernel@...gutronix.de;
>> netdev@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
>> linux-kernel@...r.kernel.org; dl-linux-imx <linux-imx@....com>; Fabio
>> Estevam <festevam@...il.com>; David Jander <david@...tonic.nl>; Russell
>> King <linux@...linux.org.uk>; Philippe Schenker
>> <philippe.schenker@...adex.com>
>> Subject: Re: [PATCH net-next v3 0/6] provide generic net selftest support
>>
>> Hi Joakim,
>>
>> On Fri, Apr 23, 2021 at 03:18:32AM +0000, Joakim Zhang wrote:
>>>
>>> Hi Oleksij,
>>>
>>> I look both stmmac selftest code and this patch set. For stmmac, if PHY
>> doesn't support loopback, it will fallthrough to MAC loopback.
>>> You provide this generic net selftest support based on PHY loopback, I have a
>> question, is it possible to extend it also support MAC loopback later?
>>
>> Yes. If you have interest and time to implement it, please do.
>> It should be some kind of generic callback as phy_loopback() and if PHY and
>> MAC loopbacks are supported we need to tests both variants.
> Hi Oleksij,
> 
> Yes, I can try to implement it when I am free, but I still have some questions:
> 1. Where we place the generic function? Such as mac_loopback().
> 2. MAC is different from PHY, need program different registers to enable loopback on different SoCs, that means we need get MAC private data from "struct net_device".
> So we need a callback for MAC drivers, where we extend this callback? Could be "struct net_device_ops"? Such as ndo_set_loopback?

Even for PHY devices, if we implemented external PHY loopback in the
future, the programming would be different from one vendor to another. I
am starting to wonder if the existing ethtool self-tests are the best
API to expose the ability for an user to perform PHY and MAC loopback
testing.

>From an Ethernet MAC and PHY driver perspective, what I would imagine we
could have for a driver API is:

enum ethtool_loopback_mode {
	ETHTOOL_LOOPBACK_OFF,
	ETHTOOL_LOOPBACK_PHY_INTERNAL,
	ETHTOOL_LOOPBACK_PHY_EXTERNAL,
	ETHTOOL_LOOPBACK_MAC_INTERNAL,
	ETHTOOL_LOOPBACK_MAC_EXTERNAL,
	ETHTOOL_LOOPBACK_FIXTURE,
	__ETHTOOL_LOOPBACK_MAX
};

	int (*ndo_set_loopback_mode)(struct net_device *dev, enum
ethtool_loopback_mode mode);

and within the Ethernet MAC driver you would do something like this:

	switch (mode) {
	case ETHTOOL_LOOPBACK_PHY_INTERNAL:
	case ETHTOOL_LOOPBACK_PHY_EXTERNAL:
	case ETHTOOL_LOOPBACK_OFF:
		ret = phy_loopback(ndev->phydev, mode);
		break;
	/* Other case statements implemented in driver */
	
we would need to change the signature of phy_loopback() to accept being
passed ethtool_loopback_mode so we can support different modes.

Whether we want to continue using the self-tests API, or if we implement
a new ethtool command in order to request a loopback operation is up for
discussion.
-- 
Florian