* Re: [PATCH net v4 0/5] nfc: fix multiple OOB reads in NCI and LLCP parsing paths
From: David Heidelberg @ 2026-06-24 16:11 UTC (permalink / raw)
To: Lekë Hapçiu, oe-linux-nfc
Cc: davem, edumazet, kuba, pabeni, krzk, horms, linux-kernel, netdev
In-Reply-To: <20260424180151.3808557-1-snowwlake@icloud.com>
On 24/04/2026 20:01, Lekë Hapçiu wrote:
> This series fixes five out-of-bounds / underflow bugs in the kernel NFC
> stack. All are reachable from a remote NFC peer that the local stack
> has already associated with; in the LLCP cases the peer only needs to
> send a malformed frame.
>
> 1/5 nci: u8 underflow in nci_store_general_bytes_nfc_dep() lets the
> attacker-controlled atr_res_len skip the GT-offset subtraction
> and cause an OOB read/write against general_bytes[].
> 2/5 llcp: parse_gb_tlv() / parse_connection_tlv() trust the TLV
> length byte without checking remaining buffer, and the tlv16
> accessors read past the end when length < 2.
> 3/5 llcp: nfc_llcp_recv_snl() has the same TLV-length trust bug, and
> its SDRES handler uses an unbounded "%.16s" pr_debug() that
> walks past service_name_len.
> 4/5 llcp: nfc_llcp_recv_dm() reads skb->data[3] without checking
> skb->len, giving a 1-byte heap OOB read.
> 5/5 llcp: nfc_llcp_connect_sn() walks the TLV array with no length
> validation; a crafted CONNECT frame drops it into OOB reads /
> an unbounded service-name pointer.
>
> The series applies on top of net/main.
>
> Lekë Hapçiu (5):
> nfc: nci: fix u8 underflow in nci_store_general_bytes_nfc_dep
> nfc: llcp: fix TLV parsing in parse_gb_tlv and parse_connection_tlv
> nfc: llcp: fix TLV parsing OOB in nfc_llcp_recv_snl
> nfc: llcp: fix OOB read of DM reason byte in nfc_llcp_recv_dm
> nfc: llcp: fix TLV parsing OOB in nfc_llcp_connect_sn
>
> net/nfc/llcp_commands.c | 24 ++++++++++++++++++++++--
> net/nfc/llcp_core.c | 35 ++++++++++++++++++++++++++++++++---
> net/nfc/nci/ntf.c | 6 ++++++
> 3 files changed, 60 insertions(+), 5 deletions(-)
>
Hello Lekë,
could you please rebase this series against NFC for-linus branch [1]?
Likely some checks has been added meanwhile, but I would love to get the
remaining ones in!
Don't forget also add NFC mailing list oe-linux-nfc@lists.linux.dev .
Thank you
David
^ permalink raw reply
* Re: [RFC PATCH v1 0/5] perf annotate: Add ARM64 data type profiling support
From: Shuai Xue @ 2026-06-24 16:10 UTC (permalink / raw)
To: Tengda Wu, Namhyung Kim
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Ian Rogers,
Adrian Hunter, James Clark, Zecheng Li, linux-perf-users,
linux-kernel
In-Reply-To: <7f95a323-b2af-4355-abbf-1d1d418fb99a@huaweicloud.com>
On 6/24/26 2:37 PM, Tengda Wu wrote:
> Hi Shuai,
>
> On 2026/6/24 9:51, Shuai Xue wrote:
>> Hi, Namhyung
>>
>> On 6/24/26 12:56 AM, Namhyung Kim wrote:
>>> Hello,
>>>
>>> On Tue, Jun 23, 2026 at 09:02:29PM +0800, Shuai Xue wrote:
>>>> `perf test -v "perf data type profiling tests"` fails on ARM64:
>>>>
>>>> Basic Rust perf annotate test
>>>> perf mem record -o /tmp/perf.data perf test -w code_with_type
>>>> perf annotate --code-with-type -i /tmp/perf.data --stdio --percent-limit 1
>>>> Basic annotate [Failed: missing target data type]
>>>>
>>>> The root cause is that ARM64 lacks the instruction parsing infrastructure
>>>> required for data type profiling. Specifically:
>>>>
>>>> 1. annotate_get_insn_location() cannot extract register numbers and
>>>> memory offsets from ARM64 load/store instructions, because ARM64
>>>> does not set objdump.register_char or objdump.memory_ref_char
>>>> (unlike x86 which uses '%' and '(').
>>>>
>>>> 2. arch_supports_insn_tracking() does not include ARM64, so
>>>> find_data_type_block() cannot perform instruction-level type state
>>>> tracking.
>>>>
>>>> 3. init_type_state() has no ARM64 branch, leaving stack_reg as 0 (x0)
>>>> after memset, which causes x0-based memory accesses to be
>>>> misidentified as stack accesses.
>>>>
>>>> As a result, perf annotate --code-with-type silently produces no type
>>>> annotations on ARM64, and the test grep for "# data-type: struct Buf"
>>>> fails.
>>>>
>>>> This series adds ARM64 data type profiling support following the PowerPC
>>>> model: decode raw 32-bit instruction words rather than parsing objdump
>>>> text. ARM64's fixed-width encoding and trivial DWARF register mapping
>>>> (x0-x30 = DWARF 0-30) make this approach clean and robust.
>>>>
>>>> Three classes of instructions are tracked for register state propagation:
>>>> - ADRP: compute PC-relative page address for global variable resolution
>>>> - ADD (immediate): combine with ADRP result to form full variable address
>>>> - MOV (register): propagate type state between registers
>>>>
>>>> This covers the common `adrp + add + ldr/str` pattern that ARM64
>>>> compilers emit for global variable access.
>>>>
>>>> Known limitations:
>>>> - The `adrp + ldr` pattern (with :lo12: folded into the load offset,
>>>> without an intermediate ADD) is not yet handled. This requires
>>>> extending check_matching_type() to resolve TSR_KIND_CONST with the
>>>> load offset, which can be added incrementally.
>>>> - Pointer chain tracking (load-from-memory propagating type to the
>>>> destination register) is not implemented, matching PowerPC's current
>>>> scope.
>>>>
>>>> Testing:
>>>> All four sub-tests in `perf test "perf data type profiling tests"`
>>>> pass reliably on ARM64 (AArch64, SPE-capable hardware):
>>>> - Basic/Pipe Rust: struct Buf (code_with_type workload)
>>>> - Basic/Pipe C: struct buf (datasym workload, global variable)
>>>>
>>>> Patch breakdown:
>>>> 1/5 Widen type_state_reg::imm_value from u32 to u64 (prerequisite
>>>> for storing 64-bit addresses from ADRP)
>>>> 2/5 Add arch__is_arm64() detection, raw instruction parsing from
>>>> objdump output, and enable show_asm_raw for ARM64
>>>> 3/5 Add get_arm64_regs() to extract registers and memory offsets
>>>> from load/store instruction encodings (4 addressing modes)
>>>> 4/5 Wire up ARM64 in annotate_get_insn_location(),
>>>> arch_supports_insn_tracking(), and init_type_state()
>>>> 5/5 Main patch: instruction classification, ADRP/ADD/MOV register
>>>> state tracking, and architecture initialization
>>>>
>>>> Shuai Xue (5):
>>>> perf annotate-data: Widen type_state_reg::imm_value to u64
>>>> perf disasm: Add ARM64 architecture detection and raw instruction
>>>> parsing
>>>> perf dwarf-regs: Add ARM64 register and offset extraction from raw
>>>> instructions
>>>> perf annotate: Wire up ARM64 data type profiling infrastructure
>>>> perf annotate-arch: Add ARM64 data type profiling support
>>>
>>> Thanks for the contribution!
>>>
>>> There was another series on this, please take a look. I hope you guys
>>> can collaborate.
>>>
>>> https://lore.kernel.org/r/20260403094800.1418825-1-wutengda@huaweicloud.com
>>>
>>
>> Thanks for the pointer! I wasn't aware of Wutengda's series.
>>
>> I'll take a close look at it and compare our approaches. Since both
>> series target ARM64 data type profiling, I'll reach out to Wutengda
>> directly so we can align our efforts and avoid duplicated work.
>>
>>
>> Best regards,
>> Shuai Xue
>>
> Thanks for reaching out!
>
> I'm currently finalizing the v3 of my patch series. Most of the work is
> already done (19/21 patches verified), and I plan to send it out within
> the next few days.
Glad to hear that.
>
> The overall approach remains unchanged and continues to follow the x86
> implementation. However, compared to v2, it includes several bug fixes
> and optimizations addressing known issues.
>
> Once v3 is out, I'd appreciate it if you could review the series and see
> if your specific use cases or ideas can be integrated on top of it.
>
Sure. I am glad to review.
Thanks.
Shuai
^ permalink raw reply
* Patchwork housekeeping for: spi-devel-general
From: patchwork-bot+spi-devel-general @ 2026-06-24 16:09 UTC (permalink / raw)
To: linux-spi, broonie
Latest series: [v2] spi: imx: reconfigure for PIO when DMA cannot be started (2026-06-24T15:19:58)
Superseding: [v1] spi: imx: reconfigure for PIO when DMA cannot be started (2026-06-23T15:32:39):
spi: imx: reconfigure for PIO when DMA cannot be started
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 7/8] md/raid5: raise MAX_STRIPE_BATCH from 8 to 32
From: sashiko-bot @ 2026-06-24 16:09 UTC (permalink / raw)
To: Hiroshi Nishida; +Cc: yukuai, linux-raid
In-Reply-To: <20260624155452.211646-8-nishidafmly@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Increasing MAX_STRIPE_BATCH to 32 without proportionally increasing STRIPE_BATCH_WORKERS serializes stripe processing and causes worker starvation.
--
commit b1a0a169dabd8b46b6b9ca40375034cf879934c6
Author: Hiroshi Nishida <nishidafmly@gmail.com>
md/raid5: raise MAX_STRIPE_BATCH from 8 to 32
This commit increases the maximum stripe batch size from 8 to 32 to
amortize device_lock acquisition over more stripes. It also introduces
STRIPE_BATCH_WORKERS to decouple the worker spawning threshold from the
batch size.
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index c8787ab7b309c..ad6230415af33 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
[ ... ]
> @@ -210,7 +210,7 @@ static void raid5_wakeup_stripe_thread(struct stripe_head *sh)
> /* at least one worker should run to avoid race */
> queue_work_on(sh->cpu, raid5_wq, &group->workers[0].work);
>
> - thread_cnt = group->stripes_cnt / MAX_STRIPE_BATCH - 1;
> + thread_cnt = group->stripes_cnt / STRIPE_BATCH_WORKERS - 1;
> /* wakeup more workers */
> for (i = 1; i < conf->worker_cnt_per_group && thread_cnt > 0; i++) {
[Severity: High]
Will increasing the stripe batch size while keeping the worker spawn threshold
small serialize stripe processing and starve the worker threads?
With this change, raid5_wakeup_stripe_thread() still wakes up an additional
worker for every 8 pending stripes (e.g., waking 4 threads for 32 stripes).
However, the first awakened worker executing handle_active_stripes() will
greedily dequeue up to MAX_STRIPE_BATCH (32) stripes under the lock:
drivers/md/raid5.c:handle_active_stripes() {
...
while (batch_size < MAX_STRIPE_BATCH &&
(sh = __get_priority_stripe(conf, group)) != NULL)
batch[batch_size++] = sh;
...
}
It appears the first thread will steal all 32 pending stripes and process
them sequentially, while the other awakened threads acquire the lock,
find the lists empty, and exit without doing any work.
Could this cause a performance regression by serializing CPU-intensive parity
operations onto a single thread, while also creating unnecessary lock
contention from the starved threads?
> diff --git a/drivers/md/raid5.h b/drivers/md/raid5.h
> index 7aeba1fc7f09e..1f37dabd727be 100644
> --- a/drivers/md/raid5.h
> +++ b/drivers/md/raid5.h
[ ... ]
> @@ -496,7 +496,8 @@ struct disk_info {
> #define BYPASS_THRESHOLD 1
> #define NR_HASH (PAGE_SIZE / sizeof(struct hlist_head))
> #define HASH_MASK (NR_HASH - 1)
> -#define MAX_STRIPE_BATCH 8
> +#define MAX_STRIPE_BATCH 32 /* stripes per handle_active_stripes pass */
> +#define STRIPE_BATCH_WORKERS 8 /* stripes-per-worker threshold for spawning */
> #define RAID5_SYNC_WINDOW 32 /* stripes to pre-submit per sync_request call */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624155452.211646-1-nishidafmly@gmail.com?part=7
^ permalink raw reply
* [pci:next] BUILD SUCCESS 2c2fb7a8aa10e9ca7f2a49d426469ec89e3b267a
From: kernel test robot @ 2026-06-24 16:07 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
branch HEAD: 2c2fb7a8aa10e9ca7f2a49d426469ec89e3b267a Merge branch 'pci/misc'
elapsed time: 1030m
configs tested: 329
configs skipped: 19
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001-20260624 gcc-15.2.0
arc randconfig-001-20260624 gcc-9.5.0
arc randconfig-002-20260624 gcc-15.2.0
arm allnoconfig clang-23
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm davinci_all_defconfig clang-16
arm defconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260624 clang-19
arm randconfig-001-20260624 gcc-15.2.0
arm randconfig-002-20260624 gcc-15.2.0
arm randconfig-002-20260624 gcc-8.5.0
arm randconfig-003-20260624 gcc-15.2.0
arm randconfig-004-20260624 clang-16
arm randconfig-004-20260624 gcc-15.2.0
arm sama5_defconfig gcc-16.1.0
arm tegra_defconfig gcc-16.1.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260624 clang-21
arm64 randconfig-001-20260624 clang-23
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260624 clang-21
arm64 randconfig-002-20260624 clang-23
arm64 randconfig-002-20260624 gcc-15.2.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260624 clang-21
arm64 randconfig-003-20260624 clang-23
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260624 clang-21
arm64 randconfig-004-20260624 clang-23
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001 clang-23
csky randconfig-001-20260624 clang-21
csky randconfig-001-20260624 clang-23
csky randconfig-001-20260624 gcc-16.1.0
csky randconfig-002 clang-23
csky randconfig-002-20260624 clang-21
csky randconfig-002-20260624 clang-23
csky randconfig-002-20260624 gcc-9.5.0
hexagon allmodconfig clang-23
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-16.1.0
hexagon defconfig clang-23
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 clang-23
hexagon randconfig-001-20260624 clang-20
hexagon randconfig-001-20260624 gcc-9.5.0
hexagon randconfig-002 clang-23
hexagon randconfig-002-20260624 clang-23
hexagon randconfig-002-20260624 gcc-9.5.0
i386 allmodconfig clang-22
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001 gcc-12
i386 buildonly-randconfig-001 gcc-14
i386 buildonly-randconfig-001-20260624 gcc-12
i386 buildonly-randconfig-001-20260624 gcc-14
i386 buildonly-randconfig-002 clang-22
i386 buildonly-randconfig-002 gcc-12
i386 buildonly-randconfig-002-20260624 gcc-12
i386 buildonly-randconfig-002-20260624 gcc-14
i386 buildonly-randconfig-003 clang-22
i386 buildonly-randconfig-003 gcc-12
i386 buildonly-randconfig-003-20260624 gcc-12
i386 buildonly-randconfig-004 gcc-12
i386 buildonly-randconfig-004 gcc-14
i386 buildonly-randconfig-004-20260624 gcc-12
i386 buildonly-randconfig-004-20260624 gcc-14
i386 buildonly-randconfig-005 gcc-12
i386 buildonly-randconfig-005 gcc-14
i386 buildonly-randconfig-005-20260624 gcc-12
i386 buildonly-randconfig-005-20260624 gcc-14
i386 buildonly-randconfig-006 gcc-12
i386 buildonly-randconfig-006 gcc-14
i386 buildonly-randconfig-006-20260624 gcc-12
i386 buildonly-randconfig-006-20260624 gcc-14
i386 defconfig clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001 clang-22
i386 randconfig-001-20260624 clang-22
i386 randconfig-001-20260624 gcc-14
i386 randconfig-002 clang-22
i386 randconfig-002-20260624 clang-22
i386 randconfig-002-20260624 gcc-14
i386 randconfig-003 clang-22
i386 randconfig-003-20260624 clang-22
i386 randconfig-003-20260624 gcc-14
i386 randconfig-004 clang-22
i386 randconfig-004-20260624 clang-22
i386 randconfig-004-20260624 gcc-12
i386 randconfig-005 clang-22
i386 randconfig-005-20260624 clang-22
i386 randconfig-006 clang-22
i386 randconfig-006-20260624 clang-22
i386 randconfig-007 clang-22
i386 randconfig-007-20260624 clang-22
i386 randconfig-007-20260624 gcc-14
i386 randconfig-011 clang-22
i386 randconfig-011-20260624 clang-22
i386 randconfig-012 clang-22
i386 randconfig-012-20260624 clang-22
i386 randconfig-012-20260624 gcc-14
i386 randconfig-013 clang-22
i386 randconfig-013 gcc-14
i386 randconfig-013-20260624 clang-22
i386 randconfig-014 clang-22
i386 randconfig-014-20260624 clang-22
i386 randconfig-015 clang-22
i386 randconfig-015 gcc-14
i386 randconfig-015-20260624 clang-22
i386 randconfig-015-20260624 gcc-14
i386 randconfig-016 clang-22
i386 randconfig-016 gcc-14
i386 randconfig-016-20260624 clang-22
i386 randconfig-017 clang-22
i386 randconfig-017 gcc-14
i386 randconfig-017-20260624 clang-22
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-20
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 clang-23
loongarch randconfig-001-20260624 gcc-16.1.0
loongarch randconfig-001-20260624 gcc-9.5.0
loongarch randconfig-002 gcc-16.1.0
loongarch randconfig-002-20260624 gcc-15.2.0
loongarch randconfig-002-20260624 gcc-9.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
m68k defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
microblaze defconfig gcc-16.1.0
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips omega2p_defconfig clang-17
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 defconfig gcc-11.5.0
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260624 gcc-9.5.0
nios2 randconfig-002 gcc-8.5.0
nios2 randconfig-002-20260624 gcc-11.5.0
nios2 randconfig-002-20260624 gcc-9.5.0
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-17
parisc allyesconfig clang-23
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001 gcc-16.1.0
parisc randconfig-001 gcc-8.5.0
parisc randconfig-001-20260624 gcc-16.1.0
parisc randconfig-002 gcc-12.5.0
parisc randconfig-002 gcc-16.1.0
parisc randconfig-002-20260624 gcc-14.3.0
parisc randconfig-002-20260624 gcc-16.1.0
parisc64 defconfig clang-23
parisc64 defconfig gcc-16.1.0
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc asp8347_defconfig clang-23
powerpc g5_defconfig gcc-16.1.0
powerpc randconfig-001 gcc-10.5.0
powerpc randconfig-001 gcc-16.1.0
powerpc randconfig-001-20260624 clang-23
powerpc randconfig-001-20260624 gcc-16.1.0
powerpc randconfig-002 gcc-16.1.0
powerpc randconfig-002 gcc-8.5.0
powerpc randconfig-002-20260624 gcc-16.1.0
powerpc randconfig-002-20260624 gcc-8.5.0
powerpc64 randconfig-001 clang-16
powerpc64 randconfig-001 gcc-16.1.0
powerpc64 randconfig-001-20260624 gcc-16.1.0
powerpc64 randconfig-001-20260624 gcc-8.5.0
powerpc64 randconfig-002 clang-23
powerpc64 randconfig-002 gcc-16.1.0
powerpc64 randconfig-002-20260624 gcc-11.5.0
powerpc64 randconfig-002-20260624 gcc-16.1.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001-20260624 clang-18
riscv randconfig-001-20260624 gcc-13.4.0
riscv randconfig-002-20260624 clang-18
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig clang-18
s390 defconfig gcc-16.1.0
s390 randconfig-001-20260624 clang-18
s390 randconfig-001-20260624 gcc-8.5.0
s390 randconfig-002-20260624 clang-18
s390 randconfig-002-20260624 gcc-10.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-17
sh allyesconfig clang-23
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh defconfig gcc-16.1.0
sh randconfig-001-20260624 clang-18
sh randconfig-001-20260624 gcc-15.2.0
sh randconfig-002-20260624 clang-18
sh randconfig-002-20260624 gcc-9.5.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260624 gcc-14.3.0
sparc randconfig-002-20260624 gcc-14.3.0
sparc64 allmodconfig clang-20
sparc64 defconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260624 gcc-14.3.0
sparc64 randconfig-002-20260624 gcc-14.3.0
um allmodconfig clang-17
um allmodconfig clang-23
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig clang-23
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260624 gcc-14.3.0
um randconfig-002-20260624 gcc-14.3.0
um x86_64_defconfig clang-23
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260624 clang-22
x86_64 buildonly-randconfig-001-20260624 gcc-14
x86_64 buildonly-randconfig-002-20260624 clang-22
x86_64 buildonly-randconfig-003-20260624 clang-22
x86_64 buildonly-randconfig-003-20260624 gcc-14
x86_64 buildonly-randconfig-004-20260624 clang-22
x86_64 buildonly-randconfig-005-20260624 clang-22
x86_64 buildonly-randconfig-005-20260624 gcc-14
x86_64 buildonly-randconfig-006-20260624 clang-22
x86_64 buildonly-randconfig-006-20260624 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 gcc-14
x86_64 randconfig-001-20260624 clang-22
x86_64 randconfig-002 gcc-14
x86_64 randconfig-002-20260624 clang-22
x86_64 randconfig-003 clang-22
x86_64 randconfig-003-20260624 clang-22
x86_64 randconfig-004 clang-22
x86_64 randconfig-004-20260624 clang-22
x86_64 randconfig-004-20260624 gcc-14
x86_64 randconfig-005 gcc-14
x86_64 randconfig-005-20260624 clang-22
x86_64 randconfig-006 clang-22
x86_64 randconfig-006-20260624 clang-22
x86_64 randconfig-006-20260624 gcc-14
x86_64 randconfig-011-20260624 gcc-14
x86_64 randconfig-012-20260624 gcc-14
x86_64 randconfig-013-20260624 gcc-12
x86_64 randconfig-013-20260624 gcc-14
x86_64 randconfig-014-20260624 gcc-14
x86_64 randconfig-015-20260624 gcc-14
x86_64 randconfig-016-20260624 gcc-14
x86_64 randconfig-071 gcc-14
x86_64 randconfig-071-20260624 gcc-14
x86_64 randconfig-072 gcc-14
x86_64 randconfig-072-20260624 clang-22
x86_64 randconfig-072-20260624 gcc-14
x86_64 randconfig-073 gcc-14
x86_64 randconfig-073-20260624 gcc-14
x86_64 randconfig-074 gcc-14
x86_64 randconfig-074-20260624 clang-22
x86_64 randconfig-074-20260624 gcc-14
x86_64 randconfig-075 gcc-14
x86_64 randconfig-075-20260624 gcc-14
x86_64 randconfig-076 gcc-14
x86_64 randconfig-076-20260624 clang-22
x86_64 randconfig-076-20260624 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa randconfig-001-20260624 gcc-14.3.0
xtensa randconfig-002-20260624 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema
From: sashiko-bot @ 2026-06-24 16:07 UTC (permalink / raw)
To: David Heidelberg via B4 Relay; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260624-dt-cirrus-cs35l36-v2-1-74eccdbd8fe4@ixit.cz>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Incorrect `$id` path in the YAML schema breaks cross-referencing.
- [Low] Undefined properties in the dt-schema example cause validation failure.
--
commit 637d0c2cb3168267adcc3eaf3f2d6a7d9fd028f5
Author: David Heidelberg <david@ixit.cz>
ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema
This commit converts the CS35L36 Speaker Amplifier device tree binding from
plain text to YAML schema. It also includes the dai-common.yaml schema for
sound DAI cells and prefix.
> diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
> new file mode 100644
> index 0000000000000..af0acaaefb68e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
> @@ -0,0 +1,224 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/cirrus,cs35l36.yaml#
[Severity: Medium]
Does this $id field break schema cross-referencing? Since this file is located
in the sound/ subdirectory, shouldn't the path exactly match the file location
(e.g., http://devicetree.org/schemas/sound/cirrus,cs35l36.yaml#) to allow
dt_binding_check to resolve references properly?
[ ... ]
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - VA-supply
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
[ ... ]
> + cirrus,boost-ind-nanohenry = <1000>;
> + cirrus,boost-ctl-millivolt = <10000>;
> + cirrus,boost-peak-milliamp = <4500>;
> + cirrus,boost-ctl-select = <0x00>;
> + cirrus,weak-fet-delay = <4>;
> + cirrus,weak-fet-thld = <0x01>;
[Severity: Low]
Will this example fail validation with dt_binding_check due to the
unevaluatedProperties: false restriction?
The example uses cirrus,weak-fet-delay and cirrus,weak-fet-thld, but the
schema defined earlier specifies these properties as cirrus,classh-wk-fet-delay
and cirrus,classh-weak-fet-thld-millivolt.
Additionally, is <0x01> a valid value for the millivolt threshold enum?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-dt-cirrus-cs35l36-v2-1-74eccdbd8fe4@ixit.cz?part=1
^ permalink raw reply
* Re: [PATCH v13 11/22] KVM: selftests: Set up TDX boot parameters region
From: Xiaoyao Li @ 2026-06-24 16:07 UTC (permalink / raw)
To: Lisa Wang, Andrew Jones, Ackerley Tng, Binbin Wu, Chao Gao,
Chenyi Qiang, Dave Hansen, Erdem Aktas, Ira Weiny, Isaku Yamahata,
Kiryl Shutsemau, linux-kselftest, Paolo Bonzini, Pratik R. Sampat,
Reinette Chatre, Rick Edgecombe, Roger Wang, Ryan Afranji,
Sagi Shahar, Sean Christopherson, Shuah Khan, Oliver Upton
Cc: Jeremiah McReynolds, kvm, linux-coco, linux-kernel, x86
In-Reply-To: <20260521-tdx-selftests-v13-v13-11-6983ae4c3a4d@google.com>
On 5/22/2026 7:16 AM, Lisa Wang wrote:
> +void tdx_vm_load_common_boot_parameters(struct kvm_vm *vm)
> +{
> + struct td_boot_parameters *params =
> + addr_gpa2hva(vm, TD_BOOT_PARAMETERS_GPA);
> + u32 cr4;
> +
> + TEST_ASSERT_EQ(vm->mode, VM_MODE_PXXVYY_4K);
Why TDX needs to check it explicitly?
x86's virt_arch_pgd_alloc() already has such assertation. I think we can
just drop it.
^ permalink raw reply
* Re: [PATCH 6/8] md/raid5: allocate worker groups per NUMA node
From: sashiko-bot @ 2026-06-24 16:07 UTC (permalink / raw)
To: Hiroshi Nishida; +Cc: linux-raid, yukuai
In-Reply-To: <20260624155452.211646-7-nishidafmly@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] The patch incorrectly uses a sequential loop index `i` as the NUMA node ID parameter to `kzalloc_node()`.
Pre-existing issues:
- [High] The `worker_groups` array is sized using `num_possible_nodes()` but is indexed by the raw NUMA node ID, leading to out-of-bounds accesses on systems with sparse NUMA node IDs.
--
commit bce08bf6ce446b00da625ff4028f5782b756e17c
Author: Hiroshi Nishida <nishidafmly@gmail.com>
md/raid5: allocate worker groups per NUMA node
alloc_thread_groups() previously allocated all r5worker arrays in a
single kcalloc() block, assigning workers for NUMA node N from node 0
memory. On multi-socket systems this causes remote memory traffic on
every worker->work and worker->temp_inactive_list access.
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 8e9edaaca667b..c8787ab7b309c 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
[ ... ]
> @@ -7336,7 +7340,6 @@ static int alloc_thread_groups(struct r5conf *conf, int cnt, int *group_cnt,
[ ... ]
> *group_cnt = num_possible_nodes();
> - size = sizeof(struct r5worker) * cnt;
> - workers = kcalloc(size, *group_cnt, GFP_NOIO);
> *worker_groups = kzalloc_objs(struct r5worker_group, *group_cnt,
> GFP_NOIO);
[Severity: High]
This isn't a bug introduced by this patch, but could this array sizing cause
an out-of-bounds access on systems with sparse NUMA nodes?
We size the worker_groups array using num_possible_nodes(), which is a count.
On systems with sparse NUMA node IDs (for example, nodes 0 and 8), the array
would only have 2 elements. Later, in raid5_wakeup_stripe_thread(), we index
into this array using cpu_to_group(cpu) which expands to cpu_to_node(cpu).
If a CPU belongs to node 8, we would access conf->worker_groups[8], exceeding
the allocated size and corrupting memory.
> - if (!*worker_groups || !workers) {
> - kfree(workers);
> - kfree(*worker_groups);
> + if (!*worker_groups)
> return -ENOMEM;
> - }
>
> + size = sizeof(struct r5worker) * cnt;
> for (i = 0; i < *group_cnt; i++) {
> - struct r5worker_group *group;
> + struct r5worker_group *group = &(*worker_groups)[i];
> + struct r5worker *workers;
> +
> + workers = kzalloc_node(size, GFP_NOIO, i);
[Severity: High]
Could passing the sequential loop index i directly to kzalloc_node cause a
NULL pointer dereference on systems with sparse NUMA nodes?
Since num_possible_nodes returns a count rather than an upper bound on IDs,
on a system with nodes 0 and 8, i would be evaluated as 1. Passing an
unpopulated node ID to kzalloc_node without validation can lead to a crash
when accessing NODE_DATA(nid). Should this loop use
for_each_node_state(nid, N_MEMORY) or similar to get the actual node ID
instead of using the loop counter?
> + if (!workers)
> + goto out_free;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624155452.211646-1-nishidafmly@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH 30/37] drm/bridge: add drm_bridge_is_tail() to know whether a bridge completes the pipeline
From: Luca Ceresoli @ 2026-06-24 16:06 UTC (permalink / raw)
To: Maxime Ripard, Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260624-vagabond-neon-gorilla-cd6487@houat>
On Wed Jun 24, 2026 at 3:04 PM CEST, Maxime Ripard wrote:
> On Tue, Jun 09, 2026 at 10:23:24AM +0200, Luca Ceresoli wrote:
>> Hi Maxime,
>>
>> thanks for the review of this long series!
>>
>> On Mon Jun 8, 2026 at 2:34 PM CEST, Maxime Ripard wrote:
>> ...
>> >> --- a/include/drm/drm_bridge.h
>> >> +++ b/include/drm/drm_bridge.h
>> >> @@ -78,6 +78,19 @@ struct drm_bridge_funcs {
>> >> int (*attach)(struct drm_bridge *bridge, struct drm_encoder *encoder,
>> >> enum drm_bridge_attach_flags flags);
>> >>
>> >> + /**
>> >> + * @is_tail:
>> >> + *
>> >> + * Returns true if this is a tail bridge, i.e. it does not need a
>> >> + * next bridge to work. E.g. a panel_bridge is a tail bridge, a
>> >> + * DSI-to-LVDS bridge is not a tail bridge (no matter whether the
>> >> + * next bridge is present or not).
>> >
>> > Why a DSI-to-LDVS bridge isn't a tail bridge? It only needs a panel
>> > next, right?
>>
>> Uhm, good point, but I'd say it can be a tail bridge or not: in the
>> ATTACH_NO_CONNECTOR case it will need a bridge (a panel_bridge most
>> likely), no?
>
> Yeah, I think it cannot (always) be a blanket statement from the driver.
> For drivers that do not support ATTACH_NO_CONNECTOR, then it's always
> going to be a tail, but if the driver supports it, we should use a
> helper because it's going to depend on the DT, basically.
>
>> However this is possibly irrelevant as the whole .is_tail is meant to
>> disappear in v2, see below.
>>
>> >> + * The @is_tail callback is optional but it is required if the
>> >> + * bridge is part of a pipeline with hot-pluggable components.
>> >> + */
>> >> + bool (*is_tail)(struct drm_bridge *bridge);
>> >> +
>> >
>> > I don't think that's the right way to think about it, if only because
>> > you never really know at the driver level if you're supposed to be last
>> > or not. A DSI-to-LVDS bridge might just as well be chained with an
>> > LVDS-to-eDP bridge, or feed the panel directly without any additional
>> > bridge.
>> >
>> > I *think* that what you're trying to find out here is whether the chain
>> > is complete or not.
>>
>> You nailed it.
>>
>> That was the main point discussed during the Display Next Hackfest 2026
>> (see the report [0]) and we all agreed the .is_tail along with the
>> -EPROBE_DEFER changes (patches 20+35) are not a good approach.
>>
>> This is actually the most crucial aspect of the whole work still not having
>> no well-defined solution.
>
> Ok
>
>> > I think you can get the same information by checking
>> > whether you have a connector for that bridge chain. If you don't, you
>> > know the chain isn't complete, and if you do, it's supposed to be.
>>
>> There's a checken-egg problem here. Knowing whether the pipeline is
>> complete or not is needed to know whether we have to create a
>> connector. See patch 36:
>>
>> + if (drm_bridge_connector_pipeline_is_complete(bridge_connector))
>> + drm_bridge_connector_add_connector(bridge_connector);
>>
>> So the question is still open, what I need the most right now is comments
>> on the overall architecture of this aspecs. Maybe replying to [0] can be
>> more effective than here.
>>
>> In a nutshell what we need is:
>>
>> * when a bridge needs a following element (a bridge, or a panel which
>> however might/should have a panel_bridge), but that element is not
>> present, instead of deferring the whole card probe the card should be
>> allowed to probe but without a connector
>>
>> * when something is added to an incomplete pipeline we need to know
>> whether the pipeline has become complete (in order to create the
>> connector)
>>
>> How to implement this is still an open point. I'll welcome proposals in
>> addition to the ones in [0].
>
> Thanks for the notes, I think I largely agree with the discussion.
Good! :)
> Reading through it, I thought it would be nice for a new callback called
> get_next_bridge or something that would return either an error, NULL or a
> (refcounted) pointer to the next bridge in the chain. And have some kind
> of special error (ENODEV?) when the bridge should be there but isn't
> (and thus the chain isn't complete).
I initially preferred exposing the fwnode of the next bridge as discussed
with Dmitry during the Display Next Hackfest, which looks simpler for
driver writers. But then I realized it would be tricyk in cases such as
dual-LVDS output bridges (ti-sn65dsi83.c) which have two output ports in
DT, none of which is mandatory. So I've come to thinking a callback is
better as it should be flexible enough.
Picking the best errno is probably the only aspect needing special
attention now.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [GIT PULL] tracing: More updates for 7.2
From: Steven Rostedt @ 2026-06-24 16:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: LKML, Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers,
Andrew Morton, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Peter Zijlstra, Julia Lawall, Yury Norov
Linus,
More tracing updates for 7.2:
- Move non-trace_printk() functions into trace_controls.h
Several tracing controls and output function prototypes were included in
kernel.h. When trace_printk.h was created, all of them were moved from
kernel.h into trace_printk.h. Several of those functions have nothing to
do with trace_printk() but instead are used to start, stop tracing as
well as trigger stack traces into the tracing buffer or dump it to the
console. Create a new header called trace_controls.h and move these
functions into that file from trace_printk.h.
- Remove the include of trace_printk.h from kernel.h.
Instead of having trace_printk.h indirectly included in all files of the
kernel for debugging purposes, require trace_printk.h to be included on
a per file bases when it is needed. The locations in the kernel that
reference trace_printk() now have a direct include of trace_printk.h.
Note, I applied and tested this on your latest commit from yesterday to
make sure it works and I didn't miss other possible use cases that needed
the includes.
Please pull the latest trace-v7.2-2 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
trace-v7.2-2
Tag SHA1: 38ba0725f41b26abf4295138c02653d2372a8e26
Head SHA1: 9cbc3d9806d31abda2718ceac587ddee3a04849b
Steven Rostedt (2):
tracing: Move non-trace_printk prototypes into trace_controls.h
tracing: Remove trace_printk.h from kernel.h
----
arch/powerpc/kvm/book3s_xics.c | 1 +
arch/powerpc/xmon/xmon.c | 1 +
arch/s390/kernel/ipl.c | 1 +
arch/s390/kernel/machine_kexec.c | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
drivers/gpu/drm/i915/i915_gem.h | 2 ++
drivers/hwtracing/stm/dummy_stm.c | 1 +
drivers/infiniband/hw/hfi1/trace_dbg.h | 1 +
drivers/tty/sysrq.c | 1 +
drivers/usb/early/xhci-dbc.c | 1 +
fs/ext4/inline.c | 1 +
include/linux/ftrace.h | 2 ++
include/linux/kernel.h | 1 -
include/linux/sunrpc/debug.h | 1 +
include/linux/trace_controls.h | 54 ++++++++++++++++++++++++++++++++
include/linux/trace_printk.h | 56 ++--------------------------------
kernel/debug/debug_core.c | 1 +
kernel/panic.c | 1 +
kernel/rcu/rcu.h | 2 ++
kernel/rcu/rcutorture.c | 1 +
kernel/trace/ring_buffer_benchmark.c | 1 +
kernel/trace/trace.h | 1 +
kernel/trace/trace_benchmark.c | 1 +
lib/sys_info.c | 1 +
samples/fprobe/fprobe_example.c | 1 +
samples/ftrace/ftrace-direct-too.c | 1 -
samples/trace_printk/trace-printk.c | 1 +
27 files changed, 83 insertions(+), 55 deletions(-)
create mode 100644 include/linux/trace_controls.h
---------------------------
^ permalink raw reply
* Re: [PATCH v5 01/15] drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips
From: Harry Wentland @ 2026-06-24 16:06 UTC (permalink / raw)
To: Thomas Zimmermann, mripard, maarten.lankhorst, airlied, airlied,
simona, admin, gargaditya08, paul, jani.nikula, mhklkml,
zack.rusin, bcm-kernel-feedback-list, sunpeng.li, siqueira,
alexander.deucher, rodrigo.vivi, joonas.lahtinen, tursulin,
javierm, dmitry.osipenko, gurchetansingh, olvaffe
Cc: dri-devel, linux-hyperv, intel-gfx, intel-xe, linux-mips,
virtualization, amd-gfx, Zack Rusin, stable
In-Reply-To: <20260610152505.260172-2-tzimmermann@suse.de>
On 2026-06-10 11:18, Thomas Zimmermann wrote:
> The mode-setting pipeline can disabled damage clippings for a commit
> by setting ignore_damage_clips in struct drm_plane_state. The commit
> will then do a full display update.
>
> Test the flag in DCN code and do a full update in DCN code if it has
> been set.
>
> Commit 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers
> to ignore damage clips") introduced ignore_damage_clips to selectively
> ignore damage clipping in certain framebuffer changes. This driver does
> not do that, but DRM's damage iterator will soon rely on the flag.
> Therefore supporting it here as well make sense for consistency.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Fixes: 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers to ignore damage clips")
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Zack Rusin <zackr@vmware.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: <stable@vger.kernel.org> # v6.8+
While I haven't looked thoroughly at the rest of the series this
patch for amdgpu_dm looks fine.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 0e20194e6662..4cbb27f65a0b 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6614,8 +6614,8 @@ static void fill_dc_dirty_rects(struct drm_plane *plane,
> {
> struct dm_crtc_state *dm_crtc_state = to_dm_crtc_state(crtc_state);
> struct rect *dirty_rects = flip_addrs->dirty_rects;
> - u32 num_clips;
> - struct drm_mode_rect *clips;
> + u32 num_clips = 0;
> + struct drm_mode_rect *clips = NULL;
> bool bb_changed;
> bool fb_changed;
> u32 i = 0;
> @@ -6631,8 +6631,10 @@ static void fill_dc_dirty_rects(struct drm_plane *plane,
> if (new_plane_state->rotation != DRM_MODE_ROTATE_0)
> goto ffu;
>
> - num_clips = drm_plane_get_damage_clips_count(new_plane_state);
> - clips = drm_plane_get_damage_clips(new_plane_state);
> + if (!new_plane_state->ignore_damage_clips) {
> + num_clips = drm_plane_get_damage_clips_count(new_plane_state);
> + clips = drm_plane_get_damage_clips(new_plane_state);
> + }
>
> if (num_clips && (!amdgpu_damage_clips || (amdgpu_damage_clips < 0 &&
> is_psr_su)))
^ permalink raw reply
* Re: [OE-core][PATCH v3 5/8] Add SPDX deploy tasks to various recipes
From: Joshua Watt @ 2026-06-24 16:05 UTC (permalink / raw)
To: Mikko Rapeli; +Cc: openembedded-core
In-Reply-To: <ajvqUhlN4Ge2MzG_@nuoska>
On Wed, Jun 24, 2026 at 8:31 AM Mikko Rapeli <mikko.rapeli@linaro.org> wrote:
>
> Hi,
>
> On Wed, Jun 24, 2026 at 08:15:22AM -0600, Joshua Watt via lists.openembedded.org wrote:
> > Adds SPDX deploy tasks to many recipes to record their output when
> > consumed in an SBoM
> >
> > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
> > ---
> > meta/classes-recipe/barebox.bbclass | 1 +
> > meta/classes-recipe/devicetree.bbclass | 1 +
> > meta/classes-recipe/kernel-fit-image.bbclass | 1 +
> > meta/classes-recipe/kernel.bbclass | 1 +
> > meta/recipes-bsp/grub/grub-efi_2.14.bb | 1 +
> > meta/recipes-bsp/opensbi/opensbi_1.8.1.bb | 1 +
> > meta/recipes-bsp/u-boot/u-boot.inc | 1 +
> > meta/recipes-core/systemd/systemd-boot_259.5.bb | 2 +-
> > 8 files changed, 8 insertions(+), 1 deletion(-)
>
> Why not doing this in deploy.bbclass for all users of the class?
We probably could do that; I guess I'd like some feedback if anyone
else thinks that's a good idea or not. I initially did it this way
just to minimize disruption
>
> Cheers
>
> -Mikko
>
> > diff --git a/meta/classes-recipe/barebox.bbclass b/meta/classes-recipe/barebox.bbclass
> > index 2411fb5caa..60437c1ad1 100644
> > --- a/meta/classes-recipe/barebox.bbclass
> > +++ b/meta/classes-recipe/barebox.bbclass
> > @@ -158,5 +158,6 @@ barebox_do_deploy () {
> > fi
> > }
> > addtask deploy after do_compile
> > +SPDX_DEPLOY_TASKS += "do_deploy"
> >
> > EXPORT_FUNCTIONS do_configure do_compile do_install do_deploy
> > diff --git a/meta/classes-recipe/devicetree.bbclass b/meta/classes-recipe/devicetree.bbclass
> > index ce9d008aac..35c2499bdb 100644
> > --- a/meta/classes-recipe/devicetree.bbclass
> > +++ b/meta/classes-recipe/devicetree.bbclass
> > @@ -164,6 +164,7 @@ devicetree_do_deploy() {
> > done
> > }
> > addtask deploy before do_build after do_install
> > +SPDX_DEPLOY_TASKS += "do_deploy"
> >
> > EXPORT_FUNCTIONS do_compile do_install do_deploy
> >
> > diff --git a/meta/classes-recipe/kernel-fit-image.bbclass b/meta/classes-recipe/kernel-fit-image.bbclass
> > index ae8f3c6688..5115482eff 100644
> > --- a/meta/classes-recipe/kernel-fit-image.bbclass
> > +++ b/meta/classes-recipe/kernel-fit-image.bbclass
> > @@ -241,3 +241,4 @@ do_deploy() {
> > fi
> > }
> > addtask deploy after do_compile before do_build
> > +SPDX_DEPLOY_TASKS += "do_deploy"
> > diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-recipe/kernel.bbclass
> > index 50cef17f69..8d0cb91688 100644
> > --- a/meta/classes-recipe/kernel.bbclass
> > +++ b/meta/classes-recipe/kernel.bbclass
> > @@ -842,6 +842,7 @@ kernel_do_deploy() {
> > do_deploy[prefuncs] += "read_subpackage_metadata"
> >
> > addtask deploy after do_install do_populate_sysroot do_packagedata
> > +SPDX_DEPLOY_TASKS += "do_deploy"
> >
> > EXPORT_FUNCTIONS do_deploy
> >
> > diff --git a/meta/recipes-bsp/grub/grub-efi_2.14.bb b/meta/recipes-bsp/grub/grub-efi_2.14.bb
> > index 6354b43989..e535d99710 100644
> > --- a/meta/recipes-bsp/grub/grub-efi_2.14.bb
> > +++ b/meta/recipes-bsp/grub/grub-efi_2.14.bb
> > @@ -97,6 +97,7 @@ do_deploy() {
> > }
> >
> > addtask deploy after do_install before do_build
> > +SPDX_DEPLOY_TASKS += "do_deploy"
> >
> > FILES:${PN} = "${libdir}/grub/${GRUB_TARGET}-efi \
> > ${datadir}/grub \
> > diff --git a/meta/recipes-bsp/opensbi/opensbi_1.8.1.bb b/meta/recipes-bsp/opensbi/opensbi_1.8.1.bb
> > index 0a9652c283..93646a97df 100644
> > --- a/meta/recipes-bsp/opensbi/opensbi_1.8.1.bb
> > +++ b/meta/recipes-bsp/opensbi/opensbi_1.8.1.bb
> > @@ -45,6 +45,7 @@ do_deploy () {
> > }
> >
> > addtask deploy before do_build after do_install
> > +SPDX_DEPLOY_TASKS += "do_deploy"
> >
> > FILES:${PN} += "/share/opensbi/*/${RISCV_SBI_PLAT}/firmware/fw_jump.*"
> > FILES:${PN} += "/share/opensbi/*/${RISCV_SBI_PLAT}/firmware/fw_payload.*"
> > diff --git a/meta/recipes-bsp/u-boot/u-boot.inc b/meta/recipes-bsp/u-boot/u-boot.inc
> > index a75948dfc3..acc2bf9819 100644
> > --- a/meta/recipes-bsp/u-boot/u-boot.inc
> > +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> > @@ -471,3 +471,4 @@ uboot_deploy_spl () {
> > }
> >
> > addtask deploy before do_build after do_compile
> > +SPDX_DEPLOY_TASKS += "do_deploy"
> > diff --git a/meta/recipes-core/systemd/systemd-boot_259.5.bb b/meta/recipes-core/systemd/systemd-boot_259.5.bb
> > index c6c443f929..c887835806 100644
> > --- a/meta/recipes-core/systemd/systemd-boot_259.5.bb
> > +++ b/meta/recipes-core/systemd/systemd-boot_259.5.bb
> > @@ -72,4 +72,4 @@ do_deploy () {
> > }
> >
> > addtask deploy before do_build after do_compile
> > -
> > +SPDX_DEPLOY_TASKS += "do_deploy"
> > --
> > 2.54.0
> >
>
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#239514): https://lists.openembedded.org/g/openembedded-core/message/239514
> > Mute This Topic: https://lists.openembedded.org/mt/119957548/7159507
> > Group Owner: openembedded-core+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mikko.rapeli@linaro.org]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >
>
^ permalink raw reply
* Re: [PATCH V3 0/3] Ensure ordered namespace registration during async scan
From: Maurizio Lombardi @ 2026-06-24 16:05 UTC (permalink / raw)
To: Hannes Reinecke, Keith Busch
Cc: Maurizio Lombardi, John Meneghini, Maurizio Lombardi, hch,
chaitanyak, bvanassche, linux-scsi, linux-nvme, James.Bottomley,
emilne, bgurney
In-Reply-To: <d46493a3-3c9c-4799-bd63-e8759f04463c@suse.de>
On Mon Jun 22, 2026 at 9:15 AM CEST, Hannes Reinecke wrote:
>
> In general I fail to see the issue here.
> Any modern distro should be using persistent device links to access
> devices, so the actual device name is pretty much irrelevant.
> We on our side haven't had any issues here since ages.
In principle, I agree with you that persistent links are best practice.
That said, many users still rely on /dev/nvmeXnY links, for example for
some nvme-cli commands. Because kernel 6.11 made these names totally
random across reboots, it's causing some confusion for them.
But yes, I totally understand the reason why you don't perceive this as
an issue.
Maurizio
^ permalink raw reply
* Re: [PATCH v3 23/23] xen/riscv: add initial dom0less infrastructure support
From: Oleksii Kurochko @ 2026-06-24 16:04 UTC (permalink / raw)
To: Jan Beulich
Cc: Romain Caritey, Alistair Francis, Connor Davis, Andrew Cooper,
Anthony PERARD, Michal Orzel, Julien Grall, Roger Pau Monné,
Stefano Stabellini, xen-devel
In-Reply-To: <74d47657-2fa2-4f8f-93f6-cdd96c99ce11@suse.com>
On 6/23/26 10:36 AM, Jan Beulich wrote:
> On 17.06.2026 13:17, Oleksii Kurochko wrote:
>> Enable dom0less support for RISC-V by selecting HAS_DOM0LESS and
>> providing the minimal architecture hooks required by the common
>> dom0less infrastructure.
>>
>> Add stub implementations for architecture-specific helpers used when
>> building domains from the device tree. These currently perform no
>> additional work but allow the generic dom0less code to build and run
>> on RISC-V.
>>
>> Introduce max_init_domid as a runtime variable rather than a constant
>> so that it can be updated during dom0less domain creation.
>>
>> Provide missing helpers and definitions required by the domain
>> construction code, including domain bitness helpers and the
>> p2m_set_allocation() prototype.
>>
>> Additionally define the guest magic memory region in the public
>> RISC-V interface. GUEST_MAGIC_BASE is placed at 0x79000000 to avoid
>> overlapping with the QEMU RISC-V virt machine address space.
>
> No qemu comes into play so far (and likely such also isn't planned).
> Then why would such an overlap be problematic? Plus as before, the
> constraints on such arbitrarily chosen numbers want putting down in
> a code comment next to the respective #define-s.
You're right QEMU isn't used directly, so my wording was misleading.
I used QEMU's RISC-V virt machine memory layout [1] as a reference when
laying out the guest's physical address map, but the value itself is
arbitrary. The only real constraint is that the GUEST_MAGIC_SIZE region
must not overlap guest RAM or the emulated device regions; since the RAM
bank sizes are known, it could equally be placed in a hole after a RAM
bank rather than below GUEST_RAM0_BASE. I'll drop the QEMU mention from
the commit message and document this constraint in a comment next to the
#define-s instead.
/*
* The guest magic region holds Xen-reserved pages mapped into the guest's
* physical address space (shared info, grant table, etc.). The only real
* constraint is that the GUEST_MAGIC_SIZE-byte region must not overlap
* guest RAM (the GUEST_RAMx banks) or the emulated device regions defined
* above; the exact base is otherwise arbitrary. Here it is placed in the
* unused gap below GUEST_RAM0_BASE (0x80000000), but a hole after a RAM
* bank would work equally well.
*/
#define GUEST_MAGIC_BASE _ULL(0x79000000)
#define GUEST_MAGIC_SIZE _ULL(0x01000000)
[1] https://elixir.bootlin.com/qemu/v11.0.1/source/hw/riscv/virt.c#L82
>
>> --- a/xen/arch/riscv/domain-build.c
>> +++ b/xen/arch/riscv/domain-build.c
>> @@ -156,9 +156,22 @@ int __init make_cpus_node(const struct domain *d, struct kernel_info *kinfo)
>> return fdt_end_node(fdt);
>> }
>>
>> +int __init construct_hwdom(struct kernel_info *kinfo,
>> + const struct dt_device_node *node)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +
>> int __init make_timer_node(const struct kernel_info *kinfo)
>> {
>> /* There is no need for timer node for RISC-V. */
>>
>> return 0;
>> }
>> +
>> +int __init make_hypervisor_node(struct domain *d,
>> + const struct kernel_info *kinfo,
>> + int addrcells, int sizecells)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>
> In the description you say "to build and run". How come "run" is actually
> true when these two new stubs return an error? For construct_hwdom() this
> may be explained by you not aiming at supporting Dom0 / hwdom (but that
> then still is a limitation to mention, perhaps in a TODO comment), but
> with DOM0LESS_ENHANCED_NO_XS set make_hypervisor_node() failing is going
> to break DomU building as well, afaics.
You're right. I've dropped "run" from the description, since some other
stuff should be introduced to make dom0less guest domain to be runnable.
Regarding make_hypervisor_node(): it's true that returning an error
breaks DomU building too, not only Dom0. As you mentioned it's
acceptable for the moment only because no RISC-V domain currently sets
DOM0LESS_ENHANCED_NO_XS, so the failing path is never taken in practice.
I'll add a TODO comment to make this limitation explicit:
/*
* TODO: Generating the hypervisor node isn't implemented yet.
Returning
* an error here breaks building of any domain (DomU included) whose
* dom0less_feature has DOM0LESS_ENHANCED_NO_XS set. This is
harmless for
* now because Dom0/hwdom construction isn't supported on RISC-V yet
* either, and no RISC-V DomU sets that flag, so this path is never
taken.
* It must be implemented before DOM0LESS_ENHANCED_NO_XS is used.
*/
>
>> --- a/xen/arch/riscv/include/asm/setup.h
>> +++ b/xen/arch/riscv/include/asm/setup.h
>> @@ -5,7 +5,9 @@
>>
>> #include <xen/types.h>
>>
>> -#define max_init_domid (0)
>> +#include <public/xen.h>
>> +
>> +extern domid_t max_init_domid;
>
> Shouldn't this be generalized, seeing that dom0less code requires it this
> way on every arch? Same ...
>
>> --- a/xen/arch/riscv/setup.c
>> +++ b/xen/arch/riscv/setup.c
>> @@ -33,6 +33,8 @@
>> #include <asm/traps.h>
>> #include <asm/vsbi.h>
>>
>> +domid_t __initdata max_init_domid;
>
> ... for the placement of this then, obviously.
I tried here to introduce less changes.
Also considering that max_init_domid is used in console.c code after
init is freed it seems like it is incorrect to use __initdata here. So
what Arm is using better suites (__read_mostly).
If you think it would be better to do just now instead of later then I
would suggest something like this:diff --git
a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 0adfa4993a8f..2af780512540 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -25,8 +25,6 @@ struct map_range_data
struct rangeset *irq_ranges;
};
-extern domid_t max_init_domid;
-
void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
size_t estimate_efi_size(unsigned int mem_nr_banks);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 6310a47d68b6..86532d0a35b6 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -62,8 +62,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo;
bool __read_mostly acpi_disabled;
#endif
-domid_t __read_mostly max_init_domid;
-
static __used void noreturn init_done(void)
{
/* Must be done past setting system_state. */
diff --git a/xen/arch/ppc/include/asm/setup.h
b/xen/arch/ppc/include/asm/setup.h
index e4f64879b68c..956fa6985adb 100644
--- a/xen/arch/ppc/include/asm/setup.h
+++ b/xen/arch/ppc/include/asm/setup.h
@@ -1,6 +1,4 @@
#ifndef __ASM_PPC_SETUP_H__
#define __ASM_PPC_SETUP_H__
-#define max_init_domid (0)
-
#endif /* __ASM_PPC_SETUP_H__ */
diff --git a/xen/arch/riscv/include/asm/setup.h
b/xen/arch/riscv/include/asm/setup.h
index 678b65ac1e54..73ce2f293348 100644
--- a/xen/arch/riscv/include/asm/setup.h
+++ b/xen/arch/riscv/include/asm/setup.h
@@ -5,10 +5,6 @@
#include <xen/types.h>
-#include <public/xen.h>
-
-extern domid_t max_init_domid;
-
void setup_mm(void);
void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 05708039ab54..e30e4624f882 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -39,8 +39,6 @@
#include <asm/traps.h>
#include <asm/vsbi.h>
-domid_t __initdata max_init_domid;
-
/* Xen stack for bringing up the first CPU. */
unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
__aligned(STACK_SIZE);
diff --git a/xen/arch/x86/include/asm/setup.h
b/xen/arch/x86/include/asm/setup.h
index b01e83a8ed9f..5925c5f39cff 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -68,6 +68,4 @@ extern bool opt_dom0_verbose;
extern bool opt_dom0_cpuid_faulting;
extern bool opt_dom0_msr_relaxed;
-#define max_init_domid (0)
-
#endif
diff --git a/xen/common/domid.c b/xen/common/domid.c
index b0258e477c1a..cc5f468a30de 100644
--- a/xen/common/domid.c
+++ b/xen/common/domid.c
@@ -9,6 +9,15 @@
*/
#include <xen/domain.h>
+#include <xen/dom0less-build.h>
+
+#ifdef CONFIG_DOM0LESS_BOOT
+/*
+ * Highest domain ID assigned to a boot-time (dom0less) domain. Read at
runtime
+ * by the console serial-input switcher, so it must not be __initdata.
+ */
+domid_t __read_mostly max_init_domid;
+#endif
static DEFINE_SPINLOCK(domid_lock);
static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index bcd6d261491b..4c09f4c7a984 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -31,6 +31,7 @@
#include <xen/warning.h>
#include <xen/pv_console.h>
#include <asm/setup.h>
+#include <xen/dom0less-build.h>
#include <xen/sections.h>
#include <xen/consoled.h>
diff --git a/xen/include/xen/dom0less-build.h
b/xen/include/xen/dom0less-build.h
index 4118dec76c0a..8d4da16d1f0a 100644
--- a/xen/include/xen/dom0less-build.h
+++ b/xen/include/xen/dom0less-build.h
@@ -5,6 +5,8 @@
#include <xen/stdbool.h>
+#include <public/xen.h>
+
struct domain;
#ifdef CONFIG_DOM0LESS_BOOT
@@ -13,6 +15,9 @@ struct boot_domain;
struct dt_device_node;
struct kernel_info;
+/* Highest domain ID assigned to a boot-time (dom0less) domain. */
+extern domid_t max_init_domid;
+
/*
* List of possible features for dom0less domUs
*
@@ -72,6 +77,8 @@ static inline bool is_dom0less_mode(void)
}
static inline void set_xs_domain(struct domain *d) {}
+#define max_init_domid 0
+
#endif /* CONFIG_DOM0LESS_BOOT */
#endif /* __ASM_GENERIC_DOM0LESS_BUILD_H__ */
Thanks.
~ Oleksii
^ permalink raw reply related
* [PATCH v3] selftests/cgroup: Adjust cpu test duration based on HZ
From: Joe Simmons-Talbott @ 2026-06-24 16:03 UTC (permalink / raw)
To: Tejun Heo, Johannes Weiner, Michal Koutný, Shuah Khan
Cc: Joe Simmons-Talbott, cgroups, linux-kselftest, linux-kernel
For lower HZ values a quota of 1000us is much lower than the amount
of microseconds per tick which makes the tests test_cpucg_max and
test_cpugc_max_nested fail. Increase the test duration to accommodate
for lower HZ values.
Link: https://lore.kernel.org/lkml/20260623194239.GA899029@oak/
Signed-off-by: Joe Simmons-Talbott <joest@redhat.com>
---
v2 -> v3:
- Instead of changing cpu.max quota extend the test duration based on
the HZ value.
- don't call pclose() if popen() fails.
- check return value of fscanf().
v1 -> v2:
- Try checking /proc/config.gz to get the actual kernel HZ value and
fallback to 1000 if the value cannot be determined.
tools/testing/selftests/cgroup/test_cpu.c | 44 ++++++++++++++++++++---
1 file changed, 40 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/cgroup/test_cpu.c b/tools/testing/selftests/cgroup/test_cpu.c
index 7a40d76b9548..feb7eb6a875c 100644
--- a/tools/testing/selftests/cgroup/test_cpu.c
+++ b/tools/testing/selftests/cgroup/test_cpu.c
@@ -639,6 +639,30 @@ test_cpucg_nested_weight_underprovisioned(const char *root)
return run_cpucg_nested_weight_test(root, false);
}
+/*
+ * Best effort attempt to get the kernel's HZ value from the config.
+ * Return the HZ value if found otherwise return -1 to indicate failure.
+ */
+static long
+_get_config_hz(void)
+{
+ long hz = -1;
+ FILE *f;
+ char cmd[256] = "zcat /proc/config.gz 2>/dev/null | grep '^CONFIG_HZ='";
+
+ f = popen(cmd, "r");
+
+ if (!f)
+ return hz;
+
+ if (fscanf(f, "CONFIG_HZ=%ld", &hz) == EOF)
+ goto out;
+
+out:
+ pclose(f);
+ return hz;
+}
+
/*
* This test creates a cgroup with some maximum value within a period, and
* verifies that a process in the cgroup is not overscheduled.
@@ -646,15 +670,21 @@ test_cpucg_nested_weight_underprovisioned(const char *root)
static int test_cpucg_max(const char *root)
{
int ret = KSFT_FAIL;
+ long hz = _get_config_hz();
long quota_usec = 1000;
long default_period_usec = 100000; /* cpu.max's default period */
- long duration_seconds = 1;
+ long duration_seconds;
- long duration_usec = duration_seconds * USEC_PER_SEC;
+ long duration_usec;
long usage_usec, n_periods, remainder_usec, expected_usage_usec;
char *cpucg;
char quota_buf[32];
+ if (hz == -1)
+ hz = 1000;
+ duration_seconds = 1000 / hz;
+ duration_usec = duration_seconds * USEC_PER_SEC;
+
snprintf(quota_buf, sizeof(quota_buf), "%ld", quota_usec);
cpucg = cg_name(root, "cpucg_test");
@@ -710,15 +740,21 @@ static int test_cpucg_max(const char *root)
static int test_cpucg_max_nested(const char *root)
{
int ret = KSFT_FAIL;
+ long hz = _get_config_hz();
long quota_usec = 1000;
long default_period_usec = 100000; /* cpu.max's default period */
- long duration_seconds = 1;
+ long duration_seconds;
- long duration_usec = duration_seconds * USEC_PER_SEC;
+ long duration_usec;
long usage_usec, n_periods, remainder_usec, expected_usage_usec;
char *parent, *child;
char quota_buf[32];
+ if (hz == -1)
+ hz = 1000;
+ duration_seconds = 1000 / hz;
+ duration_usec = duration_seconds * USEC_PER_SEC;
+
snprintf(quota_buf, sizeof(quota_buf), "%ld", quota_usec);
parent = cg_name(root, "cpucg_parent");
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 04/13] mm/page_alloc: relax GFP WARN in nolock allocs
From: Suren Baghdasaryan @ 2026-06-24 16:04 UTC (permalink / raw)
To: Brendan Jackman
Cc: Andrew Morton, Vlastimil Babka, Michal Hocko, Johannes Weiner,
Zi Yan, Muchun Song, Oscar Salvador, David Hildenbrand,
Lorenzo Stoakes, Liam R. Howlett, Mike Rapoport, Matthew Brost,
Joshua Hahn, Rakie Kim, Byungchul Park, Ying Huang,
Alistair Popple, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Sebastian Andrzej Siewior, Clark Williams,
Steven Rostedt, Harry Yoo (Oracle), Gregory Price,
Alexei Starovoitov, Matthew Wilcox, linux-mm, linux-kernel,
linux-rt-devel
In-Reply-To: <20260622-alloc-trylock-v2-4-31f31367d420@google.com>
On Mon, Jun 22, 2026 at 3:01 AM Brendan Jackman <jackmanb@google.com> wrote:
>
> This WARN forbids setting other flags than __GFP_ACCOUNT but we
> unconditionally set the ones in gfp_nolock so they are certainly fine
> for the caller to set.
>
> There are other GFP flags that are almost certainly fine to set here;
> Willy noted GFP_HIGHMEM, GFP_DMA, GFP_MOVABLE and GFP_HARDWALL. But,
> nolock allocation is rather special, so be conservative to try and
> ensure we have a chance to think carefully before nontrivial new
> usecases arise.
>
> Suggested-by: Matthew Wilcox <willy@infradead.org>
> Link: https://lore.kernel.org/linux-mm/ajS96fWbG4dzP3u3@casper.infradead.org/
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> ---
> mm/page_alloc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index e31babe2181a1..074e007bf1bc3 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5337,7 +5337,8 @@ struct page *__alloc_frozen_pages_noprof(gfp_t gfp, unsigned int order,
> return NULL;
>
> if (alloc_flags & ALLOC_NOLOCK) {
> - VM_WARN_ON_ONCE(gfp & ~__GFP_ACCOUNT);
> + /* Certain other flags could be supported later if needed. */
> + VM_WARN_ON_ONCE(gfp & ~(__GFP_ACCOUNT | gfp_nolock));
> if (!alloc_trylock_allowed())
> return NULL;
> gfp |= gfp_nolock;
>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH 4/5] md: use sector_t for recovery_active in status_resync()
From: sashiko-bot @ 2026-06-24 16:03 UTC (permalink / raw)
To: Hiroshi Nishida; +Cc: yukuai, linux-raid
In-Reply-To: <20260624155421.211626-5-nishidafmly@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message falsely claims `mddev->recovery_active` is a 'sector-typed atomic' and that declaring a local variable as `int` 'needlessly narrows it', but the structure field remains a standard 32-bit `atomic_t`.
--
commit 7ec77a6b233ce4d151f7fc723e5f312b20b4ac92
Author: Hiroshi Nishida <nishidafmly@gmail.com>
md: use sector_t for recovery_active in status_resync()
This commit changes the local variable recovery_active in status_resync()
from int to sector_t. The commit message states this is to match the type
of mddev->recovery_active and avoid needlessly narrowing the value.
> recovery_active holds a sector count read from the sector-typed atomic
> mddev->recovery_active and is then combined with the sector_t values
> curr_mark_cnt and resync_mark_cnt. Declaring it as a plain int needlessly
> narrows it and mixes signedness into sector_t arithmetic; declare it
> sector_t to match.
[Severity: Medium]
Is this description accurate? Looking at struct mddev in drivers/md/md.h,
recovery_active is defined as a standard atomic_t:
drivers/md/md.h:struct mddev {
...
atomic_t recovery_active;
...
}
Since atomic_t is a 32-bit signed integer, and atomic_read() returns an int,
does changing this local variable to sector_t actually prevent narrowing? The
implicit cast from int to sector_t will now simply happen at assignment
rather than during the arithmetic operations.
Could the commit message be updated to reflect that mddev->recovery_active
is a standard atomic_t, rather than a "sector-typed atomic"?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624155421.211626-1-nishidafmly@gmail.com?part=4
^ permalink raw reply
* Re: [RFC PATCH v3 2/3] drm/xe: Add RAS logging helpers
From: Mallesh, Koujalagi @ 2026-06-24 16:03 UTC (permalink / raw)
To: Michal Wajdeczko, intel-xe, rodrigo.vivi, matthew.brost,
thomas.hellstrom
Cc: anshuman.gupta, badal.nilawar, vinay.belgaumkar,
aravind.iddamsetty, riana.tauro, karthik.poosa, sk.anirban,
raag.jadav
In-Reply-To: <6a1dbfd1-9fce-4f02-85bd-7d6038f41ff8@intel.com>
On 21-06-2026 12:59 am, Michal Wajdeczko wrote:
>
> On 6/17/2026 12:47 PM, Mallesh Koujalagi wrote:
>> Add xe_ras_log.c and xe_ras_log.h so the driver can report
>> faults in a structured, machine-readable way.
> hmm, but the dmesg logs are mostly for the human admins, no?
You are right, dmesg is mostly for humans. The machine-readable
interface appears to be the CPER
payload exposed through xe_error_cper/tracefs, while dmesg is a human
friendly rendering of the
same event.
>> The core is __xe_ras_log(), which emits a single log line with:
>> SIG_ID, severity, location (device or tile/GT), errno, and message.
> our dmesg logs are already to some extend structured as they contain:
>
> severity: <3>
> driver name: xe
> device name: 0000:00:02.0
> subsystem name: [drm]
> error tag: *ERROR*
> location: Tile0:
> Tile0: GT0:
> message: GuC mmio request ...
This patch add is a more uniform fault-event format plus the
CPER/tracepoint path for machine consumption.
>> Fatal faults go to drm_err(); recoverable ones to drm_warn().
> note that we already have xe_err() and xe_warn() wrappers
Good catch.
>> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
>> ---
>> v3:
>> - Refer "Tile%u" and "GT%u" strings. (Michal Wajdeczko)
>> - Remov xe_cper_severity_str(). (Michal Wajdeczko/Riana)
>> - Move __xe_ras_log() function to xe_ras_log.h. (Michal Wajdeczko)
>> - Make macro function properly.
>> - Remove *_FIRST and *_LAST macro. (Michal Wajdeczko/Riana)
>> - Add sig id documents. (Riana)
>> - Change macro function same prefix as the file.
>> - Handle __xe_ras_log() function with variable format.
>> ---
>> drivers/gpu/drm/xe/Makefile | 1 +
>> drivers/gpu/drm/xe/xe_ras_log.c | 63 +++++++++++++++++++
>> drivers/gpu/drm/xe/xe_ras_log.h | 108 ++++++++++++++++++++++++++++++++
>> 3 files changed, 172 insertions(+)
>> create mode 100644 drivers/gpu/drm/xe/xe_ras_log.c
>> create mode 100644 drivers/gpu/drm/xe/xe_ras_log.h
>>
>> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
>> index 8e7b146880f4..607c9b099d03 100644
>> --- a/drivers/gpu/drm/xe/Makefile
>> +++ b/drivers/gpu/drm/xe/Makefile
>> @@ -114,6 +114,7 @@ xe-y += xe_bb.o \
>> xe_query.o \
>> xe_range_fence.o \
>> xe_ras.o \
>> + xe_ras_log.o \
>> xe_reg_sr.o \
>> xe_reg_whitelist.o \
>> xe_ring_ops.o \
>> diff --git a/drivers/gpu/drm/xe/xe_ras_log.c b/drivers/gpu/drm/xe/xe_ras_log.c
>> new file mode 100644
>> index 000000000000..0e836ef5dcf6
>> --- /dev/null
>> +++ b/drivers/gpu/drm/xe/xe_ras_log.c
>> @@ -0,0 +1,63 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright © 2026 Intel Corporation
>> + */
>> +
>> +#include <drm/drm_print.h>
>> +
>> +#include "xe_device.h"
>> +#include "xe_gt.h"
>> +#include "xe_ras_log.h"
>> +
>> +/**
>> + * __xe_ras_log - Emit a structured RAS log entry
>> + * @xe: xe device instance
>> + * @gt: GT instance where the error occurred, or NULL if device-wide
>> + * @sig_id: signature ID from xe_sig_ids.h identifying the error class
>> + * @cper_sev: CPER severity (one of CPER_SEV_FATAL, CPER_SEV_RECOVERABLE, etc.)
>> + * @errno_val: negative errno describing the error condition
>> + * @fmt: printf-style format string
>> + * @...: format arguments
>> + *
>> + * Formats the message and emits a kernel log line via drm_err() for fatal
>> + * events or drm_warn() for all others. CPER record generation and hex dump
>> + * are planned as follow-ups.
>> + *
>> + * Format:
>> + * [xe-err] SIG_ID = <id> Severity = <sev> Location = <loc> Errno = <n> Message = "<msg>"
>> + */
>> +__printf(6, 7)
>> +void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
>> + u16 sig_id, u32 cper_sev, int errno_val,
>> + const char *fmt, ...)
>> +{
>> + char loc[32];
>> + struct va_format vaf;
>> + va_list ap;
>> +
>> + if (gt)
>> + snprintf(loc, sizeof(loc), "tile%u/gt%u",
>> + gt->tile->id, gt->info.id);
>> + else
>> + snprintf(loc, sizeof(loc), "device");
>> +
>> + va_start(ap, fmt);
>> + vaf.fmt = fmt;
>> + vaf.va = ≈
>> +
>> + if (cper_sev == CPER_SEV_FATAL)
>> + drm_err(&xe->drm,
>> + "[xe-err] SIG_ID = %u Severity = %s Location = %s Errno = %d Message = \"%pV\"",
>> + sig_id, cper_severity_str(cper_sev), loc,
>> + errno_val, &vaf);
>> + else
>> + drm_warn(&xe->drm,
>> + "[xe-err] SIG_ID = %u Severity = %s Location = %s Errno = %d Message = \"%pV\"",
>> + sig_id, cper_severity_str(cper_sev), loc,
>> + errno_val, &vaf);
> again, this is not a very friendly message for the human admin
>
> can't we just add severity/id pair to our updated xe_printk macros, like
>
> xe_err_fatal(xe, id, fmt, ...)
> xe_err_recoverable(xe, id, fmt, ...)
>
> xe_gt_err_fatal(gt, id, fmt, ...)
> xe_gt_err_recoverable(gt, id, fmt, ...)
>
> and print sev/id pair within single tag:
>
> 0000:02.0 xe [drm] *ERROR* [ID=123456] *FATAL* format ...
Agreed, however we've per file macro reference.
>> +
>> + va_end(ap);
>> +
>> + /* TODO: Add CPER record driver handler */
>> + /* TODO: Add RAS dump cper hex handler */
>> +}
>> diff --git a/drivers/gpu/drm/xe/xe_ras_log.h b/drivers/gpu/drm/xe/xe_ras_log.h
>> new file mode 100644
>> index 000000000000..08318dea75a9
>> --- /dev/null
>> +++ b/drivers/gpu/drm/xe/xe_ras_log.h
>> @@ -0,0 +1,108 @@
>> +/* SPDX-License-Identifier: MIT */
>> +/*
>> + * Copyright © 2026 Intel Corporation
>> + */
>> +
>> +#ifndef _XE_RAS_LOG_H_
>> +#define _XE_RAS_LOG_H_
>> +
>> +#include <linux/cper.h>
>> +
>> +#include "xe_sig_ids.h"
>> +
>> +struct xe_device;
>> +struct xe_gt;
>> +
>> +/**
>> + * DOC: RAS structured logging and SIG_IDs
>> + *
>> + * What this file is for
>> + * ---------------------
>> + * Use the xe_ras_log_*() macros to report faults in a
>> + * machine-readable way.
>> + *
>> + * What is a SIG_ID?
>> + * -----------------
>> + * A SIG_ID (defined in xe_sig_ids.h) is a stable numeric error class.
> hmm, so a SIG is now a CLASS ?
> in the prev patch it was described as 'GPU fault signature'
Sure, i'll make it consistence.
> and this kernel-doc for SIG_IDs should be in .h file where we define those IDs
Sure, I'll move to header.
>> + * It tells tooling what kind of fault happened, independent of message text.
>> + *
>> + * Driver SIG_ID classes:
>> + * XE_SIG_PROBE - probe/init failure
>> + * XE_SIG_WEDGED - device unrecoverable
> hmm, in drm_dev_wedged_event() we can specify recovery method
> so what unrecoverable means here?
Good point, I'll fix the comment.
>> + * XE_SIG_SURVIVABILITY - degraded/safe mode
>> + * XE_SIG_FW - firmware fault (GuC/HuC/GSC/CSC/PCODE)
>> + * XE_SIG_GT_TDR - engine hang or GT reset (TDR)
>> + * XE_SIG_MEM_FAULT - VM/page-fault/GTT error
>> + * XE_SIG_IO_BUS - PCIe/IOMMU/MMIO bus error
>> + *
>> + * HW SIG_ID classes are hardware-defined categories, reported by firmware via
>> + * CPER records (for example XE_SIG_HW_DEVICE_MEMORY). Driver code does not
>> + * emit HW SIG_IDs directly.
> if HW SIGs are HW defined, are below IDs also defined by the HW
> or HW just defines different components, and we define IDs for them?
No, the numeric values are not defined by the HW. HW defines the
categories; we define the IDs for them.
>> + * XE_SIG_HW_DEVICE_MEMORY - device memory errors (e.g. ECC)
>> + * XE_SIG_HW_CORE_COMPUTE - compute/shader core errors
>> + * XE_SIG_HW_PCIE - PCIe interface errors
>> + * XE_SIG_HW_FABRIC - on-package fabric errors
>> + * XE_SIG_HW_SOC_INTERNAL - SoC-internal errors
>> + *
>> + * Why this exists
>> + * ---------------
>> + * SIG_IDs let RAS tools parse logs reliably, correlate CPER events, and apply
> dmesg is not reliable
dmesg is explicitly not a stable API, it is emitted “for logging purpose,”
while the machine-consumable path is the CPER record
via the existing xe_error_cper tracepoint.
>> + * policy/thresholding without depending on fragile string matching.
> if the whole idea is to group our errors per fault class,
> then maybe our macros should be used like:
>
> xe_err_fatal(xe, CLASS, fmt, ...)
> xe_err_recoverable(xe, CLASS, fmt, ...)
>
> and output should be:
>
> 0000:02.0 xe [drm] *ERROR* [PROBE] *FATAL* format ...
> 0000:02.0 xe [drm] *ERROR* [TDR] *RECOVERABLE* format ...
>
> as printing magic ID numbers is not very friendly
>
> and any 'machine structured output' should be exposed elsewhere?
> maybe as sysfs file on the xe module level (to catch probe errors)
>
> and maybe start with that alternate method first,
> and use dmesg logging only as a best-effort informational step?
We need component based helper, not based on severity.
>> + *
>> + * When to use xe_ras_log_*()
>> + * --------------------------
>> + * Use these macros when the event is:
>> + * 1) a real hardware/firmware fault,
>> + * 2) relevant to production monitoring, and
>> + * 3) clearly mapped to one SIG_ID class.
>> + *
>> + * Do not use for all logs
>> + * -----------------------
>> + * Keep regular debug/info/driver-state messages on standard logging helpers
>> + * (xe_gt_dbg(), xe_gt_info(), xe_gt_warn(), xe_gt_err(), drm_dbg(), drm_info()).
>> + * RAS macros are for structured fault reporting only.
>> + */
>> +
>> +/*
>> + * Common backend helper
>> + */
>> +__printf(6, 7)
>> +void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
>> + u16 sig_id, u32 cper_sev, int errno_val,
>> + const char *fmt, ...);
>> +
>> +/*
>> + * Driver-facing reporting macros
>> + */
>> +
>> +/* FATAL */
>> +#define xe_ras_log_probe(xe, errno, fmt, ...) \
>> + __xe_ras_log((xe), NULL, XE_SIG_PROBE, CPER_SEV_FATAL, \
>> + (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_wedged(xe, errno, fmt, ...) \
>> + __xe_ras_log((xe), NULL, XE_SIG_WEDGED, CPER_SEV_FATAL, \
>> + (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_survivability(xe, errno, fmt, ...) \
>> + __xe_ras_log((xe), NULL, XE_SIG_SURVIVABILITY, CPER_SEV_FATAL, \
>> + (errno), fmt, ##__VA_ARGS__)
>> +
>> +/* RECOVERABLE */
>> +#define xe_ras_log_fw(xe, gt, errno, fmt, ...) \
>> + __xe_ras_log((xe), (gt), XE_SIG_FW, CPER_SEV_RECOVERABLE, \
>> + (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_gt_tdr(xe, gt, errno, fmt, ...) \
>> + __xe_ras_log((xe), (gt), XE_SIG_GT_TDR, CPER_SEV_RECOVERABLE, \
>> + (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_mem_fault(xe, gt, errno, fmt, ...) \
>> + __xe_ras_log((xe), (gt), XE_SIG_MEM_FAULT, CPER_SEV_RECOVERABLE, \
>> + (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_io_bus(xe, errno, fmt, ...) \
>> + __xe_ras_log((xe), NULL, XE_SIG_IO_BUS, CPER_SEV_RECOVERABLE, \
>> + (errno), fmt, ##__VA_ARGS__)
> IMO those RAS customized macros, should be per severity and take
> a CLASS as a param since there is much less severity levels than
> your new SIG_IDs fault classes, so it scales better
>
> xe_err_fatal(xe, PROBE, fmt, ...)
> xe_err_recoverable(xe, IO_BUS, fmt, ...)
>
> and I'm not sure that there is 1:1 relation between CLASS and severity
ditto
Thanks,
-/Mallesh
>> +
>> +#endif /* _XE_RAS_LOG_H_ */
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema
From: David Heidelberg via B4 Relay @ 2026-06-24 16:02 UTC (permalink / raw)
To: David Rhodes, Richard Fitzgerald, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, patches,
Bjorn Helgaas
Cc: David Rhodes, linux-sound, devicetree, linux-kernel, phone-devel,
David Heidelberg
From: David Heidelberg <david@ixit.cz>
Convert CS35L36 Speaker Amplifier to yaml.
Changes:
- maintainers email to the generic Cirrus email
- Both the codec and downstream worked just fine without
VP-supply provided. Align with datasheet for similar models.
- add dai-common.yaml to cover for '#sound-dai-cells',
'sound-name-prefix'
Reviewed-by: David Rhodes <David.Rhodes@cirrus.com>
Co-developed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Relevant for Pixel 3 / 3XL / 4.
---
Changes in v2:
- Rename the commit. (Mark)
- Link to v1: https://lore.kernel.org/r/20260618-dt-cirrus-cs35l36-v1-1-1a43515666ad@ixit.cz
---
.../devicetree/bindings/sound/cirrus,cs35l36.yaml | 224 +++++++++++++++++++++
.../devicetree/bindings/sound/cs35l36.txt | 168 ----------------
2 files changed, 224 insertions(+), 168 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
new file mode 100644
index 0000000000000..af0acaaefb68e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
@@ -0,0 +1,224 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cirrus,cs35l36.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CS35L36 Speaker Amplifier
+
+maintainers:
+ - patches@opensource.cirrus.com
+ - Bjorn Helgaas <bhelgaas@google.com>
+
+description: |
+ CS35L36 is a boosted mono Class D amplifier
+
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - cirrus,cs35l36
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ VA-supply:
+ description: Voltage regulator of analog internal section
+
+ VP-supply:
+ description: Voltage regulator of boost converter
+
+ reset-gpios:
+ maxItems: 1
+
+ cirrus,boost-ctl-millivolt:
+ description: Boost converter output voltage in millivolts (step 50)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 2550
+ maximum: 12000
+
+ cirrus,boost-peak-milliamp:
+ description: Boost-converter peak current limit in mA (step 50)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 4500
+ minimum: 1600
+ maximum: 4500
+
+ cirrus,boost-ind-nanohenry:
+ description: Initial inductor estimation reference value in nanohenry (1000=1μH, 1200=1.2μH)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 1000
+
+ cirrus,multi-amp-mode:
+ description: Hi-Z ASP port when more than one amplifier in system.
+ type: boolean
+
+ cirrus,boost-ctl-select:
+ description: Boost converter control source selection
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0x01
+ enum:
+ - 0x00 # Control Port
+ - 0x01 # Class
+ - 0x10 # Sync
+
+ cirrus,amp-pcm-inv:
+ description: Invert incoming PCM data when true.
+ type: boolean
+
+ cirrus,imon-pol-inv:
+ description: Invert polarity of outbound IMON feedback when true.
+ type: boolean
+
+ cirrus,vmon-pol-inv:
+ description: Invert polarity of outbound VMON feedback when true.
+ type: boolean
+
+ cirrus,dcm-mode-enable:
+ description: Enable boost converter automatic Discontinuous Conduction Mode.
+ type: boolean
+
+ cirrus,weak-fet-disable:
+ description: Reduce output driver strength in Weak-FET Drive Mode when true.
+ type: boolean
+
+ cirrus,classh-wk-fet-delay:
+ description: Weak-FET entry delay in ms
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 100
+ enum:
+ - 0 # 0
+ - 1 # 5
+ - 2 # 10
+ - 3 # 50
+ - 4 # 100
+ - 5 # 200
+ - 6 # 500
+ - 7 # 1000
+
+ cirrus,classh-weak-fet-thld-millivolt:
+ description: Weak-FET drive threshold in mV
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, 600, 650, 700]
+
+ cirrus,temp-warn-threshold:
+ description: Overtemperature warning threshold
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 2
+ enum:
+ - 0 # 105°C
+ - 1 # 115°C
+ - 2 # 125°C
+ - 3 # 135°C
+
+ cirrus,irq-drive-select:
+ description: Interrupt output driver type
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 1
+ enum:
+ - 0 # open-drain
+ - 1 # push-pull
+
+ cirrus,irq-gpio-select:
+ description: Programmable IRQ pin selection
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # PDM_DATA/SWIRE_SD/INT
+ - 1 # GPIO
+
+ cirrus,vpbr-config:
+ description: Brownout prevention configuration sub-node
+ type: object
+ additionalProperties: false
+
+ properties:
+ cirrus,vpbr-en:
+ description: VBST brownout prevention enable
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+ enum:
+ - 0 # disabled
+ - 1 # enabled
+
+ cirrus,vpbr-thld:
+ description: Initial VPBR threshold voltage
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-atk-rate:
+ description: Attenuation attack step rate
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-atk-vol:
+ description: VP brownout prevention step size
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-max-attn:
+ description: Maximum attenuation during VP brownout prevention
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-wait:
+ description: Delay between brownout clearance and attenuation release
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-rel-rate:
+ description: Attenuation release step rate
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-mute-en:
+ description: Mute audio if maximum attenuation reached
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - VA-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@40 {
+ compatible = "cirrus,cs35l36";
+ reg = <0x40>;
+ VA-supply = <&dummy_vreg>;
+ VP-supply = <&dummy_vreg>;
+ reset-gpios = <&gpio0 54 GPIO_ACTIVE_HIGH>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+ cirrus,boost-ind-nanohenry = <1000>;
+ cirrus,boost-ctl-millivolt = <10000>;
+ cirrus,boost-peak-milliamp = <4500>;
+ cirrus,boost-ctl-select = <0x00>;
+ cirrus,weak-fet-delay = <4>;
+ cirrus,weak-fet-thld = <0x01>;
+ cirrus,temp-warn-threshold = <1>;
+ cirrus,multi-amp-mode;
+ cirrus,irq-drive-select = <1>;
+ cirrus,irq-gpio-select = <0x01>;
+
+ cirrus,vpbr-config {
+ cirrus,vpbr-en = <0>;
+ cirrus,vpbr-thld = <0x05>;
+ cirrus,vpbr-atk-rate = <0x02>;
+ cirrus,vpbr-atk-vol = <0x01>;
+ cirrus,vpbr-max-attn = <0x09>;
+ cirrus,vpbr-wait = <0x01>;
+ cirrus,vpbr-rel-rate = <0x05>;
+ cirrus,vpbr-mute-en = <0x00>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/cs35l36.txt b/Documentation/devicetree/bindings/sound/cs35l36.txt
deleted file mode 100644
index d34117b8558e5..0000000000000
--- a/Documentation/devicetree/bindings/sound/cs35l36.txt
+++ /dev/null
@@ -1,168 +0,0 @@
-CS35L36 Speaker Amplifier
-
-Required properties:
-
- - compatible : "cirrus,cs35l36"
-
- - reg : the I2C address of the device for I2C
-
- - VA-supply, VP-supply : power supplies for the device,
- as covered in
- Documentation/devicetree/bindings/regulator/regulator.txt.
-
- - cirrus,boost-ctl-millivolt : Boost Voltage Value. Configures the boost
- converter's output voltage in mV. The range is from 2550mV to 12000mV with
- increments of 50mV.
- (Default) VP
-
- - cirrus,boost-peak-milliamp : Boost-converter peak current limit in mA.
- Configures the peak current by monitoring the current through the boost FET.
- Range starts at 1600mA and goes to a maximum of 4500mA with increments of
- 50mA.
- (Default) 4.50 Amps
-
- - cirrus,boost-ind-nanohenry : Inductor estimation LBST reference value.
- Seeds the digital boost converter's inductor estimation block with the initial
- inductance value to reference.
-
- 1000 = 1uH (Default)
- 1200 = 1.2uH
-
-Optional properties:
- - cirrus,multi-amp-mode : Boolean to determine if there are more than
- one amplifier in the system. If more than one it is best to Hi-Z the ASP
- port to prevent bus contention on the output signal
-
- - cirrus,boost-ctl-select : Boost converter control source selection.
- Selects the source of the BST_CTL target VBST voltage for the boost
- converter to generate.
- 0x00 - Control Port Value
- 0x01 - Class H Tracking (Default)
- 0x10 - MultiDevice Sync Value
-
- - cirrus,amp-pcm-inv : Boolean to determine Amplifier will invert incoming
- PCM data
-
- - cirrus,imon-pol-inv : Boolean to determine Amplifier will invert the
- polarity of outbound IMON feedback data
-
- - cirrus,vmon-pol-inv : Boolean to determine Amplifier will invert the
- polarity of outbound VMON feedback data
-
- - cirrus,dcm-mode-enable : Boost converter automatic DCM Mode enable.
- This enables the digital boost converter to operate in a low power
- (Discontinuous Conduction) mode during low loading conditions.
-
- - cirrus,weak-fet-disable : Boolean : The strength of the output drivers is
- reduced when operating in a Weak-FET Drive Mode and must not be used to drive
- a large load.
-
- - cirrus,classh-wk-fet-delay : Weak-FET entry delay. Controls the delay
- (in ms) before the Class H algorithm switches to the weak-FET voltage
- (after the audio falls and remains below the value specified in WKFET_AMP_THLD).
-
- 0 = 0ms
- 1 = 5ms
- 2 = 10ms
- 3 = 50ms
- 4 = 100ms (Default)
- 5 = 200ms
- 6 = 500ms
- 7 = 1000ms
-
- - cirrus,classh-weak-fet-thld-millivolt : Weak-FET amplifier drive threshold.
- Configures the signal threshold at which the PWM output stage enters
- weak-FET operation. The range is 50mV to 700mV in 50mV increments.
-
- - cirrus,temp-warn-threshold : Amplifier overtemperature warning threshold.
- Configures the threshold at which the overtemperature warning condition occurs.
- When the threshold is met, the overtemperature warning attenuation is applied
- and the TEMP_WARN_EINT interrupt status bit is set.
- If TEMP_WARN_MASK = 0, INTb is asserted.
-
- 0 = 105C
- 1 = 115C
- 2 = 125C (Default)
- 3 = 135C
-
- - cirrus,irq-drive-select : Selects the driver type of the selected interrupt
- output.
-
- 0 = Open-drain
- 1 = Push-pull (Default)
-
- - cirrus,irq-gpio-select : Selects the pin to serve as the programmable
- interrupt output.
-
- 0 = PDM_DATA / SWIRE_SD / INT (Default)
- 1 = GPIO
-
-Optional properties for the "cirrus,vpbr-config" Sub-node
-
- - cirrus,vpbr-en : VBST brownout prevention enable. Configures whether the
- VBST brownout prevention algorithm is enabled or disabled.
-
- 0 = VBST brownout prevention disabled (default)
- 1 = VBST brownout prevention enabled
-
- See Section 7.31.1 VPBR Config for configuration options & further details
-
- - cirrus,vpbr-thld : Initial VPBR threshold. Configures the VP brownout
- threshold voltage
-
- - cirrus,cirrus,vpbr-atk-rate : Attenuation attack step rate. Configures the
- amount delay between consecutive volume attenuation steps when a brownout
- condition is present and the VP brownout condition is in an attacking state.
-
- - cirrus,vpbr-atk-vol : VP brownout prevention step size. Configures the VP
- brownout prevention attacking attenuation step size when operating in either
- digital volume or analog gain modes.
-
- - cirrus,vpbr-max-attn : Maximum attenuation that the VP brownout prevention
- can apply to the audio signal.
-
- - cirrus,vpbr-wait : Configures the delay time between a brownout condition
- no longer being present and the VP brownout prevention entering an attenuation
- release state.
-
- - cirrus,vpbr-rel-rate : Attenuation release step rate. Configures the delay
- between consecutive volume attenuation release steps when a brownout condition
- is not longer present and the VP brownout is in an attenuation release state.
-
- - cirrus,vpbr-mute-en : During the attack state, if the vpbr-max-attn value
- is reached, the error condition still remains, and this bit is set, the audio
- is muted.
-
-Example:
-
-cs35l36: cs35l36@40 {
- compatible = "cirrus,cs35l36";
- reg = <0x40>;
- VA-supply = <&dummy_vreg>;
- VP-supply = <&dummy_vreg>;
- reset-gpios = <&gpio0 54 0>;
- interrupt-parent = <&gpio8>;
- interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
-
- cirrus,boost-ind-nanohenry = <1000>;
- cirrus,boost-ctl-millivolt = <10000>;
- cirrus,boost-peak-milliamp = <4500>;
- cirrus,boost-ctl-select = <0x00>;
- cirrus,weak-fet-delay = <0x04>;
- cirrus,weak-fet-thld = <0x01>;
- cirrus,temp-warn-threshold = <0x01>;
- cirrus,multi-amp-mode;
- cirrus,irq-drive-select = <0x01>;
- cirrus,irq-gpio-select = <0x01>;
-
- cirrus,vpbr-config {
- cirrus,vpbr-en = <0x00>;
- cirrus,vpbr-thld = <0x05>;
- cirrus,vpbr-atk-rate = <0x02>;
- cirrus,vpbr-atk-vol = <0x01>;
- cirrus,vpbr-max-attn = <0x09>;
- cirrus,vpbr-wait = <0x01>;
- cirrus,vpbr-rel-rate = <0x05>;
- cirrus,vpbr-mute-en = <0x00>;
- };
-};
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260618-dt-cirrus-cs35l36-99c466fb13fd
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply related
* [PATCH v2] ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema
From: David Heidelberg @ 2026-06-24 16:02 UTC (permalink / raw)
To: David Rhodes, Richard Fitzgerald, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, patches,
Bjorn Helgaas
Cc: David Rhodes, linux-sound, devicetree, linux-kernel, phone-devel,
David Heidelberg
Convert CS35L36 Speaker Amplifier to yaml.
Changes:
- maintainers email to the generic Cirrus email
- Both the codec and downstream worked just fine without
VP-supply provided. Align with datasheet for similar models.
- add dai-common.yaml to cover for '#sound-dai-cells',
'sound-name-prefix'
Reviewed-by: David Rhodes <David.Rhodes@cirrus.com>
Co-developed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Relevant for Pixel 3 / 3XL / 4.
---
Changes in v2:
- Rename the commit. (Mark)
- Link to v1: https://lore.kernel.org/r/20260618-dt-cirrus-cs35l36-v1-1-1a43515666ad@ixit.cz
---
.../devicetree/bindings/sound/cirrus,cs35l36.yaml | 224 +++++++++++++++++++++
.../devicetree/bindings/sound/cs35l36.txt | 168 ----------------
2 files changed, 224 insertions(+), 168 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
new file mode 100644
index 0000000000000..af0acaaefb68e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
@@ -0,0 +1,224 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cirrus,cs35l36.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CS35L36 Speaker Amplifier
+
+maintainers:
+ - patches@opensource.cirrus.com
+ - Bjorn Helgaas <bhelgaas@google.com>
+
+description: |
+ CS35L36 is a boosted mono Class D amplifier
+
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - cirrus,cs35l36
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ VA-supply:
+ description: Voltage regulator of analog internal section
+
+ VP-supply:
+ description: Voltage regulator of boost converter
+
+ reset-gpios:
+ maxItems: 1
+
+ cirrus,boost-ctl-millivolt:
+ description: Boost converter output voltage in millivolts (step 50)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 2550
+ maximum: 12000
+
+ cirrus,boost-peak-milliamp:
+ description: Boost-converter peak current limit in mA (step 50)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 4500
+ minimum: 1600
+ maximum: 4500
+
+ cirrus,boost-ind-nanohenry:
+ description: Initial inductor estimation reference value in nanohenry (1000=1μH, 1200=1.2μH)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 1000
+
+ cirrus,multi-amp-mode:
+ description: Hi-Z ASP port when more than one amplifier in system.
+ type: boolean
+
+ cirrus,boost-ctl-select:
+ description: Boost converter control source selection
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0x01
+ enum:
+ - 0x00 # Control Port
+ - 0x01 # Class
+ - 0x10 # Sync
+
+ cirrus,amp-pcm-inv:
+ description: Invert incoming PCM data when true.
+ type: boolean
+
+ cirrus,imon-pol-inv:
+ description: Invert polarity of outbound IMON feedback when true.
+ type: boolean
+
+ cirrus,vmon-pol-inv:
+ description: Invert polarity of outbound VMON feedback when true.
+ type: boolean
+
+ cirrus,dcm-mode-enable:
+ description: Enable boost converter automatic Discontinuous Conduction Mode.
+ type: boolean
+
+ cirrus,weak-fet-disable:
+ description: Reduce output driver strength in Weak-FET Drive Mode when true.
+ type: boolean
+
+ cirrus,classh-wk-fet-delay:
+ description: Weak-FET entry delay in ms
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 100
+ enum:
+ - 0 # 0
+ - 1 # 5
+ - 2 # 10
+ - 3 # 50
+ - 4 # 100
+ - 5 # 200
+ - 6 # 500
+ - 7 # 1000
+
+ cirrus,classh-weak-fet-thld-millivolt:
+ description: Weak-FET drive threshold in mV
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, 600, 650, 700]
+
+ cirrus,temp-warn-threshold:
+ description: Overtemperature warning threshold
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 2
+ enum:
+ - 0 # 105°C
+ - 1 # 115°C
+ - 2 # 125°C
+ - 3 # 135°C
+
+ cirrus,irq-drive-select:
+ description: Interrupt output driver type
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 1
+ enum:
+ - 0 # open-drain
+ - 1 # push-pull
+
+ cirrus,irq-gpio-select:
+ description: Programmable IRQ pin selection
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # PDM_DATA/SWIRE_SD/INT
+ - 1 # GPIO
+
+ cirrus,vpbr-config:
+ description: Brownout prevention configuration sub-node
+ type: object
+ additionalProperties: false
+
+ properties:
+ cirrus,vpbr-en:
+ description: VBST brownout prevention enable
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+ enum:
+ - 0 # disabled
+ - 1 # enabled
+
+ cirrus,vpbr-thld:
+ description: Initial VPBR threshold voltage
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-atk-rate:
+ description: Attenuation attack step rate
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-atk-vol:
+ description: VP brownout prevention step size
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-max-attn:
+ description: Maximum attenuation during VP brownout prevention
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-wait:
+ description: Delay between brownout clearance and attenuation release
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-rel-rate:
+ description: Attenuation release step rate
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-mute-en:
+ description: Mute audio if maximum attenuation reached
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - VA-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@40 {
+ compatible = "cirrus,cs35l36";
+ reg = <0x40>;
+ VA-supply = <&dummy_vreg>;
+ VP-supply = <&dummy_vreg>;
+ reset-gpios = <&gpio0 54 GPIO_ACTIVE_HIGH>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+ cirrus,boost-ind-nanohenry = <1000>;
+ cirrus,boost-ctl-millivolt = <10000>;
+ cirrus,boost-peak-milliamp = <4500>;
+ cirrus,boost-ctl-select = <0x00>;
+ cirrus,weak-fet-delay = <4>;
+ cirrus,weak-fet-thld = <0x01>;
+ cirrus,temp-warn-threshold = <1>;
+ cirrus,multi-amp-mode;
+ cirrus,irq-drive-select = <1>;
+ cirrus,irq-gpio-select = <0x01>;
+
+ cirrus,vpbr-config {
+ cirrus,vpbr-en = <0>;
+ cirrus,vpbr-thld = <0x05>;
+ cirrus,vpbr-atk-rate = <0x02>;
+ cirrus,vpbr-atk-vol = <0x01>;
+ cirrus,vpbr-max-attn = <0x09>;
+ cirrus,vpbr-wait = <0x01>;
+ cirrus,vpbr-rel-rate = <0x05>;
+ cirrus,vpbr-mute-en = <0x00>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/cs35l36.txt b/Documentation/devicetree/bindings/sound/cs35l36.txt
deleted file mode 100644
index d34117b8558e5..0000000000000
--- a/Documentation/devicetree/bindings/sound/cs35l36.txt
+++ /dev/null
@@ -1,168 +0,0 @@
-CS35L36 Speaker Amplifier
-
-Required properties:
-
- - compatible : "cirrus,cs35l36"
-
- - reg : the I2C address of the device for I2C
-
- - VA-supply, VP-supply : power supplies for the device,
- as covered in
- Documentation/devicetree/bindings/regulator/regulator.txt.
-
- - cirrus,boost-ctl-millivolt : Boost Voltage Value. Configures the boost
- converter's output voltage in mV. The range is from 2550mV to 12000mV with
- increments of 50mV.
- (Default) VP
-
- - cirrus,boost-peak-milliamp : Boost-converter peak current limit in mA.
- Configures the peak current by monitoring the current through the boost FET.
- Range starts at 1600mA and goes to a maximum of 4500mA with increments of
- 50mA.
- (Default) 4.50 Amps
-
- - cirrus,boost-ind-nanohenry : Inductor estimation LBST reference value.
- Seeds the digital boost converter's inductor estimation block with the initial
- inductance value to reference.
-
- 1000 = 1uH (Default)
- 1200 = 1.2uH
-
-Optional properties:
- - cirrus,multi-amp-mode : Boolean to determine if there are more than
- one amplifier in the system. If more than one it is best to Hi-Z the ASP
- port to prevent bus contention on the output signal
-
- - cirrus,boost-ctl-select : Boost converter control source selection.
- Selects the source of the BST_CTL target VBST voltage for the boost
- converter to generate.
- 0x00 - Control Port Value
- 0x01 - Class H Tracking (Default)
- 0x10 - MultiDevice Sync Value
-
- - cirrus,amp-pcm-inv : Boolean to determine Amplifier will invert incoming
- PCM data
-
- - cirrus,imon-pol-inv : Boolean to determine Amplifier will invert the
- polarity of outbound IMON feedback data
-
- - cirrus,vmon-pol-inv : Boolean to determine Amplifier will invert the
- polarity of outbound VMON feedback data
-
- - cirrus,dcm-mode-enable : Boost converter automatic DCM Mode enable.
- This enables the digital boost converter to operate in a low power
- (Discontinuous Conduction) mode during low loading conditions.
-
- - cirrus,weak-fet-disable : Boolean : The strength of the output drivers is
- reduced when operating in a Weak-FET Drive Mode and must not be used to drive
- a large load.
-
- - cirrus,classh-wk-fet-delay : Weak-FET entry delay. Controls the delay
- (in ms) before the Class H algorithm switches to the weak-FET voltage
- (after the audio falls and remains below the value specified in WKFET_AMP_THLD).
-
- 0 = 0ms
- 1 = 5ms
- 2 = 10ms
- 3 = 50ms
- 4 = 100ms (Default)
- 5 = 200ms
- 6 = 500ms
- 7 = 1000ms
-
- - cirrus,classh-weak-fet-thld-millivolt : Weak-FET amplifier drive threshold.
- Configures the signal threshold at which the PWM output stage enters
- weak-FET operation. The range is 50mV to 700mV in 50mV increments.
-
- - cirrus,temp-warn-threshold : Amplifier overtemperature warning threshold.
- Configures the threshold at which the overtemperature warning condition occurs.
- When the threshold is met, the overtemperature warning attenuation is applied
- and the TEMP_WARN_EINT interrupt status bit is set.
- If TEMP_WARN_MASK = 0, INTb is asserted.
-
- 0 = 105C
- 1 = 115C
- 2 = 125C (Default)
- 3 = 135C
-
- - cirrus,irq-drive-select : Selects the driver type of the selected interrupt
- output.
-
- 0 = Open-drain
- 1 = Push-pull (Default)
-
- - cirrus,irq-gpio-select : Selects the pin to serve as the programmable
- interrupt output.
-
- 0 = PDM_DATA / SWIRE_SD / INT (Default)
- 1 = GPIO
-
-Optional properties for the "cirrus,vpbr-config" Sub-node
-
- - cirrus,vpbr-en : VBST brownout prevention enable. Configures whether the
- VBST brownout prevention algorithm is enabled or disabled.
-
- 0 = VBST brownout prevention disabled (default)
- 1 = VBST brownout prevention enabled
-
- See Section 7.31.1 VPBR Config for configuration options & further details
-
- - cirrus,vpbr-thld : Initial VPBR threshold. Configures the VP brownout
- threshold voltage
-
- - cirrus,cirrus,vpbr-atk-rate : Attenuation attack step rate. Configures the
- amount delay between consecutive volume attenuation steps when a brownout
- condition is present and the VP brownout condition is in an attacking state.
-
- - cirrus,vpbr-atk-vol : VP brownout prevention step size. Configures the VP
- brownout prevention attacking attenuation step size when operating in either
- digital volume or analog gain modes.
-
- - cirrus,vpbr-max-attn : Maximum attenuation that the VP brownout prevention
- can apply to the audio signal.
-
- - cirrus,vpbr-wait : Configures the delay time between a brownout condition
- no longer being present and the VP brownout prevention entering an attenuation
- release state.
-
- - cirrus,vpbr-rel-rate : Attenuation release step rate. Configures the delay
- between consecutive volume attenuation release steps when a brownout condition
- is not longer present and the VP brownout is in an attenuation release state.
-
- - cirrus,vpbr-mute-en : During the attack state, if the vpbr-max-attn value
- is reached, the error condition still remains, and this bit is set, the audio
- is muted.
-
-Example:
-
-cs35l36: cs35l36@40 {
- compatible = "cirrus,cs35l36";
- reg = <0x40>;
- VA-supply = <&dummy_vreg>;
- VP-supply = <&dummy_vreg>;
- reset-gpios = <&gpio0 54 0>;
- interrupt-parent = <&gpio8>;
- interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
-
- cirrus,boost-ind-nanohenry = <1000>;
- cirrus,boost-ctl-millivolt = <10000>;
- cirrus,boost-peak-milliamp = <4500>;
- cirrus,boost-ctl-select = <0x00>;
- cirrus,weak-fet-delay = <0x04>;
- cirrus,weak-fet-thld = <0x01>;
- cirrus,temp-warn-threshold = <0x01>;
- cirrus,multi-amp-mode;
- cirrus,irq-drive-select = <0x01>;
- cirrus,irq-gpio-select = <0x01>;
-
- cirrus,vpbr-config {
- cirrus,vpbr-en = <0x00>;
- cirrus,vpbr-thld = <0x05>;
- cirrus,vpbr-atk-rate = <0x02>;
- cirrus,vpbr-atk-vol = <0x01>;
- cirrus,vpbr-max-attn = <0x09>;
- cirrus,vpbr-wait = <0x01>;
- cirrus,vpbr-rel-rate = <0x05>;
- cirrus,vpbr-mute-en = <0x00>;
- };
-};
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260618-dt-cirrus-cs35l36-99c466fb13fd
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply related
* CTI TAC Meeting Notes 2026-06-24
From: Carlos O'Donell @ 2026-06-24 16:02 UTC (permalink / raw)
To: CTI TAC
Attendees:
* Carlos O'Donell
* Joseph Myers
* David Edelsohn
Regrets:
* Siddhesh Poyarekar
* Kris Borchers
Agenda:
* Sponsorship discussion. Discussed the pitch deck going out to sponsors.
* Carlos: I broke down the AdaCore hook definition into 12 parts. Does this meet your requirements for the analysis?
* Joseph: Yes, for the AdaCore hooks. However, we should have more detailed timelines around the implementation of specific items.
* Carlos: Updated the service-transition-plan with requested TODO items, and will circle back to fill those in.
* Joseph: Is the new mailing list setup going to do some from rewriting?
* Carlos: Updated the plan with a TODO to verify AdaCore Hook 12/12 step versus the from-rewriting on the mailing list.
* Discussed with the TAC the question of mailing list forwarding that was raised.
* Discussed with the TAC the question of renaming the mailing lists to more meaningful names.
* Updated service transition plan.
--
Cheers,
Carlos.
^ permalink raw reply
* Re: [PATCH v2 0/2] iio: chemical: sps30, scd30
From: Tomasz Duszynski @ 2026-06-24 16:01 UTC (permalink / raw)
To: m32285159
Cc: andriy.shevchenko, andy, dlechner, jic23, linux-iio, linux-kernel,
nuno.sa, tduszyns
In-Reply-To: <CAKqfh0GF1WCF_85r4F0FTvwEdBPoihynx2VHmT+CtyDfYoRDbQ@mail.gmail.com>
> On Thu, Jun 18, 2026 at 10:40 AM Maxwell Doose <m32285159@gmail.com> wrote:
> >
> > On Wed, Jun 17, 2026 at 12:22 PM Tomasz Duszynski <tduszyns@gmail.com> wrote:
> > >
> > > This series replaces old email addresses with a current one to
> > > make sure changes show up in my mailbox.
> > >
> > > v2:
> > > - add missing mailmap entry
> > >
> > > Tomasz Duszynski (2):
> > > iio: chemical: sps30: update email
> > > iio: chemical: scd30: update email
> > >
> >
> > Even though you were the previous maintainer I should probably still
> > ack this for the scd30 for good measure, so for scd30 patches:
> >
> > Acked-by: Maxwell Doose <m32285159@gmail.com>
>
> I also neglected to mention this but I updated your entry in the
> dt-bindings for this so you may want to go and add yourself to that as
> well.
Yup, I'll modify that too for completeness.
^ permalink raw reply
* [PATCH v3 2/3] KVM: arm64: top up pKVM mapping cache for permission faults
From: Bradley Morgan @ 2026-06-24 16:00 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Fuad Tabba, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Quentin Perret,
Vincent Donnefort, Gavin Shan, Alexandru Elisei, linux-arm-kernel,
kvmarm, linux-kernel, Bradley Morgan, stable
In-Reply-To: <20260624160028.15591-1-include@grrlz.net>
Permission faults normally only relax an existing leaf, so the fault path
does not top up the memcache.
With pKVM, a permission fault can also replace page mappings with a
PMD mapping. That path needs a fresh pkvm_mapping object, and can
dereference a NULL cache->mapping if the cache was not topped up.
Allocate just that object for pKVM permission faults.
The issue was discovered [1] by Sashiko.
Link: https://lore.kernel.org/all/20260623161545.EA08E1F000E9@smtp.kernel.org/ [1]
Fixes: db14091d8f75 ("KVM: arm64: Stage-2 huge mappings for np-guests")
Cc: stable@vger.kernel.org
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
arch/arm64/kvm/mmu.c | 29 ++++++++++++++++++++++-------
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 6c941aaa10c6..3f57f6825a33 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1177,17 +1177,26 @@ void free_hyp_memcache(struct kvm_hyp_memcache *mc)
__free_hyp_memcache(mc, hyp_mc_free_fn, kvm_host_va, mc);
}
+static int topup_hyp_memcache_mapping(struct kvm_hyp_memcache *mc)
+{
+ if (mc->mapping)
+ return 0;
+
+ mc->mapping = kzalloc_obj(struct pkvm_mapping,
+ GFP_KERNEL_ACCOUNT);
+ return mc->mapping ? 0 : -ENOMEM;
+}
+
int topup_hyp_memcache(struct kvm_hyp_memcache *mc, unsigned long min_pages)
{
+ int ret;
+
if (!is_protected_kvm_enabled())
return 0;
- if (!mc->mapping) {
- mc->mapping = kzalloc_obj(struct pkvm_mapping,
- GFP_KERNEL_ACCOUNT);
- if (!mc->mapping)
- return -ENOMEM;
- }
+ ret = topup_hyp_memcache_mapping(mc);
+ if (ret)
+ return ret;
return __topup_hyp_memcache(mc, min_pages, hyp_mc_alloc_fn,
kvm_host_pa, mc);
@@ -2113,7 +2122,9 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
* Permission faults just need to update the existing leaf entry,
* and so normally don't require allocations from the memcache. The
* only exception to this is when dirty logging is enabled at runtime
- * and a write fault needs to collapse a block entry into a table.
+ * and a write fault needs to collapse a block entry into a table. With
+ * pKVM, they may still need a fresh mapping object if the fault turns
+ * page entries into a block entry.
*/
memcache = get_mmu_memcache(s2fd->vcpu);
if (!perm_fault || (memslot_is_logging(s2fd->memslot) &&
@@ -2121,6 +2132,10 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
ret = topup_mmu_memcache(s2fd->vcpu, memcache);
if (ret)
return ret;
+ } else if (is_protected_kvm_enabled()) {
+ ret = topup_hyp_memcache_mapping(memcache);
+ if (ret)
+ return ret;
}
/*
--
2.53.0
^ permalink raw reply related
* [PATCH v3 3/3] KVM: arm64: top up stage 2 memcache for dirty logging faults
From: Bradley Morgan @ 2026-06-24 16:00 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Fuad Tabba, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Quentin Perret,
Vincent Donnefort, Gavin Shan, Alexandru Elisei, linux-arm-kernel,
kvmarm, linux-kernel, Bradley Morgan, stable
In-Reply-To: <20260624160028.15591-1-include@grrlz.net>
Dirty logging forces new stage 2 mappings down to page size, but
it does not always remove an existing block mapping before the next
fault. Eager splitting is best effort and is disabled by default.
A permission fault on such a block can still need a page table page
to install the smaller mapping. Top up the memcache for any permission
fault while dirty logging is active, not only for write faults.
The issue was discovered [1] by Sashiko.
Link: https://lore.kernel.org/all/59984F6D-06F2-4302-BDD7-92DF334E8FA0@grrlz.net/T/#t [1]
Fixes: 6f745f1bb5bf ("KVM: arm64: Convert user_mem_abort() to generic page-table API")
Cc: stable@vger.kernel.org
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
arch/arm64/kvm/mmu.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 3f57f6825a33..8911e319e6fa 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -2122,13 +2122,12 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
* Permission faults just need to update the existing leaf entry,
* and so normally don't require allocations from the memcache. The
* only exception to this is when dirty logging is enabled at runtime
- * and a write fault needs to collapse a block entry into a table. With
- * pKVM, they may still need a fresh mapping object if the fault turns
- * page entries into a block entry.
+ * and a fault needs to collapse a block entry into a table. With pKVM,
+ * they may still need a fresh mapping object if the fault turns page
+ * entries into a block entry.
*/
memcache = get_mmu_memcache(s2fd->vcpu);
- if (!perm_fault || (memslot_is_logging(s2fd->memslot) &&
- kvm_is_write_fault(s2fd->vcpu))) {
+ if (!perm_fault || memslot_is_logging(s2fd->memslot)) {
ret = topup_mmu_memcache(s2fd->vcpu, memcache);
if (ret)
return ret;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/3] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Bradley Morgan @ 2026-06-24 16:00 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Fuad Tabba, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Quentin Perret,
Vincent Donnefort, Gavin Shan, Alexandru Elisei, linux-arm-kernel,
kvmarm, linux-kernel, Bradley Morgan
In-Reply-To: <20260624160028.15591-1-include@grrlz.net>
pKVM keeps its own mapping list for stage 2 operations. Its flush path
uses that list directly, so it lost the PTE attribute check done by the
generic stage 2 walker.
Record whether a mapping is cacheable and skip cache maintenance for
mappings that are not cacheable.
Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
arch/arm64/kvm/pkvm.c | 51 ++++++++++++++++++++++++++++++++++---------
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
index 428723b1b0f5..ca6e823028c2 100644
--- a/arch/arm64/kvm/pkvm.c
+++ b/arch/arm64/kvm/pkvm.c
@@ -302,9 +302,32 @@ static u64 __pkvm_mapping_start(struct pkvm_mapping *m)
return m->gfn * PAGE_SIZE;
}
+#define PKVM_MAPPING_NR_PAGES_MASK GENMASK_ULL(47, 0)
+#define PKVM_MAPPING_CACHEABLE BIT_ULL(48)
+
+static u64 pkvm_mapping_nr_pages(struct pkvm_mapping *m)
+{
+ return m->nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
+}
+
+static bool pkvm_mapping_is_cacheable(struct pkvm_mapping *m)
+{
+ return m->nr_pages & PKVM_MAPPING_CACHEABLE;
+}
+
+static void pkvm_mapping_set_nr_pages(struct pkvm_mapping *m, u64 nr_pages,
+ bool cacheable)
+{
+ WARN_ON_ONCE(nr_pages & ~PKVM_MAPPING_NR_PAGES_MASK);
+
+ m->nr_pages = nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
+ if (cacheable)
+ m->nr_pages |= PKVM_MAPPING_CACHEABLE;
+}
+
static u64 __pkvm_mapping_end(struct pkvm_mapping *m)
{
- return (m->gfn + m->nr_pages) * PAGE_SIZE - 1;
+ return (m->gfn + pkvm_mapping_nr_pages(m)) * PAGE_SIZE - 1;
}
INTERVAL_TREE_DEFINE(struct pkvm_mapping, node, u64, __subtree_last,
@@ -350,7 +373,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct kvm_pgtable *pgt, u64 start, u64
continue;
page = pfn_to_page(mapping->pfn);
- WARN_ON_ONCE(mapping->nr_pages != 1);
+ WARN_ON_ONCE(pkvm_mapping_nr_pages(mapping) != 1);
unpin_user_pages_dirty_lock(&page, 1, true);
account_locked_vm(kvm->mm, 1, false);
pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
@@ -369,7 +392,7 @@ static int __pkvm_pgtable_stage2_unshare(struct kvm_pgtable *pgt, u64 start, u64
for_each_mapping_in_range_safe(pgt, start, end, mapping) {
ret = kvm_call_hyp_nvhe(__pkvm_host_unshare_guest, handle, mapping->gfn,
- mapping->nr_pages);
+ pkvm_mapping_nr_pages(mapping));
if (WARN_ON(ret))
return ret;
pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
@@ -448,7 +471,7 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
* permission faults are handled in the relax_perms() path.
*/
if (mapping) {
- if (size == (mapping->nr_pages * PAGE_SIZE))
+ if (size == (pkvm_mapping_nr_pages(mapping) * PAGE_SIZE))
return -EAGAIN;
/*
@@ -472,7 +495,9 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
swap(mapping, cache->mapping);
mapping->gfn = gfn;
mapping->pfn = pfn;
- mapping->nr_pages = size / PAGE_SIZE;
+ pkvm_mapping_set_nr_pages(mapping, size / PAGE_SIZE,
+ !(prot & (KVM_PGTABLE_PROT_DEVICE |
+ KVM_PGTABLE_PROT_NORMAL_NC)));
pkvm_mapping_insert(mapping, &pgt->pkvm_mappings);
return ret;
@@ -503,7 +528,7 @@ int pkvm_pgtable_stage2_wrprotect(struct kvm_pgtable *pgt, u64 addr, u64 size)
lockdep_assert_held(&kvm->mmu_lock);
for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
ret = kvm_call_hyp_nvhe(__pkvm_host_wrprotect_guest, handle, mapping->gfn,
- mapping->nr_pages);
+ pkvm_mapping_nr_pages(mapping));
if (WARN_ON(ret))
break;
}
@@ -517,9 +542,13 @@ int pkvm_pgtable_stage2_flush(struct kvm_pgtable *pgt, u64 addr, u64 size)
struct pkvm_mapping *mapping;
lockdep_assert_held(&kvm->mmu_lock);
- for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
+ for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
+ if (!pkvm_mapping_is_cacheable(mapping))
+ continue;
+
__clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
- PAGE_SIZE * mapping->nr_pages);
+ PAGE_SIZE * pkvm_mapping_nr_pages(mapping));
+ }
return 0;
}
@@ -536,8 +565,10 @@ bool pkvm_pgtable_stage2_test_clear_young(struct kvm_pgtable *pgt, u64 addr, u64
lockdep_assert_held(&kvm->mmu_lock);
for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
- young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest, handle, mapping->gfn,
- mapping->nr_pages, mkold);
+ young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest,
+ handle, mapping->gfn,
+ pkvm_mapping_nr_pages(mapping),
+ mkold);
return young;
}
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.