From: "Karumanchi, Vineeth" <vineeth@amd.com>
To: "Théo Lebrun" <theo.lebrun@bootlin.com>,
"Conor Dooley" <conor@kernel.org>,
"Vineeth Karumanchi" <vineeth.karumanchi@amd.com>
Cc: conor.dooley@microchip.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, git@amd.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 1/4] net: macb: Rename MACB_CAPS_QBV to MACB_CAPS_TC
Date: Mon, 31 Aug 2026 12:27:15 +0530 [thread overview]
Message-ID: <19708df1-7f79-48c0-b026-3c69eb8c2034@amd.com> (raw)
In-Reply-To: <DL0GSSXQPVDE.2O8IIQA60348U@bootlin.com>
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@amd.com/
>>
>> "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.
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
next prev parent reply other threads:[~2026-08-31 6:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 9:50 [PATCH net-next 0/4] net: macb: Add TSN MQPRIO and CBS traffic-class offload Vineeth Karumanchi
2026-08-07 9:50 ` [PATCH net-next 1/4] net: macb: Rename MACB_CAPS_QBV to MACB_CAPS_TC Vineeth Karumanchi
2026-08-07 17:09 ` Conor Dooley
2026-08-07 18:26 ` Théo Lebrun
2026-08-10 10:11 ` Karumanchi, Vineeth
2026-08-28 9:21 ` Théo Lebrun
2026-08-31 6:57 ` Karumanchi, Vineeth [this message]
2026-09-01 9:49 ` Karumanchi, Vineeth
2026-08-07 9:50 ` [PATCH net-next 2/4] net: macb: Move TC capability and PM checks to macb_setup_tc() Vineeth Karumanchi
2026-08-28 9:25 ` Théo Lebrun
2026-08-07 9:50 ` [PATCH net-next 3/4] net: macb: Add MQPRIO qdisc hardware offload support Vineeth Karumanchi
2026-08-07 9:50 ` [PATCH net-next 4/4] net: macb: Add TSN CBS TC " Vineeth Karumanchi
2026-08-07 17:32 ` Conor Dooley
2026-08-10 10:33 ` Karumanchi, Vineeth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19708df1-7f79-48c0-b026-3c69eb8c2034@amd.com \
--to=vineeth@amd.com \
--cc=andrew+netdev@lunn.ch \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=git@amd.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=theo.lebrun@bootlin.com \
--cc=vineeth.karumanchi@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox