Re: [PATCH net-next 2/2] net: macb: configure ENST registers for all queues

["Théo Lebrun" <theo.lebrun@bootlin.com>]

On Mon Jul 27, 2026 at 2:05 PM CEST, Théo Lebrun wrote:
> On Mon Jul 27, 2026 at 7:32 AM CEST, Karumanchi, Vineeth wrote:
>> On 7/24/2026 11:36 PM, Théo Lebrun wrote:
>>> On Fri Jul 24, 2026 at 6:32 AM CEST, Vineeth Karumanchi wrote:
>>>> The initial "tc" command was not overwriting the reset value of ENST
>>>> registers if only a subset of queues were configured, leading to an
>>>> invalid setup. To fix this, configure all queues unconditionally.
>>>> Unconfigured queues are zero-initialized via kcalloc(), ensuring a
>>>> complete and consistent configuration.
>>> But if a subset of queues are configured, the remaining queues don't
>>> have their ENST support enabled thanks to ENST_CONTROL and their ENST
>>> per-queue register values aren't read? Or HW is broken and reads ENST
>>> registers anyway? Or something else I misunderstood?
>>>
>>> What reset value of ENST regs you observed that caused you trouble?
>>> That info could make it into the commit message.
>> //
>> Yes, this is a confirmed hardware issue. We raised it with Cadence, and 
>> they have
>> acknowledged the problem. The reset value of the |enst_on_time_qX| 
>> registers is *0x0001FFFF*.
>
> ACK. 0x1FFFF translates to the max value of on_time. Important also to
> note that off_time reset value is 0x0 according to the manual. This
> combination probably explains why queues feel free to emit whenever
> they want.
>
>> During ENST initialization, packet interleaving was observed when only a
>> subset of the available queues was configured, while the remaining 
>> queues—whose
>> corresponding |enst_on_time_qX| registers still contained non-zero 
>> values—were left disabled in |ENST_CONTROL|.
>>
>> For example, in a configuration where only two of the four queues are 
>> enabled,
>> some packets from *Q0* getting transmitted during the *Q1* time slot, 
>> and vice versa.
>
> This description isn't enough to fully show there is a bug.
>  - You say "only two of the four queues are enabled" but did you mean
>    "queue enabled" or "EnST is enabled on that queue"?
>  - EnST enabled doesn't mean the timeslots don't overlap, this is one
>    allowed config.
>
> Maybe it's not a bug? What behavior would you expect when EnST is
> enabled on some queues only? When should queues without EnST active
> transmit their frames?
>
> Please be exhaustive in your future commit message; thanks!
>
>> Furthermore, once the hardware enters this state, it does not recover 
>> even after a
>> complete ENST queue reconfiguration is performed.
>
> ---
>
> As you contribute to EnST support, you might be interested in a bug I
> just noticed in the enst_ns_to_hw_units() implementation. It doesn't do
> rounding properly.
>
> Eg ns=100 speed_mbps=100 => 2 units of time but that is 2*80ns=160ns,
> whereas one unit of time (80ns) would have been a better choice. This
> example is the worst case scenario (the closer we are to 1 unit of
> time, the worst the bug is).

Let me backpaddle on this. Maybe it makes sense that we always configure
strictly longer timeslot durations to what was asked by userspace. But
I'm not convinced. We round up both on_time and off_time for all
queues, meaning it's hard for userspace to configure mutually exclusive
timeslots. We have no equivalent to clk_ops::determine_rate() for
userspace to query what values we support.

An LLM reported to me 5 out of 7 drivers write nanoseconds values
directly. macb and am65-cpsw are the two exceptions and we use the same
formula: DIV_ROUND_UP(ns*speed, 8000).

> ---
>
> PS: please note your email formatting is off because of hard wrapping.
> It's well visible on lore. Email is still readable but less than optimal.
>
> https://lore.kernel.org/netdev/3924babc-9755-46ce-97b2-bd6dfce6f6c6@amd.com/
>
> Thanks,
>
> --
> Théo Lebrun, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com