linux-kernel - Re: [PATCH v9 11/14] platform/x86: Split the alienware-wmi driver

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]

Message-ID: <a360d20e-4c14-18db-64d0-99149cd89d0e@linux.intel.com>
Date: Mon, 10 Feb 2025 16:07:31 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Kurt Borja <kuurtb@...il.com>
cc: platform-driver-x86@...r.kernel.org, Armin Wolf <W_Armin@....de>, 
    Mario Limonciello <mario.limonciello@....com>, 
    Hans de Goede <hdegoede@...hat.com>, Dell.Client.Kernel@...l.com, 
    LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 11/14] platform/x86: Split the alienware-wmi driver

On Mon, 10 Feb 2025, Kurt Borja wrote:

> On Mon Feb 10, 2025 at 6:53 AM -05, Ilpo Järvinen wrote:

> > It is one of the reasons why I prefer to have move patches do as little 
> > extra work as possible because I can use pipelines to verify the pre and 
> > post content is identical.
> >
> > I usually starting by diffing - and + lines in the diff which is how I 
> > came across this one too. In the best case there are no code line changes 
> > at all but all changes are in the boilerplate, it gives very high 
> > confidence on the move being done correctly. When a rebase conflicts, 
> > everyone (me included), might introduce unintended changes to move-only 
> > patches so I tend to check even my own move patches in similar fashion to 
> > avoid making stupid mistakes.
> 
> Speaking of this. Let's say I want to add a new model to the DMI list,
> how should I go about it? 
> 
> If I base it on the fixes branches it's going to conflict when merging
> with Linus, and even worse, it would need to be manually added to
> alienware-wmi-wmax.c every time it happens.
> 
> My solution is to just base the added models on the for-next branch. Of
> course users wouldn't get this until v6.15 but I'd prefer not to give
> you or some other maintainer extra work.
> 
> Another solution is to make two patches one for for-next and one for
> stable, but I don't know if people do this to begin with.
> 
> What do you think about this?

It is possible for me to merge the fixes branch containing the new model 
into for-next to avoid Linus having to deal with such conflicts. However, 
it only moves the stable conflicts problem by one kernel release because 
after 6.14 is released, all new additions will be based on the 6.15 code 
anyway so any patch going into stable will have to deal with the conflicts.

If you so prefer, it is fine for me if you want base them on for-next 
after such a major restructuring, I won't complain. But as you said, 
there's a small delay until stable will pick them up. They do actually 
start to pick the patches into stable right after 6.15-rc1 (and 
sometimes even during the merge window), not only after 6.15 release.

You do get a FAILED mail from the stable maintainers if a patch they 
wanted to apply doesn't apply without conflicts and then can send them
a backported version.

-- 
 i.