<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/dsa/microchip, branch linux-6.10.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.10.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.10.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2024-08-29T15:36:08Z</updated>
<entry>
<title>net: dsa: microchip: fix PTP config failure when using multiple ports</title>
<updated>2024-08-29T15:36:08Z</updated>
<author>
<name>Martin Whitaker</name>
</author>
<published>2024-08-17T09:41:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6c323c3b8089b0affd0249cf9feb6e6595897535'/>
<id>urn:sha1:6c323c3b8089b0affd0249cf9feb6e6595897535</id>
<content type='text'>
commit 6efea5135417ae8194485d1d05ea79a21cf1a11c upstream.

When performing the port_hwtstamp_set operation, ptp_schedule_worker()
will be called if hardware timestamoing is enabled on any of the ports.
When using multiple ports for PTP, port_hwtstamp_set is executed for
each port. When called for the first time ptp_schedule_worker() returns
0. On subsequent calls it returns 1, indicating the worker is already
scheduled. Currently the ksz driver treats 1 as an error and fails to
complete the port_hwtstamp_set operation, thus leaving the timestamping
configuration for those ports unchanged.

This patch fixes this by ignoring the ptp_schedule_worker() return
value.

Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/7aae307a-35ca-4209-a850-7b2749d40f90@martin-whitaker.me.uk
Fixes: bb01ad30570b0 ("net: dsa: microchip: ptp: manipulating absolute time using ptp hw clock")
Signed-off-by: Martin Whitaker &lt;foss@martin-whitaker.me.uk&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Acked-by: Arun Ramadoss &lt;arun.ramadoss@microchip.com&gt;
Link: https://patch.msgid.link/20240817094141.3332-1-foss@martin-whitaker.me.uk
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: dsa: microchip: disable EEE for KSZ8567/KSZ9567/KSZ9896/KSZ9897.</title>
<updated>2024-08-14T13:34:05Z</updated>
<author>
<name>Martin Whitaker</name>
</author>
<published>2024-08-07T20:52:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9bd6911af5224834d8592831de40356b64873fa4'/>
<id>urn:sha1:9bd6911af5224834d8592831de40356b64873fa4</id>
<content type='text'>
[ Upstream commit 0411f73c13afcf619d7aa7546edbc5710a871cae ]

As noted in the device errata [1-8], EEE support is not fully operational
in the KSZ8567, KSZ9477, KSZ9567, KSZ9896, and KSZ9897 devices, causing
link drops when connected to another device that supports EEE. The patch
series "net: add EEE support for KSZ9477 switch family" merged in commit
9b0bf4f77162 caused EEE support to be enabled in these devices. A fix for
this regression for the KSZ9477 alone was merged in commit 08c6d8bae48c2.
This patch extends this fix to the other affected devices.

[1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/Errata/KSZ8567R-Errata-DS80000752.pdf
[2] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/Errata/KSZ8567S-Errata-DS80000753.pdf
[3] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/Errata/KSZ9477S-Errata-DS80000754.pdf
[4] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/Errata/KSZ9567R-Errata-DS80000755.pdf
[5] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/Errata/KSZ9567S-Errata-DS80000756.pdf
[6] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/Errata/KSZ9896C-Errata-DS80000757.pdf
[7] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/Errata/KSZ9897R-Errata-DS80000758.pdf
[8] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/Errata/KSZ9897S-Errata-DS80000759.pdf

Fixes: 69d3b36ca045 ("net: dsa: microchip: enable EEE support") # for KSZ8567/KSZ9567/KSZ9896/KSZ9897
Link: https://lore.kernel.org/netdev/137ce1ee-0b68-4c96-a717-c8164b514eec@martin-whitaker.me.uk/
Signed-off-by: Martin Whitaker &lt;foss@martin-whitaker.me.uk&gt;
Acked-by: Arun Ramadoss &lt;arun.ramadoss@microchip.com&gt;
Reviewed-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Reviewed-by: Lukasz Majewski &lt;lukma@denx.de&gt;
Link: https://patch.msgid.link/20240807205209.21464-1-foss@martin-whitaker.me.uk
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: dsa: microchip: Fix Wake-on-LAN check to not return an error</title>
<updated>2024-08-14T13:34:03Z</updated>
<author>
<name>Tristram Ha</name>
</author>
<published>2024-08-05T23:52:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f3535cfd8c932e08de62a52f03bc88b978da2f72'/>
<id>urn:sha1:f3535cfd8c932e08de62a52f03bc88b978da2f72</id>
<content type='text'>
[ Upstream commit c7a19018bd557c24072b59088ad2684fd83ea3f4 ]

The wol variable in ksz_port_set_mac_address() is declared with random
data, but the code in ksz_get_wol call may not be executed so the
WAKE_MAGIC check may be invalid resulting in an error message when
setting a MAC address after starting the DSA driver.

Fixes: 3b454b6390c3 ("net: dsa: microchip: ksz9477: Add Wake on Magic Packet support")
Signed-off-by: Tristram Ha &lt;tristram.ha@microchip.com&gt;
Reviewed-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Reviewed-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Link: https://patch.msgid.link/20240805235200.24982-1-Tristram.Ha@microchip.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: dsa: ksz_common: Allow only up to two HSR HW offloaded ports for KSZ9477</title>
<updated>2024-08-03T06:59:39Z</updated>
<author>
<name>Lukasz Majewski</name>
</author>
<published>2024-06-19T14:58:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=00e09f86c6fa522c4c55b7305c1df4fa396930bf'/>
<id>urn:sha1:00e09f86c6fa522c4c55b7305c1df4fa396930bf</id>
<content type='text'>
[ Upstream commit dcec8d291da8813b5e1c7c0967ae63463a8521f6 ]

The KSZ9477 allows HSR in-HW offloading for any of two selected ports.
This patch adds check if one tries to use more than two ports with
HSR offloading enabled.

The problem is with RedBox configuration (HSR-SAN) - when configuring:
ip link add name hsr0 type hsr slave1 lan1 slave2 lan2 interlink lan3 \
	supervision 45 version 1

The lan1 (port0) and lan2 (port1) are correctly configured as ports, which
can use HSR offloading on ksz9477.

However, when we do already have two bits set in hsr_ports, we need to
return (-ENOTSUPP), so the interlink port (lan3) would be used with
SW based HSR RedBox support.

Otherwise, I do see some strange network behavior, as some HSR frames are
visible on non-HSR network and vice versa.

This causes the switch connected to interlink port (lan3) to drop frames
and no communication is possible.

Moreover, conceptually - the interlink (i.e. HSR-SAN port - lan3/port2)
shall be only supported in software as it is also possible to use ksz9477
with only SW based HSR (i.e. port0/1 -&gt; hsr0 with offloading, port2 -&gt;
HSR-SAN/interlink, port4/5 -&gt; hsr1 with SW based HSR).

Fixes: 5055cccfc2d1 ("net: hsr: Provide RedBox support (HSR-SAN)")
Signed-off-by: Lukasz Majewski &lt;lukma@denx.de&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Reviewed-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: dsa: microchip: fix wrong register write when masking interrupt</title>
<updated>2024-06-25T11:26:25Z</updated>
<author>
<name>Tristram Ha</name>
</author>
<published>2024-06-21T22:34:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b1c4b4d45263241ec6c2405a8df8265d4b58e707'/>
<id>urn:sha1:b1c4b4d45263241ec6c2405a8df8265d4b58e707</id>
<content type='text'>
The switch global port interrupt mask, REG_SW_PORT_INT_MASK__4, is
defined as 0x001C in ksz9477_reg.h.  The designers used 32-bit value in
anticipation for increase of port count in future product but currently
the maximum port count is 7 and the effective value is 0x7F in register
0x001F.  Each port has its own interrupt mask and is defined as 0x#01F.
It uses only 4 bits for different interrupts.

The developer who implemented the current interrupt mechanism in the
switch driver noticed there are similarities between the mechanism to
mask port interrupts in global interrupt and individual interrupts in
each port and so used the same code to handle these interrupts.  He
updated the code to use the new macro REG_SW_PORT_INT_MASK__1 which is
defined as 0x1F in ksz_common.h but he forgot to update the 32-bit write
to 8-bit as now the mask registers are 0x1F and 0x#01F.

In addition all KSZ switches other than the KSZ9897/KSZ9893 and LAN937X
families use only 8-bit access and so this common code will eventually
be changed to accommodate them.

Fixes: e1add7dd6183 ("net: dsa: microchip: use common irq routines for girq and pirq")
Signed-off-by: Tristram Ha &lt;tristram.ha@microchip.com&gt;
Link: https://lore.kernel.org/r/1719009262-2948-1-git-send-email-Tristram.Ha@microchip.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;

</content>
</entry>
<entry>
<title>net: dsa: microchip: monitor potential faults in half-duplex mode</title>
<updated>2024-06-23T09:06:58Z</updated>
<author>
<name>Enguerrand de Ribaucourt</name>
</author>
<published>2024-06-21T14:43:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bf1bff11e497a01b0cc6cb2afcff734340ae95f8'/>
<id>urn:sha1:bf1bff11e497a01b0cc6cb2afcff734340ae95f8</id>
<content type='text'>
The errata DS80000754 recommends monitoring potential faults in
half-duplex mode for the KSZ9477 family.

half-duplex is not very common so I just added a critical message
when the fault conditions are detected. The switch can be expected
to be unable to communicate anymore in these states and a software
reset of the switch would be required which I did not implement.

Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477")
Signed-off-by: Enguerrand de Ribaucourt &lt;enguerrand.de-ribaucourt@savoirfairelinux.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: dsa: microchip: use collision based back pressure mode</title>
<updated>2024-06-23T09:06:58Z</updated>
<author>
<name>Enguerrand de Ribaucourt</name>
</author>
<published>2024-06-21T14:43:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d963c95bc9840d070a788c35e41b715a648717f7'/>
<id>urn:sha1:d963c95bc9840d070a788c35e41b715a648717f7</id>
<content type='text'>
Errata DS80000758 states that carrier sense back pressure mode can cause
link down issues in 100BASE-TX half duplex mode. The datasheet also
recommends to always use the collision based back pressure mode.

Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477")
Signed-off-by: Enguerrand de Ribaucourt &lt;enguerrand.de-ribaucourt@savoirfairelinux.com&gt;
Reviewed-by: Woojung Huh &lt;Woojung.huh@microchip.com&gt;
Acked-by: Arun Ramadoss &lt;arun.ramadoss@microchip.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: dsa: microchip: fix initial port flush problem</title>
<updated>2024-06-21T02:31:42Z</updated>
<author>
<name>Tristram Ha</name>
</author>
<published>2024-06-19T00:16:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ad53f5f54f351e967128edbc431f0f26427172cf'/>
<id>urn:sha1:ad53f5f54f351e967128edbc431f0f26427172cf</id>
<content type='text'>
The very first flush in any port will flush all learned addresses in all
ports.  This can be observed by unplugging the cable from one port while
additional ports are connected and dumping the fdb entries.

This problem is caused by the initially wrong value programmed to the
REG_SW_LUE_CTRL_1 register.  Setting SW_FLUSH_STP_TABLE and
SW_FLUSH_MSTP_TABLE bits does not have an immediate effect.  It is when
ksz9477_flush_dyn_mac_table() is called then the SW_FLUSH_STP_TABLE bit
takes effect and flushes all learned entries.  After that call both bits
are reset and so the next port flush will not cause such problem again.

Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477")
Signed-off-by: Tristram Ha &lt;tristram.ha@microchip.com&gt;
Link: https://patch.msgid.link/1718756202-2731-1-git-send-email-Tristram.Ha@microchip.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: dsa: microchip: fix RGMII error in KSZ DSA driver</title>
<updated>2024-05-30T01:44:36Z</updated>
<author>
<name>Tristram Ha</name>
</author>
<published>2024-05-28T21:34:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=278d65ccdadb5f0fa0ceaf7b9cc97b305cd72822'/>
<id>urn:sha1:278d65ccdadb5f0fa0ceaf7b9cc97b305cd72822</id>
<content type='text'>
The driver should return RMII interface when XMII is running in RMII mode.

Fixes: 0ab7f6bf1675 ("net: dsa: microchip: ksz9477: use common xmii function")
Signed-off-by: Tristram Ha &lt;tristram.ha@microchip.com&gt;
Acked-by: Arun Ramadoss &lt;arun.ramadoss@microchip.com&gt;
Acked-by: Jerry Ray &lt;jerry.ray@microchip.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/1716932066-3342-1-git-send-email-Tristram.Ha@microchip.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: dsa: microchip: Correct initialization order for KSZ88x3 ports</title>
<updated>2024-05-17T19:25:22Z</updated>
<author>
<name>Oleksij Rempel</name>
</author>
<published>2024-05-17T05:01:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f0fa84116434b50a8d249d0da8852f410a21ba98'/>
<id>urn:sha1:f0fa84116434b50a8d249d0da8852f410a21ba98</id>
<content type='text'>
Adjust the initialization sequence of KSZ88x3 switches to enable
802.1p priority control on Port 2 before configuring Port 1. This
change ensures the apptrust functionality on Port 1 operates
correctly, as it depends on the priority settings of Port 2. The
prior initialization sequence incorrectly configured Port 1 first,
which could lead to functional discrepancies.

Fixes: a1ea57710c9d ("net: dsa: microchip: dcb: add special handling for KSZ88X3 family")
Signed-off-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Reviewed-by: Hariprasad Kelam &lt;hkelam@marvell.com&gt;
Acked-by: Arun Ramadoss &lt;arun.ramadoss@microchip.com&gt;
Link: https://lore.kernel.org/r/20240517050121.2174412-1-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
</feed>
