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

[Karumanchi, Vineeth]

Hi,

On 8/31/2026 12:27 PM, Karumanchi, Vineeth wrote:
> Hi Théo Lebrun,
> 
> On 8/28/2026 2:51 PM, Théo Lebrun wrote:
>> 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?
> 
> Yes. The source is the AMD register documentation for Zynq and ZynqMP
> devices. Some DCFG register layouts on these devices differ from those
> on newer devices.
> 

https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/designcfg_debug1-GEM-Register

This information was taken from the original Cadence IP documentation
for that version.

Thanks,
> For example:
> 
> GEM IP revision: r1p6f4  (revision_reg: 0x40070106)
> For this GEM revision, bit 1 of designcfg_debug1 is defined as
> "serdes", while bit 24 is reserved and reads as zero.
> 
>>
>> Thanks,
>>
>> --
>> Théo Lebrun, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>>
> 
> Thanks

-- 
🙏 Vineeth