netdev - Re: [PATCH] usbnet: Set duplex status to unknown in the absence of MII

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: <20250723084456.1507563-1-yicongsrfy@163.com>
Date: Wed, 23 Jul 2025 16:44:56 +0800
From: yicongsrfy@....com
To: oneukum@...e.com
Cc: andrew+netdev@...n.ch,
	andrew@...n.ch,
	davem@...emloft.net,
	linux-usb@...r.kernel.org,
	netdev@...r.kernel.org,
	yicong@...inos.cn
Subject: Re: [PATCH] usbnet: Set duplex status to unknown in the absence of MII

On Wed, 23 Jul 2025 09:17:02 +0200 Oliver <oneukum@...e.com> wrote:
>
> On 23.07.25 03:29, yicongsrfy@....com wrote:
>
> >  From these two tests, we can conclude that both full-duplex
> > and half-duplex modes are supported — the problem is simply
> > that the duplex status cannot be retrieved in the absence of
> > MII support.
>
> Sort of. You are asking a generic driver to apply a concept
> from ethernet. It cannot. Ethernet even if it is half-duplex
> is very much symmetrical in speed. Cable modems do not, just
> to give an example.
>
> I think we need to centralize the reaction to stuff that is not ethernet.

Thanks!

I think I understand what you mean now.
You're suggesting to create a unified interface or
framework to retrieve the duplex status of all CDC
protocol-supported devices?
This seems like a rather big undertaking, and one of the key
reasons is that the CDC protocol itself does not define anything
related to duplex status — unlike the 802.3 standard, which
clearly defines how to obtain this information via MDIO.

Coming back to the issue described in this patch,
usbnet_get_link_ksettings_internal is currently only used in
cdc_ether.c and cdc_ncm.c as a callback for ethtool.
Can we assume that this part only concerns Ethernet devices
(and that, at least for now, none of the existing devices can
retrieve the duplex status through this interface)?