lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 May 2023 14:54:16 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Christian Marangi <ansuelsmth@...il.com>, Pavel Machek <pavel@....cz>,
	Lee Jones <lee@...nel.org>, Jonathan Corbet <corbet@....net>,
	Florian Fainelli <f.fainelli@...il.com>,
	Vladimir Oltean <olteanv@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	linux-leds@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [net-next PATCH v4 00/13] leds: introduce new LED hw control APIs

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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ