diff options
author | Jakub Kicinski <kuba@kernel.org> | 2025-04-30 00:44:39 +0300 |
---|---|---|
committer | Jakub Kicinski <kuba@kernel.org> | 2025-04-30 00:44:40 +0300 |
commit | 1e0bff3bb59ca9bf84243df2a4ad3cfa6ca6f303 (patch) | |
tree | ea760162e09865b0285fb57fb2fd93a9d4e5738e /drivers/platform/surface/aggregator/ssh_parser.c | |
parent | 6e0490fc36cdac696f96e57b61d93b9ae32e0f4c (diff) | |
parent | 4eb9da050f005fbbb7d301e8e99cfdb6e4771a0d (diff) | |
download | linux-1e0bff3bb59ca9bf84243df2a4ad3cfa6ca6f303.tar.xz |
Merge branch 'fix-felix-dsa-taprio-gates-after-clock-jump'
Vladimir Oltean says:
====================
Fix Felix DSA taprio gates after clock jump
Richie Pearn presented a reproducible situation where traffic would get
blocked on the NXP LS1028A switch if a certain taprio schedule was
applied, and stepping the PTP clock would take place. The latter event
is an expected initial occurrence, but also at runtime, for example when
transitioning from one grandmaster to another.
The issue is completely described in patch 1/4, which also contains
the fix, but it has left me with some doubts regarding the need for
vsc9959_tas_clock_adjust() in general.
In order to prove to myself that vsc9959_tas_clock_adjust() is needed in
general, I have written a selftest for the tc-taprio data path in patch
4/4. On the LS1028A, we can clearly see the following failures without
that function:
INFO: Forcing a backward clock jump
TEST: ping [FAIL]
INFO: Setting up taprio after PTP
TEST: In band with gate [FAIL]
Reception of 100 packets failed
TEST: Out of band with gate [FAIL]
Reception of 100 packets failed
As for testing my fix from patch 1/4, that was quite a bit more complex
to do automatically. In fact, I couldn't find any other schedule that
would fail to be updated by vsc9959_tas_clock_adjust() as cleanly as
the schedule from Richie, so I've added that specific schedule as the
test_clock_jump_backward() test.
The test ordering is also (unfortunately) very strategic. Running the
selftest to the end dirties the GCL RAM, and when running
test_clock_jump_backward() once again, the GCL entries won't be all
zeroes as they were the first time around. They will contain bits and
pieces of old schedules, making it very challenging to make it fail.
Thus, test_clock_jump_backward() is the first in the test suite, and
without patch 1/4, it is only supposed to fail the _first_ time when
running after a clean boot.
====================
Link: https://patch.msgid.link/20250426144859.3128352-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'drivers/platform/surface/aggregator/ssh_parser.c')
0 files changed, 0 insertions, 0 deletions