From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCH net] mscc: Register poll timeout should be wall time not
 attempts
Date: Thu, 20 Dec 2018 12:31:11 +0100
Message-ID: <20181220113111.GE13180@lunn.ch>
References: <20181220090816.12764-1-steen.hegelund@microchip.com>
 <20181220103150.GD13180@lunn.ch>
 <20181220111149.ht4nt7jtgilysnk7@soft-dev13.dk.vitesse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: netdev@vger.kernel.org
Return-path: <netdev-owner@vger.kernel.org>
Received: from vps0.lunn.ch ([185.16.172.187]:54153 "EHLO vps0.lunn.ch"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1728425AbeLTLbO (ORCPT <rfc822;netdev@vger.kernel.org>);
        Thu, 20 Dec 2018 06:31:14 -0500
Received: from andrew by vps0.lunn.ch with local (Exim 4.84_2)
        (envelope-from <andrew@lunn.ch>)
        id 1gZwXo-0004TW-02
        for netdev@vger.kernel.org; Thu, 20 Dec 2018 12:31:12 +0100
Content-Disposition: inline
In-Reply-To: <20181220111149.ht4nt7jtgilysnk7@soft-dev13.dk.vitesse.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Thu, Dec 20, 2018 at 12:11:50PM +0100, Steen Hegelund wrote:
> The 12/20/2018 11:31, Andrew Lunn wrote:
> > On Thu, Dec 20, 2018 at 10:08:16AM +0100, Steen Hegelund wrote:
> > > When doing indirect access in the Ocelot chip, a command is setup,
> > > issued and then we need to poll until the result is ready. The polling
> > > timeout is specified in milliseconds in the datasheet and not in
> > > register access attempts.
> > > 
> > > Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
> > 
> > Hi Steen
> > 
> > Have you seen real issues with this code? You have marked this for
> > net, indicating it is a bug fix. If it is a real fix, please provide a
> > fixes: tag.
> > 
> > Thanks
> > 	Andrew
> 
> Hi Andrew,
> 
> It is not a bug on the currently supported platform, but we observed
> that the code does not work properly on other platforms that we want to
> support as the timing requirements there are different.  So maybe this
> is rather an improvement than a fix...
> 
> Should this rather go to net-next?

The requirements for stable are listed here:

https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

net-next seems a better fit.

	 Andrew