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

[Karumanchi, Vineeth]

Hi Conor & Théo Lebrun,

On 8/7/2026 11:56 PM, Théo Lebrun wrote:
> Hello Vineeth & Conor,
> 
> 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."


We currently have access to four GEM IP versions. Across these versions,
TSN support is either fully available (including features such as Qav
and Qbv) or not supported at all. Based on this observation, we adopted
this approach for capability detection.

Please let me know your thoughts

> 
> What I like with 1 is that when reading code it's easy to see what
> platform can use what features.
> 
> What I like with 2 is that it's less churn overall: no modification of
> match data once support is merged.
> 
> I guess let's go with 2?
> 
> (I'll review the rest of the series later on.)
> 
> Thanks,
> 
> --
> Théo Lebrun, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 

Thanks,
-- 
🙏 Vineeth