summaryrefslogtreecommitdiff
path: root/drivers/platform/surface/aggregator/ssh_parser.c
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2025-04-30 00:44:39 +0300
committerJakub Kicinski <kuba@kernel.org>2025-04-30 00:44:40 +0300
commit1e0bff3bb59ca9bf84243df2a4ad3cfa6ca6f303 (patch)
treeea760162e09865b0285fb57fb2fd93a9d4e5738e /drivers/platform/surface/aggregator/ssh_parser.c
parent6e0490fc36cdac696f96e57b61d93b9ae32e0f4c (diff)
parent4eb9da050f005fbbb7d301e8e99cfdb6e4771a0d (diff)
downloadlinux-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