* Re: [PATCH 05/16] fscrypt: Always use blk-crypto for contents on block-based filesystems
From: Christoph Hellwig @ 2026-06-26 5:23 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fscrypt, linux-fsdevel, linux-ext4, linux-f2fs-devel,
linux-block, Theodore Ts'o, Andreas Dilger, Baokun Li,
Jan Kara, Ojaswin Mujoo, Ritesh Harjani, Zhang Yi, Jaegeuk Kim,
Chao Yu
In-Reply-To: <20260624050334.124606-6-ebiggers@kernel.org>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH 06/16] ext4: Remove fs-layer file contents en/decryption code
From: Christoph Hellwig @ 2026-06-26 5:24 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fscrypt, linux-fsdevel, linux-ext4, linux-f2fs-devel,
linux-block, Christoph Hellwig, Theodore Ts'o, Andreas Dilger,
Baokun Li, Jan Kara, Ojaswin Mujoo, Ritesh Harjani, Zhang Yi,
Jaegeuk Kim, Chao Yu
In-Reply-To: <20260624050334.124606-7-ebiggers@kernel.org>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH 07/16] ext4: Make ext4_bio_write_folio() return void
From: Christoph Hellwig @ 2026-06-26 5:25 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fscrypt, linux-fsdevel, linux-ext4, linux-f2fs-devel,
linux-block, Theodore Ts'o, Andreas Dilger, Baokun Li,
Jan Kara, Ojaswin Mujoo, Ritesh Harjani, Zhang Yi, Jaegeuk Kim,
Chao Yu
In-Reply-To: <20260624050334.124606-8-ebiggers@kernel.org>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH 08/16] ext4: Further de-generalize the bio postprocessing code
From: Christoph Hellwig @ 2026-06-26 5:26 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fscrypt, linux-fsdevel, linux-ext4, linux-f2fs-devel,
linux-block, Christoph Hellwig, Theodore Ts'o, Andreas Dilger,
Baokun Li, Jan Kara, Ojaswin Mujoo, Ritesh Harjani, Zhang Yi,
Jaegeuk Kim, Chao Yu
In-Reply-To: <20260624050334.124606-9-ebiggers@kernel.org>
On Tue, Jun 23, 2026 at 10:03:26PM -0700, Eric Biggers wrote:
> +extern int __init ext4_init_verity_caches(void);
> +extern void ext4_exit_verity_caches(void);
Maybe drop these pointless externs while you're at it?
^ permalink raw reply
* Re: [PATCH 10/16] fs/buffer: Remove fs-layer decryption code
From: Christoph Hellwig @ 2026-06-26 5:26 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fscrypt, linux-fsdevel, linux-ext4, linux-f2fs-devel,
linux-block, Theodore Ts'o, Andreas Dilger, Baokun Li,
Jan Kara, Ojaswin Mujoo, Ritesh Harjani, Zhang Yi, Jaegeuk Kim,
Chao Yu
In-Reply-To: <20260624050334.124606-11-ebiggers@kernel.org>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH 11/16] fscrypt: Replace calls to fscrypt_inode_uses_inline_crypto()
From: Christoph Hellwig @ 2026-06-26 5:27 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fscrypt, linux-fsdevel, linux-ext4, linux-f2fs-devel,
linux-block, Theodore Ts'o, Andreas Dilger, Baokun Li,
Jan Kara, Ojaswin Mujoo, Ritesh Harjani, Zhang Yi, Jaegeuk Kim,
Chao Yu
In-Reply-To: <20260624050334.124606-12-ebiggers@kernel.org>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH 12/16] fscrypt: Remove fscrypt_dio_supported()
From: Christoph Hellwig @ 2026-06-26 5:28 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fscrypt, linux-fsdevel, linux-ext4, linux-f2fs-devel,
linux-block, Theodore Ts'o, Andreas Dilger, Baokun Li,
Jan Kara, Ojaswin Mujoo, Ritesh Harjani, Zhang Yi, Jaegeuk Kim,
Chao Yu
In-Reply-To: <20260624050334.124606-13-ebiggers@kernel.org>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH 13/16] fscrypt: Remove fs-layer zeroout code
From: Christoph Hellwig @ 2026-06-26 5:28 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fscrypt, linux-fsdevel, linux-ext4, linux-f2fs-devel,
linux-block, Theodore Ts'o, Andreas Dilger, Baokun Li,
Jan Kara, Ojaswin Mujoo, Ritesh Harjani, Zhang Yi, Jaegeuk Kim,
Chao Yu
In-Reply-To: <20260624050334.124606-14-ebiggers@kernel.org>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH 14/16] fscrypt: Remove unused functions and workqueue
From: Christoph Hellwig @ 2026-06-26 5:28 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fscrypt, linux-fsdevel, linux-ext4, linux-f2fs-devel,
linux-block, Theodore Ts'o, Andreas Dilger, Baokun Li,
Jan Kara, Ojaswin Mujoo, Ritesh Harjani, Zhang Yi, Jaegeuk Kim,
Chao Yu
In-Reply-To: <20260624050334.124606-15-ebiggers@kernel.org>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH 15/16] fscrypt: Merge bio.c and inline_crypt.c into block.c
From: Christoph Hellwig @ 2026-06-26 5:32 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fscrypt, linux-fsdevel, linux-ext4, linux-f2fs-devel,
linux-block, Christoph Hellwig, Theodore Ts'o, Andreas Dilger,
Baokun Li, Jan Kara, Ojaswin Mujoo, Ritesh Harjani, Zhang Yi,
Jaegeuk Kim, Chao Yu
In-Reply-To: <20260624050334.124606-16-ebiggers@kernel.org>
On Tue, Jun 23, 2026 at 10:03:33PM -0700, Eric Biggers wrote:
> Now that fscrypt always uses blk-crypto on block-based filesystems,
> there's no meaningful difference between bio.c and inline_crypt.c.
> Therefore merge the two files into one named block.c.
>
> Note: I didn't carry over bio.c's "Copyright (C) 2015, Motorola
> Mobility", as none of the code that applied to remained.
Yeah the current from of the code is almost entirely mine,
with some slight traces of your earlier version.
> +struct fscrypt_zero_done {
> + atomic_t pending;
> + blk_status_t status;
> + struct completion done;
> +};
> +
> +static void fscrypt_zeroout_range_done(struct fscrypt_zero_done *done)
> +{
> + if (atomic_dec_and_test(&done->pending))
> + complete(&done->done);
> +}
> +
> +static void fscrypt_zeroout_range_end_io(struct bio *bio)
> +{
> + struct fscrypt_zero_done *done = bio->bi_private;
> +
> + if (bio->bi_status)
> + cmpxchg(&done->status, 0, bio->bi_status);
> + fscrypt_zeroout_range_done(done);
> + bio_put(bio);
> +}
> +
> +/**
> + * fscrypt_zeroout_range() - zero out a range of blocks in an encrypted file
> + * @inode: the file's inode
> + * @pos: the first file position (in bytes) to zero out
> + * @sector: the first sector to zero out
> + * @len: bytes to zero out
> + *
> + * Zero out filesystem blocks in an encrypted regular file on-disk, i.e. write
> + * ciphertext blocks which decrypt to the all-zeroes block. The blocks must be
> + * both logically and physically contiguous. It's also assumed that the
> + * filesystem only uses a single block device, ->s_bdev. @len must be a
> + * multiple of the file system logical block size.
> + *
> + * Note that since each block uses a different IV, this involves writing a
> + * different ciphertext to each block; we can't simply reuse the same one.
> + *
> + * Return: 0 on success; -errno on failure.
> + */
> +int fscrypt_zeroout_range(const struct inode *inode, loff_t pos,
> + sector_t sector, u64 len)
.. but I wonder if we should rename this and move it to libfs, as it
works just fine without encyption and file systems could call it
for the non-fscrypt case and consolidate on a single implementation.
But maybe some other time, no need to complicate this series.
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH 16/16] fscrypt: Add safety checks to non-block-based en/decryption
From: Christoph Hellwig @ 2026-06-26 5:33 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fscrypt, linux-fsdevel, linux-ext4, linux-f2fs-devel,
linux-block, Theodore Ts'o, Andreas Dilger, Baokun Li,
Jan Kara, Ojaswin Mujoo, Ritesh Harjani, Zhang Yi, Jaegeuk Kim,
Chao Yu
In-Reply-To: <20260624050334.124606-17-ebiggers@kernel.org>
On Tue, Jun 23, 2026 at 10:03:34PM -0700, Eric Biggers wrote:
> fscrypt_encrypt_pagecache_blocks(), fscrypt_encrypt_block_inplace(),
> fscrypt_decrypt_block_inplace() would dereference a NULL
> fscrypt_inode_info pointer if they were to be called on a file that
> hasn't been opened yet or on a block-based filesystem. Since they have
> the ability to report errors anyway, add WARN_ON_ONCE checks for this.
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH] block: avoid potential deadlock on zone revalidation failure
From: Damien Le Moal @ 2026-06-26 5:40 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jens Axboe, linux-block
In-Reply-To: <20260625115232.GC18076@lst.de>
On 6/25/26 8:52 PM, Christoph Hellwig wrote:
> On Thu, Jun 25, 2026 at 03:28:24PM +0900, Damien Le Moal wrote:
>
> [very long lockdep trace]
>
>> + /*
>> + * We may already have a zone write plug workqueue as this function may
>> + * be called after disk_free_zone_resources(), which does not destroy
>> + * the workqueue (the zone write plugs workqueue is destroyed at
>> + * disk_release() time).
>> + */
>> + if (!disk->zone_wplugs_wq) {
>
> Can't we just allocate this at add_disk time instead of the magic NULL
> check here to mirror the freeing side?
Just tried and yes, that is fine to do. A bit more code reshuffling that I
wanted for a fix, but in the end, a lot cleaner and simpler.
Will send V2 after some more tests.
--
Damien Le Moal
Western Digital Research
^ permalink raw reply
* Re:Re: [PATCH] block: use blk_validate_byte_range() for BLKZEROOUT and BLKSECDISCARD
From: 李佑鸿 @ 2026-06-26 5:58 UTC (permalink / raw)
To: axboe; +Cc: linux-block, liyouhong, Christoph Hellwig
In-Reply-To: <ah033gO9mMlbCwKn@infradead.org>
At 2026-06-01 15:42:22, "Christoph Hellwig" <hch@infradead.org> wrote:
>Looks good:
>
>Reviewed-by: Christoph Hellwig <hch@lst.de>
Hi,
Friendly ping on this patch below — please let me know if anything
else is needed from my side.
Thanks,
Liyouhong
^ permalink raw reply
* Re: [PATCH] block: bio: check offset/length sanity in {__,}bio_add_page()
From: Christoph Hellwig @ 2026-06-26 6:12 UTC (permalink / raw)
To: Sergey Shtylyov; +Cc: Jens Axboe, linux-block, linux-kernel, Karina Yankevich
In-Reply-To: <20260624203327.25553-1-s.shtylyov@auroraos.dev>
On Wed, Jun 24, 2026 at 11:33:26PM +0300, Sergey Shtylyov wrote:
> Sum of the *struct* bio_vec's fields bv_offset and bv_len is calculated in
> some functions in block/{blk-merge.c,blk.h> (and that sum is often compared
> to PAGE_SIZE) -- that sum may overflow (and so the comparison yield a wrong
> result) if some bad arguments were previusly passed to {__,}bio_add_page().
> Add a check that the sum of the offset and length parameters won't overflow
> to {__,}bio_add_page()...
I'm not really sure there's much of a point in this, because the
error handling isn't really going to help to recover either. I think
we have to trust our programmers to at least get the very basics
right.
^ permalink raw reply
* Re: [PATCH v2 2/4] blk-cgroup: fix race between policy activation and blkg destruction
From: Nilay Shroff @ 2026-06-26 6:12 UTC (permalink / raw)
To: yukuai, Tejun Heo, Josef Bacik, Jens Axboe
Cc: Zheng Qixing, Christoph Hellwig, Tang Yizhou, Ming Lei, cgroups,
linux-block, linux-kernel
In-Reply-To: <749d17be-ff9f-4f70-a948-0133f02eec93@fygo.io>
On 6/26/26 7:22 AM, yu kuai wrote:
> Hi,
>
> 在 2026/6/26 9:50, yu kuai 写道:
>> Hi,
>>
>> 在 2026/6/25 23:08, Nilay Shroff 写道:
>>> On 6/24/26 12:16 PM, Yu Kuai wrote:
>>>> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
>>>> index 7baccfb690fe..f7e788a7fe95 100644
>>>> --- a/block/blk-cgroup.c
>>>> +++ b/block/blk-cgroup.c
>>>> @@ -1563,10 +1563,12 @@ int blkcg_activate_policy(struct gendisk
>>>> *disk, const struct blkcg_policy *pol)
>>>> if (WARN_ON_ONCE(!pol->pd_alloc_fn || !pol->pd_free_fn))
>>>> return -EINVAL;
>>>> if (queue_is_mq(q))
>>>> memflags = blk_mq_freeze_queue(q);
>>>> +
>>>> + mutex_lock(&q->blkcg_mutex);
>>>> retry:
>>>> spin_lock_irq(&q->queue_lock);
>>>> /* blkg_list is pushed at the head, reverse walk to
>>>> initialize parents first */
>>>> list_for_each_entry_reverse(blkg, &q->blkg_list, q_node) {
>>>> @@ -1625,10 +1627,11 @@ int blkcg_activate_policy(struct gendisk
>>>> *disk, const struct blkcg_policy *pol)
>>>> __set_bit(pol->plid, q->blkcg_pols);
>>>> ret = 0;
>>>> spin_unlock_irq(&q->queue_lock);
>>>> out:
>>>> + mutex_unlock(&q->blkcg_mutex);
>>>> if (queue_is_mq(q))
>>>> blk_mq_unfreeze_queue(q, memflags);
>>>> if (pinned_blkg)
>>>> blkg_put(pinned_blkg);
>>>> if (pd_prealloc)
>>> If the policy allocation fails, we jump to the lable enomem: and
>>> teardown pds.
>>> But I see this path still only acquires ->queue_lock. Don't we also need
>>> to protect it with ->blkcg_mutex?
>> Yes, I agree we should protect it as well.
>
> Just take a closer look at the code, the enomem is already protected by
> blkcg_mutex :)
>
Oh yes, but the ->blkcg_mutex is never released if we jump to enomem.
So that may potentially cause deadlock. We need to release ->blkcg_mutex
once blkcg_policy_teardown_pds() returns. Or may be refactor code (or add
comment) so that it's easy to realize or spot the ->blkcg_mutex is acquired
and then released around blkcg_policy_teardown_pds().
>>
>>> Moreover I still see race between blkg insertion in blkg_create() which
>>> still doesn't use ->blkcg_mutex and so list traversal in
>>> bfq_end_wr_async()
>>> may still race with blkg_create(), isn't it? I remember you once told
>>> this will be handled in another series but I couldn't find that yet.
>> This is the set:
>>
>> [PATCH 0/8] blk-cgroup: remove queue_lock nesting from blkcg paths - Yu
>> Kuai <https://lore.kernel.org/all/cover.1780621988.git.yukuai@fygo.io/>
>>
>> Noted that set just make sure queue_lock is not nested under other atomic
>> context, and that set do not acquire blkcg_mutex for blkg_create() yet. Howerver,
>> with that set it'll be easy to convert all queue_lock to blkcg_mtuex for blkg
>> protection, and together with lots of blk-cgroup code cleanups.
>>
Okay, so are you planning to send a follow-up patchset that replaces ->queue_lock
with ->blkcg_mutex for protecting the blkg_list? If so, I'd still prefer acquiring
->blkcg_mutex around blkg_create() in this patchset. That would address the race
between blkg_create() and the blkg_list traversal in bfq_end_wr_async(), while the
subsequent series can focus on cleaning up and removing the remaining ->queue_lock
usage for blkg protection.
Thanks,
--Nilay
^ permalink raw reply
* Re: [PATCH] iomap: Remove FGP_NOFS from iomap_get_folio()
From: Christoph Hellwig @ 2026-06-26 6:13 UTC (permalink / raw)
To: Matthew Wilcox (Oracle)
Cc: Christian Brauner, Darrick J. Wong, Jens Axboe, Namjae Jeon,
Sungjong Seo, Yuezhang Mo, Miklos Szeredi, Andreas Gruenbacher,
Hyunchul Lee, Konstantin Komarov, Carlos Maiolino, Damien Le Moal,
Naohiro Aota, Johannes Thumshirn, linux-xfs, linux-fsdevel,
linux-block, fuse-devel, gfs2, ntfs3
In-Reply-To: <20260624174228.2015893-1-willy@infradead.org>
On Wed, Jun 24, 2026 at 06:42:26PM +0100, Matthew Wilcox (Oracle) wrote:
> FGP_NOFS is legacy; filesystems should be using memalloc_nofs_save/restore
> instead. We have it here in iomap because it was buried in
> grab_cache_page_write_begin() and we didn't want to change this behaviour
> as part of the folio transition.
>
> I have tested this with XFS and see no issues. Other filesystems (cc'd)
> may need to make adjustments. Please test with lockdep enabled.
I think the most interesting one to test here would be gfs2 as it has
rather alaborate locking in the write path.
^ permalink raw reply
* [PATCH 1/1] block: partition: aix: bound LV name formatting
From: Ren Wei @ 2026-06-26 7:21 UTC (permalink / raw)
To: linux-block
Cc: axboe, kees, hexlabsecurity, phdm, objecting, akpm, yuantan098,
bird, roxy520tt, n05ec
In-Reply-To: <cover.1782398104.git.roxy520tt@gmail.com>
From: Zhiling Zou <roxy520tt@gmail.com>
AIX logical volume names are stored on disk as fixed-size fields.
The partition parser reads them into struct lvname, but later formats
the fields with %s. If an on-disk name is not NUL-terminated, the string
formatting code can keep reading past the end of the 64-byte name field.
Limit the formatted string length to the size of the on-disk name field
when printing AIX logical volume names.
Fixes: 6ceea22bbbc8 ("partitions: add aix lvm partition support files")
Cc: stable@vger.kernel.org
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Assisted-by: Codex:gpt-5.4
Signed-off-by: Zhiling Zou <roxy520tt@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
block/partitions/aix.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/block/partitions/aix.c b/block/partitions/aix.c
index f3c4174e003e..de19c19c85b2 100644
--- a/block/partitions/aix.c
+++ b/block/partitions/aix.c
@@ -261,7 +261,8 @@ int aix_partition(struct parsed_partitions *state)
put_partition(state, lv_ix + 1,
(i + 1 - lp_ix) * pp_blocks_size + psn_part1,
lvip[lv_ix].pps_per_lv * pp_blocks_size);
- seq_buf_printf(&state->pp_buf, " <%s>\n",
+ seq_buf_printf(&state->pp_buf, " <%.*s>\n",
+ (int)sizeof(n[lv_ix].name),
n[lv_ix].name);
lvip[lv_ix].lv_is_contiguous = 1;
ret = 1;
@@ -273,7 +274,8 @@ int aix_partition(struct parsed_partitions *state)
if (lvip[i].pps_found && !lvip[i].lv_is_contiguous) {
char tmp[sizeof(n[i].name) + 1]; // null char
- snprintf(tmp, sizeof(tmp), "%s", n[i].name);
+ snprintf(tmp, sizeof(tmp), "%.*s",
+ (int)sizeof(n[i].name), n[i].name);
pr_warn("partition %s (%u pp's found) is "
"not contiguous\n",
tmp, lvip[i].pps_found);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] block: Fix dio->ref leak on integrity error in __blkdev_direct_IO()
From: Yang Xiuwei @ 2026-06-26 8:58 UTC (permalink / raw)
To: vulab; +Cc: axboe, linux-block, linux-kernel, stable, Yang Xiuwei
In-Reply-To: <20260625092106.47695-1-vulab@iscas.ac.cn>
---
Hi Wentao,
On Thu, Jun 25, 2026 at 05:21:06PM +0800, Wentao Liang wrote:
> Fix by matching the existing error handling pattern used for
> blkdev_iov_iter_get_pages() failure: end the current bio with an error
> status and break out of the submission loop.
Looks good to me.
> + if (unlikely(ret)) {
> + bio->bi_status = errno_to_blk_status(ret);
> + bio_endio(bio);
> + break;
> + }
Small nit: consider bio_endio_status(bio, errno_to_blk_status(ret))
instead, now that the helper exists.
Reviewed-by: Yang Xiuwei <yangxiuwei@kylinos.cn>
Thanks,
Yang Xiuwei
^ permalink raw reply
* Re: [PATCH 1/1] block: partition: aix: bound LV name formatting
From: Philippe De Muyter @ 2026-06-26 9:09 UTC (permalink / raw)
To: Ren Wei
Cc: linux-block, axboe, kees, hexlabsecurity, objecting, akpm,
yuantan098, bird, roxy520tt
In-Reply-To: <6f381f63ccfe458e15067fd9b9428884cb8d5f97.1782407859.git.roxy520tt@gmail.com>
Hello Ren Wei,
On Fri, Jun 26, 2026 at 03:21:22PM +0800, Ren Wei wrote:
> From: Zhiling Zou <roxy520tt@gmail.com>
>
> AIX logical volume names are stored on disk as fixed-size fields.
> The partition parser reads them into struct lvname, but later formats
> the fields with %s. If an on-disk name is not NUL-terminated, the string
> formatting code can keep reading past the end of the 64-byte name field.
>
> Limit the formatted string length to the size of the on-disk name field
> when printing AIX logical volume names.
>
> Fixes: 6ceea22bbbc8 ("partitions: add aix lvm partition support files")
> Cc: stable@vger.kernel.org
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Xin Liu <bird@lzu.edu.cn>
> Assisted-by: Codex:gpt-5.4
> Signed-off-by: Zhiling Zou <roxy520tt@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
> block/partitions/aix.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/block/partitions/aix.c b/block/partitions/aix.c
> index f3c4174e003e..de19c19c85b2 100644
> --- a/block/partitions/aix.c
> +++ b/block/partitions/aix.c
> @@ -261,7 +261,8 @@ int aix_partition(struct parsed_partitions *state)
> put_partition(state, lv_ix + 1,
> (i + 1 - lp_ix) * pp_blocks_size + psn_part1,
> lvip[lv_ix].pps_per_lv * pp_blocks_size);
> - seq_buf_printf(&state->pp_buf, " <%s>\n",
> + seq_buf_printf(&state->pp_buf, " <%.*s>\n",
> + (int)sizeof(n[lv_ix].name),
> n[lv_ix].name);
> lvip[lv_ix].lv_is_contiguous = 1;
> ret = 1;
> @@ -273,7 +274,8 @@ int aix_partition(struct parsed_partitions *state)
> if (lvip[i].pps_found && !lvip[i].lv_is_contiguous) {
> char tmp[sizeof(n[i].name) + 1]; // null char
>
> - snprintf(tmp, sizeof(tmp), "%s", n[i].name);
> + snprintf(tmp, sizeof(tmp), "%.*s",
> + (int)sizeof(n[i].name), n[i].name);
Is this change necessary ? snprintf always adds a NULL terminator and
truncates the input if needed, isn't it ?
> pr_warn("partition %s (%u pp's found) is "
> "not contiguous\n",
> tmp, lvip[i].pps_found);
> --
> 2.43.0
Best Regards
Philippe De Muyter
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: remoteproc: document M0 Bluetooth Subsystem secure PIL
From: Krzysztof Kozlowski @ 2026-06-26 10:47 UTC (permalink / raw)
To: George Moussalem
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260625-ipq5018-bluetooth-v1-1-d999be0e04f7@outlook.com>
On Thu, Jun 25, 2026 at 06:10:05PM +0400, George Moussalem wrote:
> Document the M0 Bluetooth Subsystem remote processor core found in the
> Qualcomm IPQ5018 SoC. Firmware loaded is authenticated via TrustZone.
> The firmware running on the M0 core provides bluetooth functionality.
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
> .../bindings/remoteproc/qcom,m0-btss-pil.yaml | 72 ++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml
> new file mode 100644
> index 000000000000..397bb6815d71
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml
Use compatible as filename.
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/remoteproc/qcom,m0-btss-pil.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm M0 BTSS Peripheral Image Loader
> +
> +maintainers:
> + - George Moussalem <george.moussalem@outlook.com>
> +
> +description:
> + Qualcomm M0 BTSS Peripheral Secure Image Loader loads firmware and powers up
> + the M0 BTSS remote processor core on the Qualcomm IPQ5018 SoC.
> +
> +properties:
> + compatible:
> + enum:
> + - qcom,ipq5018-btss-pil
> +
> + firmware-name:
> + maxItems: 1
> + description: Firmware name for the M0 Bluetooth Subsystem core
You can drop description, pretty obvious.
> +
> + clocks:
> + items:
> + - description: M0 BTSS low power oscillator clock
> +
> + clock-names:
> + items:
> + - const: btss_lpo_clk
Just "lpo"
> +
> + memory-region:
> + items:
> + - description: M0 BTSS reserved memory carveout
> +
> + resets:
> + items:
> + - description: M0 BTSS reset
> +
> + reset-names:
> + items:
> + - const: btss_reset
Drop names. Using block name as input name is not really useful.
No supplies? no address space? How do you actually trigger remoteproc
startup?
> +
> +required:
> + - compatible
> + - firmware-name
> + - clocks
> + - clock-names
> + - resets
> + - reset-names
> + - memory-region
> +
> +additionalProperties: false
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: remoteproc: document M0 Bluetooth Subsystem secure PIL
From: George Moussalem @ 2026-06-26 10:51 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260626-tiny-warm-jerboa-3ba57a@quoll>
Hi Krzysztof,
On 6/26/26 14:47, Krzysztof Kozlowski wrote:
> On Thu, Jun 25, 2026 at 06:10:05PM +0400, George Moussalem wrote:
>> Document the M0 Bluetooth Subsystem remote processor core found in the
>> Qualcomm IPQ5018 SoC. Firmware loaded is authenticated via TrustZone.
>> The firmware running on the M0 core provides bluetooth functionality.
>>
>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>> ---
>> .../bindings/remoteproc/qcom,m0-btss-pil.yaml | 72 ++++++++++++++++++++++
>> 1 file changed, 72 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml
>> new file mode 100644
>> index 000000000000..397bb6815d71
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,m0-btss-pil.yaml
>
> Use compatible as filename.
understood, will update in v2.
>
>> @@ -0,0 +1,72 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/remoteproc/qcom,m0-btss-pil.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm M0 BTSS Peripheral Image Loader
>> +
>> +maintainers:
>> + - George Moussalem <george.moussalem@outlook.com>
>> +
>> +description:
>> + Qualcomm M0 BTSS Peripheral Secure Image Loader loads firmware and powers up
>> + the M0 BTSS remote processor core on the Qualcomm IPQ5018 SoC.
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - qcom,ipq5018-btss-pil
>> +
>> + firmware-name:
>> + maxItems: 1
>> + description: Firmware name for the M0 Bluetooth Subsystem core
>
> You can drop description, pretty obvious.
will drop
>
>> +
>> + clocks:
>> + items:
>> + - description: M0 BTSS low power oscillator clock
>> +
>> + clock-names:
>> + items:
>> + - const: btss_lpo_clk
>
> Just "lpo"
will update
>
>> +
>> + memory-region:
>> + items:
>> + - description: M0 BTSS reserved memory carveout
>> +
>> + resets:
>> + items:
>> + - description: M0 BTSS reset
>> +
>> + reset-names:
>> + items:
>> + - const: btss_reset
>
> Drop names. Using block name as input name is not really useful.
Will drop
>
> No supplies? no address space? How do you actually trigger remoteproc
> startup?
No supplied and no address space. The core is booted by a
qcom_scm_auth_and_reset call to TrustZone which authenticated the
firmware, takes it out of reset and boots it.
>
>> +
>> +required:
>> + - compatible
>> + - firmware-name
>> + - clocks
>> + - clock-names
>> + - resets
>> + - reset-names
>> + - memory-region
>> +
>> +additionalProperties: false
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller
From: Krzysztof Kozlowski @ 2026-06-26 10:53 UTC (permalink / raw)
To: George Moussalem
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260625-ipq5018-bluetooth-v1-4-d999be0e04f7@outlook.com>
On Thu, Jun 25, 2026 at 06:10:08PM +0400, George Moussalem wrote:
> Document the Qualcomm IPQ5018 Bluetooth controller.
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
> .../bindings/net/bluetooth/qcom,ipq5018-bt.yaml | 63 ++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml
> new file mode 100644
> index 000000000000..afd33f851858
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/bluetooth/qcom,ipq5018-bt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm IPQ5018 Bluetooth
> +
> +maintainers:
> + - George Moussalem <george.moussalem@outlook.com>
> +
> +properties:
> + compatible:
> + enum:
> + - qcom,ipq5018-bt
> +
> + interrupts:
> + items:
> + - description:
> + Interrupt line from the M0 Bluetooth Subsystem to the host processor
What is M0?
Anyway, this part feels completely redundant. Can "interrupts" property
be anything else than an interrupt line from the device to the host
processor?
> + to notify it of events such as re
This feels useful, but cut/incomplete.
> +
> + qcom,ipc:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + - items:
> + - description: phandle to a syscon node representing the APCS registers
> + - description: u32 representing offset to the register within the syscon
> + - description: u32 representing the ipc bit within the register
> + description: |
> + These entries specify the outgoing IPC bit used for signaling the remote
> + M0 BTSS core of a host event or for sending an ACK if the remote processor
> + expects it.
> +
> + qcom,rproc:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle to the remote processor node representing the M0 BTSS core.
> +
> +required:
> + - compatible
> + - interrupts
> + - qcom,ipc
> + - qcom,rproc
> +
> +allOf:
> + - $ref: bluetooth-controller.yaml#
> + - $ref: qcom,bluetooth-common.yaml
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + bluetooth: bluetooth {
Drop unused label
> + compatible = "qcom,ipq5018-bt";
> +
> + qcom,ipc = <&apcs_glb 8 23>;
> + interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
No firmware to load?
It feels like remoteproc node split is fake. The property qcom,rproc is
even more supporting that case. Shouldn't this be simply one device -
bluetooth? What sort of two devices do you have exactly? How can I
identify them in the hardware?
> +
> + qcom,rproc = <&m0_btss>;
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: remoteproc: document M0 Bluetooth Subsystem secure PIL
From: Krzysztof Kozlowski @ 2026-06-26 11:16 UTC (permalink / raw)
To: George Moussalem
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <SN7PR19MB67364ADE8CDD7C31297AE18D9DEB2@SN7PR19MB6736.namprd19.prod.outlook.com>
On 26/06/2026 12:51, George Moussalem wrote:
>>
>> No supplies? no address space? How do you actually trigger remoteproc
>> startup?
>
> No supplied and no address space. The core is booted by a
> qcom_scm_auth_and_reset call to TrustZone which authenticated the
> firmware, takes it out of reset and boots it.
Then commit msg could be improved:
"Firmware loaded is authenticated via TrustZone." ->
"Firmware is loaded and authenticated via TrustZone."
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/6] remoteproc: qcom: Add M0 BTSS secure PIL driver
From: Konrad Dybcio @ 2026-06-26 11:20 UTC (permalink / raw)
To: george.moussalem, Jens Axboe, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Saravana Kannan, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Bjorn Andersson,
Konrad Dybcio, Mathieu Poirier, Philipp Zabel
Cc: linux-block, linux-kernel, linux-mmc, devicetree, linux-wireless,
ath10k, linux-arm-msm, linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260625-ipq5018-bluetooth-v1-2-d999be0e04f7@outlook.com>
On 6/25/26 4:10 PM, George Moussalem via B4 Relay wrote:
> From: George Moussalem <george.moussalem@outlook.com>
>
> Add support to bring up the M0 core of the bluetooth subsystem found in
> the IPQ5018 SoC.
>
> The signed firmware loaded is authenticated by TrustZone. If successful,
> the M0 core boots the firmware and the peripheral is taken out of reset
> using a Secure Channel Manager call to TrustZone.
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
Can this not fit inside the existing PAS driver?
Konrad
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller
From: George Moussalem @ 2026-06-26 11:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260626-discerning-light-swan-6b599c@quoll>
On 6/26/26 14:53, Krzysztof Kozlowski wrote:
> On Thu, Jun 25, 2026 at 06:10:08PM +0400, George Moussalem wrote:
>> Document the Qualcomm IPQ5018 Bluetooth controller.
>>
>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>> ---
>> .../bindings/net/bluetooth/qcom,ipq5018-bt.yaml | 63 ++++++++++++++++++++++
>> 1 file changed, 63 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml
>> new file mode 100644
>> index 000000000000..afd33f851858
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml
>> @@ -0,0 +1,63 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/net/bluetooth/qcom,ipq5018-bt.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm IPQ5018 Bluetooth
>> +
>> +maintainers:
>> + - George Moussalem <george.moussalem@outlook.com>
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - qcom,ipq5018-bt
>> +
>> + interrupts:
>> + items:
>> + - description:
>> + Interrupt line from the M0 Bluetooth Subsystem to the host processor
>
> What is M0?
it's a low power Cortex M0 core, for Bluetooth processing in this case.
>
> Anyway, this part feels completely redundant. Can "interrupts" property
> be anything else than an interrupt line from the device to the host
> processor?
>
>
>> + to notify it of events such as re
>
> This feels useful, but cut/incomplete.
yeah, c/p error. The interrupt is to notify the host of bluetooth events
running on the m0 core, such as TX/CMD completion and/or availability of
new data frames in the ring buffers.
>
>> +
>> + qcom,ipc:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + items:
>> + - items:
>> + - description: phandle to a syscon node representing the APCS registers
>> + - description: u32 representing offset to the register within the syscon
>> + - description: u32 representing the ipc bit within the register
>> + description: |
>> + These entries specify the outgoing IPC bit used for signaling the remote
>> + M0 BTSS core of a host event or for sending an ACK if the remote processor
>> + expects it.
>> +
>> + qcom,rproc:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + Phandle to the remote processor node representing the M0 BTSS core.
>> +
>> +required:
>> + - compatible
>> + - interrupts
>> + - qcom,ipc
>> + - qcom,rproc
>> +
>> +allOf:
>> + - $ref: bluetooth-controller.yaml#
>> + - $ref: qcom,bluetooth-common.yaml
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +
>> + bluetooth: bluetooth {
>
> Drop unused label
will drop
>
>> + compatible = "qcom,ipq5018-bt";
>> +
>> + qcom,ipc = <&apcs_glb 8 23>;
>> + interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
>
> No firmware to load?
firmware is loaded by the remoteproc in patch 1
>
> It feels like remoteproc node split is fake. The property qcom,rproc is
> even more supporting that case. Shouldn't this be simply one device -
> bluetooth? What sort of two devices do you have exactly? How can I
> identify them in the hardware?
I wasn't sure how to represent the HW. Should I make this bluetooth node
a childnode of the rproc? Essentially, this is the transport layer
(using shared memory space and IPC/interrupt).
Most QCA BT controllers are also childnodes of a serdev/uart node as
they use serdev for transport.
From what I understand, it's simply BT firmware running on this
dedicated M0 core in the SoC itself connected to an RF.
>
>> +
>> + qcom,rproc = <&m0_btss>;
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox