[PATCH net-next v2] net: dsa: microchip: enable SGMII port for KSZ9897

[PATCH net-next v2] net: dsa: microchip: enable SGMII port for KSZ9897

[Tapio Reijonen]

The KSZ9897 has an SGMII/1000BASE-X capable port 7, but its chip_info
entry never set .sgmii_port. As a result ksz_has_sgmii_port() is false,
ksz9477_pcs_create() is never called, and ksz9477_phylink_mac_select_pcs()
returns NULL for port 7, so no PCS is ever instantiated and a
phy-mode = "sgmii" or "1000base-x" link on that port cannot come up.

The KSZ9897 shares the KSZ9477 register layout and operations
(ksz9477_dev_ops, ksz9477_regs) and reaches its port-7 PCS through the
same SPI-indirect XPCS register window. The register-identical LAN9646
already enables this via .sgmii_port = 7. Set the same for the KSZ9897
so the XPCS instance is created and 1000BASE-X / SGMII links on port 7
negotiate correctly.

Tested on a KSZ9897 with a 1000BASE-X fibre SFP wired directly to
port 7: the link negotiates at 1Gbps/full duplex and passes traffic.

Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
---
Changes in v2:
- Resend only, no functional change: v1 was dropped when the netdev
  patch queue overflowed.
- Rebased onto current net-next.
- Link to v1: https://lore.kernel.org/r/20260703-ksz9897-sgmii-port-v1-1-387e7632dd0b@vaisala.com
---
 drivers/net/dsa/microchip/ksz_common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 1a9d6f83a0232830ac4996ae5f53b8bde0b3747d..a80fde0a8c7e93ea2db4baeb2f941a260e23b687 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -1484,6 +1484,7 @@ const struct ksz_chip_data ksz_switch_chips[] = {
 		.internal_phy	= {true, true, true, true,
 				   true, false, false},
 		.gbit_capable	= {true, true, true, true, true, true, true},
+		.sgmii_port = 7,
 	},
 
 	[KSZ9893] = {

---
base-commit: b54074ffb813aa4b97585d97ae1ead69d96432b5
change-id: 20260703-ksz9897-sgmii-port-48ddb100e015

Best regards,
-- 
Tapio Reijonen <tapio.reijonen@vaisala.com>

Re: [PATCH net-next v2] net: dsa: microchip: enable SGMII port for KSZ9897

[Nicolai Buchwitz]

Hi Tapio

On 11.8.2026 12:20, Tapio Reijonen wrote:
> The KSZ9897 has an SGMII/1000BASE-X capable port 7, but its chip_info
> entry never set .sgmii_port.

AFAIK only the KSZ9897S variant.  AN5513 says the S "contains the same 
SGMII
port as the KSZ9477 however, the KSZ9897R has a second RGMII port", and
the R data sheet never mentions SGMII at all.

Unfortunately the chip id for both seems to be identical (0x00989700), 
so
this would apply to the R variant too. With this the R variant should
return -ENODEV in ksz9477_pcs_create() during probe.

Have a look how KSZ9563 is split off the KSZ9893 chip id, so maybe it 
can
be solved in a similar manner.  PORT_SGMII_SEL could also be worth a 
look.

> As a result ksz_has_sgmii_port() is false,
> ksz9477_pcs_create() is never called, and 
> ksz9477_phylink_mac_select_pcs()
> returns NULL for port 7, so no PCS is ever instantiated and a
> phy-mode = "sgmii" or "1000base-x" link on that port cannot come up.
> 
> The KSZ9897 shares the KSZ9477 register layout and operations
> (ksz9477_dev_ops, ksz9477_regs) and reaches its port-7 PCS through the
> same SPI-indirect XPCS register window. The register-identical LAN9646
> already enables this via .sgmii_port = 7. Set the same for the KSZ9897
> so the XPCS instance is created and 1000BASE-X / SGMII links on port 7
> negotiate correctly.
> 
> Tested on a KSZ9897 with a 1000BASE-X fibre SFP wired directly to
> port 7: the link negotiates at 1Gbps/full duplex and passes traffic.
> 
> Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
> ---
> Changes in v2:
> - Resend only, no functional change: v1 was dropped when the netdev
>   patch queue overflowed.
> - Rebased onto current net-next.
> - Link to v1: 
> https://lore.kernel.org/r/20260703-ksz9897-sgmii-port-v1-1-387e7632dd0b@vaisala.com
> ---
>  drivers/net/dsa/microchip/ksz_common.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/dsa/microchip/ksz_common.c 
> b/drivers/net/dsa/microchip/ksz_common.c
> index 
> 1a9d6f83a0232830ac4996ae5f53b8bde0b3747d..a80fde0a8c7e93ea2db4baeb2f941a260e23b687 
> 100644
> --- a/drivers/net/dsa/microchip/ksz_common.c
> +++ b/drivers/net/dsa/microchip/ksz_common.c
> @@ -1484,6 +1484,7 @@ const struct ksz_chip_data ksz_switch_chips[] = {
>  		.internal_phy	= {true, true, true, true,
>  				   true, false, false},
>  		.gbit_capable	= {true, true, true, true, true, true, true},
> +		.sgmii_port = 7,
>  	},
> 
>  	[KSZ9893] = {
> 
> ---
> base-commit: b54074ffb813aa4b97585d97ae1ead69d96432b5
> change-id: 20260703-ksz9897-sgmii-port-48ddb100e015
> 
> Best regards,

Thanks,
Nicolai

Re: [PATCH net-next v2] net: dsa: microchip: enable SGMII port for KSZ9897

[Tapio Reijonen]

Hi Nicolai,

On 8/11/26 15:51, Nicolai Buchwitz wrote:
> Hi Tapio
> 
> On 11.8.2026 12:20, Tapio Reijonen wrote:
>> The KSZ9897 has an SGMII/1000BASE-X capable port 7, but its chip_info
>> entry never set .sgmii_port.
> 
> AFAIK only the KSZ9897S variant.  AN5513 says the S "contains the same
> SGMII
> port as the KSZ9477 however, the KSZ9897R has a second RGMII port", and
> the R data sheet never mentions SGMII at all.
> 
> Unfortunately the chip id for both seems to be identical (0x00989700),
> so
> this would apply to the R variant too. With this the R variant should
> return -ENODEV in ksz9477_pcs_create() during probe.
> 
> Have a look how KSZ9563 is split off the KSZ9893 chip id, so maybe it
> can
> be solved in a similar manner.  PORT_SGMII_SEL could also be worth a
> look.
> 
Thanks, you are right and I missed the R/S split.

It is worse than port 7 alone: ksz9477_setup() calls ksz9477_pcs_create()
under ksz_has_sgmii_port() and returns its error, so on a KSZ9897R the
XPCS probe would fail and the whole switch would fail to probe. Please
drop v2.

The part I tested is a KSZ9897STXI, so I only have the S variant here.

For v3 the driver has to tell the two variants apart before it enables
the PCS. I will look into how to do that, either detected at runtime or
selected from DT, whichever the hardware allows. If you know of a
register that distinguishes R from S, a pointer would be welcome.
>> As a result ksz_has_sgmii_port() is false,
>> ksz9477_pcs_create() is never called, and
>> ksz9477_phylink_mac_select_pcs()
>> returns NULL for port 7, so no PCS is ever instantiated and a
>> phy-mode = "sgmii" or "1000base-x" link on that port cannot come up.
>>
>> The KSZ9897 shares the KSZ9477 register layout and operations
>> (ksz9477_dev_ops, ksz9477_regs) and reaches its port-7 PCS through the
>> same SPI-indirect XPCS register window. The register-identical LAN9646
>> already enables this via .sgmii_port = 7. Set the same for the KSZ9897
>> so the XPCS instance is created and 1000BASE-X / SGMII links on port 7
>> negotiate correctly.
>>
>> Tested on a KSZ9897 with a 1000BASE-X fibre SFP wired directly to
>> port 7: the link negotiates at 1Gbps/full duplex and passes traffic.
>>
>> Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
>> ---
>> Changes in v2:
>> - Resend only, no functional change: v1 was dropped when the netdev
>>   patch queue overflowed.
>> - Rebased onto current net-next.
>> - Link to v1:
>> https://eur03.safelinks.protection.outlook.com/? 
>> url=https%3A%2F%2Flore.kernel.org%2Fr%2F20260703-ksz9897-sgmii-port- 
>> v1-1-387e7632dd0b%40vaisala.com&data=05%7C02%7Ctapio.reijonen%40vaisala.com%7Cf9bed626171545a2def808def7a74e64%7C6d7393e041f54c2e9b124c2be5da5c57%7C0%7C0%7C639220495162934870%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lKJyNr6ZRxDKC9BpnbIU1vVn8O4QfP7oz2WWlsrlAs4%3D&reserved=0
>> ---
>>  drivers/net/dsa/microchip/ksz_common.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/net/dsa/microchip/ksz_common.c
>> b/drivers/net/dsa/microchip/ksz_common.c
>> index
>> 1a9d6f83a0232830ac4996ae5f53b8bde0b3747d..a80fde0a8c7e93ea2db4baeb2f941a260e23b687
>> 100644
>> --- a/drivers/net/dsa/microchip/ksz_common.c
>> +++ b/drivers/net/dsa/microchip/ksz_common.c
>> @@ -1484,6 +1484,7 @@ const struct ksz_chip_data ksz_switch_chips[] = {
>>               .internal_phy   = {true, true, true, true,
>>                                  true, false, false},
>>               .gbit_capable   = {true, true, true, true, true, true, 
>> true},
>> +             .sgmii_port = 7,
>>       },
>>
>>       [KSZ9893] = {
>>
>> ---
>> base-commit: b54074ffb813aa4b97585d97ae1ead69d96432b5
>> change-id: 20260703-ksz9897-sgmii-port-48ddb100e015
>>
>> Best regards,
> 
> Thanks,
> Nicolai

Thanks for catching this.

Tapio