[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZdyzUMQ+MmQ7E7sX@shell.armlinux.org.uk>
Date: Mon, 26 Feb 2024 15:50:40 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Shengyu Qu <wiagn233@...look.com>
Cc: Andrew Lunn <andrew@...n.ch>, hkallweit1@...il.com, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH v1] net: sfp: add quirks for ODI DFP-34X-2C2
On Mon, Feb 26, 2024 at 11:20:47PM +0800, Shengyu Qu wrote:
> Hi Andrew,
>
> When telnet connected to the stick(It's using busybox), "cat /proc/kmsg"
> would report something like "<4>change mode to 0", that 0 is the actual
> speed rate codename it changes to. You could check this [1] for more
> information.
>
> Sorry but I can't record my kmsg output now, since enable connection to
> my stick would make the network to disconnect for all users and my
> roommates are using it.
>
> Best regards,
> Shengyu
>
> [1] https://github.com/Anime4000/RTL960x/blob/main/Docs/FLASH_GETSET_INFO.md#lan_sds_mode
I'm aware of that link, and sadly the information in that table can at
best be described as "confused".
For example, under "Behaviour" it mentions "1GbaseT/100baseT". How
exactly does a SFP module exhibit baseT behaviour (which is twisted
pair copper ethernet.) Hint: it can't and it doesn't. "Mode" being
listed as "TP" is also misleading and wrong. The ethtool value of
0x20 is bit 5, which is 1000baseT_Full which has nothing to do with
a SFP (and won't be reported as even a supported mode for this SFP.)
Bit 41 would make sense (1000baseX), which is listed against mode 1.
I'm afraid looking at that URL just adds to more confusion.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists