Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 25 Jul 2023 11:56:41 +0100
From:   "Russell King (Oracle)" <linux@armlinux.org.uk>
To:     Paolo Abeni <pabeni@redhat.com>
Cc:     Ante Knezic <ante.knezic@helmholz.de>, andrew@lunn.ch,
        davem@davemloft.net, edumazet@google.com, f.fainelli@gmail.com,
        kuba@kernel.org, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, olteanv@gmail.com
Subject: Re: [PATCH net-next v3] net: dsa: mv88e6xxx: Add erratum 3.14 for
 88E6390X and 88E6190X
Message-ID: <ZL+qafwCqeDytFRt@shell.armlinux.org.uk>
References: <30e262679bfdfd975c2880b990fe8375b9860aab.camel@redhat.com>
 <20230725095925.25121-1-ante.knezic@helmholz.de>
 <e1cdc94be0e515a5de9d4af8fccfd99e25435b73.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e1cdc94be0e515a5de9d4af8fccfd99e25435b73.camel@redhat.com>
Sender: Russell King (Oracle) <linux@armlinux.org.uk>
Precedence: bulk

On Tue, Jul 25, 2023 at 12:47:43PM +0200, Paolo Abeni wrote:
> [adding Russell]
> On Tue, 2023-07-25 at 11:59 +0200, Ante Knezic wrote:
> > On Tue, 25 Jul 2023 10:56:25 +0200 Paolo Abeni wrote
> > > It looks like you are ignoring the errors reported by
> > > mv88e6390_erratum_3_14(). Should the above be:
> > > 
> > > 		return mv88e6390_erratum_3_14(mpcs);
> > > 
> > > instead?
> > > 
> > 
> > I guess you are right. Would it make sense to do the evaluation for the 
> > 	mv88e639x_sgmii_pcs_control_pwr(mpcs, true);
> > above as well?
> 
> Good question ;) it looks like pcs_post_config() errors are always
> ignored by the core, but I guess it's better to report them as
> accurately as possible.

... because if they occur, it's way too late to attempt to unwind the
changes that have already occurred.

> @Russell, what it your preference here, should we just ignore the
> generate errors earlier, or try to propagate them to the core/phylink,
> should that later be changed to deal with them?

How would we deal with an error?

If it's a "we can't support this configuration" then that's a driver
problem, and means that the validation failed to exclude the
unsupported configuration.

If it's a communication error of some sort, then we're unlikely to
be able to back out the configuration change, because we probably
can't communicate with some device anymore - and there are paths
in phylink where these methods are called where there is no
possibility of propagating an error (due to being called in a
workqueue.)

I did decide that phylink_major_config() ought not proceed if
mac_prepare() fails, but really once mac_prepare() has been called
we're committed - and if an error happens after that, the network
interface is dead.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!