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:   Thu, 19 Jan 2023 18:27:52 +0100
From:   Andrew Lunn <andrew@lunn.ch>
To:     Rakesh.Sankaranarayanan@microchip.com
Cc:     olteanv@gmail.com, davem@davemloft.net, pabeni@redhat.com,
        hkallweit1@gmail.com, Arun.Ramadoss@microchip.com,
        Woojung.Huh@microchip.com, linux-kernel@vger.kernel.org,
        linux@armlinux.org.uk, f.fainelli@gmail.com, kuba@kernel.org,
        edumazet@google.com, UNGLinuxDriver@microchip.com,
        netdev@vger.kernel.org
Subject: Re: [PATCH net 2/2] net: dsa: microchip: lan937x: run phy
 initialization during each link update
Message-ID: <Y8l9mMpiFSHTt1iU@lunn.ch>
References: <20230116100500.614444-1-rakesh.sankaranarayanan@microchip.com>
 <20230116100500.614444-1-rakesh.sankaranarayanan@microchip.com>
 <20230116100500.614444-3-rakesh.sankaranarayanan@microchip.com>
 <20230116100500.614444-3-rakesh.sankaranarayanan@microchip.com>
 <20230116222602.oswnt4ecoucpb2km@skbuf>
 <7d72bc330d0ce9e57cc862bec39388b7def8782a.camel@microchip.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7d72bc330d0ce9e57cc862bec39388b7def8782a.camel@microchip.com>
Precedence: bulk

On Thu, Jan 19, 2023 at 11:34:00AM +0000, Rakesh.Sankaranarayanan@microchip.com wrote:
> Hi Vladimir,
> Thanks for the comments.
> 
> > 1. Don't prefix a patch with "net: dsa: microchip: " unless it
> > touches
> > ?? the drivers/net/dsa/microchip/ folder.
> > 
> > 2. Don't make unrelated patches on different drivers part of the same
> > ?? patch set.
> > 
> I will update the patch in next revision.
> 
> > 3. AFAIU, this is the second fixup of a feature which never worked
> > well
> > ?? (changing master/slave setting through ethtool). Not sure exactly
> > ?? what are the rules, but at some point, maintainers might say
> > ?? "hey, let go, this never worked, just send your fixes to net-
> > next".
> > ?? I mean: (1) fixes of fixes of smth that never worked can't be sent
> > ad
> > ?? infinitum, especially if not small and (2) there needs to be some
> > ?? incentive to submit code that actually works and was tested,
> > rather
> > ?? than a placeholder which can be fixed up later, right? In this
> > case,
> > ?? I'm not sure, this seems borderline net-next. Let's see what the
> > PHY
> > ?? library maintainers think.
> > 
> 
> Thanks for pointing this out. Do you think submitting this patch in
> net-next is the right way?

I would probably go for net-next. That will give it more soak time to
find the next way it is broken....

You might find i gets back ported to stable anyway, due to the ML bot
spotting it.

	 Andrew