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
| ||
|
Message-ID: <7e5d1ed6-3fd7-4110-8171-9efd19b59023@lunn.ch> 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