Re: [PATCH] thunderbolt: debugfs: Don't stop reading SB registers if just one fails

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 4/9/26 4:32 PM, Mika Westerberg wrote:
> On Thu, Apr 09, 2026 at 02:59:22PM +0200, Konrad Dybcio wrote:
>> On 4/9/26 2:04 PM, Mika Westerberg wrote:

[...]

>>> I assume you have tested this on a hardware that supports this too, right?
>>
>> Hardware that exposes that register this does not exercise the altered
>> code path.
> 
> Well it may happen now that previously we got -EIO from some other register
> and we stopped there, now this changes and we actually continue reading so
> this definitely should be tested.

The only register before USB4_SB_GEN4_TXFFE that isn't in-spec for
both retimers in v1.0 and v2.0 is USB4_SB_LRD_TUNING (0x07). The PS8830
interestingly reports all zeroes (not a bounce).

The registers following USB4_SB_GEN4_TXFFE in the array are
USB4_SB_VERSION and USB4_SB_DATA. The former is not accessed anywhere
else in the code, at first glance. The latter is, during NVM r/w and
in margining ops, which have definitely been in use for a long time.

Plus both of them are the v1.0 spec. The USB4_SB_GEN4_TXFFE specifically
isn't (the retimer supplement pdf lists it as Rsvd, the main spec pdf
omits it in the SB register table), as it wasn't previously useful (since
Gen4 came about in v2.0).


I don't think there's an easy way to limit the reading of this register
since the bit indicating Gen4 capability is in USB4_SB_LINK_CONF (0x0c),
which is Rsvd on retimers regardless of the spec revision. A connected
port could easily have higher/lower capabilities, too.


So all in all, my understanding is that any bugs caused by this patch
(which would have to be in the form of "reading a register causes a
wrongful change in behavior") would really surface spec non-compliance
from a retimer, which should be quirked out explicitly if that's the
case.


I only have hardware with various Parade retimers, none of which claim
Gen4 support.

Konrad