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

On Mon, Oct 5, 2026 at 5:10 PM Linus Walleij [off-list ref] wrote:

quoted

On Fri, Oct 2, 2026 at 1:58 PM Oleksij Rempel [off-list ref] wrote:

quoted

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@pengutronix.de>

RTL8366RB has 8 queues so it's fine to keep this separate
per-subdriver.
Reviewed-by: Linus Walleij <linusw@kernel.org>

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