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] [day] [month] [year] [list]

Message-Id: <D7P6GNOLB1QL.2IHCSTG7671L3@gmail.com>
Date: Mon, 10 Feb 2025 19:08:09 -0500
From: "Kurt Borja" <kuurtb@...il.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.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 Feb 10, 2025 at 9:07 AM -05, Ilpo Järvinen wrote:
> 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 

A small delay of a couple of months :p

> 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.

I will do it like this then, I'd prefer no conflicts.

Thanks!

-- 
 ~ Kurt

>
> 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.