* Re: [PATCH] drm/amd/display: fix usage of DC_FPU_{BEGIN,END} with PREEMPT_RT
From: Bert Karwatzki @ 2026-07-29 17:46 UTC (permalink / raw)
To: Mikhail Gavrilov
Cc: linux-kernel, linux-next, linux-rt-devel, amd-gfx, # = v7 . 1,
Alex Deucher, Rafal Ostrowski, Mario Limonciello,
Sebastian Andrzej Siewior, Thomas Gleixner, spasswwolf
In-Reply-To: <CABXGCsONHe2ST-==Gso2748i7W_POPiUAF2MrrmTuqoQr7z3gg@mail.gmail.com>
Am Dienstag, dem 28.07.2026 um 05:51 +0500 schrieb mikhail.v.gavrilov@gmail.com:
> One thing that may be worth adjusting in the commit message: this is
> not only a PREEMPT_RT problem. 183182235f6d was needed on a plain non-
> RT x86 kernel. There DC_FP_START() takes fpregs_lock(), which disables
> local softirqs, and dc_plane_state is around 335 KiB, so kvzalloc_obj()
> falls through to the vmalloc path and hits BUG_ON(in_interrupt()). So
> on RT any allocation inside the FPU region is illegal, while on non-RT
> it is specifically the large ones - two failure modes, one root cause.
I think this was true when commit
183182235f6d ("drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED")
was commited, but commit
04aa71da5f35 ("mm/vmalloc: do not trigger BUG() on BH disabled context")
changed the BUG_ON() in __get_vm_area_node():
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index c31a8615a832..bb6ae08d18f5 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3203,7 +3203,7 @@ struct vm_struct *__get_vm_area_node(unsigned long size,
struct vm_struct *area;
unsigned long requested_size = size;
- BUG_ON(in_interrupt());
+ BUG_ON(in_nmi() || in_hardirq());
size = ALIGN(size, 1ul << shift);
if (unlikely(!size))
return NULL;
so on non-PREEMPT_RT kernels DC_RUN_WITH_PREEMPTION_ENABLED is no
longer required for DCN32 phantom-plane allocation.
Bert Karwatzki
^ permalink raw reply related
* linux-next: Tree for Jul 29
From: Mark Brown @ 2026-07-29 15:39 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]
Hi all,
Changes since 20260728:
The vfs-brauner tree acquired a conflict with the gfs2 tree.
The vfs-brauner tree lost it's build failure.
The mediatek tree acquired a build failure, I used the version from
next-20270728 instead.
The amdgpu tree acquired a conflict with the origin tree.
The thunderbolt tree acquired a conflict with the thunderbolt-fixes tree.
The fastrpc tree lost it's build failure.
The ftrace tree acquired a build failure in the final builds for which I
applied a revert.
Non-merge commits (relative to Linus' tree): 9466
8666 files changed, 438853 insertions(+), 139498 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at https://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There is also the merge.log file in the Next
directory. Between each merge, the tree was built with a defconfig
for arm64, an allmodconfig for x86_64, a multi_v7_defconfig for arm,
an arm64 build of various kselftests, a KUnit build and run on arm64,
and a native build of tools/perf. After the final fixups (if any), I do
an x86_64 modules_install followed by builds for x86_64 allnoconfig,
arm64 allyesconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig and pseries_le_defconfig and i386, s390, sparc and
sparc64 defconfig and htmldocs.
Below is a summary of the state of the merge.
I am currently merging 429 trees (counting Linus' and 133 trees of bug
fix patches pending for the current release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Thanks to Paul Gortmaker for triage and bug fixes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: build failure in final build
From: Mark Brown @ 2026-07-29 15:34 UTC (permalink / raw)
To: Mykyta Yatsenko, Steven Rostedt
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
Hi all,
After in the final build, today's linux-next build (arm64 allyesconfig)
failed like this:
ld: drivers/net/wireless/mediatek/mt76/usb_trace.o:(.bss+0x40): multiple definition of `__bpf_trace_btf_ids_dev_reg_evt'; drivers/net/wireless/mediatek/mt76/trace.o:(.bss+0x80): first defined here
ld: drivers/media/platform/nvidia/tegra-vde/vde.o:(.bss+0x180): multiple definition of `__bpf_trace_btf_ids_register_access'; drivers/gpu/drm/tegra/trace.o:(.bss+0x0): first defined here
Caused by commit
eadc0725ab8d3 (tracing: Expose tracepoint BTF ids via tracefs)
which I have reverted for today.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the liveupdate tree with the mm-unstable tree
From: Mike Rapoport @ 2026-07-29 14:44 UTC (permalink / raw)
To: Andrew Morton
Cc: Mark Brown, Pasha Tatashin, Pratyush Yadav,
Linux Kernel Mailing List, Linux Next Mailing List, Muchun Song,
Muchun Song
In-Reply-To: <20260729001052.72027fbb99b50783476fa7c2@linux-foundation.org>
On Wed, Jul 29, 2026 at 12:10:52AM -0700, Andrew Morton wrote:
> On Wed, 29 Jul 2026 09:06:57 +0300 Mike Rapoport <rppt@kernel.org> wrote:
>
> > > I'll get the series "mm: Refactor bootmem gigantic
> > > hugepage allocation" into mm-stable in the next couple of days. Can we
> > > then make this issue go away?
> >
> > I can base the conflicting KHO work on mm-stable.
>
> It's pushed out now. Basing on 6d098029de09 ("mm/mm_init: fold
> __init_page_from_nid() into __init_deferred_page()") would capture all
> of Muchun's "mm: Refactor bootmem gigantic hugepage allocation".
I'll apply the next version from Pratyush on this ...
> > But if mm-stable is rebased we'd be in a bigger trouble.
>
> As mentioned, rare.
... and will cross fingers that such rare event won't happen this cycle :)
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH] drm/amd/display: fix usage of DC_FPU_{BEGIN,END} with PREEMPT_RT
From: Mikhail Gavrilov @ 2026-07-29 14:39 UTC (permalink / raw)
To: Bert Karwatzki
Cc: linux-kernel, linux-next, linux-rt-devel, amd-gfx, # = v7 . 1,
Alex Deucher, Rafal Ostrowski, Mario Limonciello,
Sebastian Andrzej Siewior, Thomas Gleixner
In-Reply-To: <1ead313022bc62dce1f42af9f855727eb9074443.camel@web.de>
On Wed, Jul 29, 2026 at 5:36 PM Bert Karwatzki <spasswolf@web.de> wrote:
>
> I did try a different approach, using DC_RUN_WITH_PREEMPTION_ENABLED further
> upward in the calltrace (This would have the slight benefit of more code
> running with preemption enabled). This does not work because dml21_utils.c is compiled
> as a _LINUX_FPU_COMPILATION_UNIT, so DC_RUN_WITH_PREEMPTION_ENABLED does nothing.
Confirmed, and the chain is worth spelling out because it is not obvious
from the call site:
Makefile:1127: CC_FLAGS_FPU += -D_LINUX_FPU_COMPILATION_UNIT
dc/dml2_0/Makefile: applies $(CC_FLAGS_FPU) to every object under
dc/dml2_0/ ("Add FPU flags to all dml2 files by
default")
so both files you tried are built with -D_LINUX_FPU_COMPILATION_UNIT,
and in that branch of dc_fpu.h the macro is:
#define DC_RUN_WITH_PREEMPTION_ENABLED(code) code
What I think is the real problem here: in the same branch DC_FP_START()
and DC_FP_END() are defined as BUILD_BUG(), so misusing those inside an
FPU compilation unit fails the build. DC_RUN_WITH_PREEMPTION_ENABLED()
silently degrades to a plain call instead. It compiles cleanly, looks
correct on review, and does nothing - which is exactly the trap you just
walked into. Making it BUILD_BUG() as well would turn that into a
compile error. I can send that as a separate patch if AMD agrees it is
the right direction.
This also explains the asymmetry with 183182235f6d: dc/resource/dcn32/
does not get the FPU flags, so the call-site wrap there expands to the
real thing, while the equivalent wrap in the dml21 path would have been
a no-op. Another reason to guard the allocation in the callee, as your
patch does.
--
Thanks,
Mikhail
^ permalink raw reply
* linux-next: manual merge of the thunderbolt tree with the thunderbolt-fixes tree
From: Mark Brown @ 2026-07-29 14:18 UTC (permalink / raw)
To: Mika Westerberg
Cc: Basavaraj Natikar, Linux Kernel Mailing List,
Linux Next Mailing List, Sanath S
[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]
Hi all,
Today's linux-next merge of the thunderbolt tree got a conflict in:
drivers/thunderbolt/nhi.c
between commit:
c35c173c3daa0 ("thunderbolt: Initialize ->domain_released completion before it is being used")
from the thunderbolt-fixes tree and commit:
5f40cba7d4fa3 ("thunderbolt: Assert downstream port reset on shutdown")
from the thunderbolt tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/thunderbolt/nhi.c
index 35e3c119d5ee8,698fb124d5291..0000000000000
--- a/drivers/thunderbolt/nhi.c
+++ b/drivers/thunderbolt/nhi.c
@@@ -1235,6 -1233,10 +1235,8 @@@ int nhi_probe(struct tb_nhi *nhi
dev_dbg(dev, "NHI initialized, starting thunderbolt\n");
- init_completion(&nhi->domain_released);
-
+ nhi->host_reset = host_reset;
+
res = tb_domain_add(tb, host_reset);
if (res) {
/*
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the amdgpu tree with the origin tree
From: Mark Brown @ 2026-07-29 13:28 UTC (permalink / raw)
To: Alex Deucher
Cc: Alex Deucher, Leo Li, Linux Kernel Mailing List,
Linux Next Mailing List, Mario Limonciello
[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
between commit:
82730dba0cf9d ("drm/amd/display: Fix flip-done timeouts on mode1 reset")
from the origin tree and commit:
7e1b4bdb0e05a ("drm/amd/display: Fix flip-done timeouts on mode1 reset")
from the amdgpu tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --combined drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
index ff308ee40909e,079d4ccc88da6..0000000000000
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@@ -34,7 -34,7 +34,7 @@@
#include "amdgpu_dm_plane.h"
#include "amdgpu_dm_trace.h"
#include "amdgpu_dm_debugfs.h"
- #include "amdgpu_dm_kunit_helpers.h"
+ #include "dm_helpers.h"
#include "modules/inc/mod_power.h"
#define HPD_DETECTION_PERIOD_uS 2000000
@@@ -287,8 -287,6 +287,6 @@@ static inline int amdgpu_dm_crtc_set_vb
* is enabled. On DCE, vupdate is only needed in VRR mode.
*/
if (amdgpu_ip_version(adev, DCE_HWIP, 0) != 0) {
- rc = amdgpu_dm_crtc_set_vupdate_irq(crtc, enable);
- } else if (dc_supports_vrr(dm->dc->ctx->dce_version)) {
if (enable) {
rc = amdgpu_irq_get(adev, &adev->vupdate_irq, irq_type);
drm_dbg_vbl(crtc->dev, "Get vupdate_irq ret=%d\n", rc);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Leandro Ribeiro @ 2026-07-29 12:48 UTC (permalink / raw)
To: Tetsuo Handa, Miguel Ojeda
Cc: Mark Brown, Pekka Paalanen, Daniel Stone, Theodore Tso,
Alexander Potapenko, Christoph Hellwig, Aleksandr Nogikh,
Boqun Feng, Gary Guo, linux-next, linux-kernel, Miguel Ojeda,
Linus Torvalds, peterz, will, longman, mingo, gregkh
In-Reply-To: <bff95de5-7f0b-4f08-8ceb-58a6e354ebe2@I-love.SAKURA.ne.jp>
On 7/28/26 20:46, Tetsuo Handa wrote:
> On 2026/07/29 7:11, Miguel Ojeda wrote:
>> On Tue, Jul 28, 2026 at 4:46 PM Tetsuo Handa
>> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>>
>>> syzbot stops upon encountering "BUG:" or "WARNING:" within printk() output.
>>
>> Out of curiosity, is that a fundamental property or something that
>> could be optionally be relaxed (for certain linux-next runs only,
>> perhaps) so that you can continue testing in certain cases where the
>> "WARNING:" may be harmless (i.e. irrelevant for your particular
>> fuzzing)?
>>
>> i.e. I was wondering whether the system could ignore the "WARNING:"s
>> (and avoid the kernel panicking on them etc.) until after boot, i.e.
>> when the fuzzing starts.
>
> syzbot uses kernel.panic_on_warn=1, for most of WARN*() users are reporting
> problems that should not be ignored. Therefore, WARN*() must not be used for
> reporting recoverable mistakes like -EINVAL. Abusing WARN*() like
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/kernel/workqueue.c?id=6e845bcb78c95af935094040bd4edc3c2b6dd784#n5855
> is a fatal barrier for continuous testing systems like syzbot.
>
> Quoting from https://lkml.kernel.org/r/5b2dea50-2850-4876-b6e8-ba94b9a85034@I-love.SAKURA.ne.jp :
>
> Please never try to emit WARNING: or BUG: message just for letting developers
> update their code. If you can't use panic() instead of WARN*() or BUG*(), you
> should not use WARN*() or BUG*(). The patch author who changes the behavior of
> in-tree code is responsible for updating all in-tree code.
>
> Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format
> with alpha exposed") must be reverted or updated not to emit "WARNING:" string.
> Until authors of that commit respond, that commit had better be excluded from
> the linux-next tree.
>
Hello,
First of all, sorry for all the trouble with this warning. I'll propose
a patch replacing the warning with printk() or pr_info(), if that
doesn't cause similar issues for fuzzers.
Thanks,
Leandro
^ permalink raw reply
* Re: [PATCH] drm/amd/display: fix usage of DC_FPU_{BEGIN,END} with PREEMPT_RT
From: Bert Karwatzki @ 2026-07-29 12:35 UTC (permalink / raw)
To: mikhail.v.gavrilov@gmail.com, linux-kernel
Cc: linux-next, linux-rt-devel, amd-gfx, # = v7 . 1, Alex Deucher,
Rafal Ostrowski, Mario Limonciello, Sebastian Andrzej Siewior,
Thomas Gleixner, spasswolf
In-Reply-To: <ef1bc3d070c4156f1811c0c4a567ec98ac8fadaf.camel@gmail.com>
Am Dienstag, dem 28.07.2026 um 05:51 +0500 schrieb mikhail.v.gavrilov@gmail.com:
> On Mon, 2026-07-27 at 12:50 +0200, Bert Karwatzki wrote:
> > On PREEMPT_RT kernels kvzalloc_obj() can sleep because spin_lock is
> > converted to rt_mutex. dc_create_plane_state() can be called while
> > inside an FPU-guarded region, resuling in "scheduling while atomic"
> > errors on PREEMPT_RT kernels.
> > Fix this by calling kvzalloc_obj() with
> > DC_RUN_WITH_PREEMPTION_ENABLED().
> > Also fix the error path in dc_create_stream_for_sink().
> >
> > Fixes: 3539437f354b ("drm/amd/display: Move FPU Guards From DML To DC
> > - Part 1")
> > Link:
> > https://lore.kernel.org/lkml/20260723123449.6494-1-spasswolf@web.de/
> >
> > Signed-off-by: Bert Karwatzki <spasswolf@web.de>
> > ---
> > drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 5 +++--
> > drivers/gpu/drm/amd/display/dc/core/dc_surface.c | 4 ++--
> > 2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> > b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> > index dbc12640b01c..4ac835777b58 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> > @@ -233,8 +233,9 @@ struct dc_stream_state
> > *dc_create_stream_for_sink(
> >
> > fail:
> > if (stream) {
> > - kfree(stream->update_scratch);
> > - kfree(stream);
> > + if (stream->update_scratch)
> > + DC_RUN_WITH_PREEMPTION_ENABLED(kfree(stream-
> > > update_scratch));
> > + DC_RUN_WITH_PREEMPTION_ENABLED(kfree(stream));
> > }
> >
> > return NULL;
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
> > b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
> > index 88e825a6582c..d5c6427796b6 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
> > @@ -85,8 +85,8 @@ uint8_t dc_plane_get_pipe_mask(struct dc_state
> > *dc_state, const struct dc_plane
> >
> > *********************************************************************
> > *********/
> > struct dc_plane_state *dc_create_plane_state(const struct dc *dc)
> > {
> > - struct dc_plane_state *plane_state =
> > kvzalloc_obj(*plane_state,
> > -
> > GFP_ATOMIC);
> > + struct dc_plane_state *plane_state;
> > + DC_RUN_WITH_PREEMPTION_ENABLED(plane_state =
> > kvzalloc_obj(*plane_state, GFP_ATOMIC));
> >
> > if (NULL == plane_state)
> > return NULL;
>
> Hi Bert,
>
> You may not be aware that the same allocation is already wrapped once,
> at the dcn32 call site:
>
> 183182235f6d ("drm/amd/display: Wrap DCN32 phantom-plane allocation
> in DC_RUN_WITH_PREEMPTION_ENABLED")
>
> That one only covers the dcn32 DML1 path, while your trace goes through
> dcn401_validate_bandwidth() and dml21 - so wrapping the call site could
> never have caught your case. Which is a good argument for guarding the
> allocation in the callee, as you do: dc_create_plane_state() is reached
> from every DCN and both DML generations.
I did try a different approach, using DC_RUN_WITH_PREEMPTION_ENABLED further
upward in the calltrace (This would have the slight benefit of more code
running with preemption enabled). This does not work because dml21_utils.c is compiled
as a _LINUX_FPU_COMPILATION_UNIT, so DC_RUN_WITH_PREEMPTION_ENABLED does nothing.
(see drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.h)
diff --git a/drivers/gpu/drm/amd/display/dc/dml2_0/dml21/dml21_utils.c b/drivers/gpu/drm/amd/display/dc/dml2_0/dml21/dml21_utils.c
index 835fece1d46a..8c92deded8cd 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2_0/dml21/dml21_utils.c
+++ b/drivers/gpu/drm/amd/display/dc/dml2_0/dml21/dml21_utils.c
@@ -286,7 +286,8 @@ static struct dc_plane_state *dml21_add_phantom_plane(struct dml2_context *dml_c
(void)plane_programming;
struct dc_plane_state *phantom_plane;
- phantom_plane = dml_ctx->config.svp_pstate.callbacks.create_phantom_plane(dc, context, main_plane);
+ DC_RUN_WITH_PREEMPTION_ENABLED(phantom_plane
+ = dml_ctx->config.svp_pstate.callbacks.create_phantom_plane(dc, context, main_plane));
if (!phantom_plane)
return NULL;
diff --git a/drivers/gpu/drm/amd/display/dc/dml2_0/dml2_mall_phantom.c b/drivers/gpu/drm/amd/display/dc/dml2_0/dml2_mall_phantom.c
index 4543a60a0683..464bab9fc13b 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2_0/dml2_mall_phantom.c
+++ b/drivers/gpu/drm/amd/display/dc/dml2_0/dml2_mall_phantom.c
@@ -769,10 +769,11 @@ static void enable_phantom_plane(struct dml2_context *ctx,
if (curr_pipe->top_pipe && curr_pipe->top_pipe->plane_state == curr_pipe->plane_state) {
phantom_plane = prev_phantom_plane;
} else {
- phantom_plane = ctx->config.svp_pstate.callbacks.create_phantom_plane(
+ DC_RUN_WITH_PREEMPTION_ENABLED(phantom_plane =
+ ctx->config.svp_pstate.callbacks.create_phantom_plane(
ctx->config.svp_pstate.callbacks.dc,
state,
- curr_pipe->plane_state);
+ curr_pipe->plane_state));
if (!phantom_plane)
return;
}
Bert Karwatzki
^ permalink raw reply related
* linux-next: build failure after merge of the mediatek tree
From: Mark Brown @ 2026-07-29 12:30 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Chen-Yu Tsai
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]
Hi all,
After merging the mediatek tree, today's linux-next build
(arm64 defconfig) failed like this:
Lexical error: /tmp/next/build/arch/arm64/boot/dts/mediatek/mt8173.dtsi:1010.22-33 Unexpected 'CLK_MFG_G3D'
Lexical error: /tmp/next/build/arch/arm64/boot/dts/mediatek/mt8173.dtsi:1011.15-26 Unexpected 'CLK_MFG_MEM'
Lexical error: /tmp/next/build/arch/arm64/boot/dts/mediatek/mt8173.dtsi:1012.15-26 Unexpected 'CLK_MFG_AXI'
FATAL ERROR: Syntax error parsing input tree
make[4]: *** [/tmp/next/build/scripts/Makefile.dtbs:140: arch/arm64/boot/dts/mediatek/mt8173-elm.dtb] Error 1
make[4]: *** Waiting for unfinished jobs....
Lexical error: /tmp/next/build/arch/arm64/boot/dts/mediatek/mt8173.dtsi:1010.22-33 Unexpected 'CLK_MFG_G3D'
Lexical error: /tmp/next/build/arch/arm64/boot/dts/mediatek/mt8173.dtsi:1011.15-26 Unexpected 'CLK_MFG_MEM'
Lexical error: /tmp/next/build/arch/arm64/boot/dts/mediatek/mt8173.dtsi:1012.15-26 Unexpected 'CLK_MFG_AXI'
FATAL ERROR: Syntax error parsing input tree
make[4]: *** [/tmp/next/build/scripts/Makefile.dtbs:140: arch/arm64/boot/dts/mediatek/mt8173-evb.dtb] Error 1
Lexical error: /tmp/next/build/arch/arm64/boot/dts/mediatek/mt8173.dtsi:1010.22-33 Unexpected 'CLK_MFG_G3D'
Lexical error: /tmp/next/build/arch/arm64/boot/dts/mediatek/mt8173.dtsi:1011.15-26 Unexpected 'CLK_MFG_MEM'
Lexical error: /tmp/next/build/arch/arm64/boot/dts/mediatek/mt8173.dtsi:1012.15-26 Unexpected 'CLK_MFG_AXI'
FATAL ERROR: Syntax error parsing input tree
make[4]: *** [/tmp/next/build/scripts/Makefile.dtbs:140: arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtb] Error 1
Lexical error: /tmp/next/build/arch/arm64/boot/dts/mediatek/mt8173.dtsi:1010.22-33 Unexpected 'CLK_MFG_G3D'
Lexical error: /tmp/next/build/arch/arm64/boot/dts/mediatek/mt8173.dtsi:1011.15-26 Unexpected 'CLK_MFG_MEM'
Lexical error: /tmp/next/build/arch/arm64/boot/dts/mediatek/mt8173.dtsi:1012.15-26 Unexpected 'CLK_MFG_AXI'
FATAL ERROR: Syntax error parsing input tree
Caused by commit
75bfd9e7cdae0 (arm64: dts: mediatek: mt8173: Add GPU device nodes)
I have used the tree from next-20260728 instead.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the vfs-brauner tree with the gfs2 tree
From: Mark Brown @ 2026-07-29 12:30 UTC (permalink / raw)
To: Christian Brauner
Cc: Andreas Gruenbacher, Linux Kernel Mailing List,
Linux Next Mailing List, Mateusz Guzik
[-- Attachment #1: Type: text/plain, Size: 12234 bytes --]
Hi all,
Today's linux-next merge of the vfs-brauner tree got a conflict in:
fs/gfs2/glock.c
between commit:
da26828b82a45 ("gfs2: Remove the glock lru list and shrinker")
from the gfs2 tree and commit:
21a8e80682781 ("lockref: tidy up dead count handling")
from the vfs-brauner tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --combined fs/gfs2/glock.c
index 558c8c660a3d4,eaa2980051ed5..0000000000000
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@@ -66,6 -66,9 +66,6 @@@ static void request_demote(struct gfs2_
unsigned long delay, bool remote);
static struct dentry *gfs2_root;
-static LIST_HEAD(lru_list);
-static atomic_t lru_count = ATOMIC_INIT(0);
-static DEFINE_SPINLOCK(lru_lock);
#define GFS2_GL_HASH_SHIFT 15
#define GFS2_GL_HASH_SIZE BIT(GFS2_GL_HASH_SHIFT)
@@@ -75,7 -78,6 +75,7 @@@ static const struct rhashtable_params h
.key_len = offsetofend(struct lm_lockname, ln_type),
.key_offset = offsetof(struct gfs2_glock, gl_name),
.head_offset = offsetof(struct gfs2_glock, gl_node),
+ .automatic_shrinking = true,
};
static struct rhashtable gl_hash_table;
@@@ -155,9 -157,9 +155,9 @@@ void gfs2_glock_free(struct gfs2_glock
void gfs2_glock_free_later(struct gfs2_glock *gl) {
struct gfs2_sbd *sdp = glock_sbd(gl);
- spin_lock(&lru_lock);
- list_add(&gl->gl_lru, &sdp->sd_dead_glocks);
- spin_unlock(&lru_lock);
+ spin_lock(&sdp->sd_dead_lock);
+ list_add(&gl->gl_dead, &sdp->sd_dead_glocks);
+ spin_unlock(&sdp->sd_dead_lock);
if (atomic_dec_and_test(&sdp->sd_glock_disposal))
wake_up(&sdp->sd_kill_wait);
}
@@@ -169,8 -171,8 +169,8 @@@ static void gfs2_free_dead_glocks(struc
while(!list_empty(list)) {
struct gfs2_glock *gl;
- gl = list_first_entry(list, struct gfs2_glock, gl_lru);
- list_del_init(&gl->gl_lru);
+ gl = list_first_entry(list, struct gfs2_glock, gl_dead);
+ list_del(&gl->gl_dead);
__gfs2_glock_free(gl);
}
}
@@@ -188,6 -190,30 +188,6 @@@ struct gfs2_glock *gfs2_glock_hold(stru
return gl;
}
-static void gfs2_glock_add_to_lru(struct gfs2_glock *gl)
-{
- spin_lock(&lru_lock);
- list_move_tail(&gl->gl_lru, &lru_list);
-
- if (!test_bit(GLF_LRU, &gl->gl_flags)) {
- set_bit(GLF_LRU, &gl->gl_flags);
- atomic_inc(&lru_count);
- }
-
- spin_unlock(&lru_lock);
-}
-
-static void gfs2_glock_remove_from_lru(struct gfs2_glock *gl)
-{
- spin_lock(&lru_lock);
- if (test_bit(GLF_LRU, &gl->gl_flags)) {
- list_del_init(&gl->gl_lru);
- atomic_dec(&lru_count);
- clear_bit(GLF_LRU, &gl->gl_flags);
- }
- spin_unlock(&lru_lock);
-}
-
/*
* Enqueue the glock on the work queue. Passes one glock reference on to the
* work queue.
@@@ -214,6 -240,7 +214,6 @@@ static void __gfs2_glock_put(struct gfs
lockref_mark_dead(&gl->gl_lockref);
spin_unlock(&gl->gl_lockref.lock);
- gfs2_glock_remove_from_lru(gl);
GLOCK_BUG_ON(gl, !list_empty(&gl->gl_holders));
if (mapping) {
truncate_inode_pages_final(mapping);
@@@ -230,8 -257,8 +230,8 @@@ static bool __gfs2_glock_put_or_lock(st
return true;
GLOCK_BUG_ON(gl, gl->gl_lockref.count != 1);
if (gl->gl_state != LM_ST_UNLOCKED) {
- gl->gl_lockref.count--;
- gfs2_glock_add_to_lru(gl);
+ request_demote(gl, LM_ST_UNLOCKED, 0, false);
+ gfs2_glock_queue_work(gl, 0);
spin_unlock(&gl->gl_lockref.lock);
return true;
}
@@@ -955,19 -982,16 +955,19 @@@ static void delete_work_func(struct wor
static void glock_work_func(struct work_struct *work)
{
- unsigned long delay = 0;
struct gfs2_glock *gl = container_of(work, struct gfs2_glock, gl_work.work);
- unsigned int drop_refs = 1;
+ unsigned int drop_refs;
+ unsigned long delay;
spin_lock(&gl->gl_lockref.lock);
+again:
+ drop_refs = 1;
if (test_bit(GLF_HAVE_REPLY, &gl->gl_flags)) {
clear_bit(GLF_HAVE_REPLY, &gl->gl_flags);
finish_xmote(gl, gl->gl_reply);
drop_refs++;
}
+ delay = 0;
if (test_bit(GLF_PENDING_DEMOTE, &gl->gl_flags) &&
gl->gl_state != LM_ST_UNLOCKED &&
gl->gl_demote_state != LM_ST_EXCLUSIVE) {
@@@ -995,13 -1019,11 +995,13 @@@
GLOCK_BUG_ON(gl, gl->gl_lockref.count < drop_refs);
gl->gl_lockref.count -= drop_refs;
if (!gl->gl_lockref.count) {
- if (gl->gl_state == LM_ST_UNLOCKED) {
- __gfs2_glock_put(gl);
- return;
+ if (gl->gl_state != LM_ST_UNLOCKED) {
+ gl->gl_lockref.count++;
+ request_demote(gl, LM_ST_UNLOCKED, 0, false);
+ goto again;
}
- gfs2_glock_add_to_lru(gl);
+ __gfs2_glock_put(gl);
+ return;
}
spin_unlock(&gl->gl_lockref.lock);
}
@@@ -1037,6 -1059,8 +1037,6 @@@ again
out:
rcu_read_unlock();
finish_wait(wq, &wait.wait);
- if (gl)
- gfs2_glock_remove_from_lru(gl);
return gl;
}
@@@ -1849,6 -1873,125 +1849,6 @@@ void gfs2_glock_complete(struct gfs2_gl
spin_unlock(&gl->gl_lockref.lock);
}
-static int glock_cmp(void *priv, const struct list_head *a,
- const struct list_head *b)
-{
- struct gfs2_glock *gla, *glb;
-
- gla = list_entry(a, struct gfs2_glock, gl_lru);
- glb = list_entry(b, struct gfs2_glock, gl_lru);
-
- if (glock_number(gla) > glock_number(glb))
- return 1;
- if (glock_number(gla) < glock_number(glb))
- return -1;
-
- return 0;
-}
-
-static bool can_free_glock(struct gfs2_glock *gl)
-{
- struct gfs2_sbd *sdp = glock_sbd(gl);
-
- return !test_bit(GLF_LOCK, &gl->gl_flags) &&
- !gl->gl_lockref.count &&
- (!test_bit(GLF_LFLUSH, &gl->gl_flags) ||
- test_bit(SDF_KILL, &sdp->sd_flags));
-}
-
-/**
- * gfs2_dispose_glock_lru - Demote a list of glocks
- * @list: The list to dispose of
- *
- * Disposing of glocks may involve disk accesses, so that here we sort
- * the glocks by number (i.e. disk location of the inodes) so that if
- * there are any such accesses, they'll be sent in order (mostly).
- *
- * Must be called under the lru_lock, but may drop and retake this
- * lock. While the lru_lock is dropped, entries may vanish from the
- * list, but no new entries will appear on the list (since it is
- * private)
- */
-
-static unsigned long gfs2_dispose_glock_lru(struct list_head *list)
-__releases(&lru_lock)
-__acquires(&lru_lock)
-{
- struct gfs2_glock *gl;
- unsigned long freed = 0;
-
- list_sort(NULL, list, glock_cmp);
-
- while(!list_empty(list)) {
- gl = list_first_entry(list, struct gfs2_glock, gl_lru);
- if (!spin_trylock(&gl->gl_lockref.lock)) {
-add_back_to_lru:
- list_move(&gl->gl_lru, &lru_list);
- continue;
- }
- if (!can_free_glock(gl)) {
- spin_unlock(&gl->gl_lockref.lock);
- goto add_back_to_lru;
- }
- list_del_init(&gl->gl_lru);
- atomic_dec(&lru_count);
- clear_bit(GLF_LRU, &gl->gl_flags);
- freed++;
- gl->gl_lockref.count++;
- if (gl->gl_state != LM_ST_UNLOCKED)
- request_demote(gl, LM_ST_UNLOCKED, 0, false);
- gfs2_glock_queue_work(gl, 0);
- spin_unlock(&gl->gl_lockref.lock);
- cond_resched_lock(&lru_lock);
- }
- return freed;
-}
-
-/**
- * gfs2_scan_glock_lru - Scan the LRU looking for locks to demote
- * @nr: The number of entries to scan
- *
- * This function selects the entries on the LRU which are able to
- * be demoted, and then kicks off the process by calling
- * gfs2_dispose_glock_lru() above.
- */
-
-static unsigned long gfs2_scan_glock_lru(unsigned long nr)
-{
- struct gfs2_glock *gl, *next;
- LIST_HEAD(dispose);
- unsigned long freed = 0;
-
- spin_lock(&lru_lock);
- list_for_each_entry_safe(gl, next, &lru_list, gl_lru) {
- if (!nr--)
- break;
- if (can_free_glock(gl))
- list_move(&gl->gl_lru, &dispose);
- }
- if (!list_empty(&dispose))
- freed = gfs2_dispose_glock_lru(&dispose);
- spin_unlock(&lru_lock);
-
- return freed;
-}
-
-static unsigned long gfs2_glock_shrink_scan(struct shrinker *shrink,
- struct shrink_control *sc)
-{
- if (!(sc->gfp_mask & __GFP_FS))
- return SHRINK_STOP;
- return gfs2_scan_glock_lru(sc->nr_to_scan);
-}
-
-static unsigned long gfs2_glock_shrink_count(struct shrinker *shrink,
- struct shrink_control *sc)
-{
- return vfs_pressure_ratio(atomic_read(&lru_count));
-}
-
-static struct shrinker *glock_shrinker;
-
/**
* glock_hash_walk - Call a function for glock in a hash bucket
* @examiner: the function
@@@ -1919,12 -2062,33 +1919,12 @@@ static void thaw_glock(struct gfs2_gloc
if (!lockref_get_not_dead(&gl->gl_lockref))
return;
- gfs2_glock_remove_from_lru(gl);
spin_lock(&gl->gl_lockref.lock);
set_bit(GLF_HAVE_REPLY, &gl->gl_flags);
gfs2_glock_queue_work(gl, 0);
spin_unlock(&gl->gl_lockref.lock);
}
-/**
- * clear_glock - look at a glock and see if we can free it from glock cache
- * @gl: the glock to look at
- *
- */
-
-static void clear_glock(struct gfs2_glock *gl)
-{
- gfs2_glock_remove_from_lru(gl);
-
- spin_lock(&gl->gl_lockref.lock);
- if (!lockref_is_dead(&gl->gl_lockref)) {
- gl->gl_lockref.count++;
- if (gl->gl_state != LM_ST_UNLOCKED)
- request_demote(gl, LM_ST_UNLOCKED, 0, false);
- gfs2_glock_queue_work(gl, 0);
- }
- spin_unlock(&gl->gl_lockref.lock);
-}
-
/**
* gfs2_glock_thaw - Thaw any frozen glocks
* @sdp: The super block
@@@ -1951,7 -2115,7 +1951,7 @@@ static void dump_glock_func(struct gfs2
static void withdraw_glock(struct gfs2_glock *gl)
{
spin_lock(&gl->gl_lockref.lock);
- if (!__lockref_is_dead(&gl->gl_lockref)) {
+ if (!lockref_is_dead(&gl->gl_lockref)) {
/*
* We don't want to write back any more dirty data. Unlock the
* remaining inode and resource group glocks; this will cause
@@@ -1971,17 -2135,22 +1971,17 @@@ void gfs2_withdraw_glocks(struct gfs2_s
}
/**
- * gfs2_gl_hash_clear - Empty out the glock hash table
+ * gfs2_wait_glocks - Wait for the remaining glocks to go away
* @sdp: the filesystem
*
* Called when unmounting the filesystem.
*/
-void gfs2_gl_hash_clear(struct gfs2_sbd *sdp)
+void gfs2_wait_glocks(struct gfs2_sbd *sdp)
{
unsigned long start = jiffies;
bool timed_out = false;
- set_bit(SDF_SKIP_DLM_UNLOCK, &sdp->sd_flags);
- flush_workqueue(sdp->sd_glock_wq);
- glock_hash_walk(clear_glock, sdp);
- flush_workqueue(sdp->sd_glock_wq);
-
while (!timed_out) {
wait_event_timeout(sdp->sd_kill_wait,
!atomic_read(&sdp->sd_glock_disposal),
@@@ -2104,6 -2273,8 +2104,6 @@@ static const char *gflags2str(char *buf
*p++ = 'F';
if (!list_empty(&gl->gl_holders))
*p++ = 'q';
- if (test_bit(GLF_LRU, gflags))
- *p++ = 'L';
if (gl->gl_object)
*p++ = 'o';
if (test_bit(GLF_BLOCKING, gflags))
@@@ -2263,6 -2434,17 +2263,6 @@@ int __init gfs2_glock_init(void
if (ret < 0)
return ret;
- glock_shrinker = shrinker_alloc(0, "gfs2-glock");
- if (!glock_shrinker) {
- rhashtable_destroy(&gl_hash_table);
- return -ENOMEM;
- }
-
- glock_shrinker->count_objects = gfs2_glock_shrink_count;
- glock_shrinker->scan_objects = gfs2_glock_shrink_scan;
-
- shrinker_register(glock_shrinker);
-
for (i = 0; i < GLOCK_WAIT_TABLE_SIZE; i++)
init_waitqueue_head(glock_wait_table + i);
@@@ -2271,6 -2453,7 +2271,6 @@@
void gfs2_glock_exit(void)
{
- shrinker_free(glock_shrinker);
rhashtable_destroy(&gl_hash_table);
}
@@@ -2300,7 -2483,7 +2300,7 @@@ static void gfs2_glock_iter_next(struc
continue;
break;
} else {
- if (__lockref_is_dead(&gl->gl_lockref))
+ if (lockref_is_dead(&gl->gl_lockref))
continue;
n--;
}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree with the staging.current tree
From: Greg KH @ 2026-07-29 9:42 UTC (permalink / raw)
To: Mark Brown
Cc: Eugene Mavick, Linux Kernel Mailing List, Linux Next Mailing List,
Muhammad Bilal
In-Reply-To: <amjpRIA5G0pnhhyr@sirena.org.uk>
On Tue, Jul 28, 2026 at 06:39:16PM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the staging tree got a conflict in:
>
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c
>
> between commit:
>
> ae21407350151 ("staging: rtl8723bs: fix OOB read in WMM_param_handler()")
>
> from the staging.current tree and commit:
>
> 6e68c64a71f70 ("staging: rtl8723bs: remove unnecessary parentheses")
>
> from the staging tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> index c614c0b4c792d,8b0502a1881b5..0000000000000
> --- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
> @@@ -666,13 -665,10 +665,13 @@@ int WMM_param_handler(struct adapter *p
> return false;
> }
>
> + if (pIE->length != WLAN_WMM_LEN)
> + return false;
> +
> - if (!memcmp(&(pmlmeinfo->WMM_param), (pIE->data + 6), sizeof(struct WMM_para_element)))
> + if (!memcmp(&pmlmeinfo->WMM_param, (pIE->data + 6), sizeof(struct WMM_para_element)))
> return false;
>
> - memcpy(&(pmlmeinfo->WMM_param), (pIE->data + 6), sizeof(struct WMM_para_element));
> + memcpy(&pmlmeinfo->WMM_param, (pIE->data + 6), sizeof(struct WMM_para_element));
>
> pmlmeinfo->WMM_enable = 1;
> return true;
Looks good, thanks!
greg k-h
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Miguel Ojeda @ 2026-07-29 7:17 UTC (permalink / raw)
To: Theodore Tso
Cc: Tetsuo Handa, Mark Brown, Leandro Ribeiro, Pekka Paalanen,
Daniel Stone, Alexander Potapenko, Christoph Hellwig,
Aleksandr Nogikh, Boqun Feng, Gary Guo, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh
In-Reply-To: <amlXC0hahHo4Cdsx@mit.edu>
On Wed, Jul 29, 2026 at 3:47 AM Theodore Tso <tytso@mit.edu> wrote:
>
> It could, but it would involve making a change in syzbot.
> Specifically, syzbot would have to be changed to boot the kernel being
> tested without the kernel.panic_on_warn=1 boot command line function,
> and then in the syzbot reproducer, to add the moral equivalent of
>
> echo 1 > /proc/sys/kernel/panic_on_warn
Thanks Ted! Yeah, that's about what I was expecting.
Cheers,
Miguel
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Miguel Ojeda @ 2026-07-29 7:12 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Mark Brown, Leandro Ribeiro, Pekka Paalanen, Daniel Stone,
Theodore Tso, Alexander Potapenko, Christoph Hellwig,
Aleksandr Nogikh, Boqun Feng, Gary Guo, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh
In-Reply-To: <bff95de5-7f0b-4f08-8ceb-58a6e354ebe2@I-love.SAKURA.ne.jp>
On Wed, Jul 29, 2026 at 1:46 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> syzbot uses kernel.panic_on_warn=1, for most of WARN*() users are reporting
> problems that should not be ignored. Therefore, WARN*() must not be used for
> reporting recoverable mistakes like -EINVAL. Abusing WARN*() like
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/kernel/workqueue.c?id=6e845bcb78c95af935094040bd4edc3c2b6dd784#n5855
> is a fatal barrier for continuous testing systems like syzbot.
Yeah, a lot of CIs that grep for certain keywords in the kernel log
(or that simply enable the panicking) suffer from those, but the idea
I was mentioning is to defer that until the fuzzing starts -- see
Ted's reply, it sounds potentially doable.
It may not solve the complete problem, but it may allow you, for
certain trees or periods of time, to continue your testing. Thus
removing a bit of the coupling between you and other maintainers, i.e.
making life easier for both sides.
I don't know -- I am just trying to find compromises that could help you.
Cheers,
Miguel
^ permalink raw reply
* Re: linux-next: manual merge of the liveupdate tree with the mm-unstable tree
From: Andrew Morton @ 2026-07-29 7:10 UTC (permalink / raw)
To: Mike Rapoport
Cc: Mark Brown, Pasha Tatashin, Pratyush Yadav,
Linux Kernel Mailing List, Linux Next Mailing List, Muchun Song,
Muchun Song
In-Reply-To: <ammYgVd3Ty8JE0Fd@kernel.org>
On Wed, 29 Jul 2026 09:06:57 +0300 Mike Rapoport <rppt@kernel.org> wrote:
> > I'll get the series "mm: Refactor bootmem gigantic
> > hugepage allocation" into mm-stable in the next couple of days. Can we
> > then make this issue go away?
>
> I can base the conflicting KHO work on mm-stable.
It's pushed out now. Basing on 6d098029de09 ("mm/mm_init: fold
__init_page_from_nid() into __init_deferred_page()") would capture all
of Muchun's "mm: Refactor bootmem gigantic hugepage allocation".
> But if mm-stable is rebased we'd be in a bigger trouble.
As mentioned, rare.
^ permalink raw reply
* Re: linux-next: build failure after merge of the fastrpc tree
From: Srinivas Kandagatla @ 2026-07-29 6:55 UTC (permalink / raw)
To: Mark Brown, Srini Kandagatla, Ekansh Gupta
Cc: Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <amaNYEchEvJAcnQT@sirena.org.uk>
On 7/26/26 11:42 PM, Mark Brown wrote:
> Hi all,
>
> After merging the fastrpc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> /tmp/next/build/drivers/misc/fastrpc.c:599:29: error: call to undeclared function 'FIELD_GET'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 599 | idr_remove(&cctx->ctx_idr, FIELD_GET(FASTRPC_CTXID_MASK, ctx->ctxid));
This is now fixed in fastrpc tree.
--srini
> | ^
> /tmp/next/build/drivers/misc/fastrpc.c:737:15: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 737 | ctx->ctxid = FIELD_PREP(FASTRPC_CTXID_MASK, ret) |
> | ^
> /tmp/next/build/drivers/misc/fastrpc.c:2711:10: error: call to undeclared function 'FIELD_GET'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 2711 | ctxid = FIELD_GET(FASTRPC_CTXID_MASK, rsp->ctx);
> | ^
> /tmp/next/build/drivers/misc/fastrpc.c:2735:4: error: format specifies type 'unsigned long long' but the argument has type 'int' [-Werror,-Wformat]
> 2733 | "Stale glink response ctx 0x%llx (expected seq 0x%llx), dropping\n",
> | ~~~~
> | %x
> 2734 | rsp->ctx,
> 2735 | FIELD_GET(FASTRPC_CTXID_SEQ_MASK, ctx->ctxid));
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /tmp/next/build/include/linux/dev_printk.h:165:39: note: expanded from macro 'dev_dbg'
> 165 | dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
> | ~~~ ^~~~~~~~~~~
> /tmp/next/build/include/linux/dynamic_debug.h:285:19: note: expanded from macro 'dynamic_dev_dbg'
> 285 | dev, fmt, ##__VA_ARGS__)
> | ~~~ ^~~~~~~~~~~
> /tmp/next/build/include/linux/dynamic_debug.h:261:59: note: expanded from macro '_dynamic_func_call'
> 261 | _dynamic_func_call_cls(_DPRINTK_CLASS_DFLT, fmt, func, ##__VA_ARGS__)
> | ^~~~~~~~~~~
> /tmp/next/build/include/linux/dynamic_debug.h:259:65: note: expanded from macro '_dynamic_func_call_cls'
> 259 | __dynamic_func_call_cls(__UNIQUE_ID(ddebug), cls, fmt, func, ##__VA_ARGS__)
> | ^~~~~~~~~~~
> /tmp/next/build/include/linux/dynamic_debug.h:231:15: note: expanded from macro '__dynamic_func_call_cls'
> 231 | func(&id, ##__VA_ARGS__); \
> | ^~~~~~~~~~~
> 4 errors generated.
>
>
> Caused by commit
>
> 10555ba6126ed (misc: fastrpc: Replace hardcoded ctxid mask with GENMASK)
>
> (and one of the subsequent ones that also uses those macros). I have
> use the tree from next-20260723 instead.
^ permalink raw reply
* Re: linux-next: manual merge of the liveupdate tree with the mm-unstable tree
From: Mike Rapoport @ 2026-07-29 6:06 UTC (permalink / raw)
To: Andrew Morton
Cc: Mark Brown, Pasha Tatashin, Pratyush Yadav,
Linux Kernel Mailing List, Linux Next Mailing List, Muchun Song,
Muchun Song
In-Reply-To: <20260728134333.906cb26da4b6dec083b21344@linux-foundation.org>
On Tue, Jul 28, 2026 at 01:43:33PM -0700, Andrew Morton wrote:
> On Tue, 28 Jul 2026 20:38:54 +0300 Mike Rapoport <rppt@kernel.org> wrote:
>
> > I've got this for merging mm-unstable into liveupdate/next:
> >
> > diff --cc mm/hugetlb.c
> > index ab4afc818e8cb,a77c3c1cb8943..0000000000000
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
>
> Well that's a pain.
Once resolved it stops being a pain :)
> I'll get the series "mm: Refactor bootmem gigantic
> hugepage allocation" into mm-stable in the next couple of days. Can we
> then make this issue go away?
I can base the conflicting KHO work on mm-stable.
But if mm-stable is rebased we'd be in a bigger trouble.
Ideally we'd have a stable branch in mm tree that only contains "mm:
Refactor bootmem gigantic hugepage allocation" series and then this branch
would be easily merged into mm-stable and into liveupdate tree.
I'm going to keep liveupdate tree as it is for a couple of days and when
Pratyush sends the updated version we can resync again.
--
Sincerely yours,
Mike.
^ permalink raw reply
* [STATUS] next/master - 3652b49adac266a3d27cb41cdfdb7d8790fc3633
From: KernelCI bot @ 2026-07-29 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: linux-next
Hello,
Status summary for next/master
Dashboard:
https://d.kernelci.org/c/next/master/3652b49adac266a3d27cb41cdfdb7d8790fc3633/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: 3652b49adac266a3d27cb41cdfdb7d8790fc3633
origin: maestro
test start time: 2026-07-28 19:01:24.366000+00:00
Builds: 72 ✅ 2 ❌ 0 ⚠️
Boots: 156 ✅ 3 ❌ 0 ⚠️
Tests: 28466 ✅ 2544 ❌ 5526 ⚠️
### POSSIBLE REGRESSIONS
Hardware: bcm2837-rpi-3-b-plus
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a6919f1798ea6c1ef80582d
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a694687798ea6c1ef82fade
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a694687798ea6c1ef82fadd
history: > ✅ > ❌ > ❌ > ❌ > ❌
Hardware: meson-g12b-a311d-khadas-vim3
> Config: defconfig+preempt_rt
- Architecture/compiler: arm64/gcc-14
- rt-tests.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a690625798ea6c1ef7f73b0
history: > ✅ > ✅ > ❌ > ❌ > ❌
- rt-tests.rt-migrate-test.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a6906a3798ea6c1ef7f79c4
history: > ✅ > ✅ > ❌ > ❌ > ❌
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.devices-exist
last run: https://d.kernelci.org/test/maestro:6a691a75798ea6c1ef807ba9
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.devices-probe
last run: https://d.kernelci.org/test/maestro:6a691a83798ea6c1ef8087eb
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a691a26798ea6c1ef805cc4
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a692ccb798ea6c1ef821458
history: > ✅ > ✅ > ✅ > ❌
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a691a35798ea6c1ef805d09
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a692d06798ea6c1ef8219ed
history: > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a692d06798ea6c1ef8219ec
history: > ✅ > ❌ > ❌ > ❌
Hardware: qcs9100-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_display-controller_22001000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcfc
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcf7
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_display-controller_ae01000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcf6
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_dsi_ae94000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcf1
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_dsi_ae96000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcef
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_ae94400
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcee
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_ae96400
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fced
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_i2c-mux_70_i2c_0_bridge_58
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fccf
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_i2c-mux_70_i2c_1_bridge_58
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcce
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_serial_88c000_bluetooth
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fccc
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pcie_1c00000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcad
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pcie_1c00000_pcie_0
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcac
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_video-codec_aa00000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc29
history: > ✅ > ✅ > ✅ > ❌ > ❌
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a691a36798ea6c1ef805d14
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a694e5f798ea6c1ef83490a
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a694e5f798ea6c1ef834909
history: > ✅ > ❌ > ❌ > ❌ > ❌
Hardware: sm8750-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a691a38798ea6c1ef805d17
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a69274d798ea6c1ef81b737
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a69274d798ea6c1ef81b736
history: > ✅ > ❌ > ❌ > ❌ > ❌
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_9800000
last run: https://d.kernelci.org/test/maestro:6a6927f1798ea6c1ef81bcc8
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_9800000_display-controller_9801000
last run: https://d.kernelci.org/test/maestro:6a6927f1798ea6c1ef81bcc7
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_9800000_dsi_9ac0000
last run: https://d.kernelci.org/test/maestro:6a6927f1798ea6c1ef81bcc5
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_9800000_dsi_9ac0000_panel_0
last run: https://d.kernelci.org/test/maestro:6a6927f1798ea6c1ef81bcc3
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_9800000_phy_9ac1000
last run: https://d.kernelci.org/test/maestro:6a6927f1798ea6c1ef81bcc2
history: > ✅ > ✅ > ✅ > ❌
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a691a39798ea6c1ef805d21
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a692906798ea6c1ef81c742
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a692906798ea6c1ef81c741
history: > ✅ > ❌ > ❌ > ❌ > ❌
Hardware: qcs615-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a691a33798ea6c1ef805d03
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a693aad798ea6c1ef825dcb
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a693aad798ea6c1ef825dca
history: > ✅ > ❌ > ❌ > ❌ > ❌
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.coredump
last run: https://d.kernelci.org/test/maestro:6a6919f8798ea6c1ef805a65
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.device-error-logs
last run: https://d.kernelci.org/test/maestro:6a691a0d798ea6c1ef805bcd
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a691a34798ea6c1ef805d06
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a692c0a798ea6c1ef820f10
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a692c0a798ea6c1ef820f21
history: > ✅ > ❌ > ❌ > ❌ > ❌
Hardware: lemans-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_audio-codec-0
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef830007
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_audio-codec-1
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef830006
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_reboot-mode
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffe2
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_regulator-usb0-vbus
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffe0
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_regulator-usb1-vbus
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffdf
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_regulator-vreg-sdc
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffdc
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_clock-controller_abf0000
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffcf
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_clock-controller_ade0000
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffce
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_clock-controller_af00000
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffcd
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffb1
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_gpio_38
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffae
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_gpio_39
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffad
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_gpio_3a
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffac
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_gpio_3b
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffab
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_gpu_3d00000
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ff9b
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pmu_9091000
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ff77
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pmu_90b5400
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ff75
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pmu_90b6400
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ff73
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_regulator_891c000
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ff71
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_21c00000
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ff6b
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_26300000
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ff66
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_2a300000
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ff5a
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_30000000
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82ff4a
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7100
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82ff31
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1200
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82ff30
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1200_pwrkey
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82ff2f
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1200_resin
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82ff2e
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_rtc_6100
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82ff2d
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82ff2c
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_2_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82ff29
history: > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_4_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82ff26
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_6_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82ff23
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_sram_c3f0000
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82ff20
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_system-cache-controller_9200000
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82ff1d
history: > ✅ > ✅ > ✅ > ❌
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a691a3a798ea6c1ef805d24
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a6948e2798ea6c1ef830262
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a6948e2798ea6c1ef830261
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a691a48798ea6c1ef805dea
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.timers.timers_nanosleep
last run: https://d.kernelci.org/test/maestro:6a694b39798ea6c1ef830887
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.timers.timers_nanosleep_CLOCK_REALTIME
last run: https://d.kernelci.org/test/maestro:6a694b39798ea6c1ef830888
history: > ✅ > ✅ > ✅ > ✅ > ❌
### FIXED REGRESSIONS
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.device-error-logs
last run: https://d.kernelci.org/test/maestro:6a691a0e798ea6c1ef805bd4
history: > ❌ > ❌ > ❌ > ❌ > ✅
Hardware: qcs9100-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a6919b9798ea6c1ef804d6d
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a6940fc798ea6c1ef82e770
history: > ❌ > ✅ > ✅ > ✅ > ✅
Hardware: qcs615-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a6919b5798ea6c1ef804af1
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a692f5f798ea6c1ef822288
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a691a24798ea6c1ef805cb6
history: > ❌ > ✅ > ✅ > ✅
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a69389f798ea6c1ef8257c7
history: > ❌ > ✅ > ✅ > ✅
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_reboot-mode
last run: https://d.kernelci.org/test/maestro:6a692aa7798ea6c1ef8201c8
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_edp_aea0000
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef8201a1
history: > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec2a00
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef82019e
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_9c0000_serial_99c000_bluetooth
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820180
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_phy_88e8000
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef82015c
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_adc_3100
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820127
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_adc-tm_3400
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820128
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7000
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820125
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7100
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820124
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7400
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820123
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7c00
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820122
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7d00
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820121
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_8400
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820120
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_8500
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef82011f
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_8600
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef82011e
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_9800
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef82011d
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_9d00
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef82011c
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1300
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef82011b
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1300_pwrkey
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef82011a
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1300_resin
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820119
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_rtc_6100
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820118
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_1_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820115
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_2_pwm
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820112
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_2_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef820111
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_8_adc_3100
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef82010f
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_8_temp-alarm_2400
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef82010d
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_usb_a600000
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef8200ec
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_video-codec_aa00000
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef8200eb
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_wcn6750-pmu
last run: https://d.kernelci.org/test/maestro:6a692aa6798ea6c1ef8200e6
history: > ❌ > ✅ > ✅ > ✅ > ✅
Hardware: lemans-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a6919cc798ea6c1ef805199
history: > ❌ > ✅ > ✅
- kselftest.breakpoints.breakpoints_step_after_suspend_test
last run: https://d.kernelci.org/test/maestro:6a6943f6798ea6c1ef82f2bc
history: > ❌ > ✅
- kselftest.device-error-logs
last run: https://d.kernelci.org/test/maestro:6a691a08798ea6c1ef805bbd
history: > ❌ > ❌ > ❌ > ❌ > ✅
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a691a2b798ea6c1ef805cd3
history: > ❌ > ❌ > ❌ > ❌ > ✅
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a6947d0798ea6c1ef82fecb
history: > ❌ > ❌ > ❌ > ❌ > ✅
### UNSTABLE TESTS
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.alsa.alsa_mixer-test_event_spurious_wm8960audio_59
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822e44
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.alsa.alsa_mixer-test_event_spurious_wm8960audio_62
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822e59
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.alsa.alsa_mixer-test_name_wm8960audio_61
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822e57
history: > ❌ > ✅ > ❌ > ❌ > ❌
- kselftest.alsa.alsa_mixer-test_name_wm8960audio_62
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822e5e
history: > ❌ > ✅ > ❌ > ❌ > ❌
- kselftest.alsa.alsa_mixer-test_name_wm8960audio_63
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822e65
history: > ❌ > ✅ > ❌ > ❌ > ❌
- kselftest.alsa.alsa_mixer-test_name_wm8960audio_64
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822e6c
history: > ❌ > ✅ > ❌ > ❌ > ❌
- kselftest.alsa.alsa_mixer-test_write_default_wm8960audio_70
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822e95
history: > ❌ > ✅ > ❌ > ❌ > ❌
- kselftest.alsa.alsa_mixer-test_write_default_wm8960audio_72
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822ea3
history: > ❌ > ✅ > ❌ > ❌ > ❌
- kselftest.alsa.alsa_mixer-test_write_invalid_wm8960audio_69
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822e8c
history: > ⚠️ > ✅ > ⚠️ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_invalid_wm8960audio_70
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822e93
history: > ⚠️ > ✅ > ⚠️ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_invalid_wm8960audio_71
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822e9a
history: > ⚠️ > ✅ > ⚠️ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_invalid_wm8960audio_72
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822ea1
history: > ⚠️ > ✅ > ⚠️ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_valid_wm8960audio_69
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822e8d
history: > ⚠️ > ✅ > ⚠️ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_valid_wm8960audio_70
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822e94
history: > ⚠️ > ✅ > ⚠️ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_valid_wm8960audio_71
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822e9b
history: > ⚠️ > ✅ > ⚠️ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_valid_wm8960audio_72
last run: https://d.kernelci.org/test/maestro:6a693215798ea6c1ef822ea2
history: > ⚠️ > ✅ > ⚠️ > ⚠️ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_sound-wm8960
last run: https://d.kernelci.org/test/maestro:6a693eb7798ea6c1ef82934a
history: > ✅ > ✅ > ✅ > ❌ > ✅
Hardware: imx8mp-verdin-nonwifi-dahlia
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_bus_30800000_i2c_30a50000_eeprom_50
last run: https://d.kernelci.org/test/maestro:6a692d33798ea6c1ef821c12
history: > ✅ > ✅ > ❌ > ✅
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.clone3
last run: https://d.kernelci.org/test/maestro:6a6919eb798ea6c1ef805801
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.coredump
last run: https://d.kernelci.org/test/maestro:6a692af0798ea6c1ef82027c
history: > ❌ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_display-controller_ae01000
last run: https://d.kernelci.org/test/maestro:6a692be5798ea6c1ef820d6a
history: > ✅ > ❌ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_displayport-controller_af54000
last run: https://d.kernelci.org/test/maestro:6a692be5798ea6c1ef820d68
history: > ✅ > ❌ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_dsi_ae94000
last run: https://d.kernelci.org/test/maestro:6a692be5798ea6c1ef820d66
history: > ✅ > ❌ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000_mdio_phy_8
last run: https://d.kernelci.org/test/maestro:6a692be5798ea6c1ef820d5e
history: > ✅ > ⚠️ > ⚠️ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_ac0000_i2c_a80000_i2c-mux_70_i2c_0_bridge_58
last run: https://d.kernelci.org/test/maestro:6a692be5798ea6c1ef820d3d
history: > ✅ > ❌ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pci_1c00000
last run: https://d.kernelci.org/test/maestro:6a692be5798ea6c1ef820d24
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_usb_a600000
last run: https://d.kernelci.org/test/maestro:6a692be5798ea6c1ef820cae
history: > ✅ > ❌ > ✅ > ✅
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.ring-buffer
last run: https://d.kernelci.org/test/maestro:6a690a71798ea6c1ef7f9893
history: > ❌ > ✅ > ❌ > ❌ > ❌
Hardware: qcs9100-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.devices-probe
last run: https://d.kernelci.org/test/maestro:6a691a84798ea6c1ef8087ee
history: > ❌ > ❌ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_reboot-mode
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fd11
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_clock-controller_abf0000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fd05
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_clock-controller_ade0000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fd04
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_clock-controller_af00000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fd03
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_cti_4b13000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcfe
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcfd
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_displayport-controller_22154000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcfb
history: > ✅ > ❌ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_displayport-controller_2215c000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcfa
history: > ✅ > ❌ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_phy_220c2a00
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcf9
history: > ✅ > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_phy_220c5a00
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcf8
history: > ✅ > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_displayport-controller_af54000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcf4
history: > ✅ > ❌ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_displayport-controller_af5c000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcf2
history: > ✅ > ❌ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec2a00
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcec
history: > ✅ > ❌ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec5a00
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fceb
history: > ✅ > ❌ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23000000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fce8
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fce7
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000_mdio_phy_8
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fce5
history: > ✅ > ✅ > ✅ > ⚠️ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000_mdio_phy_a
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fce4
history: > ✅ > ✅ > ✅ > ⚠️ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_4041000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcdb
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_4042000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcda
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_4045000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcd9
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_4ad4000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcd8
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_4b04000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcd7
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_4b83000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcd6
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_6800000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcd5
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_6810000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcd4
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcd2
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_gpio_74
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcd1
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_i2c-mux_70
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcd0
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_ac0000_i2c_a90000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcc9
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_gpu_3d00000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcc4
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pcie_1c00000_pcie_0_wifi_0
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fcab
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_20c00000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc97
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_21c00000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc92
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_26300000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc8d
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_2a300000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc81
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_30000000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc72
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_replicator_4046000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc68
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_replicator_404e000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc67
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_replicator_4b06000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc66
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7100
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc59
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1200
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc58
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1200_pwrkey
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc57
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1200_resin
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc56
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_rtc_6100
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc55
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc54
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_2_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc51
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_4_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc4e
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_6_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc4b
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_sram_c3f0000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc48
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_stm_4002000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc47
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_system-cache-controller_9200000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc45
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_tmc_4048000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc3f
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_tmc_404f000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc3e
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_tmc_4b05000
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc3d
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_wcn6855-pmu
last run: https://d.kernelci.org/test/maestro:6a694740798ea6c1ef82fc1d
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.exec
last run: https://d.kernelci.org/test/maestro:6a691aa3798ea6c1ef808dde
history: > ❌ > ❌ > ❌ > ✅ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.efivars
last run: https://d.kernelci.org/test/maestro:6a690a29798ea6c1ef7f9544
history: > ❌ > ✅ > ❌ > ❌ > ❌
- kselftest.ring-buffer
last run: https://d.kernelci.org/test/maestro:6a690a72798ea6c1ef7f9896
history: > ❌ > ✅ > ❌ > ❌ > ❌
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a6919bb798ea6c1ef805082
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a6923cd798ea6c1ef8144b7
history: > ✅ > ✅ > ✅ > ❌ > ✅
Hardware: qcs615-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a6919c5798ea6c1ef8050f9
history: > ❌ > ✅ > ❌ > ❌ > ❌
- kselftest.breakpoints.breakpoints_step_after_suspend_test
last run: https://d.kernelci.org/test/maestro:6a6930ae798ea6c1ef8227e4
history: > ❌ > ✅ > ❌ > ❌ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.efivars
last run: https://d.kernelci.org/test/maestro:6a690a26798ea6c1ef7f9530
history: > ❌ > ❌ > ❌ > ✅ > ❌
- kselftest.ring-buffer
last run: https://d.kernelci.org/test/maestro:6a690a6e798ea6c1ef7f9887
history: > ❌ > ❌ > ✅ > ❌
Hardware: qcs6490-rb3gen2
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a690a44798ea6c1ef7f968a
history: > ❌ > ❌ > ❌ > ✅ > ❌
Hardware: lemans-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.devices-exist
last run: https://d.kernelci.org/test/maestro:6a691a6f798ea6c1ef806bc3
history: > ❌ > ❌ > ✅ > ❌ > ❌
- kselftest.devices-probe
last run: https://d.kernelci.org/test/maestro:6a694d8b798ea6c1ef833d31
history: > ❌ > ❌ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec5a00
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffcb
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffc5
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000_mdio_ethernet-phy_1c
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffc3
history: > ✅ > ⚠️ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_eeprom_50
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffb0
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_eeprom_50_nvmem-layout
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffaf
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_serial_88c000_bluetooth
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffa7
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_spi_888000
last run: https://d.kernelci.org/test/maestro:6a6947e3798ea6c1ef82ffa6
history: > ❌ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_usb_a800000_hub_2
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82ff00
history: > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_video-codec_aa00000
last run: https://d.kernelci.org/test/maestro:6a6947e2798ea6c1ef82feff
history: > ✅ > ❌ > ✅ > ❌
- kselftest.timers.timers_inconsistency-check_CLOCK_BOOTTIME_ALARM
last run: https://d.kernelci.org/test/maestro:6a694b39798ea6c1ef830871
history: > ✅ > ✅ > ⚠️ > ✅ > ✅
- kselftest.timers.timers_inconsistency-check_CLOCK_REALTIME_ALARM
last run: https://d.kernelci.org/test/maestro:6a694b39798ea6c1ef830872
history: > ✅ > ✅ > ⚠️ > ✅ > ✅
- kselftest.timers.timers_nsleep-lat_CLOCK_BOOTTIME_ALARM
last run: https://d.kernelci.org/test/maestro:6a694b39798ea6c1ef83087f
history: > ✅ > ✅ > ⚠️ > ✅ > ✅
- kselftest.timers.timers_nsleep-lat_CLOCK_REALTIME_ALARM
last run: https://d.kernelci.org/test/maestro:6a694b39798ea6c1ef830880
history: > ✅ > ✅ > ⚠️ > ✅ > ✅
This branch has 1 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Theodore Tso @ 2026-07-29 1:46 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Miguel Ojeda, Mark Brown, Leandro Ribeiro, Pekka Paalanen,
Daniel Stone, Alexander Potapenko, Christoph Hellwig,
Aleksandr Nogikh, Boqun Feng, Gary Guo, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh
In-Reply-To: <bff95de5-7f0b-4f08-8ceb-58a6e354ebe2@I-love.SAKURA.ne.jp>
On Wed, Jul 29, 2026 at 08:46:16AM -0500, Tetsuo Handa wrote:
> >
> > i.e. I was wondering whether the system could ignore the "WARNING:"s
> > (and avoid the kernel panicking on them etc.) until after boot, i.e.
> > when the fuzzing starts.
It could, but it would involve making a change in syzbot.
Specifically, syzbot would have to be changed to boot the kernel being
tested without the kernel.panic_on_warn=1 boot command line function,
and then in the syzbot reproducer, to add the moral equivalent of
echo 1 > /proc/sys/kernel/panic_on_warn
> Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format
> with alpha exposed") must be reverted or updated not to emit "WARNING:" string.
> Until authors of that commit respond, that commit had better be excluded from
> the linux-next tree.
There appears to be a fix which has been reviewed; I found it by
searching lore.kernel.org for the string "drm: ensure blend mode":
https://lore.kernel.org/all/CAPM=9txcOcnnxznq41z8+FA_V2BCqmRKFZBOt0oEhcHbBs8Fsg@mail.gmail.com/
- Ted
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Tetsuo Handa @ 2026-07-28 23:46 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Mark Brown, Leandro Ribeiro, Pekka Paalanen, Daniel Stone,
Theodore Tso, Alexander Potapenko, Christoph Hellwig,
Aleksandr Nogikh, Boqun Feng, Gary Guo, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh
In-Reply-To: <CANiq72kcrJw4Kt=5zTN9vvnDq33_4NV4AZ3jHTFNBJjVxmU+8Q@mail.gmail.com>
On 2026/07/29 7:11, Miguel Ojeda wrote:
> On Tue, Jul 28, 2026 at 4:46 PM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>
>> syzbot stops upon encountering "BUG:" or "WARNING:" within printk() output.
>
> Out of curiosity, is that a fundamental property or something that
> could be optionally be relaxed (for certain linux-next runs only,
> perhaps) so that you can continue testing in certain cases where the
> "WARNING:" may be harmless (i.e. irrelevant for your particular
> fuzzing)?
>
> i.e. I was wondering whether the system could ignore the "WARNING:"s
> (and avoid the kernel panicking on them etc.) until after boot, i.e.
> when the fuzzing starts.
syzbot uses kernel.panic_on_warn=1, for most of WARN*() users are reporting
problems that should not be ignored. Therefore, WARN*() must not be used for
reporting recoverable mistakes like -EINVAL. Abusing WARN*() like
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/kernel/workqueue.c?id=6e845bcb78c95af935094040bd4edc3c2b6dd784#n5855
is a fatal barrier for continuous testing systems like syzbot.
Quoting from https://lkml.kernel.org/r/5b2dea50-2850-4876-b6e8-ba94b9a85034@I-love.SAKURA.ne.jp :
Please never try to emit WARNING: or BUG: message just for letting developers
update their code. If you can't use panic() instead of WARN*() or BUG*(), you
should not use WARN*() or BUG*(). The patch author who changes the behavior of
in-tree code is responsible for updating all in-tree code.
Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format
with alpha exposed") must be reverted or updated not to emit "WARNING:" string.
Until authors of that commit respond, that commit had better be excluded from
the linux-next tree.
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Miguel Ojeda @ 2026-07-28 22:11 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Mark Brown, Leandro Ribeiro, Pekka Paalanen, Daniel Stone,
Theodore Tso, Alexander Potapenko, Christoph Hellwig,
Aleksandr Nogikh, Boqun Feng, Gary Guo, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh
In-Reply-To: <cba31f88-09f2-443f-ab0f-b2b263750947@I-love.SAKURA.ne.jp>
On Tue, Jul 28, 2026 at 4:46 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> syzbot stops upon encountering "BUG:" or "WARNING:" within printk() output.
Out of curiosity, is that a fundamental property or something that
could be optionally be relaxed (for certain linux-next runs only,
perhaps) so that you can continue testing in certain cases where the
"WARNING:" may be harmless (i.e. irrelevant for your particular
fuzzing)?
i.e. I was wondering whether the system could ignore the "WARNING:"s
(and avoid the kernel panicking on them etc.) until after boot, i.e.
when the fuzzing starts.
Cheers,
Miguel
^ permalink raw reply
* Re: linux-next: manual merge of the sysctl tree with the mm-nonmm-unstable tree
From: Andrew Morton @ 2026-07-28 20:47 UTC (permalink / raw)
To: Mark Brown
Cc: Luis Chamberlain, Kees Cook, Joel Granados,
Linux Kernel Mailing List, Linux Next Mailing List, Oleg Nesterov
In-Reply-To: <amjpZ1aYsps44ExZ@sirena.org.uk>
On Tue, 28 Jul 2026 18:39:51 +0100 Mark Brown <broonie@kernel.org> wrote:
> Today's linux-next merge of the sysctl tree got a conflict in:
>
> kernel/time/jiffies.c
>
> between commit:
>
> 842912dea6d51 ("sysctl: remove CONFIG_PROC_SYSCTL, it just mirrors CONFIG_SYSCTL")
>
> from the mm-nonmm-unstable tree and commit:
>
> a3c70a5a9f944 ("sysctl: Generate do_proc_doulongvec_minmax with do_proc_dotypevec macro")
>
> from the sysctl tree.
Luis, can you please grab both
sysctl: move the "cad_pid" entry from pid_table[] to kern_reboot_table[]
https://lore.kernel.org/al4C572uhLdBvyzH@redhat.com
and
sysctl: remove CONFIG_PROC_SYSCTL, it just mirrors CONFIG_SYSCTL
https://lore.kernel.org/amdveg1m4E4uQlGv@redhat.com
I'll email them at you...
^ permalink raw reply
* Re: linux-next: manual merge of the liveupdate tree with the mm-unstable tree
From: Andrew Morton @ 2026-07-28 20:43 UTC (permalink / raw)
To: Mike Rapoport
Cc: Mark Brown, Pasha Tatashin, Pratyush Yadav,
Linux Kernel Mailing List, Linux Next Mailing List, Muchun Song,
Muchun Song
In-Reply-To: <amjpLoJbHsqIAqJO@kernel.org>
On Tue, 28 Jul 2026 20:38:54 +0300 Mike Rapoport <rppt@kernel.org> wrote:
> I've got this for merging mm-unstable into liveupdate/next:
>
> diff --cc mm/hugetlb.c
> index ab4afc818e8cb,a77c3c1cb8943..0000000000000
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
Well that's a pain. I'll get the series "mm: Refactor bootmem gigantic
hugepage allocation" into mm-stable in the next couple of days. Can we
then make this issue go away?
^ permalink raw reply
* linux-next: Tree for Jul 28
From: Mark Brown @ 2026-07-28 18:48 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]
Hi all,
Changes since 20260727:
The vfs-brauner tree lost it's build failure but acquired a new one so I
continued to use the tree from next-20260723.
The bluetooth tree acquired a conflict with the origin tree.
The liveupdate tree acquired a conflict with the mm-unstable tree, due
to the complexity of the conflict I merged the liveupate tree from
next-20260727 instead and will review tomorrow.
The thunderbolt tree lost it's build failure.
The staging tree acquired a conflict with the staging.current tree.
The sysctl tree acquired a conflict with the mm-nonmm-unstable tree.
Non-merge commits (relative to Linus' tree): 8877
8224 files changed, 400410 insertions(+), 126960 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at https://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There is also the merge.log file in the Next
directory. Between each merge, the tree was built with a defconfig
for arm64, an allmodconfig for x86_64, a multi_v7_defconfig for arm,
an arm64 build of various kselftests, a KUnit build and run on arm64,
and a native build of tools/perf. After the final fixups (if any), I do
an x86_64 modules_install followed by builds for x86_64 allnoconfig,
arm64 allyesconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig and pseries_le_defconfig and i386, s390, sparc and
sparc64 defconfig and htmldocs.
Below is a summary of the state of the merge.
I am currently merging 429 trees (counting Linus' and 133 trees of bug
fix patches pending for the current release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Thanks to Paul Gortmaker for triage and bug fixes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the liveupdate tree with the mm-unstable tree
From: Mark Brown @ 2026-07-28 17:56 UTC (permalink / raw)
To: Mike Rapoport
Cc: Andrew Morton, Pasha Tatashin, Pratyush Yadav,
Linux Kernel Mailing List, Linux Next Mailing List, Muchun Song,
Muchun Song
In-Reply-To: <amjpLoJbHsqIAqJO@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
On Tue, Jul 28, 2026 at 08:38:54PM +0300, Mike Rapoport wrote:
> On Tue, Jul 28, 2026 at 05:27:05PM +0100, Mark Brown wrote:
> > of liveupdate from next-20260727, I'll have another look tomorrow but
> > would really appreciate it if someone could help out here.
> I've got this for merging mm-unstable into liveupdate/next:
Thanks Mike, all being well I'll go with that tomorrow.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
page: next (older)
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox