Re: [net-next] net: dsa: qca8k: only change the MIB_EN bit in MODULE_EN register

[Robert Marko]

On Tue, Nov 9, 2021 at 12:38 AM Vladimir Oltean <olteanv@xxxxxxxxx> wrote:
>
> On Mon, Nov 08, 2021 at 11:13:30PM +0100, Robert Marko wrote:
> > > The driver keeps state. If the switch just resets by itself, what do you
> > > think will continue to work fine afterwards? The code path needs testing.
> > > I am not convinced that a desynchronized software state is any better
> > > than a lockup.
> >
> > It's really unpredictable, as QCA doesn't specify what does the software reset
> > actually does, as I doubt that they are completely resetting the
> > switch to HW defaults.
> > But since I was not able to trigger the QM error and the resulting
> > reset, it's hard to tell.
> > Phylink would probably see the ports going down and trigger the MAC
> > configuration again,
> > this should at least allow using the ports and forwarding to CPU again.
> > However, it may also reset the forwarding config to basically flooding
> > all ports which is the default
> > which is not great.
> >
> > But I do agree that it may not be a lot better than a lockup.
>
> I'm not sure what you expect going forward. You haven't proven an issue
> with the actual code structure, or an improvement brought by your change.
> Allowing the hardware to autonomously reconfigure itself, even if
> partially, is out of the question (of course, that's if and only if I
> understand correctly the info that you've presented).

After this discussion, I think that John clears the bits intentionally,
I still don't think its really the best practice to do so in the MIB enablement
without documenting it.
However, since this doesn't seem to be hurting anyone I will drop it and rather
focus on IPQ4019 support which is slowly shaping into something upstreamable.

Regards,
Robert

-- 
Robert Marko
Staff Embedded Linux Engineer
Sartura Ltd.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko@xxxxxxxxxx
Web: www.sartura.hr