linux-kernel - Re: [PATCH] riscv: defconfig: run savedefconfig to reorder it

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: <CAH1PCMYR2L8TeuveA-XTorQE70wmJVA1Vbt3Qhz0864Vr206PQ@mail.gmail.com>
Date: Thu, 19 Jun 2025 11:32:54 +0800
From: Guodong Xu <guodong@...cstar.com>
To: Palmer Dabbelt <palmer@...belt.com>
Cc: Alexandre Ghiti <alex@...ti.fr>, dlan@...too.org, Conor Dooley <conor@...nel.org>, 
	Paul Walmsley <paul.walmsley@...ive.com>, aou@...s.berkeley.edu, 
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	spacemit@...ts.linux.dev
Subject: Re: [PATCH] riscv: defconfig: run savedefconfig to reorder it

On Fri, Jun 13, 2025 at 2:57 AM Palmer Dabbelt <palmer@...belt.com> wrote:
>
> On Thu, 12 Jun 2025 06:12:09 PDT (-0700), Alexandre Ghiti wrote:
> > On 6/12/25 11:32, Yixun Lan wrote:
> >> Hi Alexandre,
> >>
> >> On 10:37 Thu 12 Jun     , Alexandre Ghiti wrote:
> >>> Hi Yixun,
> >>>
> >>> On 6/11/25 16:56, Yixun Lan wrote:
> >>>> Changes to defconfig should be always updated via 'make
> >>>> savedefconfig', run this command to make it aligned again.
> >>>>
> >>>> This will ease the effort of reviewing changes of defconfig
> >>>> in the future.
> >>>>
> >>>> Signed-off-by: Yixun Lan <dlan@...too.org>
> >>>> ---
> >>>> Update PDMA config bring in unnecessary changes[1], let's fix
> >>>> it by run savedefconfig first.
> >>>
> >>> It would be easier if this patch was part of the PDMA series since the
> >>> last patch will depend on it: @Guodong can you integrate this patch to
> >>> your next revision of your patchset?
> >>>
> >> I'd rather make this patch independent, as nothing strongly ralated with PDMA,
> >> and it probably would take several rounds for PDMA patch to be settled down..
>
> Ya, I agree.
>
> >> Besides, there is no problem for PDMA patch to depend on this patch if
> >> needed (easy to use b4 to handle this..)
>
> Yep, something like "b4 shazam -lts --merge --merge-base 958097bdf88"
> should do it on the merge side -- and maybe you don't even need the
> merge base, if all the b4 send side stuff picks it up right.
>
> >> The idea here is to get this patch merged as early as possible, as it's
> >> quite straightforward, and other people may have similar problem instead
> >> of PDMA here
> >
> >
> > Ok makes sense, so let's Guodong deal with that then.
>
> (for some reason this isn't showing up in patchwork)
>
> I'm going to merge it as a single patch into for-next.  It'll loop

Sounds good. Thank you.
I will rebase, (or have it as a prerequisite in v2 of my PDMA
patchset).

Guodong

> through the tester, but things look in good shape so it shouldn't take
> too long.  This way there's a stable hash people can base stuff off,
> rather than waiting for some other patch set.
>
> >
> > Thanks,
> >
> > Alex
> >
> >
> >>
> >>> Thanks,
> >>>
> >>> Alex
> >>>