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




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ