| Message ID | cover.1610540603.git.gilles.doffe@savoirfairelinux.com |
|---|---|
| Headers | show |
| Series | Fixes on Microchip KSZ8795 DSA switch driver | expand |
On 1/13/21 4:45 AM, Gilles DOFFE wrote: > A logical 'or' was performed until now. > So if vlan 1 is the current pvid and vlan 20 is set as the new one, > vlan 21 is the new pvid. > This commit fixes this by setting the right mask to set the new pvid. > > Signed-off-by: Gilles DOFFE <gilles.doffe@savoirfairelinux.com> Looks about right, can you provide a Fixes: tag for this change?
On Wed, Jan 13, 2021 at 01:45:22PM +0100, Gilles DOFFE wrote: > '(u64)*value' casts a u32 to a u64. So depending on endianness, > LSB or MSB is lost. > The pointer needs to be cast to read the full u64: > '*((u64 *)value)' > > Signed-off-by: Gilles DOFFE <gilles.doffe@savoirfairelinux.com> > --- Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
On 1/13/21 4:45 AM, Gilles DOFFE wrote: > If a VLAN is removed, the tagging policy should not be changed as > still active VLANs could be impacted. > > Signed-off-by: Gilles DOFFE <gilles.doffe@savoirfairelinux.com> It sounds like you need to consolidate the patches dealing with tagging/untagged of a VLAN/port into a single patch, that may be clearer and easier to review rather than doing this piecemeal.
On Wed, Jan 13, 2021 at 01:45:21PM +0100, Gilles DOFFE wrote: > A logical 'or' was performed until now. > So if vlan 1 is the current pvid and vlan 20 is set as the new one, > vlan 21 is the new pvid. > This commit fixes this by setting the right mask to set the new pvid. > > Signed-off-by: Gilles DOFFE <gilles.doffe@savoirfairelinux.com> > --- Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
On Wed, Jan 13, 2021 at 01:45:20PM +0100, Gilles DOFFE wrote: > If a VLAN is removed, the tagging policy should not be changed as > still active VLANs could be impacted. > > Signed-off-by: Gilles DOFFE <gilles.doffe@savoirfairelinux.com> > --- > drivers/net/dsa/microchip/ksz8795.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/net/dsa/microchip/ksz8795.c b/drivers/net/dsa/microchip/ksz8795.c > index 193f03ef9160..b55fb2761993 100644 > --- a/drivers/net/dsa/microchip/ksz8795.c > +++ b/drivers/net/dsa/microchip/ksz8795.c > @@ -880,7 +880,6 @@ static void ksz8795_port_vlan_add(struct dsa_switch *ds, int port, > static int ksz8795_port_vlan_del(struct dsa_switch *ds, int port, > const struct switchdev_obj_port_vlan *vlan) > { > - bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED; > struct ksz_device *dev = ds->priv; > u16 data, vid, pvid, new_pvid = 0; > u8 fid, member, valid; > @@ -888,8 +887,6 @@ static int ksz8795_port_vlan_del(struct dsa_switch *ds, int port, > ksz_pread16(dev, port, REG_PORT_CTRL_VID, &pvid); > pvid = pvid & 0xFFF; > > - ksz_port_cfg(dev, port, P_TAG_CTRL, PORT_REMOVE_TAG, untagged); > - > for (vid = vlan->vid_begin; vid <= vlan->vid_end; vid++) { > ksz8795_r_vlan_table(dev, vid, &data); > ksz8795_from_vlan(data, &fid, &member, &valid); > -- > 2.25.1 > What do you mean the tagging policy "should not be changed". Nothing is changed, the write to PORT_REMOVE_TAG is identical to the one done on .port_vlan_add. If anything, the egress untagging policy is reinforced on delete, not changed... What's the actual problem (beside for the fact that the driver is obviously a lot more broken than you can fix through patches to "net")?
On Wed, Jan 13, 2021 at 01:45:16PM +0100, Gilles DOFFE wrote: > > This patchset fixes various issues. > It mainly concerns VLANs support by fixing FID table management to > allow adding more than one VLAN. > It also fixes tag/untag behavior on ingress/egress packets. As far as I understand the series, it "fixes" something that was not broken (but which nonetheless could take some improvement), and does not fix something that was broken, because it was too broken. Good thing you brought up the bugs now, because FYI a tsunami is coming soon and it will cause major conflicts once Jakub merges net back into net-next. Had you waited a little bit longer, and the bug fixes sent to "net" would have not been backported too far down the line due to the API rework. https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=b7a9e0da2d1c954b7c38217a29e002528b90d174 You should try to find a reasonable balance between bugs due to an oversight, and "bugs" due to code which was put there as a joke more than anything else. Then you should send the fixes for the former to net and for the latter to net-next. Good luck.