Re: [PATCH net-next 1/4] net: macb: Rename MACB_CAPS_QBV to MACB_CAPS_TC

[Théo Lebrun]

On Mon Aug 10, 2026 at 12:11 PM CEST, Karumanchi, Vineeth wrote:
> On 8/7/2026 11:56 PM, Théo Lebrun wrote:
>> On Fri Aug 7, 2026 at 7:09 PM CEST, Conor Dooley wrote:
>>> On Fri, Aug 07, 2026 at 03:20:09PM +0530, Vineeth Karumanchi wrote:
>>>> The MACB_CAPS_QBV capability flag was originally introduced to
>>>> gate TAPRIO/QBV support. However, GEM IP versions that support
>>>> QBV also implement multiple TSN clauses.
>>>>
>>>> Replace this with a generic capability flag that can be reused
>>>> by other TSN features. Rename MACB_CAPS_QBV to MACB_CAPS_TC to
>>>> better reflect its role as a general traffic-class offload capability.
>>>
>>> I'm not convinced that this is broadly correct, whether or not there's
>>> Qav support (which is what you're using the newly renamed flag for)
>>> depends on an IP configuration time define that I think is independent
>>> of whether or not there's Qbv support (gem_exclude_cbs).
>>>
>>> That said, the only platform that supports Qbv that I have the exact
>>> documentation for does not disable the CBS bits.
>> 
>> EyeQ5 instances have both active qbv and cbs as well.>
>> I see two ways forward:
>>  - MACB_CAPS_TC aggregating the two, coming from match data
>>  - split and use runtime-detection, see DCFG1/0x0280 bits 1 and 24
>
> This was the initial plan for the QBV implementation.
>
> Quoting from
> https://lore.kernel.org/netdev/20250814071058.3062453-3-vineeth.karumanchi@xxxxxxx/
>
> "The 'exclude_qbv' bit in the designcfg_debug1 register varies across
> MACB/GEM IP revisions, making direct probing unreliable for detecting
> QBV support. This patch introduces a capability-based approach for
> consistent QBV feature identification across the IP family."

This is surprising to me! What's the source? Do you have AMD hardware
where DCFG1-6 have diverging layouts?

Thanks,

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