* [PATCH 0/8] Organize the SMMUv3 invalidation flow so iommupt can use it
From: Jason Gunthorpe @ 2026-05-18 19:43 UTC (permalink / raw)
To: iommu, Joerg Roedel, Jean-Philippe Brucker, linux-arm-kernel,
Robin Murphy, Will Deacon
Cc: David Matlack, Pasha Tatashin, patches, Pranjal Shrivastava,
Samiullah Khawaja, Mostafa Saleh
[ This is part of the patch pile to move SMMUv3 over to the generic page
table:
1) Introduction of new gather items and RISCV usage
https://patch.msgid.link/r/0-v2-b5156f657dc1+25f-iommu_riscv_inv_jgg@nvidia.com
2) Remove SMMUv3 struct arm_smmu_cmdq_ent
https://patch.msgid.link/r/0-v2-47b2bf710ad5+716ac-smmu_no_cmdq_ent_jgg@nvidia.com
3) Organize the SMMUv3 invalidation flow so iommupt can use it
4) Use the generic iommu page table for SMMUv3
It depends on #2 only
The whole branch is here:
https://github.com/jgunthorpe/linux/commits/iommu_pt_arm64/
]
iommupt has a design that focuses on building a single iommu_iotlb_gather
for arbitary batches of map/unmap operations. The gather uses the free
list and it captures invalidations of tables, leaves and supports mixed
levels.
The introduction of PT_FEAT_DETAILED_GATHER provides some additional
information that is useful for ARM: the damage bitmaps for the table and
level changes.
Prior to switching SMMUv3 over to use iommupt prepare for this by
reworking the internal invalidation to work on the same data format that
iommupt will produce. Bridge the invalidations generated by io-pgtable
into the new format. The conversion is simple enough, io-pgtable generates
invalidation operations that have only a single set bit in
table_levels_bitmap/leaf_levels_bitmap, so we can convert the io-pgtable
provided size into the proper level leaf or table bit.
When iommupt uses this mechanism it will fill in full bitmaps reflecting
the union of all invalidations contained in the gather, and this series
provides an implementation that can work this way.
Like the other drivers the general algorithm focuses on trying to issue a
single command per gather or at most 512 single invalidations. If that
isn't possible then it falls back to full invalidation. Since table and
leaf invalidation are combined together there is no waste of invaliding
tables prior to performing a full invalidation.
On its own this provides value as the invalidation has a number of
rough spots:
- Non-leaf invalidation actually expands into a TLBI for every
translation granule because the inner logic doesn't special case the
walk vs leaf condition. Now that a table_levels_bitmap is used to
describe the walk invalidation it properly generates a RIL with optimal
TTL or only one single invalidation.
- RIL doesn't calculate perfect hints for SVA because the SVA rules are
different from the io-pgtable-arm rules that the RIL algorithm works
with. SVA can now express the combined leaf and table invalidation that
the MM callback represents and get the right TTL, with an optimization
for the common 4k only scenario.
- RIL didn't generate a single invalidation like VT-d and AMD do,
instead it tries to generate an exact coverage with many
smaller invalidations. Switch it to match the other drivers single
range approach for performance and consistency. Since ARM has a much
more flexible range definition the over invalidation is far smaller
than other systems.
The approach is to introduce a new struct arm_smmu_tlbi which
describes the invalidation, pre-compute into the tlbi the single and
range commands from the start/last and bitmaps, and then apply the
correct pre-computed command to each of items in the invalidation
list.
The RIL and single calculations are revised to use the new bitmaps
and accurately generate TTL/stride/etc.
Some of this design is to support another series to remove the batch on
the stack. Now that we have the invalidation list and the tlbi it is
simple to just expand the invs list directly into commands instead of
using the temporary on-stack batch array. Eventually removing batch will
save ~1k of stack usage here.
Jason Gunthorpe (8):
iommu/arm-smmu-v3: Pass the parameters for the invalidation in a
struct
iommu/arm-smmu-v3: Move pgsize out of arm_smmu_inv
iommu/arm-smmu-v3: Optimize range invalidation for latency
iommu/arm-smmu-v3: Keep track in the arm_smmu_invs if RIL is used
iommu/arm-smmu-v3: Precompute the invalidation commands
iommu/arm-smmu-v3: Populate the tlbi at the top of the call chain
iommu/arm-smmu-v3: Change how the tlbi describes the invalidation
iommu/arm-smmu-v3: Support the DS expansion of RIL's SCALE
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 32 +-
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-test.c | 30 +-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 439 ++++++++++++------
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 54 ++-
4 files changed, 382 insertions(+), 173 deletions(-)
base-commit: 82440c340635733f86ab9b1ade899ea21ef9da0b
--
2.43.0
^ permalink raw reply
* Re: [PATCH] media: mediatek: mdp: avoid double free on video register failure
From: kernel test robot @ 2026-05-18 20:30 UTC (permalink / raw)
To: Guangshuo Li, Minghsiu Tsai, Houlong Wei, Andrew-CT Chen,
Mauro Carvalho Chehab, Matthias Brugger,
AngeloGioacchino Del Regno, Hans Verkuil, linux-kernel,
linux-arm-kernel, linux-mediatek
Cc: oe-kbuild-all, linux-media, Guangshuo Li
In-Reply-To: <20260518125500.1000083-1-lgs201920130244@gmail.com>
Hi Guangshuo,
kernel test robot noticed the following build errors:
[auto build test ERROR on linuxtv-media-pending/master]
[also build test ERROR on media-tree/master linus/master v7.1-rc4 next-20260518]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Guangshuo-Li/media-mediatek-mdp-avoid-double-free-on-video-register-failure/20260518-211648
base: https://git.linuxtv.org/media-ci/media-pending.git master
patch link: https://lore.kernel.org/r/20260518125500.1000083-1-lgs201920130244%40gmail.com
patch subject: [PATCH] media: mediatek: mdp: avoid double free on video register failure
config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20260519/202605190406.bMshG7YY-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260519/202605190406.bMshG7YY-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605190406.bMshG7YY-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c: In function 'mtk_mdp_register_m2m_device':
>> drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c:1217:40: error: expected ';' before 'mdp'
1217 | video_device_release(mdp->vdev)
| ^
| ;
1218 | mdp->vdev = NULL;
| ~~~
vim +1217 drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c
1172
1173 int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
1174 {
1175 struct device *dev = &mdp->pdev->dev;
1176 int ret;
1177
1178 mdp->variant = &mtk_mdp_default_variant;
1179 mdp->vdev = video_device_alloc();
1180 if (!mdp->vdev) {
1181 dev_err(dev, "failed to allocate video device\n");
1182 ret = -ENOMEM;
1183 goto err_video_alloc;
1184 }
1185 mdp->vdev->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
1186 mdp->vdev->fops = &mtk_mdp_m2m_fops;
1187 mdp->vdev->ioctl_ops = &mtk_mdp_m2m_ioctl_ops;
1188 mdp->vdev->release = video_device_release_empty;
1189 mdp->vdev->lock = &mdp->lock;
1190 mdp->vdev->vfl_dir = VFL_DIR_M2M;
1191 mdp->vdev->v4l2_dev = &mdp->v4l2_dev;
1192 snprintf(mdp->vdev->name, sizeof(mdp->vdev->name), "%s:m2m",
1193 MTK_MDP_MODULE_NAME);
1194 video_set_drvdata(mdp->vdev, mdp);
1195
1196 mdp->m2m_dev = v4l2_m2m_init(&mtk_mdp_m2m_ops);
1197 if (IS_ERR(mdp->m2m_dev)) {
1198 dev_err(dev, "failed to initialize v4l2-m2m device\n");
1199 ret = PTR_ERR(mdp->m2m_dev);
1200 goto err_m2m_init;
1201 }
1202
1203 ret = video_register_device(mdp->vdev, VFL_TYPE_VIDEO, 2);
1204 if (ret) {
1205 dev_err(dev, "failed to register video device\n");
1206 goto err_vdev_register;
1207 }
1208 mdp->vdev->release = video_device_release;
1209
1210 v4l2_info(&mdp->v4l2_dev, "driver registered as /dev/video%d",
1211 mdp->vdev->num);
1212 return 0;
1213
1214 err_vdev_register:
1215 v4l2_m2m_release(mdp->m2m_dev);
1216 err_m2m_init:
> 1217 video_device_release(mdp->vdev)
1218 mdp->vdev = NULL;
1219 err_video_alloc:
1220
1221 return ret;
1222 }
1223
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS
From: Jamie Nguyen @ 2026-05-18 20:31 UTC (permalink / raw)
To: sudeep.holla; +Cc: linux-arm-kernel, linux-kernel, jamien
In-Reply-To: <20260517-cunning-pony-of-happiness-cab79d@sudeepholla>
__ffa_partition_info_get_regs() walks the response with a hardcoded
24-byte stride (regs += 3) even though the SPMC tells us the actual
per-descriptor size via PARTITION_INFO_SZ in x2[63:48]. The size is
read into buf_sz and then thrown away.
That works while every SPMC returns the FF-A v1.1 layout, but it falls
apart against a v1.3 SPMC returning the 48-byte descriptor. The loop
strides over half a descriptor at a time and ends up parsing every
other entry from a slice of two adjacent ones.
The FF-A spec (v1.2, section 18.5) says that the producer should
report the descriptor size, and the consumer is supposed to stride by
that size and ignore any trailing fields it doesn't understand. The
non-REGS path (__ffa_partition_info_get) does this already, and the
REGS path should match.
Use buf_sz for the stride, and bail out with -EINVAL if the SPMC
reports something we can't safely walk.
Fixes: ba85c644ac8d ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS")
Suggested-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Jamie Nguyen <jamien@nvidia.com>
---
Changes in v3:
- Per Sudeep's review: drop the explanatory comment and split the buf_sz
validation into three named checks (u64 alignment, minimum size for the
v1.1 layout we parse, fit in the x3..x17 window for nr_desc).
- Replace FFA_PART_INFO_GET_REGS_REGS_PER_DESC with
FFA_PART_INFO_GET_REGS_MIN_REGS_PER_DESC and replace
FFA_PART_INFO_GET_REGS_MAX_DESC with FFA_PART_INFO_GET_REGS_NUM_REGS,
computing max_desc per call from the SPMC-reported descriptor size.
- Drop the now-redundant `if (buf_sz > sizeof(*buffer))` clamp.
Changes in v2:
- Rebase onto linux-next; reuse the
FFA_PART_INFO_GET_REGS_{REGS_PER_DESC,MAX_DESC} macros it added instead of
introducing new ones.
- Return -EINVAL instead of -EPROTO to match surrounding checks.
- Update Fixes: tag to the commit that introduced the hardcoded stride.
---
drivers/firmware/arm_ffa/driver.c | 27 ++++++++++++++++-----------
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index b9f17fda7243..cab32cfdac42 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -324,11 +324,9 @@ __ffa_partition_info_get(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
#define PART_INFO_EXEC_CXT_MASK GENMASK(31, 16)
#define PART_INFO_PROPS_MASK GENMASK(63, 32)
#define FFA_PART_INFO_GET_REGS_FIRST_REG 3
-#define FFA_PART_INFO_GET_REGS_REGS_PER_DESC 3
-#define FFA_PART_INFO_GET_REGS_MAX_DESC \
- (((sizeof(ffa_value_t) / sizeof_field(ffa_value_t, a0)) - \
- FFA_PART_INFO_GET_REGS_FIRST_REG) / \
- FFA_PART_INFO_GET_REGS_REGS_PER_DESC)
+#define FFA_PART_INFO_GET_REGS_MIN_REGS_PER_DESC 3
+#define FFA_PART_INFO_GET_REGS_NUM_REGS \
+ (sizeof(ffa_value_t) / sizeof_field(ffa_value_t, a0))
#define PART_INFO_ID(x) ((u16)(FIELD_GET(PART_INFO_ID_MASK, (x))))
#define PART_INFO_EXEC_CXT(x) ((u16)(FIELD_GET(PART_INFO_EXEC_CXT_MASK, (x))))
#define PART_INFO_PROPERTIES(x) ((u32)(FIELD_GET(PART_INFO_PROPS_MASK, (x))))
@@ -342,7 +340,7 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
do {
__le64 *regs;
- int idx, nr_desc, buf_idx;
+ int idx, nr_desc, buf_idx, regs_per_desc, max_desc;
invoke_ffa_fn((ffa_value_t){
.a0 = FFA_PARTITION_INFO_GET_REGS,
@@ -365,8 +363,18 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
if (cur_idx < start_idx || cur_idx >= count)
return -EINVAL;
+ buf_sz = PARTITION_INFO_SZ(partition_info.a2);
+ if (buf_sz % sizeof(*regs))
+ return -EINVAL;
+
+ regs_per_desc = buf_sz / sizeof(*regs);
+ if (regs_per_desc < FFA_PART_INFO_GET_REGS_MIN_REGS_PER_DESC)
+ return -EINVAL;
+
nr_desc = cur_idx - start_idx + 1;
- if (nr_desc > FFA_PART_INFO_GET_REGS_MAX_DESC)
+ max_desc = (FFA_PART_INFO_GET_REGS_NUM_REGS -
+ FFA_PART_INFO_GET_REGS_FIRST_REG) / regs_per_desc;
+ if (nr_desc > max_desc)
return -EINVAL;
buf_idx = buf - buffer;
@@ -374,9 +382,6 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
return -EINVAL;
tag = UUID_INFO_TAG(partition_info.a2);
- buf_sz = PARTITION_INFO_SZ(partition_info.a2);
- if (buf_sz > sizeof(*buffer))
- buf_sz = sizeof(*buffer);
regs = (void *)&partition_info.a3;
for (idx = 0; idx < nr_desc; idx++, buf++) {
@@ -395,7 +400,7 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
buf->exec_ctxt = PART_INFO_EXEC_CXT(val);
buf->properties = PART_INFO_PROPERTIES(val);
uuid_copy(&buf->uuid, &uuid_regs.uuid);
- regs += 3;
+ regs += regs_per_desc;
}
start_idx = cur_idx + 1;
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Barry Song @ 2026-05-18 20:50 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Lorenzo Stoakes, surenb, akpm, linux-mm, david, liam, vbabka,
rppt, mhocko, jack, pfalcato, wanglian, chentao, lianux.mm,
kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng, nphamcs, bhe,
youngjun.park, linux-arm-kernel, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <ags7mPK7Ong0ZsBf@casper.infradead.org>
On Tue, May 19, 2026 at 12:17 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Mon, May 18, 2026 at 07:25:54PM +0800, Barry Song wrote:
> > We have clearly observed that the `fork()` operations of many
> > popular Android apps, such as iQiyi, Baidu Tieba, and 10086,
> > end up waiting on page-fault (PF) I/O when the VMA lock is
> > held during I/O operations. This has already become a
> > practical issue. I also believe this can lead to chained
> > waiting, since the global `mmap_lock` blocks all threads that
> > need to acquire it.
>
> It's always been a terrible idea to call fork() from a multithreaded
> application. For example, this question:
>
> https://stackoverflow.com/questions/53601200/calling-fork-on-a-multithreaded-process
>
> or this lwn thread: https://lwn.net/Articles/674660/
>
> Do we have any insight into why these applications are doing this
> horrible thing?
I swear I read the two links you shared. But the reality
is that as long as people use the Android framework,
even the simplest "Hello World" app already runs with
10+ threads :-)
main
RenderThread
ReferenceQueueDaemon
FinalizerDaemon
FinalizerWatchdogDaemon
HeapTaskDaemon
Binder:1234_1
Binder:1234_2
Signal Catcher
JDWP
...
Best Regards
Barry
^ permalink raw reply
* Re: cleanup the RAID6 P/Q library v3
From: Andrew Morton @ 2026-05-18 21:12 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Catalin Marinas, Will Deacon, Ard Biesheuvel, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Herbert Xu, Dan Williams,
Chris Mason, David Sterba, Arnd Bergmann, Song Liu, Yu Kuai,
Li Nan, linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260518051804.462141-1-hch@lst.de>
On Mon, 18 May 2026 07:17:43 +0200 Christoph Hellwig <hch@lst.de> wrote:
> this series cleans up the RAID6 P/Q library to match the recent updates
> to the RAID 5 XOR library and other CRC/crypto libraries. This includes
> providing properly documented external interfaces, hiding the internals,
> using static_call instead of indirect calls and turning the user space
> test suite into an in-kernel kunit test which is also extended to
> improve coverage.
Cool, I'll add this to mm.git's mm-nonmm-unstable branch for some
linux-next testing.
AI review found quite a lot to talk about:
https://sashiko.dev/#/patchset/20260518051804.462141-1-hch@lst.de
^ permalink raw reply
* [PATCH] fbdev: imxfb: Use of_device_get_match_data()
From: Rosen Penev @ 2026-05-18 21:13 UTC (permalink / raw)
To: linux-fbdev
Cc: Sascha Hauer, Pengutronix Kernel Team, Helge Deller, Frank Li,
Fabio Estevam,
moderated list:FREESCALE IMX / MXC FRAMEBUFFER DRIVER,
open list:FRAMEBUFFER LAYER,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, open list
Use of_device_get_match_data() to fetch the platform ID entry directly
instead of open-coding an of_match_device() lookup. No NULL check is
needed as every compatible string has a corresponding data section.
This also lets the driver drop the of_device.h include.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/video/fbdev/imxfb.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index a077bf346bdf..7a021da0a32a 100644
--- a/drivers/video/fbdev/imxfb.c
+++ b/drivers/video/fbdev/imxfb.c
@@ -30,7 +30,6 @@
#include <linux/lcd.h>
#include <linux/math64.h>
#include <linux/of.h>
-#include <linux/of_device.h>
#include <linux/bitfield.h>
#include <linux/regulator/consumer.h>
@@ -880,7 +879,6 @@ static int imxfb_probe(struct platform_device *pdev)
struct lcd_device *lcd;
struct fb_info *info;
struct imx_fb_videomode *m;
- const struct of_device_id *of_id;
struct device_node *display_np;
int ret, i;
int bytes_per_pixel;
@@ -891,9 +889,7 @@ static int imxfb_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
- of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
- if (of_id)
- pdev->id_entry = of_id->data;
+ pdev->id_entry = of_device_get_match_data(&pdev->dev);
info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
if (!info)
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] firmware: smccc: Fix Arm SMCCC SOC_ID name call
From: Paul Benoit @ 2026-05-18 21:14 UTC (permalink / raw)
To: Andre Przywara, Sudeep Holla
Cc: Mark Rutland, Lorenzo Pieralisi, linux-arm-kernel, linux-kernel
In-Reply-To: <506bf1b9-dfc4-4717-b26b-835c331d23c4@arm.com>
On 5/12/2026 10:09 AM, Andre Przywara wrote:
> Hi Paul,
>
> many thanks for the answer, and apologies for the delay (was on holidays).
>
> On 5/1/26 22:14, Paul Benoit wrote:
>> On 4/30/2026 10:59 AM, Andre Przywara wrote:
>>> [You don't often get email from andre.przywara@arm.com. Learn why
>>> this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> Hi Paul,
>>>
>>> is there any update on this?
>>> One more thought below ...
>>>
>>
>> Hi Andre,
>>
>> Using the incorrect SMC32 vs. the correct SMC64 interface, for SOC_ID
>> Name, was addressed by Ampere firmware some months back.
>>
>> In addition to recent firmware now responding to a SMC64 CC SOC_ID Name
>> request, it will continue to respond to an incorrect/broken SMC32
>> request and return the SOC_ID Name string packed in 64-bit registers.
>> This will allow Linux kernels 6.15+, incorrectly using SMC32 to get the
>> SOC_ID Name, to continue to work with new Ampere firmware versions.
>
> OK, many thanks for the information, that seems to be a good solution.
>
>> In other words, unless any other vendors also implemented SOC_ID Name as
>> SMC32 in their firmware, I think we can let the Ampere firmware handle
>> the SMC32 vs. SMC64 mix-up and keep the handling of it out of the Linux
>> kernel.
>
> But I think availability of the machines predates the "some month back"
> period you mention above?
> So it would only work if users would update the firmware?
Correct. I had already discussed that case with colleagues at Ampere,
and, rather than having quirk/errata handling in the Linux kernel, we
are ok with requiring that systems, with older firmware, be updated
before running future Linux kernels. That shouldn't pose a big risk/
problem as I'm not yet aware of anything besides some of my lscpu
experiments that use the newish SMC CC SOC_ID Name.
>
>> It should now be safe to make the SMC32->SMC64 SOC_ID Name change in
>> Linux.
>
> So I wonder if would still need a quirk for AmpereOne. I guess we can't
> query the TF-A build version easily, and a DMI quirk probably doesn't
> work either, judging by the dmidecode output of one machine I looked at.
> So I was wondering if we should employ the following algorithm:
>
> - do call with 64-bit FID
> - if (ret == -1) && (soc_id == jep106:0a16:0004)
> - try 32-bit FID
>
> Would that work? That checks for the SoC, not the firmware version, but
> seems way easier to implement and would cover all cases.
>
> Thoughts?
If it is deemed necessary to have the SMC32 quirk/fallback handling in
the Linux kernel, then, yes, it would look something like the above.
That is the correct soc_id value that you would want for the check.
>
> Cheers,
> Andre
>
>>
>>
>>> On 9/4/25 16:29, Sudeep Holla wrote:
>>>> On Wed, Sep 03, 2025 at 05:38:44PM -0400, Paul Benoit wrote:
>>>>> On 9/3/2025 10:49 AM, Sudeep Holla wrote:
>>>>>> On Wed, Sep 03, 2025 at 03:23:58PM +0100, Sudeep Holla wrote:
>>>>>>> On Tue, Sep 02, 2025 at 06:20:53PM +0100, Andre Przywara wrote:
>>>>>>>> Commit 5f9c23abc477 ("firmware: smccc: Support optional Arm
>>>>>>>> SMCCC SOC_ID
>>>>>>>> name") introduced the SOC_ID name string call, which reports a
>>>>>>>> human
>>>>>>>> readable string describing the SoC, as returned by firmware.
>>>>>>>> The SMCCC spec v1.6 describes this feature as AArch64 only,
>>>>>>>> since we rely
>>>>>>>> on 8 characters to be transmitted per register. Consequently the
>>>>>>>> SMCCC
>>>>>>>> call must use the AArch64 calling convention, which requires bit
>>>>>>>> 30 of
>>>>>>>> the FID to be set. The spec is a bit confusing here, since it
>>>>>>>> mentions
>>>>>>>> that in the parameter description ("2: SoC name (optionally
>>>>>>>> implemented for
>>>>>>>> SMC64 calls, ..."), but still prints the FID explicitly as
>>>>>>>> 0x80000002.
>>>>>>>> But as this FID is using the SMC32 calling convention (correct
>>>>>>>> for the
>>>>>>>> other two calls), it will not match what mainline TF-A is
>>>>>>>> expecting, so
>>>>>>>> any call would return NOT_SUPPORTED.
>>>>>>>>
>>>>>>>
>>>>>>> Good catch and I must admit I completely missed it inspite of
>>>>>>> discussing
>>>>>>> 32b vs 64b FID around the same time this was introduced.
>>>>>>>
>>>>>>>> Add a 64-bit version of the ARCH_SOC_ID FID macro, and use that
>>>>>>>> for the
>>>>>>>> SoC name version of the call.
>>>>>>>>
>>>>>>>> Fixes: 5f9c23abc477 ("firmware: smccc: Support optional Arm
>>>>>>>> SMCCC SOC_ID name")
>>>>>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>>>>>> ---
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> as somewhat expected, this now fails on an Ampere machine, which
>>>>>>>> reported a string in /sys/devices/soc0/machine before, but is
>>>>>>>> now missing
>>>>>>>> this file.
>>>>>>>> Any idea what's the best way to handle this? Let the code try
>>>>>>>> the 32-bit
>>>>>>>> FID, when the 64-bit one fails? Or handle this as some kind of
>>>>>>>> erratum?
>>>>>>>>
>>>>>>>
>>>>>>> Not sure about it yet. Erratum seems good option so that we can
>>>>>>> avoid
>>>>>>> others getting it wrong too as they might just run the kernel and
>>>>>>> be happy
>>>>>>> if the machine sysfs shows up as we decided to do fallback to 32b
>>>>>>> FID.
>>>>>>>
>>>>>>> I will start a discussion to get the spec updated and pushed out
>>>>>>> and see
>>>>>>> how that goes.
>>>>>>>
>>>>>>> The change itself looks good and happy to get it merged once we know
>>>>>>> what is the best approach(erratum vs fallback).
>>>>>>>
>>>>>>
>>>>>> Looking at the SMCCC spec(DEN0028 v1.6 G Edition) ->
>>>>>> Section 7.4.6 Implementation responsibilities
>>>>>>
>>>>>> If implemented, the firmware:
>>>>>> ...
>>>>>> • must not implement SoC_ID_type == 2 for SMC32.
>>>>>> • can optionally implement SoC_ID_type == 2 for SMC64 (Function ID
>>>>>> 0xC000_0002),
>>>>>> ...
>>>>>>
>>>>>> So Ampere is not spec conformant here and hence I prefer to handle
>>>>>> it as
>>>>>> erratum. Hopefully we can use SOC_ID version and revision to keep
>>>>>> the scope
>>>>>> of erratum confined to smallest set of platforms.
>>>>>>
>>>>>> Paul,
>>>>>>
>>>>>> Thoughts ?
>>>>>>
>>>>>
>>>>> Am I correctly understanding that, if the SMC64 SOC_ID Name call
>>>>> fails,
>>>>> rather than an unconditional fallback to the SMC32 call, the SMC32
>>>>> fallback would only be occurring under the proposed erratum?
>>>>>
>>>>
>>>> Correct, if we have unconditional fallback to the SMC32 call, then
>>>> there
>>>> is a chance that this issue gets carried into newer Ampere systems
>>>> as f/w
>>>> gets copied as well as other vendors will also not notice the issue if
>>>> they make similar mistake as the kernel silent makes a SMC32 call.
>>>>
>>>> We do need details of the SoC revision and version for which we
>>>> need to
>>>> apply this workaround/erratum.
>>>
>>> So this looks more like a firmware erratum than a SoC specific one,
>>> right? So I wonder if any SoC specific IDs are really appropriate here.
>>> Is there some firmware version we can read via DMI or so to identify
>>> affected systems?
>>> Or shall we use a probably much easier SoC or even MIDR check anyway,
>>> since it's just a fallback? As in: try smc64, if that fails and if it's
>>> a core that ever shipped with that affected firmware, try smc32? I think
>>> there is not much harm in trying those FIDs, so we just limit the scope
>>> to Ampere cores - even though that's technically not the right method by
>>> the book?
>>>
>>> Cheers,
>>> Andre
>>>
>>>
>>>
>>>>
>>>>> I brought this issue up at a weekly team meeting today, and I'll
>>>>> also be
>>>>> communicating with the Ampere Computing firmware team regarding this
>>>>> issue.
>>>>
>>>> Thanks!
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Barry Song @ 2026-05-18 21:14 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Lorenzo Stoakes, Matthew Wilcox, akpm, linux-mm, david, liam,
vbabka, rppt, mhocko, jack, pfalcato, wanglian, chentao,
lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng,
nphamcs, bhe, youngjun.park, linux-arm-kernel, linux-kernel,
loongarch, linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAJuCfpE0WQrB3zJp9qn3jvn5DthS=ttpX7gJJvyEhA_BJGrp5g@mail.gmail.com>
On Tue, May 19, 2026 at 3:57 AM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Mon, May 18, 2026 at 4:26 AM Barry Song <baohua@kernel.org> wrote:
> >
> > On Mon, May 18, 2026 at 5:47 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> > >
> > > On Sun, May 17, 2026 at 04:45:15PM +0800, Barry Song wrote:
[...]
> >
> > I think we either need to fix `fork()`, or keep the current
> > behavior of dropping the VMA lock before performing I/O.
>
> I see. So, this problem arises from the fact that we are changing the
> pagefaults requiring I/O operation to hold VMA lock...
> And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
> is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
> anonymous and COW VMAs only while holding mmap_write_lock, preventing
> any VMA modification. On the surface, that looks ok to me but I might
> be missing some corner cases. If nobody sees any obvious issues, I
> think it's worth a try.
>
Thanks. Besides the creation of processes via fork(), I
am also beginning to worry about the death of processes.
One thing that came to my mind this morning
is that when lowmemorykiller decides to kill an app, we
want the memory to be released as quickly as possible so
the new app or user scenario can get memory sooner.
In that case, if the app being killed is performing I/O
while holding the VMA lock, the unmapping procedure
could end up being blocked as well.
If we release the VMA lock as we currently do, we allow
process exit to proceed.
I haven't thought it through very clearly yet, and I
may be wrong. I'd like to do more investigation. I hope
the apps being killed stay very still, but who knows—we
have so many applications in the market.
Meanwhile, if you have any comments regarding the death
of processes, they would be very welcome.
Best Regards
Barry
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Yang Shi @ 2026-05-18 21:21 UTC (permalink / raw)
To: Barry Song
Cc: Matthew Wilcox, surenb, akpm, linux-mm, david, ljs, liam, vbabka,
rppt, mhocko, jack, pfalcato, wanglian, chentao, lianux.mm,
kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng, nphamcs, bhe,
youngjun.park, linux-arm-kernel, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAGsJ_4ysMcrmDLSOwBkf7qwCQrcDWeEMXkHDajTJFMLKUk0bSQ@mail.gmail.com>
On Sun, May 17, 2026 at 1:45 AM Barry Song <baohua@kernel.org> wrote:
>
> On Sat, May 2, 2026 at 1:58 AM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Sat, May 02, 2026 at 01:44:34AM +0800, Barry Song wrote:
> > > On Fri, May 1, 2026 at 10:57 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > >
> > > > On Fri, May 01, 2026 at 06:49:58AM +0800, Barry Song wrote:
> > > > > 1. There is no deterministic latency for I/O completion. It depends on
> > > > > both the hardware and the software stack (bio/request queues and the
> > > > > block scheduler). Sometimes the latency is short; at other times it can
> > > > > be quite long. In such cases, a high-priority thread performing operations
> > > > > such as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait
> > > > > for an unpredictable amount of time.
> > > >
> > > > But does that actually happen? I find it hard to believe that thread A
> > > > unmaps a VMA while thread B is in the middle of taking a page fault in
> > > > that same VMA. mprotect() and madvise() are more likely to happen, but
> > > > it still seems really unlikely to me.
> > >
> > > It doesn’t have to involve unmapping or applying mprotect to
> > > the entire VMA—just a portion of it is sufficient.
> >
> > Yes, but that still fails to answer "does this actually happen". How much
> > performance is all this complexity in the page fault handler buying us?
> > If you don't answer this question, I'm just going to go in and rip it
> > all out.
> >
>
> Hi Matthew (and Lorenzo, Jan, and anyone else who may be
> waiting for answers),
>
> As promised during LSF/MM/BPF, we conducted thorough
> testing on Android phones to determine whether performing
> I/O in `filemap_fault()` can block `vma_start_write()`.
> I wanted to give a quick update on this question.
>
> Nanzhe at Xiaomi created tracing scripts and ran various
> applications on Android devices with I/O performed under
> the VMA lock in `filemap_fault()`. We found that:
>
> 1. There are very few cases where unmap() is blocked by
> page faults. I assume this is due to buggy user code
> or poor synchronization between reads and unmap().
> So I assume it is not a problem.
>
> 2. We observed many cases where `vma_start_write()`
> is blocked by page-fault I/O in some applications.
> The blocking occurs in the `dup_mmap()` path during
> fork().
>
> With Suren's commit fb49c455323ff ("fork: lock VMAs of
> the parent process when forking"), we now always hold
> `vma_write_lock()` for each VMA. Note that the
> `mmap_lock` write lock is also held, which could lead to
> chained waiting if page-fault I/O is performed without
> releasing the VMA lock.
>
> My gut feeling is that Suren's commit may be overshooting,
> so my rough idea is that we might want to do something like
> the following (we haven't tested it yet and it might be
> wrong):
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 2311ae7c2ff4..5ddaf297f31a 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1762,7 +1762,13 @@ __latent_entropy int dup_mmap(struct mm_struct
> *mm, struct mm_struct *oldmm)
> for_each_vma(vmi, mpnt) {
> struct file *file;
>
> - retval = vma_start_write_killable(mpnt);
> + /*
> + * For anonymous or writable private VMAs, prevent
> + * concurrent CoW faults.
> + */
> + if (!mpnt->vm_file || (!(mpnt->vm_flags & VM_SHARED) &&
> + (mpnt->vm_flags & VM_WRITE)))
> + retval = vma_start_write_killable(mpnt);
> if (retval < 0)
> goto loop_out;
> if (mpnt->vm_flags & VM_DONTCOPY) {
Maybe a little bit off topic. This is an interesting idea. It seems
possible we don't have to take vma write lock unconditionally. IIUC
the write lock is mainly used to serialize against page fault and
madvise, right? I got a crazy idea off the top of my head. We may be
able to just take vma write lock iff vma->anon_vma is not NULL.
First of all, write mmap_lock is held, so the vma can't go or be
changed under us.
Secondly, if vma->anon_vma is NULL, it basically means either no page
fault happened or no cow happened, so there is no page table to copy,
this is also what copy_page_range() does currently. So we can shrink
the critical section to:
if (vma->anon_vma) {
vma_start_write_killable(src_vma);
anon_vma_fork(dst_vma, src_vma);
copy_page_range(dst_vma, src_vma);
}
But page fault can happen before write mmap_lock is taken, when we
check vma->anon_vma, it is possible it has not been set up yet. But it
seems to be equivalent to page fault after fork and won't break the
semantic.
Anyway, just a crazy idea, I may miss some corner cases.
Thanks,
Yang
}
>
> Based on the above, we may want to re-check whether fork()
> can be blocked by page faults. At the same time, if Suren,
> you, or anyone else has any comments, please feel free to
> share them.
>
> Best Regards
> Barry
>
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Andre Przywara @ 2026-05-18 21:23 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: Paul Kocialkowski, linux-sunxi, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <bc3b786313adee30cc00c65ea98ff5258a816abb.camel@gmail.com>
On Mon, 18 May 2026 16:40:11 +0200
Alexander Sverdlin <alexander.sverdlin@gmail.com> wrote:
Hi Alexander,
> On Mon, 2026-05-18 at 16:14 +0200, Paul Kocialkowski wrote:
> > I also have a U-Boot config ready for it, which I could send once the
> > device-trees are merged on the kernel side. I could send it to you if
> > you're interested.
>
> I do have one as well, I'm testing all open-source ;-) from ATF-upwards,
> just thought U-Boot would require ATF merged and kernel DT merged
> because of OF_UPSTREAM in U-Boot. But I'd be happy to sync when we get
> there.
There is no requirement for upstream TF-A support when adding U-Boot
support. All we need is *some* blob to feed to the U-Boot build system.
There is one dependency, though: the TF-A load address. Mostly that's
some quite obvious SRAM address, but in this case it turned out that
the SRAM on the A133 is probably too small, so it looks like we need to
move to DRAM. Not sure how we handle the transition, but at the moment
there is just one board supported, so it will be slightly painful for a
few weeks or months, I am afraid.
And yes, DTs need to be merged into Linus' tree to be considered, so
this series of yours is exactly the right thing to do. There are
regular syncs between the DT rebasing repo and U-Boot, but we can
manually cherry-pick patches once they have reached the mainline tree.
But feel free to send U-Boot patches once this series has been ACKed,
so the defconfig file can be reviewed and then queued, to wait for
the DT to appear in v7.2-rc1, for instance.
Cheers,
Andre
^ permalink raw reply
* Re: [PATCH v3 0/7] media: synopsys: enhancements and i.MX95 support
From: Sakari Ailus @ 2026-05-18 21:24 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Bryan O'Donoghue, Mehdi Djait,
Hans Verkuil, linux-media, linux-kernel, devicetree, imx,
linux-arm-kernel, linux-rockchip, Krzysztof Kozlowski
In-Reply-To: <20260506-csi2_imx95-v3-0-953b6e1a80dd@oss.nxp.com>
Hi Guoniu,
Thanks for the set.
On Wed, May 06, 2026 at 04:53:59PM +0800, Guoniu Zhou wrote:
> This series enhances the Synopsys DesignWare MIPI CSI-2 receiver driver
> with multiple stream support and adds i.MX95 platform support.
>
> The i.MX95 variant is similar to i.MX93 but uses IDI instead of IPI. Since
> IDI is software transparent, only a different register map is needed.
>
> Tested on i.MX93 and i.MX95 platforms.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
This doesn't seem to apply to the media committers' tree anymore. Could you
rebase it, please? (Or are there dependencies still out there?)
--
Kind regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH] usb: gadget: aspeed_udc: avoid past-the-end iterator in dequeue
From: Alan Stern @ 2026-05-18 21:43 UTC (permalink / raw)
To: Maoyi Xie
Cc: Andrew Jeffery, Neal Liu, Greg Kroah-Hartman,
Benjamin Herrenschmidt, Joel Stanley, Andrew Jeffery,
linux-aspeed, linux-arm-kernel, linux-usb, linux-kernel
In-Reply-To: <20260518073403.1285339-1-maoyi.xie@ntu.edu.sg>
On Mon, May 18, 2026 at 03:34:03PM +0800, Maoyi Xie wrote:
> From: Maoyi Xie <maoyixie.tju@gmail.com>
>
> ast_udc_ep_dequeue() declares the loop cursor `req` outside the
> list_for_each_entry(). After the loop it tests `&req->req != _req`
> to decide whether the request was found. If the queue holds no
> match, `req` is past-the-end. It then aliases
> container_of(&ep->queue, struct ast_udc_request, queue) via offset
> cancellation. Whether that synthetic address equals `_req` depends
> on heap layout. The function can return 0 without dequeueing
> anything.
>
> Use the cursor-vs-result idiom from the sibling aspeed-vhub driver,
> ast_vhub_epn_dequeue() in drivers/usb/gadget/udc/aspeed-vhub/epn.c.
> A separate `iter` walks the list. `req` is set only when a request
> matches. After the loop, `req` is NULL if nothing matched.
>
> The same idiom is used by the other UDC drivers in
> drivers/usb/gadget/udc/ (at91_udc, atmel_usba_udc, dummy_hcd,
> fsl_qe_udc, fsl_udc_core, goku_udc, gr_udc, lpc32xx_udc,
> max3420_udc, net2280, omap_udc, pxa25x_udc, pxa27x_udc, udc-xilinx,
> bcm63xx_udc).
>
> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
> ---
> drivers/usb/gadget/udc/aspeed_udc.c | 24 ++++++++++++++----------
> 1 file changed, 14 insertions(+), 10 deletions(-)
>
> --- a/drivers/usb/gadget/udc/aspeed_udc.c
> +++ b/drivers/usb/gadget/udc/aspeed_udc.c
> @@ -692,26 +692,30 @@
> {
> struct ast_udc_ep *ep = to_ast_ep(_ep);
> struct ast_udc_dev *udc = ep->udc;
> - struct ast_udc_request *req;
> + struct ast_udc_request *req = NULL, *iter;
> unsigned long flags;
> int rc = 0;
>
> spin_lock_irqsave(&udc->lock, flags);
>
> /* make sure it's actually queued on this endpoint */
> - list_for_each_entry(req, &ep->queue, queue) {
> - if (&req->req == _req) {
> - list_del_init(&req->queue);
> - ast_udc_done(ep, req, -ESHUTDOWN);
> - _req->status = -ECONNRESET;
> - break;
> - }
> + list_for_each_entry(iter, &ep->queue, queue) {
> + if (&iter->req != _req)
> + continue;
> + req = iter;
> + break;
> }
There's nothing wrong with doing it this way, and this is how the other
drivers do it. Still, organizing the loop in this way does look a
little strange. Consider this instead:
list_for_each_entry(iter, &ep->queue, queue) {
if (&iter->req == _req) {
req = iter;
break;
}
}
Alan Stern
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Paul Kocialkowski @ 2026-05-18 21:46 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-sunxi, Andre Przywara, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <04da68168f92b196cce4d49c766fc62702bf6472.camel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5275 bytes --]
Hi Alexander,
On Mon 18 May 26, 22:05, Alexander Sverdlin wrote:
> Hi Paul,
>
> thanks for the review!
>
> On Mon, 2026-05-18 at 13:52 +0200, Paul Kocialkowski wrote:
> >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> > > new file mode 100644
> > > index 000000000000..65b094f30bf5
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
>
> []
>
> > You should add:
> >
> > chosen {
> > stdout-path = "serial0:115200n8";
> > };
>
> I actually have it in .dts, but it's theoretically possible to deploy
> the core board in a way that serial0 is *not* a console, so the above
> probably will not be valid in all cases in .dtsi.
Yes I figured out later that it was in the board dts file and I initially
assumed it was missing entirely.
In practice both options are fine, although the reference software does
hardcode UART0 as debug serial.
> > > +®_dcdc2 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <500000>;
> > > + regulator-max-microvolt = <1300000>;
> >
> > Should be:
> > regulator-min-microvolt = <900000>;
> > regulator-max-microvolt = <1300000>;
>
> 0.81..1.2v according to A133 Datasheet Revision 1.1 Jul.14, 2020?
I guess the initial values are taken from the allwinner-perf1 board dts.
The 900 mV-1.3 V range matches the CPU OPPs (although it really only goes up
to 1.13 V). Maybe down to 810 mV does work, but we don't have an OPP for it.
I think I took these values from the reference BSP for the board.
Also it would be good to add:
regulator-name = "vdd-cpux";
> >
> > > +®_dcdc4 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <500000>;
> > > + regulator-max-microvolt = <1300000>;
> > > + regulator-name = "vdd-sys";
> >
> > Should be:
> > regulator-min-microvolt = <810000>;
> > regulator-max-microvolt = <990000>;
> > regulator-name = "vcc-usb-sys";
>
> I'm a bit puzzled here: datasheet says 0.9..1.0v
> and it has no "Typ" value, similar to VDD_CPU, but
> VDD_SYS is not part of OPP tables, so who is going
> to adjust this? Or shall it be just
>
> regulator-min-microvolt = <950000>;
> regulator-max-microvolt = <950000>;
>
> ?
Yes the reference BSP runs it at 950 mV, LGTM.
>
> >
> > > +};
> > > +
> > > +®_dcdc5 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <800000>;
> > > + regulator-max-microvolt = <1840000>;
> > > + regulator-name = "vcc-dram";
> >
> > Should be:
> > regulator-min-microvolt = <1100000>;
> > regulator-max-microvolt = <1100000>;
> > regulator-name = "vcc-dram-2";
> >
> > ALDO2 is the main DRAM supply, this is the second one.
>
> Core schematics mentions 1.1V/1.2/1.35/1.5 on this rail...
> Currently U-Boot has CONFIG_AXP_DCDC5_VOLT=1100, but potentially
> this is adjustable, right? At some point LPDDR4 chips they
> are soldering today will be unavailable. And in the current
> market it will happen rather sooner than later...
It is part of the LPDDR4 spec that the main voltage should be 1.8 V and
the second and I/O buffer ones should be 1.1 V. See JESD209-4D Table 180 —
Recommended DC Operating Conditions.
Maybe they jsut copied this comment from a reference design that allows for
other types of DRAM too. In any case their BSP hardcodes 1.1 V anyway.
> >
> > > +};
> > > +
> > > +/* DCDC6 unused */
> > > +
> > > +®_dldo1 {
> > > + regulator-min-microvolt = <700000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-enable-ramp-delay = <1000>;
> >
> > Should be:
> > regulator-min-microvolt = <1800000>;
> > regulator-max-microvolt = <1800000>;
> > regulator-name = "vcc-pg";
>
> Do suggest to drop vendor's
>
> regulator-enable-ramp-delay = <1000>;
>
> in all cases?
Well we generally don't have the delays in the axp regulator definitions and
it works well without them, but I guess they don't hurt either.
In practice many drivers will have a delay after a regulator power on anyway
because we generally expect that hardware needs some time to power up,
in addition to the regulator. So all in all it's rarely critical.
>
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
> > > new file mode 100644
> > > index 000000000000..ccbca5d0a40c
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
>
> []
>
> > > + aliases {
> > > + serial0 = &uart0;
> >
> > The is best added to the core dtsi.
> >
> > > + };
> > > +
> > > + chosen {
> > > + stdout-path = "serial0:115200n8";
> >
> > Ditto.
>
> But it only physically materializes in Helperboard, the carrier.
> Potentially this one can be left floating or used for something else.
Yes fair enough, I'm happy with having it on the helperboard dts file.
All the best,
Paul
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: fix urb->setup_packet leak in error paths
From: patchwork-bot+bluetooth @ 2026-05-18 21:50 UTC (permalink / raw)
To: Jiajia Liu
Cc: marcel, luiz.dentz, matthias.bgg, angelogioacchino.delregno,
sean.wang, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260518022402.20398-1-liujiajia@kylinos.cn>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 18 May 2026 10:24:02 +0800 you wrote:
> The setup_packet of control urb is not freed if usb_submit_urb fails or
> the submitted urb is killed. Add free in these two paths.
>
> Fixes: a1c49c434e150 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices")
> Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> ---
> drivers/bluetooth/btmtk.c | 2 ++
> 1 file changed, 2 insertions(+)
Here is the summary with links:
- Bluetooth: btmtk: fix urb->setup_packet leak in error paths
https://git.kernel.org/bluetooth/bluetooth-next/c/5daf96ab8398
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Andre Przywara @ 2026-05-18 21:54 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: Paul Kocialkowski, linux-sunxi, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <04da68168f92b196cce4d49c766fc62702bf6472.camel@gmail.com>
On Mon, 18 May 2026 22:05:25 +0200
Alexander Sverdlin <alexander.sverdlin@gmail.com> wrote:
Hi Paul, Alexander,
> thanks for the review!
>
> On Mon, 2026-05-18 at 13:52 +0200, Paul Kocialkowski wrote:
> >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> > > new file mode 100644
> > > index 000000000000..65b094f30bf5
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
>
> []
>
> > You should add:
> >
> > chosen {
> > stdout-path = "serial0:115200n8";
> > };
>
> I actually have it in .dts, but it's theoretically possible to deploy
> the core board in a way that serial0 is *not* a console, so the above
> probably will not be valid in all cases in .dtsi.
I am with Alexander here, to me the serial port belong into the
helper board .dts, not the SoM .dtsi.
>
> >
> >
> >
> > > +®_dcdc2 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <500000>;
> > > + regulator-max-microvolt = <1300000>;
> >
> > Should be:
> > regulator-min-microvolt = <900000>;
> > regulator-max-microvolt = <1300000>;
>
> 0.81..1.2v according to A133 Datasheet Revision 1.1 Jul.14, 2020?
Do you have the CPU OPPs for this board? Do they slightly
overclock/over-volt the core? We have seen this for some other boards.
But you could go with the safer 810mV...1200mV range, and we adjust
this when needed.
>
> >
> > > +®_dcdc4 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <500000>;
> > > + regulator-max-microvolt = <1300000>;
> > > + regulator-name = "vdd-sys";
> >
> > Should be:
> > regulator-min-microvolt = <810000>;
> > regulator-max-microvolt = <990000>;
> > regulator-name = "vcc-usb-sys";
>
> I'm a bit puzzled here: datasheet says 0.9..1.0v
> and it has no "Typ" value, similar to VDD_CPU, but
> VDD_SYS is not part of OPP tables, so who is going
> to adjust this? Or shall it be just
>
> regulator-min-microvolt = <950000>;
> regulator-max-microvolt = <950000>;
There is indeed no exact value to be found. Just go with whatever the
BSP used: either it's the PMIC reset value, or it's adjusted by boot0.
If you have a BSP kernel booted, check the value of this regulator on
the Linux prompt, then use this value. Chances are it's indeed 950mV,
as used by the Liontron board.
>
> ?
>
> >
> > > +};
> > > +
> > > +®_dcdc5 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <800000>;
> > > + regulator-max-microvolt = <1840000>;
> > > + regulator-name = "vcc-dram";
> >
> > Should be:
> > regulator-min-microvolt = <1100000>;
> > regulator-max-microvolt = <1100000>;
> > regulator-name = "vcc-dram-2";
> >
> > ALDO2 is the main DRAM supply, this is the second one.
>
> Core schematics mentions 1.1V/1.2/1.35/1.5 on this rail...
> Currently U-Boot has CONFIG_AXP_DCDC5_VOLT=1100, but potentially
> this is adjustable, right? At some point LPDDR4 chips they
> are soldering today will be unavailable. And in the current
> market it will happen rather sooner than later...
We don't support multiple DRAM types for one board, really. If they
switch to another DRAM type, we will need a new DT or some other way to
adjust this (potentially runtime patched by U-Boot). But we can address
this when we get there, so just set the 1.1V that LPDDR4 requires for
the existing boards right now.
>
> >
> > > +};
> > > +
> > > +/* DCDC6 unused */
> > > +
> > > +®_dldo1 {
> > > + regulator-min-microvolt = <700000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-enable-ramp-delay = <1000>;
> >
> > Should be:
> > regulator-min-microvolt = <1800000>;
> > regulator-max-microvolt = <1800000>;
> > regulator-name = "vcc-pg";
>
> Do suggest to drop vendor's
>
> regulator-enable-ramp-delay = <1000>;
>
> in all cases?
>
I don't see this used in many other mainline DTs, mostly it's just for
some picky peripherals (PHYs). So if that works stable for you without,
I'd drop all of them.
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
> > > new file mode 100644
> > > index 000000000000..ccbca5d0a40c
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
>
> []
>
> > > + aliases {
> > > + serial0 = &uart0;
> >
> > The is best added to the core dtsi.
> >
> > > + };
> > > +
> > > + chosen {
> > > + stdout-path = "serial0:115200n8";
> >
> > Ditto.
>
> But it only physically materializes in Helperboard, the carrier.
> Potentially this one can be left floating or used for something else.
As mentioned above, I agree on this staying in the helper board .dts,
and it not being moved.
Cheers,
Andre
^ permalink raw reply
* [PATCH] arm64: dts: allwinner: sun50i-a64: Enable DT overlays
From: Peter Robinson @ 2026-05-18 22:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, devicetree, linux-arm-kernel,
linux-sunxi
Cc: Peter Robinson
Enable DT overlays on some of the Pine64 devices to enable
use of addon accessories such as WiFi or audio modules.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
---
arch/arm64/boot/dts/allwinner/Makefile | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index d116864b6c2b3..53e6b701e7d3a 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -1,4 +1,10 @@
# SPDX-License-Identifier: GPL-2.0
+# Enables support for device-tree overlays for named devices
+DTC_FLAGS_sun50i-a64-pine64-lts := -@
+DTC_FLAGS_sun50i-a64-pine64 := -@
+DTC_FLAGS_sun50i-a64-pine64-plus := -@
+DTC_FLAGS_sun50i-a64-sopine-baseboard := -@
+
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-amarula-relic.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
--
2.54.0
^ permalink raw reply related
* [PATCH] clk: stm32: allow STM32MP COMPILE_TEST builds
From: Rosen Penev @ 2026-05-18 22:12 UTC (permalink / raw)
To: linux-clk
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Maxime Coquelin,
Alexandre Torgue, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, open list,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE,
open list:CLANG/LLVM BUILD SUPPORT:Keyword:b(?i:clang|llvm)b
COMMON_CLK_STM32MP already allows COMPILE_TEST, but the parent clock
Makefile only descends into drivers/clk/stm32 for ARCH_STM32. Use the
STM32MP clock symbol for that directory gate instead.
Building the STM32MP21 and STM32MP25 clock drivers then requires direct
linux/bitfield.h includes for FIELD_GET(), so add them as part of exposing
that compile-test coverage.
Tested with:
make LLVM=1 ARCH=loongarch drivers/clk/stm32/
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/clk/Makefile | 2 +-
drivers/clk/stm32/clk-stm32mp21.c | 1 +
drivers/clk/stm32/clk-stm32mp25.c | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 9c3a9703ad92..0cd2223de3ca 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -150,7 +150,7 @@ obj-y += spacemit/
obj-$(CONFIG_PLAT_SPEAR) += spear/
obj-y += sprd/
obj-$(CONFIG_ARCH_STI) += st/
-obj-$(CONFIG_ARCH_STM32) += stm32/
+obj-$(CONFIG_COMMON_CLK_STM32MP) += stm32/
obj-y += starfive/
obj-$(CONFIG_ARCH_SUNXI) += sunxi/
obj-y += sunxi-ng/
diff --git a/drivers/clk/stm32/clk-stm32mp21.c b/drivers/clk/stm32/clk-stm32mp21.c
index c8a37b716bd5..3c143371c77e 100644
--- a/drivers/clk/stm32/clk-stm32mp21.c
+++ b/drivers/clk/stm32/clk-stm32mp21.c
@@ -5,6 +5,7 @@
*/
#include <linux/bus/stm32_firewall_device.h>
+#include <linux/bitfield.h>
#include <linux/clk-provider.h>
#include <linux/io.h>
#include <linux/platform_device.h>
diff --git a/drivers/clk/stm32/clk-stm32mp25.c b/drivers/clk/stm32/clk-stm32mp25.c
index 52f0e8a12926..cc95fac66449 100644
--- a/drivers/clk/stm32/clk-stm32mp25.c
+++ b/drivers/clk/stm32/clk-stm32mp25.c
@@ -5,6 +5,7 @@
*/
#include <linux/bus/stm32_firewall_device.h>
+#include <linux/bitfield.h>
#include <linux/clk-provider.h>
#include <linux/io.h>
#include <linux/platform_device.h>
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 1/3] soc: bcm2835: raspberrypi-firmware: Add voltage domain IDs
From: Guenter Roeck @ 2026-05-18 22:17 UTC (permalink / raw)
To: Shubham Chakraborty
Cc: Florian Fainelli, Jonathan Corbet, Shuah Khan,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
linux-hwmon, linux-doc, linux-rpi-kernel, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260517080445.103962-2-chakrabortyshubham66@gmail.com>
On Sun, May 17, 2026 at 01:34:43PM +0530, Shubham Chakraborty wrote:
> Add Raspberry Pi firmware voltage domain identifiers for the mailbox
> property interface.
>
> Also add the voltage request structure used with
> RPI_FIRMWARE_GET_VOLTAGE so firmware clients can share the common API
> definition from the firmware header.
>
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
I'll need an Acked-by: from a maintainer to apply this patch,
or some other maintainer will have to pick it up.
Thanks,
Guenter
> ---
> include/soc/bcm2835/raspberrypi-firmware.h | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
> index e1f87fbfe554..975bef529854 100644
> --- a/include/soc/bcm2835/raspberrypi-firmware.h
> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> @@ -156,6 +156,31 @@ enum rpi_firmware_clk_id {
> RPI_FIRMWARE_NUM_CLK_ID,
> };
>
> +enum rpi_firmware_volt_id {
> + RPI_FIRMWARE_VOLT_ID_CORE = 1,
> + RPI_FIRMWARE_VOLT_ID_SDRAM_C = 2,
> + RPI_FIRMWARE_VOLT_ID_SDRAM_P = 3,
> + RPI_FIRMWARE_VOLT_ID_SDRAM_I = 4,
> + RPI_FIRMWARE_NUM_VOLT_ID,
> +};
> +
> +/**
> + * struct rpi_firmware_get_voltage_request - Firmware request for a voltage
> + * @id: ID of the voltage being queried
> + * @value: Voltage in microvolts. Set by the firmware.
> + *
> + * Used by @RPI_FIRMWARE_GET_VOLTAGE.
> + */
> +struct rpi_firmware_get_voltage_request {
> + __le32 id;
> + __le32 value;
> +} __packed;
> +
> +#define RPI_FIRMWARE_GET_VOLTAGE_REQUEST(_id) \
> + { \
> + .id = cpu_to_le32(_id), \
> + }
> +
> /**
> * struct rpi_firmware_clk_rate_request - Firmware Request for a rate
> * @id: ID of the clock being queried
^ permalink raw reply
* Re: [PATCH V14 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Bjorn Helgaas @ 2026-05-18 22:37 UTC (permalink / raw)
To: Sherry Sun
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
mani@kernel.org, bhelgaas@google.com, Hongxing Zhu,
l.stach@pengutronix.de, imx@lists.linux.dev,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB1211452312EB9BC6EF1ED2E0192032@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Mon, May 18, 2026 at 08:42:38AM +0000, Sherry Sun wrote:
> > Subject: Re: [PATCH V14 02/12] PCI: host-generic: Add common helpers for
> > parsing Root Port properties
> >
> > On Wed, Apr 22, 2026 at 05:35:39PM +0800, Sherry Sun wrote:
> > > Introduce generic helper functions to parse Root Port device tree
> > > nodes and extract common properties like reset GPIOs. This allows
> > > multiple PCI host controller drivers to share the same parsing logic.
> > >
> > > Define struct pci_host_port to hold common Root Port properties
> > > (currently only list of PERST# GPIO descriptors) and add
> > > pci_host_common_parse_ports() to parse Root Port nodes from device
> > tree.
> > >
> > > Also add the 'ports' list to struct pci_host_bridge for better
> > > maintain parsed Root Port information.
> > > ...
> >
> > > +static int pci_host_common_parse_port(struct device *dev,
> > > + struct pci_host_bridge *bridge,
> > > + struct device_node *node)
> > > +{
> > > + struct pci_host_port *port;
> > > + int ret;
> > > +
> > > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > > + if (!port)
> > > + return -ENOMEM;
> > > +
> > > + INIT_LIST_HEAD(&port->perst);
> > > +
> > > + ret = pci_host_common_parse_perst(dev, port, node);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /*
> > > + * 1. PERST# found in RP or its child nodes - list is not empty, continue
> > > + * 2. PERST# not found in RP/children, but found in RC node - return -
> > ENODEV
> > > + * to fallback legacy binding
> > > + * 3. PERST# not found anywhere - list is empty, continue (optional
> > PERST#)
> > > + */
> > > + if (list_empty(&port->perst)) {
> > > + if (of_property_present(dev->of_node, "reset-gpios") ||
> > > + of_property_present(dev->of_node, "reset-gpio"))
> > > + return -ENODEV;
> >
> > This doesn't seem right to me. The parser of per-Root Port properties should
> > not be responsible for deciding whether legacy methods are valid, i.e.,
> > whether a property is in the Root Complex node. I think it's up to the caller
> > to decide whether it needs to look elsewhere.
> >
> > I don't think this even needs to return a "success/failure" value because there
> > may be more properties in the future, and not all will be required. This
> > function can't tell which properties a specific driver requires and which are
> > optional.
> >
> > The caller can check whether we found what it needs and fall back to a legacy
> > method as needed.
>
> Hi Bjorn,
> The code here was suggested by Mani, https://lore.kernel.org/all/lnzprzrdwra7pn7d6m3sbj5pvjy64blwpjl6i3lmlnfbyho63b@czpyhpgz5vum/.
> I think your suggestion here is reasonable, the per-Root Port parser shouldn't
> check the RC-level binding. That's a policy decision that belongs to the caller.
>
> Hi Mani, if you also agree, I'll rework this so that:
> 1. pci_host_common_parse_port() only parses properties from the Root Port
> (and its children) without checking the RC node.
> 2. The function won't return failure for "property not found" - it will only return
> errors for real failures (e.g., -ENOMEM, GPIO acquisition errors).
> 3. The legacy fallback logic will be moved to the caller, which can inspect the
> parsed result and decide whether to fall back to the legacy binding.
This is only used for imx6 so far, so I think this is OK as-is for
v7.2. We can file this under "possible future rework or kernel
mentee project."
^ permalink raw reply
* Re: [PATCH v5 3/8] arm64: entry: add unwind info for various kernel entries
From: Dylan Hatch @ 2026-05-18 22:41 UTC (permalink / raw)
To: Mark Rutland
Cc: Roman Gushchin, Weinan Liu, Will Deacon, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Steven Rostedt, Catalin Marinas,
Jiri Kosina, Jens Remus, Prasanna Kumar T S M, Puranjay Mohan,
Song Liu, joe.lawrence, linux-toolchains, linux-kernel,
live-patching, linux-arm-kernel, Randy Dunlap
In-Reply-To: <agbgMb6jrgiFFHRX@J2N7QTR9R3>
On Fri, May 15, 2026 at 1:58 AM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Thu, May 14, 2026 at 08:30:43PM -0700, Dylan Hatch wrote:
> > On Wed, Apr 29, 2026 at 8:26 AM Mark Rutland <mark.rutland@arm.com> wrote:
> > > On Tue, Apr 28, 2026 at 06:36:38PM +0000, Dylan Hatch wrote:
> > > > From: Weinan Liu <wnliu@google.com>
> > > >
> > > > DWARF CFI (Call Frame Information) specifies how to recover the return
> > > > address and callee-saved registers at each PC in a given function.
> > > > Compilers are able to generate the CFI annotations when they compile
> > > > the code to assembly language. For handcrafted assembly, we need to
> > > > annotate them by hand.
> > > >
> > > > Annotate minimal CFI to enable stacktracing using SFrame for kernel
> > > > exception entries through el1*_64_*() paths
> > >
> > > I thought we were only consuming SFrame when unwinding an exeption
> > > boundary?
> > >
> > > We shouldn't be taking exceptions _from_ the entry assembly functions
> > > unless something has gone horribly wrong, and so I don't see why we'd
> > > need CFI entries for the entry assembly functions.
> > >
> > > Am I missing some reason we need CFI entries for the entry assembly
> > > functions? I strongly suspect it is not necessary to add these, and I'd
> > > prefer to omit them.
> >
> > I believe the el1 entry functions are called in an exception, and are
> > called before call_on_irq_stack.
>
> Yes, but I don't think that matters. See below for more details.
>
> > Example stacktrace segment:
> >
> > [ 262.119564] handle_percpu_devid_irq+0xb4/0x348
> > [ 262.119913] handle_irq_desc+0x3c/0x68
> > [ 262.120196] generic_handle_domain_irq+0x20/0x40
> > [ 262.120678] gic_handle_irq+0x48/0xe0
> > [ 262.121005] call_on_irq_stack+0x30/0x48
> > [ 262.121412] do_interrupt_handler+0x88/0xa0
> > [ 262.121779] el1_interrupt+0x38/0x58
> > [ 262.122089] el1h_64_irq_handler+0x18/0x30
> > [ 262.122617] el1h_64_irq+0x6c/0x70
>
> The segment immediately above can be unwound using FP, as frame records
> were created consistently, and there are no exception boundaries. No CFI
> needed.
Ah right -- with the logic in stacktrace.c changed to use SFrame only
when recovering the next frame from a pt_regs, the FP alone is
sufficient if we know these entry functions won't take an exception.
This patch was originally implemented with an SFrame-only unwinder in
mind, so my mental model still hadn't back-propagated the new logic to
this patch :)
>
> It's legitimate to take an exception from parts of call_on_irq_stack(),
> so it makes sense for that to have CFI, but for the specific unwind
> segment above, CFI isn't necessary.
>
> Everything in the stacktrace segment above was executed *after* HW took
> the exception.
>
> << EXCEPTION BOUNDARY HERE >>
>
> Everything in the stacktrace segment(s) below was executed *before* HW
> took the exception.
>
> The unwinder knows that it has crossed this exception boundary by virtue
> of finding a FRAME_META_TYPE_PT_REGS frame record.
>
> > [ 262.123159] _raw_spin_unlock_irq+0x10/0x60 (P)
>
> The unwinder knows that the value of pt_regs::pc was *definitely* the PC
> at the time the exception was taken, so that entry is reliable. No CFI
> needed.
>
> > [ 262.123720] __filemap_add_folio+0x200/0x580 (L)
>
> The unwinder doesn't know whether the LR should be used, and needs CFI
> to determine that.
>
> After this point, an FP unwind can be used until we encounter the next
> exception boundary.
Right, and this is what is implemented in the final patch of this series.
>
> > [ 262.124145] filemap_add_folio+0xec/0x300
> > [ 262.124674] page_cache_ra_unbounded+0x128/0x368
> > [ 262.125338] do_page_cache_ra+0x70/0x98
> > [ 262.125875] page_cache_ra_order+0x460/0x4e0
>
> The segment immediately above can be unwound using FP. No CFI needed.
>
> > Here, el1h_64_irq is the last function that appears in the exception
> > stack before _raw_spin_unlock_irq and __filemap_add_folio are
> > recovered from the saved PC and LR, respectively. So we therefore need
> > the CFI annotations in order to unwind through the full exception
> > boundary.
> >
> > Is my interpretation here correct?
>
> Given you say "full exception boundary" here, I think we might be using
> the term "exception boundary" to mean different things.
>
> As per the example above, I'm using "exception boundary" to mean the a
> point between two entries in the stacktrace where HW took an exception.
>
> Did my comments on the example help?
I admit I may have been using the term "exception boundary" with a
vague definition, which was partly the source of my confusion. Thanks
for the example, it did help.
>
> > > > and irq entries through call_on_irq_stack()
> > >
> > > Needing some sort of unwind annotations for call_on_irq_stack() makes
> > > sense to me, but don't we need something for other assembly functions
> > > too?
> > >
> > > We can interrupt things like memset(); I assume we'll treat those as
> > > unreliable until annotated?
> >
> > While looking into adding these annotations, I noticed a pattern where
> > a sibling call is made to a local function:
> >
> > SYM_FUNC_START(__pi_memset)
> > alternative_if_not ARM64_HAS_MOPS
> > b __pi_memset_generic
> > alternative_else_nop_endif
> >
> > mov dst, dstin
> > setp [dst]!, count!, val_x
> > setm [dst]!, count!, val_x
> > sete [dst]!, count!, val_x
> > ret
> > SYM_FUNC_END(__pi_memset)
> >
> > In this case, do we consider the stacktrace unreliable since
> > __pi_memset may not appear in the trace?
>
> This is a tail-call, and __pi_memset_generic() will not return to
> __pi_memset(). Once the branch to __pi_memset_generic() has been
> executed, it's fine for __pi_memset() to not show up in the trace.
>
> The key thing is that no more instructions from __pi_memset() itself
> will be executed unless it was called again (from its entry point).
>
> > Or is this not important because assembly functions cannot be directly
> > livepatched anyway?
>
> To the best of my knowledge, reliable stacktrace is only used to
> determine whether any thread is still within an old version of a
> patchable function (including where it's within a callee thereof).
>
> I am not aware of a case where we'd need to detect whether a thread is
> still within a non-patchable function, but I can't rule out that as a
> possibility.
>
> That's more of a question for the livepatching maintainers.
>
> Thanks,
> Mark.
Thanks,
Dylan
^ permalink raw reply
* Re: [PATCH 7/8] sched_ext: Sub-allocator over kernel-claimed BPF arena pages
From: Alexei Starovoitov @ 2026-05-18 23:26 UTC (permalink / raw)
To: Tejun Heo, Peter Zijlstra
Cc: David Vernet, Andrea Righi, Changwoo Min, Alexei Starovoitov,
Andrii Nakryiko, Daniel Borkmann, Martin KaFai Lau,
Kumar Kartikeya Dwivedi, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Andrew Morton, David Hildenbrand, Mike Rapoport, Emil Tsalapatis,
sched-ext, bpf, x86, linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <agtt2dEjS4Qg7a_P@slm.duckdns.org>
On Mon May 18, 2026 at 12:51 PM PDT, Tejun Heo wrote:
> Hello,
>
> On Mon, May 18, 2026 at 09:20:42AM +0200, Peter Zijlstra wrote:
> ...
>> Should this really be part of scx rather than be part of the bpf-arena
>> thing proper?
>
> It's just a layer on top of arena. If bpf folks are okay with it, I don't
> see why it can't be a common utility thing on the bpf side.
Well, this gen_pool based allocator of arena memory is a temporary hack.
It's ok for rare allocation like in this at scx init time, but not suitable
for active arena management. We don't need to expose it beyond scx.
Having said that the fast and generic allocator for arena is definitely needed.
This break through with scratch page and bpf_arena_handle_page_fault()
cannot be overstated. It is a huge improvement for kernel <-> bpf interaction.
Not only kfuncs can now read arena without ugly __get_kernel_nofault(),
but we can reuse mm/slub.c to manage arena memory!
The key idea is simply this:
get_freepointer() {
if (s->flags & SLAB_BPF_ARENA)
return (void *)(s->arena_kern_vm_start | (u32)(unsigned long)ptr);
}
I'm sloping a prototype.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: vgic: free private_irqs when init fails after allocation
From: Michael Bommarito @ 2026-05-19 0:26 UTC (permalink / raw)
To: Yao Yuan
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <outz3fxn7c5tkfz3adoilikhtyjbii7qwxmknh2l4pdf4kv5bj@54lpduy2fuj4>
On Mon, May 18, 2026 at 1:31 AM Yao Yuan <yaoyuan@linux.alibaba.com> wrote:
> Ah. One thing I forgot to say:
>
> Do we need a fixes: tag here ?
I struggled with that a bit. Will's sister commit in 250f25367b58
didn't have a Fixes: tag, but if I had to pick, it would probably be
this:
Fixes: 03b3d00a70b5 ("KVM: arm64: vgic: Allocate private interrupts on demand")
If you agree, I can send v2 with that added
Thanks,
Mike
^ permalink raw reply
* [PATCH] fbdev: atmel_lcdfb: Use of_device_get_match_data()
From: Rosen Penev @ 2026-05-19 0:36 UTC (permalink / raw)
To: linux-fbdev
Cc: Nicolas Ferre, Helge Deller, Alexandre Belloni, Claudiu Beznea,
open list:FRAMEBUFFER LAYER,
moderated list:ARM/Microchip (AT91) SoC support, open list
Use of_device_get_match_data() to retrieve the driver match data instead
of open-coding the OF match lookup and dereferencing match->data.
This also removes the deprecated of_device.h include from the driver.
No need for NULL check as every compatible has a corresponding data
component.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/video/fbdev/atmel_lcdfb.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c
index 9dfbc5310210..87406a5a2dcf 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -21,7 +21,6 @@
#include <linux/gpio/consumer.h>
#include <linux/module.h>
#include <linux/of.h>
-#include <linux/of_device.h>
#include <video/of_videomode.h>
#include <video/of_display_timing.h>
#include <linux/regulator/consumer.h>
@@ -56,7 +55,7 @@ struct atmel_lcdfb_info {
struct atmel_lcdfb_pdata pdata;
- struct atmel_lcdfb_config *config;
+ const struct atmel_lcdfb_config *config;
struct regulator *reg_lcd;
};
@@ -930,8 +929,7 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
int ret;
int i;
- sinfo->config = (struct atmel_lcdfb_config*)
- of_match_device(atmel_lcdfb_dt_ids, dev)->data;
+ sinfo->config = of_device_get_match_data(dev);
display_np = of_parse_phandle(np, "display", 0);
if (!display_np) {
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Chia-I Wu @ 2026-05-19 0:36 UTC (permalink / raw)
To: Boris Brezillon
Cc: Liviu Dudau, Marcin Ślusarz, Ketil Johnsen, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Steven Price, Daniel Almeida, Alice Ryhl,
Matthias Brugger, AngeloGioacchino Del Regno, dri-devel,
linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Florent Tomasin, nd
In-Reply-To: <20260518091650.5a7a4f4a@fedora>
On Mon, May 18, 2026 at 12:16 AM Boris Brezillon
<boris.brezillon@collabora.com> wrote:
>
> On Wed, 13 May 2026 12:31:32 -0700
> Chia-I Wu <olvaffe@gmail.com> wrote:
>
> > On Tue, May 12, 2026 at 8:39 AM Liviu Dudau <liviu.dudau@arm.com> wrote:
> > >
> > > On Tue, May 12, 2026 at 04:11:11PM +0200, Boris Brezillon wrote:
> > > > On Tue, 12 May 2026 14:47:27 +0100
> > > > Liviu Dudau <liviu.dudau@arm.com> wrote:
> > > >
> > > > > On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote:
> > > > > > On Thu, 7 May 2026 11:02:26 +0200
> > > > > > Marcin Ślusarz <marcin.slusarz@arm.com> wrote:
> > > > > >
> > > > > > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:
> > > > > > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > > > > > > > > return ret;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > + /* If a protected heap name is specified but not found, defer the probe until created */
> > > > > > > > > + if (protected_heap_name && strlen(protected_heap_name)) {
> > > > > > > >
> > > > > > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> > > > > > > > name is "" already?
> > > > > > >
> > > > > > > If dma_heap_find() will fail, then the whole probe with fail too.
> > > > > > > This check prevents that.
> > > > > >
> > > > > > Yeah, that's also a questionable design choice. I mean, we can
> > > > > > currently probe and boot the FW even though we never setup the
> > > > > > protected FW sections, so why should we defer the probe here? Can't we
> > > > > > just retry the next time a group with the protected bit is created and
> > > > > > fail if we can find a protected heap?
> > > > >
> > > > > The problem we have with the current firmware is that it does a number of setup steps at "boot"
> > > > > time only. One of the steps is preparing its internal structures for when it enters protected
> > > > > mode and it stores them in the buffer passed in at firmware loading. We cannot later run the
> > > > > process when we have a group with protected mode set.
> > > >
> > > > No, but we can force a full/slow reset and have that thing
> > > > re-initialized, can't we? I mean, that's basically what we do when a
> > > > fast reset fails: we re-initialize all the sections and reset again, at
> > > > which point the FW should start from a fresh state, and be able to
> > > > properly initialize the protected-related stuff if protected sections
> > > > are populated. Am I missing something?
> > >
> > > Right, we can do that. For some reason I keep associating the reset with the
> > > error handling and not with "normal" operations.
> > I kind of hope we end up with either
> >
> > - panthor knows the exact heap to use and fails with EPROBE_DEFER if
> > the heap is missing, or
> > - panthor gets a dma-buf from userspace and does the full reset
> > - userspace also needs to provide a dma-buf for each protected
> > group for the suspend buffer
> >
> > than something in-between. The latter is more ad-hoc and basically
> > kicks the issue to the userspace.
>
> Indeed, the second option is more ad-hoc, but when you think about it,
> userspace has to have this knowledge, because it needs to know the
> dma-heap to use for buffer allocation that cross a device boundary
> anyway. Think about frames produced by a video decoder, and composited
> by the GPU into a protected scanout buffer that's passed to the KMS
> device. Why would the GPU driver be source of truth when it comes to
> choosing the heap to use to allocate protected buffers for the video
> decoder or those used for the display?
I don't think the GPU driver is ever the source of truth. If the
system integrator wants to specify the source of truth (SoT) from
kernel space, they should use the device tree (or module params /
config options). If they want to specify the SoT in userspace, then we
don't really care how it is done other than providing an ioctl.
Panthor is always on the receiving end.
If we don't want to delay this functionality, but it takes time to
converge on SoT, maybe a solution that is not a long-term promise can
work? Of the options on the table (dt, module params, kconfig options,
ioctls), a kconfig option, potentially marked as experimental, seems
like a good candidate.
>
> >
> > For the former, expressing the relation in DT seems to be the best,
> > but only if possible :-). Otherwise, a kconfig option (instead of
> > module param) should be easier to work with.
> >
> > Looking at the userspace implementation, can we also have an panthor
> > ioctl to return the heap to userspace?
>
> Yes, it's something we can add, but again, I'm questioning the
> usefulness of this: how can we ensure the heap used by panthor to
> allocate its protected FW buffers is suitable for scanout buffers
> (buffers that can be used by display drivers). There needs to be a glue
> leaving in usersland and taking the decision, and I'm not too sure
> trusting any of the component in the chain (vdec, gpu, display) is the
> right thing to do.
The heap returned by panthor is only for panfrost/panvk. It says
nothing about compatibility with other components on the system.
^ permalink raw reply
* [PATCH] clk: sunxi-ng: Use of_device_get_match_data()
From: Rosen Penev @ 2026-05-19 0:39 UTC (permalink / raw)
To: linux-clk
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland,
moderated list:ARM/Allwinner sunXi SoC support,
open list:ARM/Allwinner sunXi SoC support, open list
Use of_device_get_match_data() to fetch the RTC CCU match data directly
instead of open-coding an of_match_device() lookup.
This also lets the driver drop the of_device.h include.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
index f6bfeba009e8..a3cf0dde05be 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
@@ -9,7 +9,6 @@
#include <linux/io.h>
#include <linux/module.h>
#include <linux/of.h>
-#include <linux/of_device.h>
#include <linux/clk/sunxi-ng.h>
@@ -353,14 +352,12 @@ int sun6i_rtc_ccu_probe(struct device *dev, void __iomem *reg)
{
const struct sun6i_rtc_match_data *data;
struct clk *ext_osc32k_clk = NULL;
- const struct of_device_id *match;
/* This driver is only used for newer variants of the hardware. */
- match = of_match_device(sun6i_rtc_ccu_match, dev);
- if (!match)
+ data = of_device_get_match_data(dev);
+ if (!data)
return 0;
- data = match->data;
have_iosc_calibration = data->have_iosc_calibration;
if (data->have_ext_osc32k) {
--
2.54.0
^ permalink raw reply related
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