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?

Best regards,

Luiz