* Re: [PATCH] Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array
From: patchwork-bot+bluetooth @ 2026-04-02 17:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: marcel, luiz.dentz, matthias.bgg, angelogioacchino.delregno,
floss, arnd, chris.lu, kees, johan, sean.wang, jiande.lu,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260402141119.2732591-1-arnd@kernel.org>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Thu, 2 Apr 2026 16:11:15 +0200 you wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When USB support is disabled, the array is not referenced anywhere,
> causing a warning:
>
> drivers/bluetooth/btmtk.c:35:3: error: 'btmtk_mt6639_devs' defined but not used [-Werror=unused-const-variable=]
> 35 | } btmtk_mt6639_devs[] = {
> | ^~~~~~~~~~~~~~~~~
>
> [...]
Here is the summary with links:
- Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array
https://git.kernel.org/bluetooth/bluetooth-next/c/a6e00a811c87
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 1/3] selftests/resctrl: Introduced linked list management for IMC counters
From: Reinette Chatre @ 2026-04-02 17:42 UTC (permalink / raw)
To: Yifan Wu, tony.luck, Dave.Martin, james.morse, babu.moger, shuah,
tan.shaopeng, fenghuay, ben.horgan, jonathan.cameron, zengheng4,
linux-kernel, linux-arm-kernel, linux-kselftest, linuxarm
Cc: xiaqinxin, prime.zeng, wangyushan12, xuwei5, fanghao11, wangzhou1
In-Reply-To: <20260324125034.1509177-2-wuyifan50@huawei.com>
Hi Yifan,
On 3/24/26 5:50 AM, Yifan Wu wrote:
> Added linked list based management for IMC counter configurations,
> allowing the system to dynamically allocate and clean up resources based on
> actual hardware capabilities.
Thank you very much for taking on this change, this is a good addition.
One note on the customs, even though this is user space code it is the Linux kernel
developers that work with it mostly and to support this the style is expected to
(as much as possible) match kernel coding style. Specifically related to this, please
follow coding and changelog guidance in Documentation/process/coding-style.rst and
Documentation/process/maintainer-tip.rst.
>
> Signed-off-by: Yifan Wu <wuyifan50@huawei.com>
> ---
> tools/testing/selftests/resctrl/resctrl.h | 1 +
> tools/testing/selftests/resctrl/resctrl_val.c | 25 +++++++++++++++++++
> 2 files changed, 26 insertions(+)
>
> diff --git a/tools/testing/selftests/resctrl/resctrl.h b/tools/testing/selftests/resctrl/resctrl.h
> index 175101022bf3..29c9f76132f0 100644
> --- a/tools/testing/selftests/resctrl/resctrl.h
> +++ b/tools/testing/selftests/resctrl/resctrl.h
> @@ -24,6 +24,7 @@
> #include <linux/perf_event.h>
> #include <linux/compiler.h>
> #include <linux/bits.h>
> +#include <linux/list.h>
(extra space)
> #include "kselftest.h"
>
> #define MB (1024 * 1024)
> diff --git a/tools/testing/selftests/resctrl/resctrl_val.c b/tools/testing/selftests/resctrl/resctrl_val.c
> index f20d2194c35f..ac58d3862281 100644
> --- a/tools/testing/selftests/resctrl/resctrl_val.c
> +++ b/tools/testing/selftests/resctrl/resctrl_val.c
> @@ -28,6 +28,7 @@ struct membw_read_format {
> };
>
> struct imc_counter_config {
> + struct list_head imc_list;
To make it obvious that this is an entry/node of a list as opposed to a list
header, please use a name like "entry" or "node" or similar.
> __u32 type;
> __u64 event;
> __u64 umask;
> @@ -38,6 +39,7 @@ struct imc_counter_config {
> static char mbm_total_path[1024];
> static int imcs;
> static struct imc_counter_config imc_counters_config[MAX_IMCS];
> +LIST_HEAD(imc_counters_configs);
> static const struct resctrl_test *current_test;
>
> static void read_mem_bw_initialize_perf_event_attr(int i)
> @@ -235,6 +237,7 @@ static int read_from_imc_dir(char *imc_dir, unsigned int *count)
> */
> static int num_of_imcs(void)
> {
> + struct imc_counter_config *imc_counters_config;
Please avoid variable shadowing.
> char imc_dir[512], *temp;
> unsigned int count = 0;
> struct dirent *ep;
> @@ -263,14 +266,23 @@ static int num_of_imcs(void)
> * first character is a numerical digit or not.
> */
> if (temp[0] >= '0' && temp[0] <= '9') {
> + imc_counters_config = malloc(sizeof(struct imc_counter_config));
One example of the kernel coding style applied here (see "Allocating memory" in
Documentation/process/coding-style.rst) is to use pointer variable and
not typing out the struct.
Even so, this does not look to be the right place to do this allocation ... (more below)
> + if (!imc_counters_config) {
> + ksft_print_msg("Unable to allocate memory for iMC counters\n");
> +
> + return -1;
> + }
> + memset(imc_counters_config, 0, sizeof(struct imc_counter_config));
Please use calloc() instead of the malloc() followed by memset().
> sprintf(imc_dir, "%s/%s/", DYN_PMU_PATH,
> ep->d_name);
> ret = read_from_imc_dir(imc_dir, &count);
read_from_imc_dir() obtains "count", which is used as index to imc_counters_config[],
as reference because it increments this counter. Doing so enables read_from_imc_dir()
to initialize more than one array element.
Only allocating one element for the list thus does not look right and I would actually
expect this allocation to be closer to the initialization where it is known whether
a new element is needed or not. Having new list element allocation within
parse_imc_read_bw_events() looks more appropriate?
> if (ret) {
> + free(imc_counters_config);
> closedir(dp);
>
> return ret;
> }
> + list_add(&imc_counters_config->imc_list, &imc_counters_configs);
> }
> }
> closedir(dp);
> @@ -303,6 +315,19 @@ int initialize_read_mem_bw_imc(void)
> return 0;
> }
>
> +void cleanup_read_mem_bw_imc(void)
> +{
> + struct imc_counter_config *next_imc_counters_config;
This could just be "*tmp" to make its usage clear.
> + struct imc_counter_config *imc_counters_config;
I find the "imc_counters_configs" and "imc_counters_config" names too similar
for comfort and makes the code harder to follow. A short name that is obviously
different from the global list name will make the code much easier to read.
How about "imc_counter"?
> +
> + list_for_each_entry_safe(imc_counters_config, next_imc_counters_config,
> + &imc_counters_configs, imc_list) {
> + list_del(&imc_counters_config->imc_list);
> + free(imc_counters_config);
> + }
> + INIT_LIST_HEAD(&imc_counters_configs);
Why is INIT_LIST_HEAD() needed?
> +}
> +
> static void perf_close_imc_read_mem_bw(void)
> {
> int mc;
This patch allocates memory but never frees is. This is done later in patch #3
as a fix but that change would be better as part of this to make it easier to
consider the memory management.
Reinette
^ permalink raw reply
* Re: [PATCH 2/3] selftests/resctrl: Replace array-based IMC counter management with linked lists
From: Reinette Chatre @ 2026-04-02 17:44 UTC (permalink / raw)
To: Yifan Wu, tony.luck, Dave.Martin, james.morse, babu.moger, shuah,
tan.shaopeng, fenghuay, ben.horgan, jonathan.cameron, zengheng4,
linux-kernel, linux-arm-kernel, linux-kselftest, linuxarm
Cc: xiaqinxin, prime.zeng, wangyushan12, xuwei5, fanghao11, wangzhou1
In-Reply-To: <20260324125034.1509177-3-wuyifan50@huawei.com>
Hi Yifan,
On 3/24/26 5:50 AM, Yifan Wu wrote:
> Convert IMC counter management from static array to dynamic
> linked list allocation.
Could you please split this patch into two? One patch where utilities
receive pointer to array element instead of index as parameter and
another patch that switches the code to use a list?
>
> Signed-off-by: Yifan Wu <wuyifan50@huawei.com>
> ---
> tools/testing/selftests/resctrl/resctrl_val.c | 134 +++++++++---------
> 1 file changed, 66 insertions(+), 68 deletions(-)
>
> diff --git a/tools/testing/selftests/resctrl/resctrl_val.c b/tools/testing/selftests/resctrl/resctrl_val.c
> index ac58d3862281..417d87ba368a 100644
> --- a/tools/testing/selftests/resctrl/resctrl_val.c
> +++ b/tools/testing/selftests/resctrl/resctrl_val.c
> @@ -14,7 +14,6 @@
> #define READ_FILE_NAME "cas_count_read"
> #define DYN_PMU_PATH "/sys/bus/event_source/devices"
> #define SCALE 0.00006103515625
> -#define MAX_IMCS 40
> #define MAX_TOKENS 5
>
> #define CON_MBM_LOCAL_BYTES_PATH \
> @@ -38,36 +37,37 @@ struct imc_counter_config {
>
> static char mbm_total_path[1024];
> static int imcs;
> -static struct imc_counter_config imc_counters_config[MAX_IMCS];
> LIST_HEAD(imc_counters_configs);
> static const struct resctrl_test *current_test;
>
> -static void read_mem_bw_initialize_perf_event_attr(int i)
> +static void read_mem_bw_initialize_perf_event_attr(struct imc_counter_config *imc_counters_config)
In parameters also, please use a variable name used for element that is further
away from list header name. How about just "imc_counter" for the function parameter?
...
> @@ -112,10 +113,10 @@ static int open_perf_read_event(int i, int cpu_no)
> }
>
> static int parse_imc_read_bw_events(char *imc_dir, unsigned int type,
> - unsigned int *count)
> + struct imc_counter_config *imc_counters_config)
> {
> char imc_events_dir[PATH_MAX], imc_counter_cfg[PATH_MAX];
> - unsigned int orig_count = *count;
> + unsigned int orig_count = imcs;
Why is global imcs used/needed here? The intention behind orig_count is just to
check if any iMC counters were added by this function. Original code checked
by comparing the "before" and "after" array index but with a switch to a list this
can just be done locally, for example, with a boolean.
> char cas_count_cfg[1024];
> struct dirent *ep;
> int path_len;
> @@ -165,17 +166,13 @@ static int parse_imc_read_bw_events(char *imc_dir, unsigned int type,
> ksft_perror("Could not get iMC cas count read");
> goto out_close;
> }
> - if (*count >= MAX_IMCS) {
> - ksft_print_msg("Maximum iMC count exceeded\n");
> - goto out_close;
> - }
>
> - imc_counters_config[*count].type = type;
> - get_read_event_and_umask(cas_count_cfg, *count);
> - /* Do not fail after incrementing *count. */
> - *count += 1;
> + imc_counters_config->type = type;
> + get_read_event_and_umask(cas_count_cfg, imc_counters_config);
> + /* Do not fail after incrementing count. */
> + imcs++;
Note that this is a loop that may initialize more than one counter and since it
uses the single element provided as function parameter each new counter will just
overwrite the previous's settings.
As mentioned in patch #1 it looks more appropriate to allocate and initialize
new list entry here within parse_imc_read_bw_events().
> @@ -239,7 +236,7 @@ static int num_of_imcs(void)
> {
> struct imc_counter_config *imc_counters_config;
> char imc_dir[512], *temp;
> - unsigned int count = 0;
> + imcs = 0;
> struct dirent *ep;
> int ret;
> DIR *dp;
> @@ -275,7 +272,7 @@ static int num_of_imcs(void)
> memset(imc_counters_config, 0, sizeof(struct imc_counter_config));
> sprintf(imc_dir, "%s/%s/", DYN_PMU_PATH,
> ep->d_name);
> - ret = read_from_imc_dir(imc_dir, &count);
> + ret = read_from_imc_dir(imc_dir, imc_counters_config);
> if (ret) {
> free(imc_counters_config);
> closedir(dp);
> @@ -286,7 +283,7 @@ static int num_of_imcs(void)
> }
> }
> closedir(dp);
> - if (count == 0) {
> + if (imcs == 0) {
Is this global necessary? How about list_empty() instead?
> ksft_print_msg("Unable to find iMC counters\n");
>
> return -1;
> @@ -297,20 +294,22 @@ static int num_of_imcs(void)
> return -1;
> }
>
> - return count;
> + return imcs;
Looking at how the caller, initialize_read_mem_bw_imc() below, uses the return
value it does not seem necessary to track the number of entries anymore. Could the
global imcs just be dropped?
> }
>
> int initialize_read_mem_bw_imc(void)
> {
> - int imc;
> + int ret;
> + struct imc_counter_config *imc_counters_config;
>
> - imcs = num_of_imcs();
> - if (imcs <= 0)
> - return imcs;
> + ret = num_of_imcs();
> + if (ret <= 0)
> + return ret;
>
> /* Initialize perf_event_attr structures for all iMC's */
> - for (imc = 0; imc < imcs; imc++)
> - read_mem_bw_initialize_perf_event_attr(imc);
> + list_for_each_entry(imc_counters_config, &imc_counters_configs, imc_list) {
> + read_mem_bw_initialize_perf_event_attr(imc_counters_config);
> + }
>
> return 0;
> }
Reinette
^ permalink raw reply
* Re: [PATCH V3 7/7] arm64/hw_breakpoint: Enable FEAT_Debugv8p9
From: Rob Herring @ 2026-04-02 17:46 UTC (permalink / raw)
To: Mark Rutland
Cc: Anshuman Khandual, linux-arm-kernel, linux-kernel,
Jonathan Corbet, Marc Zyngier, Oliver Upton, James Morse,
Suzuki K Poulose, Catalin Marinas, Will Deacon, Mark Brown,
kvmarm
In-Reply-To: <ac5G8e4zWTdicDBs@J2N7QTR9R3>
On Thu, Apr 2, 2026 at 5:37 AM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Tue, Mar 31, 2026 at 05:58:00PM -0500, Rob Herring wrote:
> > On Mon, Dec 16, 2024 at 10:58:29AM +0000, Mark Rutland wrote:
> > > On Mon, Dec 16, 2024 at 09:38:31AM +0530, Anshuman Khandual wrote:
> > > > Currently there can be maximum 16 breakpoints, and 16 watchpoints available
> > > > on a given platform - as detected from ID_AA64DFR0_EL1.[BRPs|WRPs] register
> > > > fields. But these breakpoint, and watchpoints can be extended further up to
> > > > 64 via a new arch feature FEAT_Debugv8p9.
> > > >
> > > > This first enables banked access for the breakpoint and watchpoint register
> > > > set via MDSELR_EL1, extended exceptions via MDSCR_EL1.EMBWE and determining
> > > > available breakpoints and watchpoints in the platform from ID_AA64DFR1_EL1,
> > > > when FEAT_Debugv8p9 is enabled.
> > >
> > > [...]
> >
> > Well, this series has landed on my plate...
>
> Sorry about that; thanks for taking a look!
>
> > > > +static u64 read_wb_reg(int reg, int n)
> > > > +{
> > > > + unsigned long flags;
> > > > + u64 val;
> > > > +
> > > > + if (!is_debug_v8p9_enabled())
> > > > + return __read_wb_reg(reg, n);
> > > > +
> > > > + /*
> > > > + * Bank selection in MDSELR_EL1, followed by an indexed read from
> > > > + * breakpoint (or watchpoint) registers cannot be interrupted, as
> > > > + * that might cause misread from the wrong targets instead. Hence
> > > > + * this requires mutual exclusion.
> > > > + */
> > > > + local_irq_save(flags);
> > > > + write_sysreg_s(SYS_FIELD_PREP(MDSELR_EL1, BANK, n / MAX_PER_BANK), SYS_MDSELR_EL1);
> > > > + isb();
> > > > + val = __read_wb_reg(reg, n % MAX_PER_BANK);
> > > > + local_irq_restore(flags);
> > > > + return val;
> > > > +}
> > > > NOKPROBE_SYMBOL(read_wb_reg);
> > >
> > > I don't believe that disabling interrupts here is sufficient. On the
> > > last version I asked about the case of racing with a watchpoint handler:
> > >
> > > | For example, what prevents watchpoint_handler() from firing in the
> > > | middle of arch_install_hw_breakpoint() or
> > > | arch_uninstall_hw_breakpoint()?
> > >
> > > ... and disabling interrupts cannot prevent that, because
> > > local_irq_{save,restore}() do not affect the behaviour of watchpoints or
> > > breakpoints.
> >
> > I think the answer is we just need NOKPROBE_SYMBOL() annotation on
> > hw_breakpoint_control() (what arch_install_hw_breakpoint() and
> > arch_uninstall_hw_breakpoint() wrap).
>
> Ok. I couldn'y spot where we prevent placing HW breakpoints on
> NOKPROBE_SYMBOL() functions, but if we do enforce that, something like
> that sounds ok.
Uh, actually you are right. I think we need the equivalent to this in
arch_build_bp_info():
case HW_BREAKPOINT_X:
/*
* We don't allow kernel breakpoints in places that are not
* acceptable for kprobes. On non-kprobes kernels, we don't
* allow kernel breakpoints at all.
*/
if (attr->bp_addr >= TASK_SIZE_MAX) {
if (within_kprobe_blacklist(attr->bp_addr))
return -EINVAL;
}
The 2nd sentence is enforced by within_kprobe_blacklist() returning
true for !CONFIG_KPROBES. Seems like a reasonable restriction, but it
would be a change. Unfortunately, we can't move this to non-arch code
as some arches support h/w BP without supporting kprobes.
>
> I suspect we'd need to make that noinstr to also prevent ftrace
> instrumentation, unless ftrace also inhibits itself for
> NOKPROBE_SYMBOL() functions.
If we use NOKPROBE_SYMBOL() along with nokprobe_inline (which just
forces inlining functions), then ftrace could only be used on the
entry or exit of
arch_install_hw_breakpoint()/arch_uninstall_hw_breakpoint() which I
think would be fine.
>
> > We also need that on __read_wb_reg
> > and __read_wb_reg though I would think those are folded into the calling
> > functions by the compiler. Interestly, the x86 code doesn't use the
> > annotation at all.
>
> IIUC, it looks like they *can* take debug NMIs during
> arch_install_hw_breakpoint() and arch_uninstall_hw_breakpoint(), which
> is why they have ordering constraints for modifying the percpu 'cpu_dr7'
> variable, and their actual DR7 register (which IIUC has the enable
> controls for each HW breakpoint).
>
> That said, the use of 'bp_per_reg' looks suspect given their
> arch_install_hw_breakpoint() and arch_uninstall_hw_breakpoint() modify
> that non-atomically.
You don't believe the comment saying counter->ctx->lock is held?
> We could consider allowing breakpoints on those functions, but I'm not
> sure whether that's possible for us, and (as noted below) it might be
> better to transiently disable breakpoints/watchpoints.
Even if possible, is it all that useful? Easier to just disable than
reason whether it would work or not IMO.
> IIRC on x86, breakpoint exceptions are taken *after* execution of the
> instruction that triggered them, so the handler doesn't have to
> manipulate single-step, and can safely ignore a breakpoint exception
> without the risk of getting stuck taking the breakpoint repeatedly.
>
> > I initially thought the IRQ disabling is also still needed as IRQ
> > handlers can trigger breakpoints. However, the x86 version of
> > arch_install_hw_breakpoint() contains a lockdep_assert_irqs_disabled(),
> > so it seems for that case interrupts are already disabled. And in debug
> > exceptions, we disable interrupts. So I think the interrupt disabling
> > can be dropped.
>
> I'd expect that the core perf code disables interrupts before calling
> arch_install_hw_breakpoint() or arch_uninstall_hw_breakpoint(), and this
> would be necessary for perf to serialise against IPIs that manipulate
> the perf_event_context.
>
> I agree that when we actually take the breakpoint, we'll mask all
> exceptions, and so it's not necessary to mask IRQs there.
>
> So a first step is probably to add that lockdep assert.
>
> > > Please can you try to answer the questions I asked last time, i.e.
> > >
> > > | What prevents a race with an exception handler? e.g.
> > > |
> > > | * Does the structure of the code prevent that somehow?
> >
> > If you can't set a breakpoint/watchpoint in NOKPROBE_SYMBOL() annotated
> > code, you can't race.
>
> As above, I agree (with caveats), but I couldn't spot where this is
> enforced.
>
> > However, there's no such annotation for data. It looks like the kernel
> > policy is "don't do that" or disable all breakpoints/watchpoints.
>
> If we have to transiently disable watchpoints/breakpoints when
> manipulating the relevant HW registers, that sounds fine to me.
For wp/bp_on_reg, the ordering is 'data access, h/w accesses'. I think
we just need a barrier to enforce that ordering so the data access
(and then watchpoint) don't trigger in the middle of the h/w accesses.
Any guidance on the flavor of dsb here? (And is there any guarantee
that the access is visible to the watchpoint h/w after a dsb
completes?)
Rob
^ permalink raw reply
* Re: [PATCH v3 1/2] mailbox: Use per-thread completion to fix wrong completion order
From: Jassi Brar @ 2026-04-02 17:59 UTC (permalink / raw)
To: Joonwon Kang
Cc: matthias.bgg, angelogioacchino.delregno, thierry.reding,
jonathanh, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-tegra, stable
In-Reply-To: <20260402170641.2082547-2-joonwonkang@google.com>
On Thu, Apr 2, 2026 at 12:07 PM Joonwon Kang <joonwonkang@google.com> wrote:
>
> Previously, a sender thread in mbox_send_message() could be woken up at
> a wrong time in blocking mode. It is because there was only a single
> completion for a channel whereas messages from multiple threads could be
> sent in any order; since the shared completion could be signalled in any
> order, it could wake up a wrong sender thread.
>
> This commit resolves the false wake-up issue with the following changes:
> - Completions are created just as many as the number of concurrent sender
> threads
> - A completion is created on a sender thread's stack
> - Each slot of the message queue, i.e. `msg_data`, contains a pointer to
> its target completion
> - tx_tick() signals the completion of the currently active slot of the
> message queue
>
I think I reviewed it already or is this happening on
one-channel-one-client usage? Because mailbox api does not support
channels shared among multiple clients.
Thanks
Jassi
^ permalink raw reply
* Re: [PATCH v3 2/2] mailbox: Make mbox_send_message() return error code when tx fails
From: Jassi Brar @ 2026-04-02 18:03 UTC (permalink / raw)
To: Joonwon Kang
Cc: matthias.bgg, angelogioacchino.delregno, thierry.reding,
jonathanh, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-tegra, stable
In-Reply-To: <20260402170641.2082547-3-joonwonkang@google.com>
On Thu, Apr 2, 2026 at 12:07 PM Joonwon Kang <joonwonkang@google.com> wrote:
>
> When the mailbox controller failed transmitting message, the error code
> was only passed to the client's tx done handler and not to
> mbox_send_message(). For this reason, the function could return a false
> success. This commit resolves the issue by introducing the tx status and
> checking it before mbox_send_message() returns.
>
Can you please share the scenario when this becomes necessary? This
can potentially change the ground underneath some clients, so we have
to be sure this is really useful.
Thanks
Jassi
> Cc: stable@vger.kernel.org
> Signed-off-by: Joonwon Kang <joonwonkang@google.com>
> ---
> drivers/mailbox/mailbox.c | 20 +++++++++++++++-----
> include/linux/mailbox_controller.h | 2 ++
> 2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
> index d63386468982..ea9aec9dc947 100644
> --- a/drivers/mailbox/mailbox.c
> +++ b/drivers/mailbox/mailbox.c
> @@ -21,7 +21,10 @@
> static LIST_HEAD(mbox_cons);
> static DEFINE_MUTEX(con_mutex);
>
> -static int add_to_rbuf(struct mbox_chan *chan, void *mssg, struct completion *tx_complete)
> +static int add_to_rbuf(struct mbox_chan *chan,
> + void *mssg,
> + struct completion *tx_complete,
> + int *tx_status)
> {
> int idx;
>
> @@ -34,6 +37,7 @@ static int add_to_rbuf(struct mbox_chan *chan, void *mssg, struct completion *tx
> idx = chan->msg_free;
> chan->msg_data[idx].data = mssg;
> chan->msg_data[idx].tx_complete = tx_complete;
> + chan->msg_data[idx].tx_status = tx_status;
> chan->msg_count++;
>
> if (idx == MBOX_TX_QUEUE_LEN - 1)
> @@ -91,12 +95,13 @@ static void msg_submit(struct mbox_chan *chan)
>
> static void tx_tick(struct mbox_chan *chan, int r, int idx)
> {
> - struct mbox_message mssg = {MBOX_NO_MSG, NULL};
> + struct mbox_message mssg = {MBOX_NO_MSG, NULL, NULL};
>
> scoped_guard(spinlock_irqsave, &chan->lock) {
> if (idx >= 0 && idx != chan->active_req) {
> chan->msg_data[idx].data = MBOX_NO_MSG;
> chan->msg_data[idx].tx_complete = NULL;
> + chan->msg_data[idx].tx_status = NULL;
> return;
> }
>
> @@ -116,8 +121,10 @@ static void tx_tick(struct mbox_chan *chan, int r, int idx)
> if (chan->cl->tx_done)
> chan->cl->tx_done(chan->cl, mssg.data, r);
>
> - if (r != -ETIME && chan->cl->tx_block)
> + if (r != -ETIME && chan->cl->tx_block) {
> + *mssg.tx_status = r;
> complete(mssg.tx_complete);
> + }
> }
>
> static enum hrtimer_restart txdone_hrtimer(struct hrtimer *hrtimer)
> @@ -286,15 +293,16 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
> int t;
> int idx;
> struct completion tx_complete;
> + int tx_status = 0;
>
> if (!chan || !chan->cl || mssg == MBOX_NO_MSG)
> return -EINVAL;
>
> if (chan->cl->tx_block) {
> init_completion(&tx_complete);
> - t = add_to_rbuf(chan, mssg, &tx_complete);
> + t = add_to_rbuf(chan, mssg, &tx_complete, &tx_status);
> } else {
> - t = add_to_rbuf(chan, mssg, NULL);
> + t = add_to_rbuf(chan, mssg, NULL, NULL);
> }
>
> if (t < 0) {
> @@ -318,6 +326,8 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
> idx = t;
> t = -ETIME;
> tx_tick(chan, t, idx);
> + } else if (tx_status < 0) {
> + t = tx_status;
> }
> }
>
> diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h
> index 912499ad08ed..890da97bcb50 100644
> --- a/include/linux/mailbox_controller.h
> +++ b/include/linux/mailbox_controller.h
> @@ -117,10 +117,12 @@ struct mbox_controller {
> * struct mbox_message - Internal representation of a mailbox message
> * @data: Data packet
> * @tx_complete: Pointer to the transmission completion
> + * @tx_status: Pointer to the transmission status
> */
> struct mbox_message {
> void *data;
> struct completion *tx_complete;
> + int *tx_status;
> };
>
> /**
> --
> 2.53.0.1185.g05d4b7b318-goog
>
^ permalink raw reply
* Re: [PATCH] iommu: Always fill in gather when unmapping
From: Robin Murphy @ 2026-04-02 18:11 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Alexandre Ghiti, AngeloGioacchino Del Regno, Albert Ou, asahi,
Baolin Wang, iommu, Janne Grunau, Jernej Skrabec, Joerg Roedel,
Jean-Philippe Brucker, linux-arm-kernel, linux-mediatek,
linux-riscv, linux-sunxi, Matthias Brugger, Neal Gompa,
Orson Zhai, Palmer Dabbelt, Paul Walmsley, Samuel Holland,
Sven Peter, virtualization, Chen-Yu Tsai, Will Deacon, Yong Wu,
Chunyan Zhang, Lu Baolu, Janusz Krzysztofik, Joerg Roedel,
Jon Hunter, patches, Samiullah Khawaja, stable, Vasant Hegde
In-Reply-To: <20260401173650.GD310919@nvidia.com>
On 2026-04-01 6:36 pm, Jason Gunthorpe wrote:
> On Wed, Apr 01, 2026 at 05:33:28PM +0100, Robin Murphy wrote:
>>> io-pgtable might have intended to allow the driver to choose between
>>> gather or immediate flush because it passed gather to
>>> ops->tlb_add_page(), however no driver does anything with it.
>>
>> Apart from arm-smmu-v3...
>
> Bah, I did my research on the wrong tree and missed this.
>
>>> mtk uses io-pgtable-arm-v7s but added the range to the gather in the
>>> unmap callback. Move this into the io-pgtable-arm unmap itself. That
>>> will fix all the armv7 using drivers (arm-smmu, qcom_iommu,
>>> ipmmu-vmsa).
>>
>> io-pgtable-arm-v7s != io-pgtable-arm. You're *breaking* MTK (and failing
>> to fix the other v7s user, which is MSM).
>
> I was very confused what you were talking about, but I see now that
> the hunk adding iommu_iotlb_gather_add_range() to v7 got lost somehow!
>
> @@ -596,6 +596,9 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable *data,
>
> __arm_v7s_set_pte(ptep, 0, num_entries, &iop->cfg);
>
> + if (!iommu_iotlb_gather_queued(gather))
> + iommu_iotlb_gather_add_range(gather, iova, size);
> +
> for (i = 0; i < num_entries; i++) {
> if (ARM_V7S_PTE_IS_TABLE(pte[i], lvl)) {
> /* Also flush any partial walks */
>
>>> arm-smmu uses both ARM_V7S and ARM LPAE formats. The LPAE formats
>>> already have the gather population because SMMUv3 requires it, so it
>>> becomes consistent.
>>
>> Huh? arm-smmu-v3 invokes iommu_iotlb_gather_add_page() itself, because
>> arm-smmu-v3 uses gathers
>
> Yeah, I missed this whole bit, it needs some changes.
>
>> Invoking add range before add_page will end up defeating the
>> iommu_iotlb_gather_is_disjoint() check and making SMMUv3
>> overinvalidate between disjoint ranges.
>
> Right, that flow needs fixing.
>
>> I guess now I remember why we weren't validating gathers in core code
>> before :(
>
> My point is not filling the gather is a micro-optimization that
> benefits a few drivers. I think it is so small compared to an IOTLB
> flush that it isn't worth worrying about.
It's hardly a "micro-optimisation" for drivers to just not touch an
optional mechanism which offers no benefit to them, especially when in
many cases said mechanism is newer than the code that isn't using it
anyway. The only required semantic of .iotlb_sync is to ensure that any
previous .unmap_pages calls are complete and their associated
translations invalidated. The entire concept of gathering and deferred
invalidation is irrelevant to many IOMMU designs where it would only
stand to make overall invalidation performance worse.
I'm starting to wish I'd been able to page all this context back in
before reviewing the first patch, as I too only really had Intel and
SMMUv3 in mind at the time... :(
> So, I'd like to make everything the same and populate the gather
> correctly in all flows. I'll fix the SMMUv3 thing and lets look again,
> this patch is not so scary to make me think we shouldn't do that.
>
>> @@ -2714,6 +2714,10 @@ static size_t __iommu_unmap(struct iommu_domain *domain,
>> pr_debug("unmapped: iova 0x%lx size 0x%zx\n",
>> iova, unmapped_page);
>> + /* If the driver itself isn't using the gather, mark it used */
>> + if (iotlb_gather->end <= iotlb_gather->start)
>> + iommu_iotlb_gather_add_range(&iotlb_gather, iova, unmapped_page);
>
> The gathers can be joined across unmaps and now we are inviting subtly
> ill-formed gathers as only the first unmap will get included.
Ill-formed? It's a perfectly valid range for the purposes of any
subsequent generic check - which couldn't realistically be anything
beyond empty vs. non-empty anyway - and it's only being set at all in
the case where we know the driver doesn't care, because if the driver
*was* going to look at gather->start or gather->end in its .iotlb_sync
then it must have already set them to meaningful values in the prior
successful .unmap_pages call. I think we can safely consider it invalid
for a driver to suddenly decide to start using a gather mid-way through
an unmap (or indeed to use start/end in any intentionally non-obvious
manner either).
> We do have error cases where the gather is legitimately empty, and
> this would squash that, it probably needs to check unmapped_page for 0
> too, at least.
Maybe try looking at the rest of the code around these lines...
Thanks,
Robin.
^ permalink raw reply
* Re: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Paul Kocialkowski @ 2026-04-02 18:29 UTC (permalink / raw)
To: Lucas Stach
Cc: dri-devel, imx, linux-arm-kernel, linux-kernel, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Krzysztof Hałasa,
Marco Felsch, Liu Ying
In-Reply-To: <3305c7ec621987a30043f274b2705f739bddd497.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 3411 bytes --]
Hi Lucas,
On Tue 31 Mar 26, 11:14, Lucas Stach wrote:
> Am Dienstag, dem 31.03.2026 um 00:46 +0200 schrieb Paul Kocialkowski:
> > It is necessary to wait for the full frame to finish streaming
> > through the DMA engine before we can safely disable it by removing
> > the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> > hardware confused and unable to resume streaming for the next frame.
> >
> > This causes the FIFO underrun and empty status bits to be set and
> > a single solid color to be shown on the display, coming from one of
> > the pixels of the previous frame. The issue occurs sporadically when
> > a new mode is set, which triggers the crtc disable and enable paths.
> >
> > Setting the shadow load bit and waiting for it to be cleared by the
> > DMA engine allows waiting for completion.
> >
> > The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep.
> >
> > Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
> > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> > Co-developed-by: Lucas Stach <l.stach@pengutronix.de>
> > ---
> > drivers/gpu/drm/mxsfb/lcdif_kms.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > index 1aac354041c7..7dce7f48d938 100644
> > --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > @@ -393,6 +393,22 @@ static void lcdif_disable_controller(struct lcdif_drm_private *lcdif)
> > if (ret)
> > drm_err(lcdif->drm, "Failed to disable controller!\n");
> >
> You can drop this no-op poll above...
You're right, it looks a bit weird to keep it as it's not needed.
> > + /*
> > + * It is necessary to wait for the full frame to finish streaming
> > + * through the DMA engine before we can safely disable it by removing
> > + * the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> > + * hardware confused and unable to resume streaming for the next frame.
> > + */
> > + reg = readl(lcdif->base + LCDC_V8_CTRLDESCL0_5);
> > + reg |= CTRLDESCL0_5_SHADOW_LOAD_EN;
> > + writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5);
> > +
> .. then setting the shadow load enable bit can be merged with the
> access clearing the DMA enable bit.
I've just tried it out and it works just as well!
> > + ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5,
> > + reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN),
> > + 0, 36000); /* Wait ~2 frame times max */
>
> I know this is just a copy from the existing poll, but I don't think
> the busy looping makes a lot of sense. I guess relaxing the poll by a
> 100us or even 200us wait between checks wouldn't hurt.
Yeah good point too. I think 200 us is definitely fine since we're looking
at an average wait of a few ms.
Will respin the series then!
Thanks for the review,
Paul
> > + if (ret)
> > + drm_err(lcdif->drm, "Failed to disable controller!\n");
> > +
> > reg = readl(lcdif->base + LCDC_V8_DISP_PARA);
> > reg &= ~DISP_PARA_DISP_ON;
> > writel(reg, lcdif->base + LCDC_V8_DISP_PARA);
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2 0/2] drm: lcdif: FIFO underrun/solid color bug fix
From: Paul Kocialkowski @ 2026-04-02 18:33 UTC (permalink / raw)
To: dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Lucas Stach,
Krzysztof Hałasa, Marco Felsch, Liu Ying, Paul Kocialkowski
This series brings a fix for the FIFO underrun/solid color bug (in the
last commit) and two other changes that may help with reliability.
Paul Kocialkowski (2):
drm: lcdif: Set undocumented bit to clear FIFO at vsync
drm: lcdif: Wait for vblank before disabling DMA
drivers/gpu/drm/mxsfb/lcdif_kms.c | 18 ++++++++++++++----
drivers/gpu/drm/mxsfb/lcdif_regs.h | 1 +
2 files changed, 15 insertions(+), 4 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH v2 1/2] drm: lcdif: Set undocumented bit to clear FIFO at vsync
From: Paul Kocialkowski @ 2026-04-02 18:33 UTC (permalink / raw)
To: dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Lucas Stach,
Krzysztof Hałasa, Marco Felsch, Liu Ying, Paul Kocialkowski
In-Reply-To: <20260402183351.3281123-1-paulk@sys-base.io>
There is an undocumented bit used in the NXP BSP to clear the FIFO
systematically at vsync. In normal operation, the FIFO should already
be empty but it doesn't hurt to add it as an extra safety measure.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 3 ++-
drivers/gpu/drm/mxsfb/lcdif_regs.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index ef3250a5c54f..a00c4f6d63f4 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -338,7 +338,8 @@ static void lcdif_set_mode(struct lcdif_drm_private *lcdif, u32 bus_flags)
* Downstream set it to 256B burst size to improve the memory
* efficiency so set it here too.
*/
- ctrl = CTRLDESCL0_3_P_SIZE(2) | CTRLDESCL0_3_T_SIZE(2) |
+ ctrl = CTRLDESCL0_3_STATE_CLEAR_VSYNC |
+ CTRLDESCL0_3_P_SIZE(2) | CTRLDESCL0_3_T_SIZE(2) |
CTRLDESCL0_3_PITCH(lcdif->crtc.primary->state->fb->pitches[0]);
writel(ctrl, lcdif->base + LCDC_V8_CTRLDESCL0_3);
}
diff --git a/drivers/gpu/drm/mxsfb/lcdif_regs.h b/drivers/gpu/drm/mxsfb/lcdif_regs.h
index c55dfb236c1d..17882c593d27 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_regs.h
+++ b/drivers/gpu/drm/mxsfb/lcdif_regs.h
@@ -190,6 +190,7 @@
#define CTRLDESCL0_1_WIDTH(n) ((n) & 0xffff)
#define CTRLDESCL0_1_WIDTH_MASK GENMASK(15, 0)
+#define CTRLDESCL0_3_STATE_CLEAR_VSYNC BIT(23)
#define CTRLDESCL0_3_P_SIZE(n) (((n) << 20) & CTRLDESCL0_3_P_SIZE_MASK)
#define CTRLDESCL0_3_P_SIZE_MASK GENMASK(22, 20)
#define CTRLDESCL0_3_T_SIZE(n) (((n) << 16) & CTRLDESCL0_3_T_SIZE_MASK)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Shivendra Pratap @ 2026-04-02 18:35 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Arnd Bergmann, Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla
In-Reply-To: <ac0trUGsRBLPS+ux@lpieralisi>
On 01-04-2026 20:07, Lorenzo Pieralisi wrote:
> On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote:
>>
>>
>> On 27-03-2026 19:25, Lorenzo Pieralisi wrote:
>>> On Wed, Mar 04, 2026 at 11:33:06PM +0530, Shivendra Pratap wrote:
>>>> PSCI supports different types of resets like COLD reset, ARCH WARM
[snip..]
>>>> + * Predefined reboot-modes are defined as per the values
>>>> + * of enum reboot_mode defined in the kernel: reboot.c.
>>>> + */
>>>> +static struct mode_info psci_resets[] = {
>>>> + { .mode = "warm", .magic = REBOOT_WARM},
>>>> + { .mode = "soft", .magic = REBOOT_SOFT},
>>>> + { .mode = "cold", .magic = REBOOT_COLD},
>
> These strings match the command userspace issue right ? I think that we
> should make them match the corresponding PSCI reset types, the list above
> maps command to reboot_mode values and those can belong to any reboot
> mode driver to be honest they don't make much sense in a PSCI reboot
> mode driver only.
>
> It is a question for everyone here: would it make sense to make these
> predefined resets a set of strings, eg:
>
> psci-system-reset
> psci-system-reset2-arch-warm-reset
>
> and then vendor resets:
>
> psci-system-reset2-vendor-reset
Can you share bit more details on this? We are already defining the
string from userspace in the struct - eg: ".mode = "warm".
yes we can move away from enum reboot_mode and use custom psci defines
one - Ack.
>
[snip ..]
>>>> +
>>>> +/*
>>>> + * arg1 is reset_type(Low 32 bit of magic).
>>>> + * arg2 is cookie(High 32 bit of magic).
>>>> + * If reset_type is 0, cookie will be used to decide the reset command.
>>>> + */
>>>> +static int psci_reboot_mode_write(struct reboot_mode_driver *reboot, u64 magic)
>>>> +{
>>>> + u32 reset_type = REBOOT_MODE_ARG1(magic);
>>>> + u32 cookie = REBOOT_MODE_ARG2(magic);
>>>> +
>>>> + if (reset_type == 0) {
>>>> + if (cookie == REBOOT_WARM || cookie == REBOOT_SOFT)
>>>> + psci_set_reset_cmd(true, 0, 0);
>>>> + else
>>>> + psci_set_reset_cmd(false, 0, 0);
>>>> + } else {
>>>> + psci_set_reset_cmd(true, reset_type, cookie);
>>>> + }
>>>
>>> I don't think that psci_set_reset_cmd() has the right interface (and this
>>> nested if is too complicated for my taste). All we need to pass is reset-type
>>> and cookie (and if the reset is one of the predefined ones, reset-type is 0
>>> and cookie is the REBOOT_* cookie).
>>>
>>> Then the PSCI firmware driver will take the action according to what
>>> resets are available.
>>>
>>> How does it sound ?
>>
>> So we mean these checks will move to the psci driver? Sorry for re-iterating
>> the question.
>
> Given what I say above, I believe that something we can do is mapping the magic
> to an enum like:
>
> PSCI_SYSTEM_RESET
> PSCI_SYSTEM_RESET2_ARCH_SYSTEM_WARM_RESET
> PSCI_SYSTEM_RESET2_VENDOR_RESET
>
> and can add a probe function into PSCI driver similar to psci_has_osi_support() but
> to probe for SYSTEM_RESET2 and initialize the predefined strings accordingly,
> depending on its presence.
Not able to get it cleanly.
1. Will move away from reboot_mode enum for pre-defined modes and define
new enum defining these modes- fine.
2. get SYSTEM_RESET2 is supported from psci exported function -- fine,
but how we use it here now, as we do not want to send the reset_cmd from
psci_set_reset_cmd now?
3. For pre-defined modes, warm/soft or cold - reset_type and cookie,
both are zero, sys_reset2 or sys_reset2 decides the ARCH reset vs cold
reset.
4. For vendor-rest , we use sys_reset2 with reset_type and cookie.
All above is done in reboot_notifier call at psci-reboot-mode.
--
Now in the final restart_notifier->psci_sys_reset --
If panic is in progress, we do not use any of the cmd based reset params
and go with the legacy reset. So we need to preserve the values that
were set from psci-reboot-mode.
Did not understand the proposed suggestion in above usecase. Need more
input on this.
--
One other option is to have a restart_notifier in psci-reboot-mode, with
lesser priority than psci_sys_rest and then handle all the case
including panic and sys_reset2.
thanks,
Shivendra
^ permalink raw reply
* [PATCH v2 2/2] drm: lcdif: Wait for vblank before disabling DMA
From: Paul Kocialkowski @ 2026-04-02 18:33 UTC (permalink / raw)
To: dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Lucas Stach,
Krzysztof Hałasa, Marco Felsch, Liu Ying, Paul Kocialkowski
In-Reply-To: <20260402183351.3281123-1-paulk@sys-base.io>
It is necessary to wait for the full frame to finish streaming
through the DMA engine before we can safely disable it by removing
the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
hardware confused and unable to resume streaming for the next frame.
This causes the FIFO underrun and empty status bits to be set and
a single solid color to be shown on the display, coming from one of
the pixels of the previous frame. The issue occurs sporadically when
a new mode is set, which triggers the crtc disable and enable paths.
Setting the shadow load bit and waiting for it to be cleared by the
DMA engine allows waiting for completion.
The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep.
Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Co-developed-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index a00c4f6d63f4..0d04a0028671 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -375,14 +375,23 @@ static void lcdif_disable_controller(struct lcdif_drm_private *lcdif)
int ret;
reg = readl(lcdif->base + LCDC_V8_CTRLDESCL0_5);
+ /* Disable the layer for DMA. */
reg &= ~CTRLDESCL0_5_EN;
+ /*
+ * It is necessary to wait for the full frame to finish streaming
+ * through the DMA engine before we can safely disable it by removing
+ * the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
+ * hardware confused and unable to resume streaming for the next frame.
+ */
+ reg |= CTRLDESCL0_5_SHADOW_LOAD_EN;
writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5);
+ /* Wait for the frame to finish or timeout after 50 ms. */
ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5,
- reg, !(reg & CTRLDESCL0_5_EN),
- 0, 36000); /* Wait ~2 frame times max */
+ reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN),
+ 200, 50000);
if (ret)
- drm_err(lcdif->drm, "Failed to disable controller!\n");
+ drm_err(lcdif->drm, "Timed out waiting for final vblank!\n");
reg = readl(lcdif->base + LCDC_V8_DISP_PARA);
reg &= ~DISP_PARA_DISP_ON;
--
2.53.0
^ permalink raw reply related
* [PATCH v2] arm64: dts: imx8mp-phyboard-pollux: Add HDMI support
From: Paul Kocialkowski @ 2026-04-02 18:36 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel, linux-kernel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Yannic Moog, Fabio Estevam,
Paul Kocialkowski
The PHYTEC phyBOARD Pollux comes with a HDMI port on the base board.
Add the required device-tree nodes to enable support for it, including
both the video and the audio paths.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
.../freescale/imx8mp-phyboard-pollux-rdk.dts | 62 +++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts b/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
index 0fe52c73fc8f..4efdc6bdfe12 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
@@ -38,6 +38,18 @@ fan0: fan {
#cooling-cells = <2>;
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+
panel_lvds1: panel-lvds1 {
/* compatible panel in overlay */
backlight = <&backlight_lvds1>;
@@ -126,6 +138,13 @@ reg_vcc_1v8_exp_con: regulator-vcc-1v8 {
regulator-name = "VCC_1V8_EXP_CON";
};
+ sound-hdmi {
+ compatible = "fsl,imx-audio-hdmi";
+ model = "audio-hdmi";
+ audio-cpu = <&aud2htx>;
+ hdmi-out;
+ };
+
thermal-zones {
soc-thermal {
trips {
@@ -146,6 +165,10 @@ map1 {
};
};
+&aud2htx {
+ status = "okay";
+};
+
/* TPM */
&ecspi1 {
#address-cells = <1>;
@@ -201,6 +224,32 @@ &flexcan2 {
status = "okay";
};
+&hdmi_pai {
+ status = "okay";
+};
+
+&hdmi_pvi {
+ status = "okay";
+};
+
+&hdmi_tx {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi>;
+ status = "okay";
+
+ ports {
+ port@1 {
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+};
+
+&hdmi_tx_phy {
+ status = "okay";
+};
+
&i2c2 {
clock-frequency = <400000>;
pinctrl-names = "default", "gpio";
@@ -244,6 +293,10 @@ &i2c3 {
scl-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
};
+&lcdif3 {
+ status = "okay";
+};
+
&ldb_lvds_ch1 {
remote-endpoint = <&panel1_in>;
};
@@ -444,6 +497,15 @@ MX8MP_IOMUXC_SAI5_RXD0__GPIO3_IO21 0x154
>;
};
+ pinctrl_hdmi: hdmigrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x1c3
+ MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x1c3
+ MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD 0x19
+ MX8MP_IOMUXC_HDMI_CEC__HDMIMIX_HDMI_CEC 0x19
+ >;
+ };
+
pinctrl_i2c2: i2c2grp {
fsl,pins = <
MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001c2
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Shivendra Pratap @ 2026-04-02 18:38 UTC (permalink / raw)
To: Arnd Bergmann, Lorenzo Pieralisi
Cc: Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, André Draszik, Kathiravan Thirumoorthy,
linux-pm, linux-kernel, linux-arm-kernel, linux-arm-msm,
devicetree, Srinivas Kandagatla
In-Reply-To: <f6ed07b1-8bfc-49ea-951e-b590bf8b299a@app.fastmail.com>
On 01-04-2026 20:26, Arnd Bergmann wrote:
> On Wed, Apr 1, 2026, at 16:37, Lorenzo Pieralisi wrote:
>> On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote:
>>>
>>>>> +#include <linux/err.h>
>>>>> +#include <linux/of.h>
>>>>> +#include <linux/psci.h>
>>>>> +#include <linux/reboot.h>
>>>>> +#include <linux/reboot-mode.h>
>>>>> +#include <linux/types.h>
>>>>> +
>>>>> +/*
>>>>> + * Predefined reboot-modes are defined as per the values
>>>>> + * of enum reboot_mode defined in the kernel: reboot.c.
>>>>> + */
>>>>> +static struct mode_info psci_resets[] = {
>>>>> + { .mode = "warm", .magic = REBOOT_WARM},
>>>>> + { .mode = "soft", .magic = REBOOT_SOFT},
>>>>> + { .mode = "cold", .magic = REBOOT_COLD},
>>
>> These strings match the command userspace issue right ? I think that we
>> should make them match the corresponding PSCI reset types, the list above
>> maps command to reboot_mode values and those can belong to any reboot
>> mode driver to be honest they don't make much sense in a PSCI reboot
>> mode driver only.
>>
>> It is a question for everyone here: would it make sense to make these
>> predefined resets a set of strings, eg:
>>
>> psci-system-reset
>> psci-system-reset2-arch-warm-reset
>>
>> and then vendor resets:
>>
>> psci-system-reset2-vendor-reset
>>
>> at least we know what a string maps to ?
>>
>> We can export a function from the PSCI driver to detect whether PSCI
>> SYSTEM_RESET2 is supported, an equivalent of psci_has_osi_support() for
>> instance that we can call from this driver to detect its presence.
>
> Sorry I've been out of the loop for this series for a while, but
> can someone refresh me on why we got back to mixing in
> the 'enum reboot_mode' from legacy i386 and arm32 into the new
> interface?
>
> I don't mind having whichever strings are defined for PSCI present
> in the user interface, but this seems like a mistake to me.
> If at all possible, lets define your own magic constants that
> are not tied to "enum reboot_mode" or the legacy reboot= command
> line argument.
sure. will remove usage of "enum reboot_mode".
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH net-next v2 00/14] net: stmmac: TSO fixes/cleanups
From: patchwork-bot+netdevbpf @ 2026-04-02 18:40 UTC (permalink / raw)
To: Russell King
Cc: andrew, alexandre.torgue, andrew+netdev, davem, edumazet, kuba,
linux-arm-kernel, linux-stm32, netdev, boon.leong.ong, pabeni
In-Reply-To: <aczHVF04LIGq_lYO@shell.armlinux.org.uk>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 1 Apr 2026 08:20:52 +0100 you wrote:
> This is a more refined version of the previous patch series fixing
> and cleaning up the TSO code.
>
> I'm not sure whether "TSO" or "GSO" should be used to describe this
> feature - although it primarily handles TCP, dwmac4 appears to also
> be able to handle UDP.
>
> [...]
Here is the summary with links:
- [net-next,v2,01/14] net: stmmac: fix channel TSO enable on resume
https://git.kernel.org/netdev/net-next/c/989a9c20f63e
- [net-next,v2,02/14] net: stmmac: fix .ndo_fix_features()
https://git.kernel.org/netdev/net-next/c/afe840ddf15c
- [net-next,v2,03/14] net: stmmac: fix TSO support when some channels have TBS available
https://git.kernel.org/netdev/net-next/c/e32820264c29
- [net-next,v2,04/14] net: stmmac: add stmmac_tso_header_size()
https://git.kernel.org/netdev/net-next/c/f799b5dab9c9
- [net-next,v2,05/14] net: stmmac: add TSO check for header length
https://git.kernel.org/netdev/net-next/c/6732e474f880
- [net-next,v2,06/14] net: stmmac: add GSO MSS checks
https://git.kernel.org/netdev/net-next/c/c05a81cbee87
- [net-next,v2,07/14] net: stmmac: move TSO VLAN tag insertion to core code
https://git.kernel.org/netdev/net-next/c/3f6a6eb9ef21
- [net-next,v2,08/14] net: stmmac: move check for hardware checksum supported
https://git.kernel.org/netdev/net-next/c/b55dfb173ce8
- [net-next,v2,09/14] net: stmmac: simplify GSO/TSO test in stmmac_xmit()
https://git.kernel.org/netdev/net-next/c/2e4082e4b739
- [net-next,v2,10/14] net: stmmac: split out gso features setup
https://git.kernel.org/netdev/net-next/c/c04939cb9851
- [net-next,v2,11/14] net: stmmac: make stmmac_set_gso_features() more readable
https://git.kernel.org/netdev/net-next/c/6ad004442897
- [net-next,v2,12/14] net: stmmac: add warning when TSO is requested but unsupported
https://git.kernel.org/netdev/net-next/c/f8c70ab540c1
- [net-next,v2,13/14] net: stmmac: check txpbl for TSO
https://git.kernel.org/netdev/net-next/c/33f5cc83bbbd
- [net-next,v2,14/14] net: stmmac: move "TSO supported" message to stmmac_set_gso_features()
https://git.kernel.org/netdev/net-next/c/0f96212a5142
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Pass a 64bit function-id in the SMC handlers
From: Sebastian Ene @ 2026-04-02 18:46 UTC (permalink / raw)
To: Marc Zyngier
Cc: catalin.marinas, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, joey.gouly, korneld, mrigendra.chaubey, oupton,
perlarsen, suzuki.poulose, will, yuzenghui
In-Reply-To: <875x6acyxc.wl-maz@kernel.org>
On Wed, Apr 1, 2026 at 7:34 PM Marc Zyngier <maz@kernel.org> wrote:
>
> On Wed, 01 Apr 2026 19:28:28 +0100,
> Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Wed, 01 Apr 2026 18:21:58 +0100,
> > Sebastian Ene <sebastianene@google.com> wrote:
> > >
> > > On Wed, Apr 01, 2026 at 03:55:11PM +0100, Marc Zyngier wrote:
> > > > On Wed, 01 Apr 2026 13:32:01 +0100,
> > > > Sebastian Ene <sebastianene@google.com> wrote:
> > > > >
> > > > > Make the SMC handlers accept a 64bit value for the function-id to keep
> > > > > it uniform with the rest of the code and prevent a u64 -> u32 -> u64
> > > > > conversion as it currently happens when we handle PSCI.
> > > >
> > > > That seems overly creative. The spec says (2.5, from ARM DEN 0028 1.6
> > > > G):
> > >
> > > I'm not plannig to be *overly creative*. Thanks for pointing out the ARM
> > > spec.
> > >
> > > >
> > > > "The Function Identifier is passed on W0 on every SMC and HVC
> > > > call. Its 32-bit integer value indicates which function is being
> > > > requested by the caller. It is always passed as the first argument to
> > > > every SMC or HVC call in R0 or W0."
> > > >
> > > > which indicates that it is *always* a 32bit value.
> > > >
> > > > So if you have a 64bit value somewhere, *that* should be fixed, not
> > > > propagated arbitrarily.
> > >
> > > If you have a non SMCCC call that happen to have the first 32-bits of
> > > the function-id matching either PSCI or FF-A you will end up handling
> > > them instead of forwarding it to Trustzone because func_id is declared as:
> > >
> > > DECLARE_REG(u64, func_id, host_ctxt, 0);
> >
> > Again, the correct approach to prevent the propagation of something
> > that is known to be wrong. Something like this:
> >
Hello Marc,
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index 007fc993f2319..dae993a1d081b 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > @@ -694,6 +694,11 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> > DECLARE_REG(u64, func_id, host_ctxt, 0);
> > bool handled;
> >
> > + if (upper_32_bits(func_id)) {
> > + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> > + kvm_skip_host_instr();
>
> Plus the obviously missing:
>
> + return;
>
Thanks for the suggestion, I will do this and spin a new version.
Sebastian
> > + }
> > +
>
> M.
>
> --
> Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v10 6/6] usb: typec: tcpm/tcpci_maxim: deprecate WAR for setting charger mode
From: Amit Sunil Dhamne @ 2026-04-02 18:47 UTC (permalink / raw)
To: Heikki Krogerus
Cc: André Draszik, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, Jagan Sridharan, Mark Brown,
Matti Vaittinen, Andrew Morton, Sebastian Reichel, Peter Griffin,
Tudor Ambarus, Alim Akhtar, linux-kernel, devicetree, linux-usb,
linux-pm, linux-arm-kernel, linux-samsung-soc, RD Babiera,
Kyle Tso
In-Reply-To: <ac5-OzwQkczTWtMg@kuha>
Hi Heikki,
On 4/2/26 7:33 AM, Heikki Krogerus wrote:
> Hi Amit,
>
>> +static int get_vbus_regulator_handle(struct max_tcpci_chip *chip)
>> +{
>> + if (IS_ERR_OR_NULL(chip->vbus_reg)) {
>> + chip->vbus_reg = devm_regulator_get_exclusive(chip->dev,
>> + "vbus");
> Sorry to go back to this, but why can't you just get the regulator in
> max_tcpci_probe()?
Thanks for calling this out. This was an intentional design decision to
break a circular dependency.
The charger driver is guaranteed to probe after the TCPC driver due to a
power supply dependency (the TCPC is a supplier of power for the Battery
Charger). However, the charger driver is also the regulator provider for
VBUS out (when Type-C goes into source mode).
Because of this, the regulator handle will not be available during the
TCPC driver's probe. If we tried to fetch it in max_tcpci_probe() and
returned -EPROBE_DEFER, it would create a probe deadlock, as the charger
would then never probe. Therefore, I made the decision to get the
regulator handle lazily and on-demand.
Thanks,
Amit
>
> thanks,
>
>> + if (IS_ERR_OR_NULL(chip->vbus_reg)) {
>> + dev_err(chip->dev,
>> + "Failed to get vbus regulator handle\n");
>> + return -ENODEV;
>> + }
>> + }
>> +
>> + return 0;
>> +}
^ permalink raw reply
* [soc:riscv/soc-fixes-2] BUILD SUCCESS c7596f9001e2b83293e3658e4e1addde69bb335d
From: kernel test robot @ 2026-04-02 19:40 UTC (permalink / raw)
To: Conor Dooley; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git riscv/soc-fixes-2
branch HEAD: c7596f9001e2b83293e3658e4e1addde69bb335d firmware: microchip: fail auto-update probe if no flash found
elapsed time: 10067m
configs tested: 537
configs skipped: 6
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260327 gcc-8.5.0
arc randconfig-001-20260328 gcc-15.2.0
arc randconfig-001-20260331 clang-23
arc randconfig-001-20260401 clang-23
arc randconfig-001-20260402 gcc-11.5.0
arc randconfig-002-20260327 gcc-8.5.0
arc randconfig-002-20260328 gcc-15.2.0
arc randconfig-002-20260331 clang-23
arc randconfig-002-20260401 clang-23
arc randconfig-002-20260402 gcc-11.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm imx_v4_v5_defconfig clang-23
arm orion5x_defconfig clang-23
arm randconfig-001-20260327 gcc-8.5.0
arm randconfig-001-20260328 gcc-15.2.0
arm randconfig-001-20260331 clang-23
arm randconfig-001-20260401 clang-23
arm randconfig-001-20260402 gcc-11.5.0
arm randconfig-002-20260327 gcc-8.5.0
arm randconfig-002-20260328 gcc-15.2.0
arm randconfig-002-20260331 clang-23
arm randconfig-002-20260401 clang-23
arm randconfig-002-20260402 gcc-11.5.0
arm randconfig-003-20260327 gcc-8.5.0
arm randconfig-003-20260328 gcc-15.2.0
arm randconfig-003-20260331 clang-23
arm randconfig-003-20260401 clang-23
arm randconfig-003-20260402 gcc-11.5.0
arm randconfig-004-20260327 gcc-8.5.0
arm randconfig-004-20260328 gcc-15.2.0
arm randconfig-004-20260331 clang-23
arm randconfig-004-20260401 clang-23
arm randconfig-004-20260402 gcc-11.5.0
arm spear13xx_defconfig gcc-15.2.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260327 clang-23
arm64 randconfig-001-20260328 gcc-14.3.0
arm64 randconfig-001-20260331 clang-18
arm64 randconfig-001-20260401 gcc-15.2.0
arm64 randconfig-001-20260402 gcc-15.2.0
arm64 randconfig-002-20260327 clang-23
arm64 randconfig-002-20260328 gcc-14.3.0
arm64 randconfig-002-20260331 clang-18
arm64 randconfig-002-20260401 gcc-15.2.0
arm64 randconfig-002-20260402 gcc-15.2.0
arm64 randconfig-003-20260327 clang-23
arm64 randconfig-003-20260328 gcc-14.3.0
arm64 randconfig-003-20260331 clang-18
arm64 randconfig-003-20260401 gcc-15.2.0
arm64 randconfig-003-20260402 gcc-15.2.0
arm64 randconfig-004-20260327 clang-23
arm64 randconfig-004-20260328 gcc-14.3.0
arm64 randconfig-004-20260331 clang-18
arm64 randconfig-004-20260401 gcc-15.2.0
arm64 randconfig-004-20260402 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260327 clang-23
csky randconfig-001-20260328 gcc-14.3.0
csky randconfig-001-20260331 clang-18
csky randconfig-001-20260401 gcc-15.2.0
csky randconfig-001-20260402 gcc-15.2.0
csky randconfig-002-20260327 clang-23
csky randconfig-002-20260328 gcc-14.3.0
csky randconfig-002-20260331 clang-18
csky randconfig-002-20260401 gcc-15.2.0
csky randconfig-002-20260402 gcc-15.2.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260327 gcc-8.5.0
hexagon randconfig-001-20260328 gcc-11.5.0
hexagon randconfig-001-20260331 gcc-11.5.0
hexagon randconfig-001-20260401 gcc-15.2.0
hexagon randconfig-001-20260402 clang-18
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260327 gcc-8.5.0
hexagon randconfig-002-20260328 gcc-11.5.0
hexagon randconfig-002-20260331 gcc-11.5.0
hexagon randconfig-002-20260401 gcc-15.2.0
hexagon randconfig-002-20260402 clang-18
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260327 clang-20
i386 buildonly-randconfig-001-20260328 clang-20
i386 buildonly-randconfig-001-20260331 clang-20
i386 buildonly-randconfig-001-20260401 gcc-14
i386 buildonly-randconfig-001-20260402 clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260327 clang-20
i386 buildonly-randconfig-002-20260328 clang-20
i386 buildonly-randconfig-002-20260331 clang-20
i386 buildonly-randconfig-002-20260401 gcc-14
i386 buildonly-randconfig-002-20260402 clang-20
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260327 clang-20
i386 buildonly-randconfig-003-20260328 clang-20
i386 buildonly-randconfig-003-20260331 clang-20
i386 buildonly-randconfig-003-20260401 gcc-14
i386 buildonly-randconfig-003-20260402 clang-20
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260327 clang-20
i386 buildonly-randconfig-004-20260328 clang-20
i386 buildonly-randconfig-004-20260331 clang-20
i386 buildonly-randconfig-004-20260401 gcc-14
i386 buildonly-randconfig-004-20260402 clang-20
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260327 clang-20
i386 buildonly-randconfig-005-20260328 clang-20
i386 buildonly-randconfig-005-20260331 clang-20
i386 buildonly-randconfig-005-20260401 gcc-14
i386 buildonly-randconfig-005-20260402 clang-20
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260327 clang-20
i386 buildonly-randconfig-006-20260328 clang-20
i386 buildonly-randconfig-006-20260331 clang-20
i386 buildonly-randconfig-006-20260401 gcc-14
i386 buildonly-randconfig-006-20260402 clang-20
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260327 clang-20
i386 randconfig-001-20260328 clang-20
i386 randconfig-001-20260331 gcc-14
i386 randconfig-001-20260401 gcc-14
i386 randconfig-001-20260402 clang-20
i386 randconfig-002-20260327 clang-20
i386 randconfig-002-20260328 clang-20
i386 randconfig-002-20260331 gcc-14
i386 randconfig-002-20260401 gcc-14
i386 randconfig-002-20260402 clang-20
i386 randconfig-003-20260327 clang-20
i386 randconfig-003-20260328 clang-20
i386 randconfig-003-20260331 gcc-14
i386 randconfig-003-20260401 gcc-14
i386 randconfig-003-20260402 clang-20
i386 randconfig-004-20260327 clang-20
i386 randconfig-004-20260328 clang-20
i386 randconfig-004-20260331 gcc-14
i386 randconfig-004-20260401 gcc-14
i386 randconfig-004-20260402 clang-20
i386 randconfig-005-20260327 clang-20
i386 randconfig-005-20260328 clang-20
i386 randconfig-005-20260331 gcc-14
i386 randconfig-005-20260401 gcc-14
i386 randconfig-005-20260402 clang-20
i386 randconfig-006-20260327 clang-20
i386 randconfig-006-20260328 clang-20
i386 randconfig-006-20260331 gcc-14
i386 randconfig-006-20260401 gcc-14
i386 randconfig-006-20260402 clang-20
i386 randconfig-007-20260327 clang-20
i386 randconfig-007-20260328 clang-20
i386 randconfig-007-20260331 gcc-14
i386 randconfig-007-20260401 gcc-14
i386 randconfig-007-20260402 clang-20
i386 randconfig-011-20260327 gcc-14
i386 randconfig-011-20260328 gcc-13
i386 randconfig-011-20260331 clang-20
i386 randconfig-011-20260401 clang-20
i386 randconfig-011-20260402 clang-20
i386 randconfig-012-20260327 gcc-14
i386 randconfig-012-20260328 gcc-13
i386 randconfig-012-20260331 clang-20
i386 randconfig-012-20260401 clang-20
i386 randconfig-012-20260402 clang-20
i386 randconfig-013-20260327 gcc-14
i386 randconfig-013-20260328 gcc-13
i386 randconfig-013-20260331 clang-20
i386 randconfig-013-20260401 clang-20
i386 randconfig-013-20260402 clang-20
i386 randconfig-014-20260327 gcc-14
i386 randconfig-014-20260328 gcc-13
i386 randconfig-014-20260331 clang-20
i386 randconfig-014-20260401 clang-20
i386 randconfig-014-20260402 clang-20
i386 randconfig-015-20260327 gcc-14
i386 randconfig-015-20260328 gcc-13
i386 randconfig-015-20260331 clang-20
i386 randconfig-015-20260401 clang-20
i386 randconfig-015-20260402 clang-20
i386 randconfig-016-20260327 gcc-14
i386 randconfig-016-20260328 gcc-13
i386 randconfig-016-20260401 clang-20
i386 randconfig-016-20260402 clang-20
i386 randconfig-017-20260327 gcc-14
i386 randconfig-017-20260328 gcc-13
i386 randconfig-017-20260331 clang-20
i386 randconfig-017-20260401 clang-20
i386 randconfig-017-20260402 clang-20
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260327 gcc-8.5.0
loongarch randconfig-001-20260328 gcc-11.5.0
loongarch randconfig-001-20260331 gcc-11.5.0
loongarch randconfig-001-20260401 gcc-15.2.0
loongarch randconfig-001-20260402 clang-18
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260327 gcc-8.5.0
loongarch randconfig-002-20260328 gcc-11.5.0
loongarch randconfig-002-20260331 gcc-11.5.0
loongarch randconfig-002-20260401 gcc-15.2.0
loongarch randconfig-002-20260402 clang-18
loongarch randconfig-002-20260403 clang-23
m68k alldefconfig gcc-15.2.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
m68k hp300_defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260327 gcc-8.5.0
nios2 randconfig-001-20260328 gcc-11.5.0
nios2 randconfig-001-20260331 gcc-11.5.0
nios2 randconfig-001-20260401 gcc-15.2.0
nios2 randconfig-001-20260402 clang-18
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260327 gcc-8.5.0
nios2 randconfig-002-20260328 gcc-11.5.0
nios2 randconfig-002-20260331 gcc-11.5.0
nios2 randconfig-002-20260401 gcc-15.2.0
nios2 randconfig-002-20260402 clang-18
nios2 randconfig-002-20260403 clang-23
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260327 clang-18
parisc randconfig-001-20260328 gcc-10.5.0
parisc randconfig-001-20260331 clang-23
parisc randconfig-001-20260401 gcc-8.5.0
parisc randconfig-001-20260402 clang-20
parisc randconfig-002-20260327 clang-18
parisc randconfig-002-20260328 gcc-10.5.0
parisc randconfig-002-20260331 clang-23
parisc randconfig-002-20260401 gcc-8.5.0
parisc randconfig-002-20260402 clang-20
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc mpc512x_defconfig clang-23
powerpc randconfig-001-20260327 clang-18
powerpc randconfig-001-20260328 gcc-10.5.0
powerpc randconfig-001-20260331 clang-23
powerpc randconfig-001-20260401 gcc-8.5.0
powerpc randconfig-001-20260402 clang-20
powerpc randconfig-002-20260327 clang-18
powerpc randconfig-002-20260328 gcc-10.5.0
powerpc randconfig-002-20260331 clang-23
powerpc randconfig-002-20260401 gcc-8.5.0
powerpc randconfig-002-20260402 clang-20
powerpc64 randconfig-001-20260327 clang-18
powerpc64 randconfig-001-20260328 gcc-10.5.0
powerpc64 randconfig-001-20260331 clang-23
powerpc64 randconfig-001-20260401 gcc-8.5.0
powerpc64 randconfig-001-20260402 clang-20
powerpc64 randconfig-002-20260327 clang-18
powerpc64 randconfig-002-20260328 gcc-10.5.0
powerpc64 randconfig-002-20260331 clang-23
powerpc64 randconfig-002-20260401 gcc-8.5.0
powerpc64 randconfig-002-20260402 clang-20
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv nommu_virt_defconfig clang-23
riscv randconfig-001-20260327 gcc-12.5.0
riscv randconfig-001-20260328 clang-23
riscv randconfig-001-20260331 gcc-15.2.0
riscv randconfig-001-20260401 gcc-9.5.0
riscv randconfig-001-20260402 clang-23
riscv randconfig-002-20260327 gcc-12.5.0
riscv randconfig-002-20260328 clang-23
riscv randconfig-002-20260331 gcc-15.2.0
riscv randconfig-002-20260401 gcc-9.5.0
riscv randconfig-002-20260402 clang-23
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260327 gcc-12.5.0
s390 randconfig-001-20260328 clang-23
s390 randconfig-001-20260331 gcc-15.2.0
s390 randconfig-001-20260401 gcc-9.5.0
s390 randconfig-001-20260402 clang-23
s390 randconfig-002-20260327 gcc-12.5.0
s390 randconfig-002-20260328 clang-23
s390 randconfig-002-20260331 gcc-15.2.0
s390 randconfig-002-20260401 gcc-9.5.0
s390 randconfig-002-20260402 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260327 gcc-12.5.0
sh randconfig-001-20260328 clang-23
sh randconfig-001-20260331 gcc-15.2.0
sh randconfig-001-20260401 gcc-9.5.0
sh randconfig-001-20260402 clang-23
sh randconfig-002-20260327 gcc-12.5.0
sh randconfig-002-20260328 clang-23
sh randconfig-002-20260331 gcc-15.2.0
sh randconfig-002-20260401 gcc-9.5.0
sh randconfig-002-20260402 clang-23
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260327 gcc-14.3.0
sparc randconfig-001-20260328 gcc-14
sparc randconfig-001-20260331 gcc-15.2.0
sparc randconfig-001-20260401 clang-16
sparc randconfig-001-20260402 gcc-14
sparc randconfig-002-20260327 gcc-14.3.0
sparc randconfig-002-20260328 gcc-14
sparc randconfig-002-20260331 gcc-15.2.0
sparc randconfig-002-20260401 clang-16
sparc randconfig-002-20260402 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260327 gcc-14.3.0
sparc64 randconfig-001-20260328 gcc-14
sparc64 randconfig-001-20260331 gcc-15.2.0
sparc64 randconfig-001-20260401 clang-16
sparc64 randconfig-001-20260402 gcc-14
sparc64 randconfig-002-20260327 gcc-14.3.0
sparc64 randconfig-002-20260328 gcc-14
sparc64 randconfig-002-20260331 gcc-15.2.0
sparc64 randconfig-002-20260401 clang-16
sparc64 randconfig-002-20260402 gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260328 gcc-14
um randconfig-001-20260331 gcc-15.2.0
um randconfig-001-20260401 clang-16
um randconfig-001-20260402 gcc-14
um randconfig-002-20260327 gcc-14.3.0
um randconfig-002-20260328 gcc-14
um randconfig-002-20260331 gcc-15.2.0
um randconfig-002-20260401 clang-16
um randconfig-002-20260402 gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260327 clang-20
x86_64 buildonly-randconfig-001-20260328 clang-20
x86_64 buildonly-randconfig-001-20260331 clang-20
x86_64 buildonly-randconfig-001-20260401 gcc-12
x86_64 buildonly-randconfig-001-20260402 clang-20
x86_64 buildonly-randconfig-002-20260327 clang-20
x86_64 buildonly-randconfig-002-20260328 clang-20
x86_64 buildonly-randconfig-002-20260331 clang-20
x86_64 buildonly-randconfig-002-20260401 gcc-12
x86_64 buildonly-randconfig-002-20260402 clang-20
x86_64 buildonly-randconfig-003-20260327 clang-20
x86_64 buildonly-randconfig-003-20260328 clang-20
x86_64 buildonly-randconfig-003-20260331 clang-20
x86_64 buildonly-randconfig-003-20260401 gcc-12
x86_64 buildonly-randconfig-003-20260402 clang-20
x86_64 buildonly-randconfig-004-20260327 clang-20
x86_64 buildonly-randconfig-004-20260328 clang-20
x86_64 buildonly-randconfig-004-20260331 clang-20
x86_64 buildonly-randconfig-004-20260401 gcc-12
x86_64 buildonly-randconfig-004-20260402 clang-20
x86_64 buildonly-randconfig-005-20260327 clang-20
x86_64 buildonly-randconfig-005-20260328 clang-20
x86_64 buildonly-randconfig-005-20260331 clang-20
x86_64 buildonly-randconfig-005-20260401 gcc-12
x86_64 buildonly-randconfig-005-20260402 clang-20
x86_64 buildonly-randconfig-006-20260327 clang-20
x86_64 buildonly-randconfig-006-20260328 clang-20
x86_64 buildonly-randconfig-006-20260331 clang-20
x86_64 buildonly-randconfig-006-20260401 gcc-12
x86_64 buildonly-randconfig-006-20260402 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260327 gcc-14
x86_64 randconfig-001-20260328 gcc-14
x86_64 randconfig-001-20260331 gcc-14
x86_64 randconfig-001-20260401 clang-20
x86_64 randconfig-001-20260402 gcc-14
x86_64 randconfig-002-20260327 gcc-14
x86_64 randconfig-002-20260328 gcc-14
x86_64 randconfig-002-20260331 gcc-14
x86_64 randconfig-002-20260401 clang-20
x86_64 randconfig-002-20260402 gcc-14
x86_64 randconfig-003-20260327 gcc-14
x86_64 randconfig-003-20260328 gcc-14
x86_64 randconfig-003-20260331 gcc-14
x86_64 randconfig-003-20260401 clang-20
x86_64 randconfig-003-20260402 gcc-14
x86_64 randconfig-004-20260327 gcc-14
x86_64 randconfig-004-20260328 gcc-14
x86_64 randconfig-004-20260331 gcc-14
x86_64 randconfig-004-20260401 clang-20
x86_64 randconfig-004-20260402 gcc-14
x86_64 randconfig-005-20260327 gcc-14
x86_64 randconfig-005-20260328 gcc-14
x86_64 randconfig-005-20260331 gcc-14
x86_64 randconfig-005-20260401 clang-20
x86_64 randconfig-005-20260402 gcc-14
x86_64 randconfig-006-20260327 gcc-14
x86_64 randconfig-006-20260328 gcc-14
x86_64 randconfig-006-20260331 gcc-14
x86_64 randconfig-006-20260401 clang-20
x86_64 randconfig-006-20260402 gcc-14
x86_64 randconfig-011-20260327 gcc-14
x86_64 randconfig-011-20260328 clang-20
x86_64 randconfig-011-20260331 clang-20
x86_64 randconfig-011-20260401 gcc-14
x86_64 randconfig-011-20260402 clang-20
x86_64 randconfig-012-20260327 gcc-14
x86_64 randconfig-012-20260328 clang-20
x86_64 randconfig-012-20260331 clang-20
x86_64 randconfig-012-20260401 gcc-14
x86_64 randconfig-012-20260402 clang-20
x86_64 randconfig-013-20260327 gcc-14
x86_64 randconfig-013-20260328 clang-20
x86_64 randconfig-013-20260331 clang-20
x86_64 randconfig-013-20260401 gcc-14
x86_64 randconfig-013-20260402 clang-20
x86_64 randconfig-014-20260327 gcc-14
x86_64 randconfig-014-20260328 clang-20
x86_64 randconfig-014-20260331 clang-20
x86_64 randconfig-014-20260401 gcc-14
x86_64 randconfig-014-20260402 clang-20
x86_64 randconfig-015-20260327 gcc-14
x86_64 randconfig-015-20260328 clang-20
x86_64 randconfig-015-20260331 clang-20
x86_64 randconfig-015-20260401 gcc-14
x86_64 randconfig-015-20260402 clang-20
x86_64 randconfig-016-20260327 gcc-14
x86_64 randconfig-016-20260328 clang-20
x86_64 randconfig-016-20260331 clang-20
x86_64 randconfig-016-20260401 gcc-14
x86_64 randconfig-016-20260402 clang-20
x86_64 randconfig-071-20260327 gcc-13
x86_64 randconfig-071-20260328 gcc-12
x86_64 randconfig-071-20260331 clang-20
x86_64 randconfig-071-20260401 gcc-14
x86_64 randconfig-071-20260402 clang-20
x86_64 randconfig-072-20260327 gcc-13
x86_64 randconfig-072-20260328 gcc-12
x86_64 randconfig-072-20260331 clang-20
x86_64 randconfig-072-20260401 gcc-14
x86_64 randconfig-072-20260402 clang-20
x86_64 randconfig-073-20260327 gcc-13
x86_64 randconfig-073-20260328 gcc-12
x86_64 randconfig-073-20260331 clang-20
x86_64 randconfig-073-20260401 gcc-14
x86_64 randconfig-073-20260402 clang-20
x86_64 randconfig-074-20260327 gcc-13
x86_64 randconfig-074-20260328 gcc-12
x86_64 randconfig-074-20260331 clang-20
x86_64 randconfig-074-20260401 gcc-14
x86_64 randconfig-074-20260402 clang-20
x86_64 randconfig-075-20260327 gcc-13
x86_64 randconfig-075-20260328 gcc-12
x86_64 randconfig-075-20260331 clang-20
x86_64 randconfig-075-20260401 gcc-14
x86_64 randconfig-075-20260402 clang-20
x86_64 randconfig-076-20260327 gcc-13
x86_64 randconfig-076-20260328 gcc-12
x86_64 randconfig-076-20260331 clang-20
x86_64 randconfig-076-20260401 gcc-14
x86_64 randconfig-076-20260402 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa allyesconfig gcc-15.2.0
xtensa randconfig-001-20260327 gcc-14.3.0
xtensa randconfig-001-20260328 gcc-14
xtensa randconfig-001-20260331 gcc-15.2.0
xtensa randconfig-001-20260401 clang-16
xtensa randconfig-001-20260402 gcc-14
xtensa randconfig-002-20260327 gcc-14.3.0
xtensa randconfig-002-20260328 gcc-14
xtensa randconfig-002-20260331 gcc-15.2.0
xtensa randconfig-002-20260401 clang-16
xtensa randconfig-002-20260402 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [soc:soc/arm] BUILD SUCCESS 9ac420358dd8e0ff4c2d8f34818b3f9183b1c34a
From: kernel test robot @ 2026-04-02 19:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/arm
branch HEAD: 9ac420358dd8e0ff4c2d8f34818b3f9183b1c34a Merge tag 'renesas-arm-soc-for-v7.1-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/arm
elapsed time: 741m
configs tested: 183
configs skipped: 156
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260402 gcc-11.5.0
arc randconfig-002-20260402 gcc-11.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm orion5x_defconfig clang-23
arm randconfig-001-20260402 gcc-11.5.0
arm randconfig-002-20260402 gcc-11.5.0
arm randconfig-003-20260402 gcc-11.5.0
arm randconfig-004-20260402 gcc-11.5.0
arm spear13xx_defconfig gcc-15.2.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260402 gcc-15.2.0
arm64 randconfig-002-20260402 gcc-15.2.0
arm64 randconfig-003-20260402 gcc-15.2.0
arm64 randconfig-004-20260402 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260402 gcc-15.2.0
csky randconfig-002-20260402 gcc-15.2.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260402 clang-18
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260402 clang-18
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260402 clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260402 clang-20
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260402 clang-20
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260402 clang-20
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260402 clang-20
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260402 clang-20
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260402 clang-20
i386 randconfig-002-20260402 clang-20
i386 randconfig-003-20260402 clang-20
i386 randconfig-004-20260402 clang-20
i386 randconfig-005-20260402 clang-20
i386 randconfig-006-20260402 clang-20
i386 randconfig-007-20260402 clang-20
i386 randconfig-011-20260402 clang-20
i386 randconfig-012-20260402 clang-20
i386 randconfig-013-20260402 clang-20
i386 randconfig-014-20260402 clang-20
i386 randconfig-015-20260402 clang-20
i386 randconfig-016-20260402 clang-20
i386 randconfig-017-20260402 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260402 clang-18
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260402 clang-18
loongarch randconfig-002-20260403 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260402 clang-18
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260402 clang-18
nios2 randconfig-002-20260403 clang-23
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260402 clang-20
parisc randconfig-002-20260402 clang-20
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260402 clang-20
powerpc randconfig-002-20260402 clang-20
powerpc64 randconfig-001-20260402 clang-20
powerpc64 randconfig-002-20260402 clang-20
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260402 clang-23
riscv randconfig-002-20260402 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260402 clang-23
s390 randconfig-002-20260402 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260402 clang-23
sh randconfig-002-20260402 clang-23
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260402 gcc-14
sparc randconfig-002-20260402 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260402 gcc-14
sparc64 randconfig-002-20260402 gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260402 gcc-14
um randconfig-002-20260402 gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260402 clang-20
x86_64 buildonly-randconfig-002-20260402 clang-20
x86_64 buildonly-randconfig-003-20260402 clang-20
x86_64 buildonly-randconfig-004-20260402 clang-20
x86_64 buildonly-randconfig-005-20260402 clang-20
x86_64 buildonly-randconfig-006-20260402 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260402 gcc-14
x86_64 randconfig-002-20260402 gcc-14
x86_64 randconfig-003-20260402 gcc-14
x86_64 randconfig-004-20260402 gcc-14
x86_64 randconfig-005-20260402 gcc-14
x86_64 randconfig-006-20260402 gcc-14
x86_64 randconfig-011-20260402 clang-20
x86_64 randconfig-012-20260402 clang-20
x86_64 randconfig-013-20260402 clang-20
x86_64 randconfig-014-20260402 clang-20
x86_64 randconfig-015-20260402 clang-20
x86_64 randconfig-016-20260402 clang-20
x86_64 randconfig-071-20260402 clang-20
x86_64 randconfig-072-20260402 clang-20
x86_64 randconfig-073-20260402 clang-20
x86_64 randconfig-074-20260402 clang-20
x86_64 randconfig-075-20260402 clang-20
x86_64 randconfig-076-20260402 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260402 gcc-14
xtensa randconfig-002-20260402 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [soc:arm/fixes] BUILD SUCCESS b986e98ccd0d09538a841b832faef44c49f4d655
From: kernel test robot @ 2026-04-02 19:43 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/fixes
branch HEAD: b986e98ccd0d09538a841b832faef44c49f4d655 Merge tag 'qcom-arm64-fixes-for-7.0-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
elapsed time: 745m
configs tested: 202
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260402 gcc-11.5.0
arc randconfig-002-20260402 gcc-11.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm orion5x_defconfig clang-23
arm randconfig-001-20260402 gcc-11.5.0
arm randconfig-002-20260402 gcc-11.5.0
arm randconfig-003-20260402 gcc-11.5.0
arm randconfig-004-20260402 gcc-11.5.0
arm spear13xx_defconfig gcc-15.2.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260402 gcc-15.2.0
arm64 randconfig-002-20260402 gcc-15.2.0
arm64 randconfig-003-20260402 gcc-15.2.0
arm64 randconfig-004-20260402 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260402 gcc-15.2.0
csky randconfig-002-20260402 gcc-15.2.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260402 clang-18
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260402 clang-18
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260402 clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260402 clang-20
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260402 clang-20
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260402 clang-20
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260402 clang-20
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260402 clang-20
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260402 clang-20
i386 randconfig-002-20260402 clang-20
i386 randconfig-003-20260402 clang-20
i386 randconfig-004-20260402 clang-20
i386 randconfig-005-20260402 clang-20
i386 randconfig-006-20260402 clang-20
i386 randconfig-007-20260402 clang-20
i386 randconfig-011-20260402 clang-20
i386 randconfig-012-20260402 clang-20
i386 randconfig-013-20260402 clang-20
i386 randconfig-014-20260402 clang-20
i386 randconfig-015-20260402 clang-20
i386 randconfig-016-20260402 clang-20
i386 randconfig-017-20260402 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260402 clang-18
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260402 clang-18
loongarch randconfig-002-20260403 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260402 clang-18
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260402 clang-18
nios2 randconfig-002-20260403 clang-23
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260402 clang-20
parisc randconfig-002-20260402 clang-20
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260402 clang-20
powerpc randconfig-002-20260402 clang-20
powerpc64 randconfig-001-20260402 clang-20
powerpc64 randconfig-002-20260402 clang-20
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260402 clang-23
riscv randconfig-002-20260402 clang-23
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260402 clang-23
s390 randconfig-002-20260402 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260402 clang-23
sh randconfig-002-20260402 clang-23
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260402 gcc-14
sparc randconfig-002-20260402 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260402 gcc-14
sparc64 randconfig-002-20260402 gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260402 gcc-14
um randconfig-002-20260402 gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260402 clang-20
x86_64 buildonly-randconfig-002-20260402 clang-20
x86_64 buildonly-randconfig-003-20260402 clang-20
x86_64 buildonly-randconfig-004-20260402 clang-20
x86_64 buildonly-randconfig-005-20260402 clang-20
x86_64 buildonly-randconfig-006-20260402 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260402 gcc-14
x86_64 randconfig-002-20260402 gcc-14
x86_64 randconfig-003-20260402 gcc-14
x86_64 randconfig-004-20260402 gcc-14
x86_64 randconfig-005-20260402 gcc-14
x86_64 randconfig-006-20260402 gcc-14
x86_64 randconfig-011-20260402 clang-20
x86_64 randconfig-012-20260402 clang-20
x86_64 randconfig-013-20260402 clang-20
x86_64 randconfig-014-20260402 clang-20
x86_64 randconfig-015-20260402 clang-20
x86_64 randconfig-016-20260402 clang-20
x86_64 randconfig-071-20260402 clang-20
x86_64 randconfig-072-20260402 clang-20
x86_64 randconfig-073-20260402 clang-20
x86_64 randconfig-074-20260402 clang-20
x86_64 randconfig-075-20260402 clang-20
x86_64 randconfig-076-20260402 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260402 gcc-14
xtensa randconfig-002-20260402 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v5 2/4] software node: remove software_node_exit()
From: Dmitry Torokhov @ 2026-04-02 19:46 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <ac6XAyjxTct_WCEI@ashevche-desk.local>
On Thu, Apr 02, 2026 at 07:19:15PM +0300, Andy Shevchenko wrote:
> On Thu, Apr 02, 2026 at 04:15:03PM +0200, Bartosz Golaszewski wrote:
> > software_node_exit() is an __exitcall() in a built-in compilation unit
> > so effectively dead code. Remove it.
>
> a dead code
"
In technical writing, "dead code" is typically treated as an uncountable
noun, meaning it does not need the article "a" when referring to it as a
category or state.
"
Thanks.
--
Dmitry
^ permalink raw reply
* [soc:soc/dt] BUILD SUCCESS 0a1f536c9ffdad35dc19f21b7d4772f858b15b68
From: kernel test robot @ 2026-04-02 19:49 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/dt
branch HEAD: 0a1f536c9ffdad35dc19f21b7d4772f858b15b68 Merge tag 'sunxi-dt-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into soc/dt
elapsed time: 747m
configs tested: 206
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260402 gcc-11.5.0
arc randconfig-002-20260402 gcc-11.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm orion5x_defconfig clang-23
arm randconfig-001-20260402 gcc-11.5.0
arm randconfig-002-20260402 gcc-11.5.0
arm randconfig-003-20260402 gcc-11.5.0
arm randconfig-004-20260402 gcc-11.5.0
arm spear13xx_defconfig gcc-15.2.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260402 gcc-15.2.0
arm64 randconfig-002-20260402 gcc-15.2.0
arm64 randconfig-003-20260402 gcc-15.2.0
arm64 randconfig-004-20260402 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260402 gcc-15.2.0
csky randconfig-002-20260402 gcc-15.2.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260402 clang-18
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260402 clang-18
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260402 clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260402 clang-20
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260402 clang-20
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260402 clang-20
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260402 clang-20
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260402 clang-20
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260402 clang-20
i386 randconfig-002-20260402 clang-20
i386 randconfig-003-20260402 clang-20
i386 randconfig-004-20260402 clang-20
i386 randconfig-005-20260402 clang-20
i386 randconfig-006-20260402 clang-20
i386 randconfig-007-20260402 clang-20
i386 randconfig-011-20260402 clang-20
i386 randconfig-012-20260402 clang-20
i386 randconfig-013-20260402 clang-20
i386 randconfig-014-20260402 clang-20
i386 randconfig-015-20260402 clang-20
i386 randconfig-016-20260402 clang-20
i386 randconfig-017-20260402 clang-20
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260402 clang-18
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260402 clang-18
loongarch randconfig-002-20260403 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260402 clang-18
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260402 clang-18
nios2 randconfig-002-20260403 clang-23
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260402 clang-20
parisc randconfig-002-20260402 clang-20
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260402 clang-20
powerpc randconfig-002-20260402 clang-20
powerpc64 randconfig-001-20260402 clang-20
powerpc64 randconfig-002-20260402 clang-20
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260402 clang-23
riscv randconfig-002-20260402 clang-23
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260402 clang-23
s390 randconfig-002-20260402 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260402 clang-23
sh randconfig-002-20260402 clang-23
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260402 gcc-14
sparc randconfig-002-20260402 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260402 gcc-14
sparc64 randconfig-002-20260402 gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260402 gcc-14
um randconfig-002-20260402 gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260402 clang-20
x86_64 buildonly-randconfig-002-20260402 clang-20
x86_64 buildonly-randconfig-003-20260402 clang-20
x86_64 buildonly-randconfig-004-20260402 clang-20
x86_64 buildonly-randconfig-005-20260402 clang-20
x86_64 buildonly-randconfig-006-20260402 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260402 gcc-14
x86_64 randconfig-002-20260402 gcc-14
x86_64 randconfig-003-20260402 gcc-14
x86_64 randconfig-004-20260402 gcc-14
x86_64 randconfig-005-20260402 gcc-14
x86_64 randconfig-006-20260402 gcc-14
x86_64 randconfig-011-20260402 clang-20
x86_64 randconfig-012-20260402 clang-20
x86_64 randconfig-013-20260402 clang-20
x86_64 randconfig-014-20260402 clang-20
x86_64 randconfig-015-20260402 clang-20
x86_64 randconfig-016-20260402 clang-20
x86_64 randconfig-071-20260402 clang-20
x86_64 randconfig-072-20260402 clang-20
x86_64 randconfig-073-20260402 clang-20
x86_64 randconfig-074-20260402 clang-20
x86_64 randconfig-075-20260402 clang-20
x86_64 randconfig-076-20260402 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260402 gcc-14
xtensa randconfig-002-20260402 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [soc:soc/drivers] BUILD SUCCESS 84a5fe2ee01f1c99f98227b76dbbc0017fc746bd
From: kernel test robot @ 2026-04-02 19:49 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/drivers
branch HEAD: 84a5fe2ee01f1c99f98227b76dbbc0017fc746bd Merge tag 'imx-soc-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into soc/drivers
elapsed time: 748m
configs tested: 209
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260402 gcc-11.5.0
arc randconfig-002-20260402 gcc-11.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm orion5x_defconfig clang-23
arm randconfig-001-20260402 gcc-11.5.0
arm randconfig-002-20260402 gcc-11.5.0
arm randconfig-003-20260402 gcc-11.5.0
arm randconfig-004-20260402 gcc-11.5.0
arm spear13xx_defconfig gcc-15.2.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260402 gcc-15.2.0
arm64 randconfig-002-20260402 gcc-15.2.0
arm64 randconfig-003-20260402 gcc-15.2.0
arm64 randconfig-004-20260402 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260402 gcc-15.2.0
csky randconfig-002-20260402 gcc-15.2.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260402 clang-18
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260402 clang-18
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260402 clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260402 clang-20
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260402 clang-20
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260402 clang-20
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260402 clang-20
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260402 clang-20
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260402 clang-20
i386 randconfig-002-20260402 clang-20
i386 randconfig-003-20260402 clang-20
i386 randconfig-004-20260402 clang-20
i386 randconfig-005-20260402 clang-20
i386 randconfig-006-20260402 clang-20
i386 randconfig-007-20260402 clang-20
i386 randconfig-011-20260402 clang-20
i386 randconfig-012-20260402 clang-20
i386 randconfig-013-20260402 clang-20
i386 randconfig-014-20260402 clang-20
i386 randconfig-015-20260402 clang-20
i386 randconfig-016-20260402 clang-20
i386 randconfig-017-20260402 clang-20
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260402 clang-18
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260402 clang-18
loongarch randconfig-002-20260403 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260402 clang-18
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260402 clang-18
nios2 randconfig-002-20260403 clang-23
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260402 clang-20
parisc randconfig-002-20260402 clang-20
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260402 clang-20
powerpc randconfig-002-20260402 clang-20
powerpc64 randconfig-001-20260402 clang-20
powerpc64 randconfig-002-20260402 clang-20
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260402 clang-23
riscv randconfig-002-20260402 clang-23
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260402 clang-23
s390 randconfig-002-20260402 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260402 clang-23
sh randconfig-002-20260402 clang-23
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260402 gcc-14
sparc randconfig-002-20260402 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260402 gcc-14
sparc64 randconfig-002-20260402 gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260402 gcc-14
um randconfig-002-20260402 gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260402 clang-20
x86_64 buildonly-randconfig-002-20260402 clang-20
x86_64 buildonly-randconfig-003-20260402 clang-20
x86_64 buildonly-randconfig-004-20260402 clang-20
x86_64 buildonly-randconfig-005-20260402 clang-20
x86_64 buildonly-randconfig-006-20260402 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260402 gcc-14
x86_64 randconfig-002-20260402 gcc-14
x86_64 randconfig-003-20260402 gcc-14
x86_64 randconfig-004-20260402 gcc-14
x86_64 randconfig-005-20260402 gcc-14
x86_64 randconfig-006-20260402 gcc-14
x86_64 randconfig-011-20260402 clang-20
x86_64 randconfig-012-20260402 clang-20
x86_64 randconfig-013-20260402 clang-20
x86_64 randconfig-014-20260402 clang-20
x86_64 randconfig-015-20260402 clang-20
x86_64 randconfig-016-20260402 clang-20
x86_64 randconfig-071-20260402 clang-20
x86_64 randconfig-072-20260402 clang-20
x86_64 randconfig-073-20260402 clang-20
x86_64 randconfig-074-20260402 clang-20
x86_64 randconfig-075-20260402 clang-20
x86_64 randconfig-076-20260402 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260402 gcc-14
xtensa randconfig-002-20260402 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [soc:for-next] BUILD SUCCESS ae68bfb2cfda020996e0ce41f1af0e54ac9d549f
From: kernel test robot @ 2026-04-02 20:00 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: ae68bfb2cfda020996e0ce41f1af0e54ac9d549f soc: document merges
elapsed time: 761m
configs tested: 207
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260402 gcc-11.5.0
arc randconfig-002-20260402 gcc-11.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm orion5x_defconfig clang-23
arm randconfig-001-20260402 gcc-11.5.0
arm randconfig-002-20260402 gcc-11.5.0
arm randconfig-003-20260402 gcc-11.5.0
arm randconfig-004-20260402 gcc-11.5.0
arm spear13xx_defconfig gcc-15.2.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260402 gcc-15.2.0
arm64 randconfig-002-20260402 gcc-15.2.0
arm64 randconfig-003-20260402 gcc-15.2.0
arm64 randconfig-004-20260402 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260402 gcc-15.2.0
csky randconfig-002-20260402 gcc-15.2.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260402 clang-18
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260402 clang-18
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260402 clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260402 clang-20
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260402 clang-20
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260402 clang-20
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260402 clang-20
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260402 clang-20
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260402 clang-20
i386 randconfig-002-20260402 clang-20
i386 randconfig-003-20260402 clang-20
i386 randconfig-004-20260402 clang-20
i386 randconfig-005-20260402 clang-20
i386 randconfig-006-20260402 clang-20
i386 randconfig-007-20260402 clang-20
i386 randconfig-011-20260402 clang-20
i386 randconfig-012-20260402 clang-20
i386 randconfig-013-20260402 clang-20
i386 randconfig-014-20260402 clang-20
i386 randconfig-015-20260402 clang-20
i386 randconfig-016-20260402 clang-20
i386 randconfig-017-20260402 clang-20
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260402 clang-18
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260402 clang-18
loongarch randconfig-002-20260403 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260402 clang-18
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260402 clang-18
nios2 randconfig-002-20260403 clang-23
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260402 clang-20
parisc randconfig-002-20260402 clang-20
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260402 clang-20
powerpc randconfig-002-20260402 clang-20
powerpc64 randconfig-001-20260402 clang-20
powerpc64 randconfig-002-20260402 clang-20
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260402 clang-23
riscv randconfig-002-20260402 clang-23
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260402 clang-23
s390 randconfig-002-20260402 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260402 clang-23
sh randconfig-002-20260402 clang-23
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260402 gcc-14
sparc randconfig-002-20260402 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260402 gcc-14
sparc64 randconfig-002-20260402 gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260402 gcc-14
um randconfig-002-20260402 gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260402 clang-20
x86_64 buildonly-randconfig-002-20260402 clang-20
x86_64 buildonly-randconfig-003-20260402 clang-20
x86_64 buildonly-randconfig-004-20260402 clang-20
x86_64 buildonly-randconfig-005-20260402 clang-20
x86_64 buildonly-randconfig-006-20260402 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260402 gcc-14
x86_64 randconfig-002-20260402 gcc-14
x86_64 randconfig-003-20260402 gcc-14
x86_64 randconfig-004-20260402 gcc-14
x86_64 randconfig-005-20260402 gcc-14
x86_64 randconfig-006-20260402 gcc-14
x86_64 randconfig-011-20260402 clang-20
x86_64 randconfig-012-20260402 clang-20
x86_64 randconfig-013-20260402 clang-20
x86_64 randconfig-014-20260402 clang-20
x86_64 randconfig-015-20260402 clang-20
x86_64 randconfig-016-20260402 clang-20
x86_64 randconfig-071-20260402 clang-20
x86_64 randconfig-072-20260402 clang-20
x86_64 randconfig-073-20260402 clang-20
x86_64 randconfig-074-20260402 clang-20
x86_64 randconfig-075-20260402 clang-20
x86_64 randconfig-076-20260402 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260402 gcc-14
xtensa randconfig-002-20260402 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Catalin Marinas @ 2026-04-02 20:43 UTC (permalink / raw)
To: Ryan Roberts
Cc: Will Deacon, David Hildenbrand (Arm), Dev Jain, Yang Shi,
Suzuki K Poulose, Jinjiang Tu, Kevin Brodsky, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <20260330161705.3349825-2-ryan.roberts@arm.com>
On Mon, Mar 30, 2026 at 05:17:02PM +0100, Ryan Roberts wrote:
> int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
> {
> int ret;
>
> - /*
> - * !BBML2_NOABORT systems should not be trying to change permissions on
> - * anything that is not pte-mapped in the first place. Just return early
> - * and let the permission change code raise a warning if not already
> - * pte-mapped.
> - */
> - if (!system_supports_bbml2_noabort())
> - return 0;
> -
> /*
> * If the region is within a pte-mapped area, there is no need to try to
> * split. Additionally, CONFIG_DEBUG_PAGEALLOC and CONFIG_KFENCE may
> * change permissions from atomic context so for those cases (which are
> * always pte-mapped), we must not go any further because taking the
> - * mutex below may sleep.
> + * mutex below may sleep. Do not call force_pte_mapping() here because
> + * it could return a confusing result if called from a secondary cpu
> + * prior to finalizing caps. Instead, linear_map_requires_bbml2 gives us
> + * what we need.
> */
> - if (force_pte_mapping() || is_kfence_address((void *)start))
> + if (!linear_map_requires_bbml2 || is_kfence_address((void *)start))
> return 0;
>
> + if (!system_supports_bbml2_noabort()) {
> + /*
> + * !BBML2_NOABORT systems should not be trying to change
> + * permissions on anything that is not pte-mapped in the first
> + * place. Just return early and let the permission change code
> + * raise a warning if not already pte-mapped.
> + */
> + if (system_capabilities_finalized())
> + return 0;
> +
> + /*
> + * Boot-time: split_kernel_leaf_mapping_locked() allocates from
> + * page allocator. Can't split until it's available.
> + */
> + if (WARN_ON(!page_alloc_available))
> + return -EBUSY;
> +
> + /*
> + * Boot-time: Started secondary cpus but don't know if they
> + * support BBML2_NOABORT yet. Can't allow splitting in this
> + * window in case they don't.
> + */
> + if (WARN_ON(num_online_cpus() > 1))
> + return -EBUSY;
> + }
I think sashiko is over cautions here
(https://sashiko.dev/#/patchset/20260330161705.3349825-1-ryan.roberts@arm.com)
but it has a somewhat valid point from the perspective of
num_online_cpus() semantics. We have have num_online_cpus() == 1 while
having a secondary CPU just booted and with its MMU enabled. I don't
think we can have any asynchronous tasks running at that point to
trigger a spit though. Even async_init() is called after smp_init().
An option may be to attempt cpus_read_trylock() as this lock is taken by
_cpu_up(). If it fails, return -EBUSY, otherwise check num_online_cpus()
and unlock (and return -EBUSY if secondaries already started).
Another thing I couldn't get my head around - IIUC is_realm_world()
won't return true for map_mem() yet (if in a realm). Can we have realms
on hardware that does not support BBML2_NOABORT? We may not have
configuration with rodata_full set (it should be complementary to realm
support).
I'll add the patches to for-next/core to give them a bit of time in
-next but let's see next week if we ignore this (with an updated
comment) or we try to avoid the issue altogether.
--
Catalin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- 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