RE: Re: Attempting Yocto Scarthgap prototype using 0001-net-dsa-microchip-ksz9477-add-E2E-support.patch

<[email protected]>
Newsgroups org.kernel.vger.netdev
Message-ID <BNAP110MB1935F55396E14528B4FB2655C3DEA@BNAP110MB1935.NAMP110.PROD.OUTLOOK.COM>
Christian,

I owe you an update on our progress. It took a bit of experimentation, but we were eventually able to figure out the source of our wildly divergent master_offset values.

One of my co-workers (Mikhail) discovered what was missing. Here is the summary:

  *   Config of DSA / KSZ switch from 6.1 -> 6.6 moved a bunch of important (errata) configs from DSA driver -> Micrel driver.
  *   This change occurred in the common DSA driver code - had nothing to do with our out-of-tree E2E patch.
  *   Difficult to identify because chip config defaults DO NOT fail in obvious ways (working bonding, dhcp, ssh, ldap, http, even PTP on simpler networks).
  *   Enabling Micrel driver required one other change for our chip.
  *   Ultimately small 1 config + 1 kernel change needed. This is in addition to applying the E2E patch we had to ultimately

Commit comment from our local Linux kernel repo. This has some extra references & info.

    Enable micrel driver to handle ksz9477 logic being moved from dsa path to phy driver path.

      - Enabled Micrel PHY driver in defconfig
        - Allows KSZ9477/KSZ9567 PHY-specific init and EEE handling paths become available at runtime
        - https://github.com/Freescale/linux-fslc/commit/6068e6d7ba5001dfb96bb8b7b92e2ed2a5877786#diff-554dbe14174afbc1aad9f969287dadbff13f6a20e00067c6d9f4f936f316b52b
        - The KSZ9477 PHY errata handling code has now been moved into the Micrel PHY driver, so it is no longer needed inside the DSA switch driver.
      - Ensure MICREL_NO_EEE is enabled for KSZ9567_CHIP_ID
        - https://github.com/Freescale/linux-fslc/blob/6.6.x%2Bfslc/drivers/net/dsa/microchip/ksz_common.c#L2348
        - Found that KSZ9567 also requires EEE to be disabled as well
        - https://lkml.rescloud.iu.edu/2505.0/03000.html

arch/arm64/configs/two47_scarthgap_5.0.16_defconfig | 2 +-
drivers/net/dsa/microchip/ksz_common.c              | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)

I attached a copy of the .patch file that reflects our local changes for this fix which were applied in addition to the E2E .patch.

We still have some testing to do, but we now have PTP + E2E converging on Scarthap (currently 5.0.16 + kernel 6.6.50 + linuxptp4.1). Our offsets look very similar to our prior Dunfell/Kirkstone results .

-Matt

[email protected]<mailto:[email protected]>
(585) 369-1184

From: Christian Eggers <[email protected]>
Sent: Thursday, April 30, 2026 3:59 AM
To: Becker, Matt (US) - MCC <[email protected]>; Hutchinson, Brian (US) - MCC <[email protected]>
Cc: [email protected]; [email protected]; [email protected]
Subject: [EXTERNAL] Re: Attempting Yocto Scarthgap prototype using 0001-net-dsa-microchip-ksz9477-add-E2E-support.patch

WARNING: Email originated from an EXTERNAL source. Do NOT click links, open attachments or reply unless you recognize sender and know the content is safe.
CC: [email protected]<mailto:[email protected]>
CC: [email protected]<mailto:[email protected]>

Hi Matt, hi Brian,

although I did the initial development of the KSZ PTP patches, this never went
into our final products. Because of this, I am quite happy that Arun from
Microchip took over this and made several improvements.

The E2E patch was originally rejected (AFAIR), because the KSZ applies
(unwanted) filtering on the PTP messages. For E2E this means, that the
KSZ hardware filter needs to "know" whether this node is currently master or
slave clock. As there is no (and probably never will be) interface between
ptp4l and the kernel for communicating the current master/slave state, there
was no interest in merging this.

As we do not use PTP in our current software, I have only forward ported
the patch(es) for being compile clean (see attachment). But I haven't done
any real tests with newer kernels / ptp4l versions.

Unfortunately I will not be able to spent any time on this for the next
3 weeks. If the problem still persists then, I can try to have a look on
this. If you find the solution yourself, I would be happy getting an
update on this.

regards,
Christian

On Wednesday, 29 April 2026, 21:27:12 CEST, [email protected]<mailto:[email protected]> wrote:
> Christian/Arun,
>
> My name is Matt Becker. I work with Brian Hutchinson at L3Harris.
>
> A few years back we received & applied patches (net-dsa-microchip-ptp*) from Christian for our embedded board (imx8mm Arm processor + KSZ Microchip part). At the time these patches were developed for Yocto Dunfell (3.1) + Linux Kernel 5.10.69 + linuxptp-2.0 .
>
> We followed up and reapplied these patches with success on the same board when we upgraded to Yocto Kirkstone (4.0.x) + Linux Kernel 6.1.38 + linuxptp-3.1.1.
>
> We’re now attempting to bring this same board up to the most recent Yocto LTS release (Scarthgap 5.0.16) + Linux Kernel 6.6.50 + linuxptp-4.1 . This is where we’re running into some difficulty.
>
> It looks like most of the patches from a few years back were already merged back to the 6.6 kernel level. I only had to re-apply the patch 0001-net-dsa-microchip-ksz9477-add-E2E-support.patch as this was not merged back. It seems this change alone might not be sufficient. Our Scarthgap board is now able to select a grandmaster clock and it is able to receive adjustments. However, the master_offset values are very large, and PTP never converges.
>
> My suspicion is that I may need other changes to make this work on this new OS/kernel/PTP configuration.
>
> I was wondering if you might be able to offer any guidance:
>
> * Have you ever tried bringing this functionality (net-dsa-microchip-ksz9477-add-E2E-support) forward to a newer Linux kernel and/or PTP?
> * If so, do you have any unofficial patches we might be able to try?
> * If not, do you have any other advice on a path forward (e.g. changes that might be necessary outside of the original patches)?
>
> I attached an email thread with myself & Brian that has a little bit more detail.
>
> If you have any ideas or help you can offer it would be greatly appreciated!
>
> Sincerely,
>
> -Matt Becker
>
> [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>
> (585) 369-1184
>
>
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.
>
>
_______________________________________________________
​​​​
Christian

Eggers
Software Engineer
​
ARRI
Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Herbert‑Bayer‑Str. 10
,
80807

München
www.arri.com

<http://www.arri.com/>
[cid:[email protected]]
+49 89 3809-1321<tel:+49%2089%203809-1321>
[cid:[email protected]]
[email protected]<mailto:[email protected]>

​
[The cinematography of “Frankenstein” | shot on ALEXA 65]<https://youtu.be/Oka0A8RspUc?si=4NHJ78cNY_h5YQJx>
Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: München ‑ Registergericht: Amtsgericht München ‑ Handelsregisternummer: HRA 57918
Persönlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: München ‑ Registergericht: Amtsgericht München ‑ Handelsregisternummer: HRB 54477
Geschäftsführer: David Bermbach, Christian Richter

​
image001.png (image/png, 528 B) - not displayed
image002.png (image/png, 824 B) - not displayed
image003.jpg (image/jpeg, 169.9 KB) - not displayed
0001-Enable-micrel-driver-to-handle-ksz9477-logic-being-m.patch (application/octet-stream, 2.2 KB)
From 6e836bda5304943cdf93fa6c3f8d7cfccee0c28e Mon Sep 17 00:00:00 2001
From: Mikhail Mikhaylov <[email protected]>
Date: Thu, 30 Jul 2026 13:11:20 -0400
Subject: [PATCH 1/2] Enable micrel driver to handle ksz9477 logic being moved
 from dsa path to phy driver path.

  - Enabled Micrel PHY driver in defconfig
    - Allows KSZ9477/KSZ9567 PHY-specific init and EEE handling paths become available at runtime
    - https://github.com/Freescale/linux-fslc/commit/6068e6d7ba5001dfb96bb8b7b92e2ed2a5877786#diff-554dbe14174afbc1aad9f969287dadbff13f6a20e00067c6d9f4f936f316b52b
    - The KSZ9477 PHY errata handling code has now been moved into the Micrel PHY driver, so it is no longer needed inside the DSA switch driver.
  - Ensure MICREL_NO_EEE is enabled for KSZ9567_CHIP_ID
    - https://github.com/Freescale/linux-fslc/blob/6.6.x%2Bfslc/drivers/net/dsa/microchip/ksz_common.c#L2348
    - Found that KSZ9567 also requires EEE to be disabled as well
    - https://lkml.rescloud.iu.edu/2505.0/03000.html
---
 arch/arm64/configs/two47_scarthgap_5.0.16_defconfig | 2 +-
 drivers/net/dsa/microchip/ksz_common.c              | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/configs/two47_scarthgap_5.0.16_defconfig b/arch/arm64/configs/two47_scarthgap_5.0.16_defconfig
index d6ad4f3508..c625aa4e25 100644
--- a/arch/arm64/configs/two47_scarthgap_5.0.16_defconfig
+++ b/arch/arm64/configs/two47_scarthgap_5.0.16_defconfig
@@ -1941,7 +1941,7 @@ CONFIG_FIXED_PHY=y
 # CONFIG_MARVELL_88X2222_PHY is not set
 # CONFIG_MAXLINEAR_GPHY is not set
 # CONFIG_MEDIATEK_GE_PHY is not set
-# CONFIG_MICREL_PHY is not set
+CONFIG_MICREL_PHY=y
 CONFIG_MICROCHIP_PHY=y
 # CONFIG_MICROCHIP_T1_PHY is not set
 # CONFIG_MICROSEMI_PHY is not set
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 1c3f186499..2ba5a989e6 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -2344,6 +2344,7 @@ static u32 ksz_get_phy_flags(struct dsa_switch *ds, int port)
 		if (!port)
 			return MICREL_KSZ8_P1_ERRATA;
 		break;
+	case KSZ9567_CHIP_ID:
 	case KSZ9477_CHIP_ID:
 		/* KSZ9477 Errata DS80000754C
 		 *
-- 
2.43.0
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.