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, 30 May 2023 14:54:16 +0200
From:   Andrew Lunn <andrew@lunn.ch>
To:     Jakub Kicinski <kuba@kernel.org>
Cc:     Christian Marangi <ansuelsmth@gmail.com>,
        Pavel Machek <pavel@ucw.cz>, Lee Jones <lee@kernel.org>,
        Jonathan Corbet <corbet@lwn.net>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>, linux-leds@vger.kernel.org,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org
Subject: Re: [net-next PATCH v4 00/13] leds: introduce new LED hw control APIs
Message-ID: <7e5d1ed6-3fd7-4110-8171-9efd19b59023@lunn.ch>
References: <20230529163243.9555-1-ansuelsmth@gmail.com>
 <20230529221722.549dfbd8@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230529221722.549dfbd8@kernel.org>
Precedence: bulk

On Mon, May 29, 2023 at 10:17:22PM -0700, Jakub Kicinski wrote:
> On Mon, 29 May 2023 18:32:30 +0200 Christian Marangi wrote:
> > Since this series is cross subsystem between LED and netdev,
> > a stable branch was created to facilitate merging process.
> > 
> > This is based on top of branch ib-leds-netdev-v6.5 present here [1]
> > and rebased on top of net-next since the LED stable branch got merged.
> > 
> > This is a continue of [2]. It was decided to take a more gradual
> > approach to implement LEDs support for switch and phy starting with
> > basic support and then implementing the hw control part when we have all
> > the prereq done.
> > 
> > This is the main part of the series, the one that actually implement the
> > hw control API.
> 
> Just to be 100% sure - these go into netdev/net-next directly, right?
> No stable branch needed?

From Christian and my side, yes. Ideally with Acked-by from Lee. We
have more patches to come, and we will just stack them on top in
net-next. The majority of those patches are for network drivers, not
the LED subsystem.

If there are going to be any merge conflicts, they will be to the core
LED header files. And such conflicts should be simple to resolve in
linux-next. If anybody else starts hacking on ledtrig-netdev.c then we
have problems, especially if it is an LED wide change. I don't know
how easy it is to create a stable branch from net-next, which could be
pulled into led-next, without it actually pulling in a huge number of
networking patches?

Lee?

	Andrew