linux-kernel - Re: linux-next: duplicate patches in the drivers-x86 tree

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: <7a292539-e3d7-958c-a806-54681a0c79ca@redhat.com>
Date:   Fri, 3 Feb 2023 10:14:54 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Mark Gross <markgross@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: duplicate patches in the drivers-x86 tree

Hi,

On 2/2/23 22:34, Stephen Rothwell wrote:
> Hi all,
> 
> The following commits are also in Linus Torvalds' tree as different
> commits (but the same patches):
> 
>   037d07aeef02 ("platform/x86/amd/pmf: Fix to update SPS default pprof thermals")
>   5cca42fb5578 ("platform/x86/amd/pmf: Fix to update SPS thermals when power supply change")
>   66dc77b5c2a7 ("platform/x86/amd: pmc: add CONFIG_SERIO dependency")
>   8b6ad2361561 ("platform/x86: thinkpad_acpi: Fix thinklight LED brightness returning 255")
>   9f093aff1dda ("platform/x86: touchscreen_dmi: Add Chuwi Vi8 (CWI501) DMI match")
>   a63149e5d662 ("platform/x86/amd/pmf: update to auto-mode limits only after AMT event")
>   b3c37edce7dc ("platform/x86/amd/pmf: Add helper routine to update SPS thermals")
>   c02576762825 ("platform/x86/amd/pmf: Add helper routine to check pprof is balanced")
>   f1db3f08b51d ("platform/x86/amd/pmf: Ensure mutexes are initialized before use")

Hmm, this appears to be a new warning.

This is the result of my workflow for bug-fix patches, I first
merge all patches into the for-next branch and then I cherry-pick
fixes into the fixes branch and send out a pull-req from the fixes
branch for the current cycle.

AFAIK this is a pretty standard workflow ?

Bit I agree that ideally the duplicate commit ids from this workflow
should be avoided, so I'll try to change my workflow to putting fixes
directly on the fixes branch and then merging the fixes branch into
for-next and see how that goes.

I've also fixed the set of above duplicates by rebasing my current
for-next on top of fixes since I needed to do a forced push because
of the missing S-o-b-s anyways.

Regards,

Hans