Re: [PATCH net v4 3/7] net: stmmac: Rework S-VLAN handling

[Joseph Steel]

On Tue, Sep 15, 2026 at 09:27:51AM +0000, Ovidiu Panait wrote:
> Hi Joseph,
> 
> > 
> > Hi
> > 
> > On Tue, Sep 08, 2026 at 04:43:05PM +0000, Ovidiu Panait wrote:
> > > The ESVL and DOVLTC bits control S-VLAN tag processing and have
> > > nothing to do with the double VLAN feature, which only provides a way
> > > to process an additional inner VLAN tag. However, the driver code
> > > that handles them always refers to "double VLAN", which is unrelated
> > > and makes the implementation confusing. The driver does not use any
> > > of the inner VLAN tag features, and the networking core does not
> > > support offloads for the inner tag anyway.
> > >
> > > To simplify the logic and to reduce the confusion regarding S-Tag vs
> > > double VLAN handling, drop the is_double logic and add a hw_svlan_en
> > > flag that is set when S-Tag hardware handling is enabled.
> > 
> > I believe I suggested to just change the "double" word to "svlan", and
> > not to drop the respective logic completely. The number of S-VLAN tags
> > added/removed must be still counted, otherwise any subsequent VLAN
> > S-Tag removal will disable S-VLAN processing even if there are S-Tags
> > left added.
> > 
> 
> While working on this I realized we don't actually need to toggle the
> S-VLAN bits on/off whenever a S-VLAN tag is added/removed. We can just
> keep them always set as long as the NETIF_F_HW_VLAN_STAG_RX or
> NETIF_F_HW_VLAN_STAG_FILTER features are advertised.
> 
> This simplified the S-VLAN logic quite a bit, by getting rid of the counting.

and reduces the system security by permitting the packets that
otherwise would be filtered out by the controller if there is no any
S-VLAN tags added. So no. The counting logic here is quite
appropriate(-ish).

-Joseph

> 
> Ovidiu
> 
> > -Joseph
> > 
> > >
>