Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20211104124927.364683-1-robert.marko@sartura.hr>
 <20211108202058.th7vjq4sjca3encz@skbuf> <CA+HBbNE_jh_h9bx9GLfMRFz_Kq=Vx1pu0dE1aK0guMoEkX1S5A@mail.gmail.com>
 <20211108211811.qukts37eufgfj4sc@skbuf> <CA+HBbNGvg43wMNbte827wmK_fnWuweKSgA-nWW+UPGCvunUwGA@mail.gmail.com>
 <20211108214613.5fdhm4zg43xn5edm@skbuf> <CA+HBbNEKOW3F6Yu=OV3BDea+KKNH6AEUMS07az6=62aEAKHGgw@mail.gmail.com>
 <20211108215926.hnrmqdyxbkt7lbhl@skbuf> <CA+HBbNH=31j1Nv8T67DKhLXaQub2Oz11Dw2RuMEWQ3iXrF2fxg@mail.gmail.com>
 <20211108233816.tnov6gufaagdrhlv@skbuf>
In-Reply-To: <20211108233816.tnov6gufaagdrhlv@skbuf>
From:   Robert Marko <robert.marko@sartura.hr>
Date:   Tue, 9 Nov 2021 00:52:21 +0100
Message-ID: <CA+HBbNGHrQi_SbY=Ta395_J22Ab1s3wG_RtRvbjwa1LOw8Kfmw@mail.gmail.com>
Subject: Re: [net-next] net: dsa: qca8k: only change the MIB_EN bit in
 MODULE_EN register
To:     Vladimir Oltean <olteanv@gmail.com>
Cc:     Andrew Lunn <andrew@lunn.ch>, vivien.didelot@gmail.com,
        Florian Fainelli <f.fainelli@gmail.com>,
        David Miller <davem@davemloft.net>, kuba@kernel.org,
        netdev@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Gabor Juhos <j4g8y7@gmail.com>, John Crispin <john@phrozen.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Nov 9, 2021 at 12:38 AM Vladimir Oltean <olteanv@gmail.com> 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@sartura.hr
Web: www.sartura.hr