Re: [PATCH net-next v1 5/8] net: dsa: realtek: rtl8365mb: store the egress queue count per chip

[Luiz Angelo Daros de Luca]

> > On Mon, Oct 5, 2026 at 5:10 PM Linus Walleij <linusw@xxxxxxxxxx> wrote:
> > > On Fri, Oct 2, 2026 at 1:58 PM Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote:
> > >
> > > > Store the number of egress queues in the per-chip info structure and
> > > > advertise it through ds->num_tx_queues, following the ksz driver
> > > > (struct ksz_chip_data.num_tx_queues).
> > > >
> > > > The queue count is a per-chip hardware property, and this driver supports
> > > > several chips of the rtl8367c family. All currently-supported chips expose
> > > > eight queues, but keeping the count in chip_info lets the QoS code that
> > > > follows program the priority-to-queue map via the ieee8021q helpers for
> > > > whatever queue count a chip carries, so the 802.1Q collapse is correct
> > > > rather than hard-coded to eight.
> > > >
> > > > Signed-off-by: Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx>
> > >
> > > RTL8366RB has 8 queues so it's fine to keep this separate
> > > per-subdriver.
> > > Reviewed-by: Linus Walleij <linusw@xxxxxxxxxx>
> >
> > I meant RTL8366RB has 6 queues. Hm maybe you rather want to
> > store this in struct realtek_variant and have the core
> > helper instead?
>
> Hi Linus,
>
> Right now, the common realtek core doesn't handle any queue or QoS
> logic yet. In rtl8365mb, this property is primarily used internally by
> the driver. Moving it to struct realtek_variant felt premature since
> rtl8366rb doesn't implement this functionality yet. Unless we want to
> refactor both drivers to share QoS helpers right now, keeping it
> private to rtl8365mb's chip_info seems cleaner for this series. We can
> always promote it to the variant when rtl8366rb gains similar support.
>
> What do you think?

Never mind. I only saw your review on the next patch asking for shared
helpers after sending this. In that context, your point definitely
stands.

Best regards,

Luiz