[PATCH net-next v2 13/14] net: stmmac: tc956x: add TC956x/QPS615 support
Alex Elder
elder at riscstar.com
Tue Jun 9 12:32:00 PDT 2026
On 6/5/26 11:05 AM, Maxime Chevallier wrote:
> Hi Alex,
>
> On 6/5/26 03:00, Alex Elder wrote:
>> From: Daniel Thompson <daniel at riscstar.com>
>>
>> Toshiba TC956x is an Ethernet AVB/TSN bridge and is essentially a
>> small and highly-specialized SoC. TC956x includes an "eMAC" subsystem
>> that can be accessed, along with several other peripherals, via two
>> PCIe endpoint functions. There is a main driver for the endpoint that
>> decomposes things and creates auxiliary bus devices to model the SoC.
>>
>> The eMAC consists of a Designware XGMAC, XPCS and PMA. Each eMAC is
>> supported by an MSIGEN that bridges TC956x level interrupts to PCIe
>> MSIs.
>>
>> Add a driver for the eMAC/MSIGEN combination.
>>
>> Co-developed-by: Alex Elder <elder at riscstar.com>
>> Signed-off-by: Alex Elder <elder at riscstar.com>
>> Signed-off-by: Daniel Thompson <daniel at riscstar.com>
>> ---
> [...]
>
>> +static int tc956x_lookup_max_speed(phy_interface_t phy_interface)
>> +{
>> + switch (phy_interface) {
>> + case PHY_INTERFACE_MODE_SGMII:
>
> The SGMII definition we use in the kernel is the Cisco SGMII de-facto
> standard that only supports 10/100/1000M. Some vendors use flavours with
> names such as HS-SGMII and such, that's basically SGMII clocked at 2.5G
> with aneg disabled. It kinda becomes 2500BaseX then.
So for SGMII then, the max speed returned/used should be
SPEED_1000, correct? And for 2500BASEX it's SPEED_2500.
(I'll fix this.)
For USXGMII I presume we'd use SPEED_10000 as the max_speed.
Can someone explain when the plat_stmmacenet_data->max_speed value
must be set? It seems like plat_stmmacenet_data->phy_interface
should normally imply the right maximum speed. It looks like
phylink_interface_max_speed() has a big switch statement related
to this.
Thanks.
-Alex
> So all in all, we don't support 2500M on SGMII.
>
>> + case PHY_INTERFACE_MODE_2500BASEX:
>> + return SPEED_2500;
>> +
>> + default:
>> + return -EOPNOTSUPP;
>> + }
>
> Maxime
More information about the linux-arm-kernel
mailing list