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

Théo Lebrun <[email protected]>
Newsgroups gmane.linux.network,gmane.linux.kernel
Message-ID <[email protected]>
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

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,
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.