* Re: [PATCH v2] crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A
From: Thorsten Blum @ 2026-04-28 12:32 UTC (permalink / raw)
To: Marek Behún
Cc: Bill Cox, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Linus Walleij, Ard Biesheuvel,
stable, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <25ntssyy6t5uwxlwfpmrpzpcq6xv62l643hflf26hxi6lv5wqu@6vub6ysczjvd>
Hi Marek,
On Tue, Apr 28, 2026 at 01:18:08PM +0200, Marek Behún wrote:
> Adding Bill Cox (waywardgeek) to the conversation.
>
> In the meantime Nack from me on this patch.
>
> From the original messages by Bill, it seems to me the part he was reviewing
> was the ATSHA204A.
>
> In subsequent reply [1] Bill states
>
> While there is some evidence, there is still no convincing proof that there
> is an entropy source in this device at all. There is some evidence that
> Atmel has inserted a back-door. My advice is to avoid this line of parts
> from Atmel for cryptographic use.
>
> In another message Peter Gutmann asks about ATECC108 [2] and Bill replies [3]
>
> This part uses the same language to describe the random number generator.
> It is "high quality". I think that's pretty funny.
> I would be interested in seeing if the new part can generate random numbers
> continuously, or if it fails after it's EEPROM wears out like their other
> parts. The use of an EEPROM seed is for PWN-ing your RNG, not making it
> more secure.
>
> IMO the comments from the actual reviewer are more relevant than those of the
> engineer working for the company which was accused of creating low quality
> / backdoored TRNG, at least until the Atmel engineer provides some evaluation
> code for the device (which they suggested they might do [4], but never did as
> far as I can find).
>
> Maybe we can instead change the ATECC quality to something like 32? Does that
> even make sense?
>
> Marek
>
> [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023857.html
> [2] https://www.metzdowd.com/pipermail/cryptography/2014-December/023870.html
> [3] https://www.metzdowd.com/pipermail/cryptography/2014-December/023879.html
> [4] https://www.metzdowd.com/pipermail/cryptography/2014-December/023886.html
Bill wrote in his review:
"If I made no mistake (and I do make a lot), the "random" data from
the Atmel ATSHA204A is highly predictable when you disable the seed
update to EEPROM."
However, the atmel-sha204a driver doesn't operate the device in that
mode. It uses the Random command with seed updates enabled, which is
also what the datasheet recommends for highest security:
"Microchip recommends that the EEPROM seed always be updated."
So the reported behavior doesn't reflect how the driver uses the device.
Thanks,
Thorsten
^ permalink raw reply
* Re: [PATCH v21 07/13] power: reset: Add psci-reboot-mode driver
From: Shivendra Pratap @ 2026-04-28 12:33 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-pm, linux-kernel, linux-arm-msm, linux-arm-kernel,
devicetree, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik, Greg Kroah-Hartman,
Kathiravan Thirumoorthy, Srinivas Kandagatla, Sebastian Reichel,
Mark Rutland, Lorenzo Pieralisi, Rafael J. Wysocki,
Daniel Lezcano, Christian Loehle, Ulf Hansson, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Arnd Bergmann, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer, Sudeep Holla
In-Reply-To: <CAMRc=MdLTMX34DEhoMskMzjRqx+Cdpm3=P5QTZ8S6sUVJ3eTbg@mail.gmail.com>
On 28-04-2026 13:26, Bartosz Golaszewski wrote:
[SNIP..]
>> +
>> + return psci_reboot_mode_add_predefined_mode(dev, reboot, &psci_resets[1]);
> Looking at this, I'd introduce a core reboot-mode helper for initializing the
> predefined_modes field and adding an array of modes and use it here and earlier
> in the series.
sure. thanks for review. Will expose a call from reboot-mode to init/add
predefined_modes.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH V1 1/3] ACPICA: IORT: Add Root Complex PASID Flags field
From: Hanjun Guo @ 2026-04-28 12:32 UTC (permalink / raw)
To: Jason Gunthorpe, Vidya Sagar
Cc: rafael, lenb, saket.dumbre, lpieralisi, sudeep.holla, will,
catalin.marinas, joro, robin.murphy, nicolinc, praan, vsethi,
sdonthineni, kthota, sagar.tv, linux-acpi, linux-arm-kernel,
acpica-devel, iommu, linux-kernel
In-Reply-To: <20260423224318.GT3611611@ziepe.ca>
On 2026/4/24 6:43, Jason Gunthorpe wrote:
> On Fri, Apr 24, 2026 at 12:44:15AM +0530, Vidya Sagar wrote:
>> The IORT spec, Issue E.c (ARM DEN 0049E.c, January 2022), bumps the
>> Root Complex Node to revision 4 and adds two PASID descriptors:
>>
>> - PASID Capabilities at byte offset 33 (2 bytes), bits[4:0] of which
>> report the Max PASID Width supported by the Root Complex.
>> - Flags at byte offset 36 (4 bytes), bit 0 of which reports whether
>> the Root Complex itself supports PASID. This is distinct from the
>> existing ATS Attribute bit 2 (at offset 24) that only reports
>> whether the RC forwards PASID information on translated
>> transactions.
>>
>> The ACPICA struct in include/acpi/actbl2.h was updated for the E.c
>> PASID Capabilities descriptor (offset 33) but stops short with a
>> trailing 'u8 reserved[]' flexible array, so the new Flags field at
>> offset 36 is unreachable and the existing ACPI_IORT_PASID_*
>> definitions have no consumer.
>>
>> Replace the trailing flexible array with a fixed 'u8 reserved[1]'
>> followed by 'u32 flags' so the struct fully covers RC node revision 4,
>> and add the ACPI_IORT_RC_PASID_SUPPORTED mask for bit 0 of the new
>> field. With #pragma pack(1) in effect for actbl2.h, this lands the new
>> field at the spec-mandated absolute offset 36.
>>
>> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
>> ---
>> include/acpi/actbl2.h | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> There is a whole process to change this file, I went through it once
> for canwbs..
>
> https://lore.kernel.org/acpica-devel/2-v3-e2e16cd7467f+2a6a1-smmuv3_nesting_jgg@nvidia.com/
>
> You have to make a pull request here:
>
> https://github.com/acpica/acpica/pulls
Yes, please get this patch merged in ACPICA first.
Thanks
Hanjun
^ permalink raw reply
* Re: [PATCH v4 3/3] coco: guest: arm64: Query host IPA-change alignment via RHI
From: Aneesh Kumar K.V @ 2026-04-28 12:49 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-kernel, iommu, linux-coco, linux-arm-kernel, kvmarm,
Catalin Marinas, Jason Gunthorpe, Marek Szyprowski, Robin Murphy,
Steven Price, Suzuki K Poulose, Thomas Gleixner, Will Deacon
In-Reply-To: <86y0i8zo9f.wl-maz@kernel.org>
Marc Zyngier <maz@kernel.org> writes:
> On Mon, 27 Apr 2026 07:31:08 +0100,
> "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org> wrote:
>>
>> Add the Realm Host Interface support needed to query host configuration
>> from a Realm guest. Define the RHI hostconf SMCs, add rsi_host_call(), and
>> use them during Realm initialization to retrieve the host IPA-change
>> alignment size.
>
> I don't understand what "IPA-change" means. What you are after is the
> host's sharing granule size.
>
This is part of the RHI specification, and the call is named
RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT. The intent is to determine the
alignment requirements for changing IPA attributes (protected vs.
unprotected IPA
>
>>
>> Expose that alignment through realm_get_hyp_pagesize() and
>> mem_decrypt_granule_size() so shared-buffer allocation and
>> encryption/decryption paths can honor the ipa change page-size requirement.
>>
>> If the host reports an invalid alignment (when alginment value is not
>> multiple of 4K), do not enable Realm support.
>>
>> This provides the host alignment information required by the shared buffer
>> alignment changes.
>>
>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>> ---
>> arch/arm64/include/asm/mem_encrypt.h | 3 ++
>> arch/arm64/include/asm/rhi.h | 24 +++++++++++++
>> arch/arm64/include/asm/rsi.h | 2 ++
>> arch/arm64/include/asm/rsi_cmds.h | 10 ++++++
>> arch/arm64/include/asm/rsi_smc.h | 7 ++++
>> arch/arm64/kernel/Makefile | 2 +-
>> arch/arm64/kernel/rhi.c | 54 ++++++++++++++++++++++++++++
>> arch/arm64/kernel/rsi.c | 13 +++++++
>> arch/arm64/mm/mem_encrypt.c | 8 +++++
>> 9 files changed, 122 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm64/include/asm/rhi.h
>> create mode 100644 arch/arm64/kernel/rhi.c
>>
>> diff --git a/arch/arm64/include/asm/mem_encrypt.h b/arch/arm64/include/asm/mem_encrypt.h
>> index 314b2b52025f..5541911eb028 100644
>> --- a/arch/arm64/include/asm/mem_encrypt.h
>> +++ b/arch/arm64/include/asm/mem_encrypt.h
>> @@ -16,6 +16,9 @@ int arm64_mem_crypt_ops_register(const struct arm64_mem_crypt_ops *ops);
>> int set_memory_encrypted(unsigned long addr, int numpages);
>> int set_memory_decrypted(unsigned long addr, int numpages);
>>
>> +#define mem_decrypt_granule_size mem_decrypt_granule_size
>> +size_t mem_decrypt_granule_size(void);
>> +
>> int realm_register_memory_enc_ops(void);
>>
>> static inline bool force_dma_unencrypted(struct device *dev)
>> diff --git a/arch/arm64/include/asm/rhi.h b/arch/arm64/include/asm/rhi.h
>> new file mode 100644
>> index 000000000000..0895dd92ea1d
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/rhi.h
>> @@ -0,0 +1,24 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (C) 2026 ARM Ltd.
>> + */
>> +
>> +#ifndef __ASM_RHI_H_
>> +#define __ASM_RHI_H_
>> +
>> +#include <linux/types.h>
>> +
>> +#define SMC_RHI_CALL(func) \
>> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
>> + ARM_SMCCC_SMC_64, \
>> + ARM_SMCCC_OWNER_STANDARD_HYP,\
>> + (func))
>> +
>> +unsigned long rhi_get_ipa_change_alignment(void);
>> +#define RHI_HOSTCONF_VER_1_0 0x10000
>> +#define RHI_HOSTCONF_VERSION SMC_RHI_CALL(0x004E)
>> +
>> +#define __RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT BIT(0)
>> +#define RHI_HOSTCONF_FEATURES SMC_RHI_CALL(0x004F)
>> +#define RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT SMC_RHI_CALL(0x0050)
>> +#endif
>> diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
>> index 88b50d660e85..ae54fb3b1429 100644
>> --- a/arch/arm64/include/asm/rsi.h
>> +++ b/arch/arm64/include/asm/rsi.h
>> @@ -67,4 +67,6 @@ static inline int rsi_set_memory_range_shared(phys_addr_t start,
>> return rsi_set_memory_range(start, end, RSI_RIPAS_EMPTY,
>> RSI_CHANGE_DESTROYED);
>> }
>> +
>> +unsigned long realm_get_hyp_pagesize(void);
>> #endif /* __ASM_RSI_H_ */
>> diff --git a/arch/arm64/include/asm/rsi_cmds.h b/arch/arm64/include/asm/rsi_cmds.h
>> index 2c8763876dfb..a341ce0eeda1 100644
>> --- a/arch/arm64/include/asm/rsi_cmds.h
>> +++ b/arch/arm64/include/asm/rsi_cmds.h
>> @@ -159,4 +159,14 @@ static inline unsigned long rsi_attestation_token_continue(phys_addr_t granule,
>> return res.a0;
>> }
>>
>> +static inline unsigned long rsi_host_call(struct rsi_host_call *rhi_call)
>> +{
>> + phys_addr_t addr = virt_to_phys(rhi_call);
>> + struct arm_smccc_res res;
>> +
>> + arm_smccc_1_1_invoke(SMC_RSI_HOST_CALL, addr, &res);
>
> Errr... What guarantees that *rhi_call is *IPA contiguous*? This is
> incredibly fragile. You should at the very least check that this isn't
> vmalloc'd.
>
I didn’t quite follow that. We have other RSI calls (even RMI calls)
that do similar things, and the caller understands that the address
should be IPA-contiguous. Are you suggesting that all RSI calls should
add checks for this?. or are you suggesting to update the API to
unsigned long rsi_host_call(unsigned long rhi_call_phys) ?
>> +
>> + return res.a0;
>> +}
>> +
>> #endif /* __ASM_RSI_CMDS_H */
>> diff --git a/arch/arm64/include/asm/rsi_smc.h b/arch/arm64/include/asm/rsi_smc.h
>> index e19253f96c94..9ee8b5c7612e 100644
>> --- a/arch/arm64/include/asm/rsi_smc.h
>> +++ b/arch/arm64/include/asm/rsi_smc.h
>> @@ -182,6 +182,13 @@ struct realm_config {
>> */
>> #define SMC_RSI_IPA_STATE_GET SMC_RSI_FID(0x198)
>>
>> +struct rsi_host_call {
>> + union {
>> + u16 imm;
>> + u64 padding0;
>> + };
>> + u64 gprs[31];
>> +} __aligned(0x100);
>> /*
>> * Make a Host call.
>> *
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index fe627100d199..3e72dd9584ed 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -34,7 +34,7 @@ obj-y := debug-monitors.o entry.o irq.o fpsimd.o \
>> cpufeature.o alternative.o cacheinfo.o \
>> smp.o smp_spin_table.o topology.o smccc-call.o \
>> syscall.o proton-pack.o idle.o patching.o pi/ \
>> - rsi.o jump_label.o
>> + rsi.o jump_label.o rhi.o
>>
>> obj-$(CONFIG_COMPAT) += sys32.o signal32.o \
>> sys_compat.o
>> diff --git a/arch/arm64/kernel/rhi.c b/arch/arm64/kernel/rhi.c
>> new file mode 100644
>> index 000000000000..7cd6c5102464
>> --- /dev/null
>> +++ b/arch/arm64/kernel/rhi.c
>> @@ -0,0 +1,54 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2026 ARM Ltd.
>> + */
>> +
>> +#include <linux/mm.h>
>> +#include <asm/rsi.h>
>> +#include <asm/rhi.h>
>> +
>> +/* we need an aligned rhicall for rsi_host_call. slab is not yet ready */
>> +static struct rsi_host_call hyp_pagesize_rhicall;
>
> Why the "hyp_" prefix? This has absolutely nothing to with the
> hypervisor.
>
Sure will update "hyp_" reference to host.
>> +unsigned long rhi_get_ipa_change_alignment(void)
>> +{
>> + long ret;
>> + unsigned long ipa_change_align;
>> +
>> + hyp_pagesize_rhicall.imm = 0;
>> + hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_VERSION;
>> + ret = rsi_host_call(lm_alias(&hyp_pagesize_rhicall));
>> + if (ret != RSI_SUCCESS)
>> + goto err_out;
>> +
>> + if (hyp_pagesize_rhicall.gprs[0] != RHI_HOSTCONF_VER_1_0)
>> + goto err_out;
>> +
>> + hyp_pagesize_rhicall.imm = 0;
>> + hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_FEATURES;
>> + ret = rsi_host_call(lm_alias(&hyp_pagesize_rhicall));
>> + if (ret != RSI_SUCCESS)
>> + goto err_out;
>> +
>> + if (!(hyp_pagesize_rhicall.gprs[0] & __RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT))
>> + goto err_out;
>> +
>> + hyp_pagesize_rhicall.imm = 0;
>> + hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT;
>> + ret = rsi_host_call(lm_alias(&hyp_pagesize_rhicall));
>> + if (ret != RSI_SUCCESS)
>> + goto err_out;
>> +
>> + ipa_change_align = hyp_pagesize_rhicall.gprs[0];
>> + /* This error needs special handling in the caller */
>> + if (ipa_change_align & (SZ_4K - 1))
>> + return 0;
>> +
>> + return ipa_change_align;
>> +
>> +err_out:
>> + /*
>> + * For failure condition assume host is built with 4K page size
>> + * and hence ipa change alignment can be guest PAGE_SIZE.
>> + */
>> + return PAGE_SIZE;
>> +}
>
> Why can't this be part of rsi.c? This is an RSI call, and it should be
> part of the RSI initialisation.
>
This is an RHI call as per the specification, hence it has been added to
rhi.c.
>> diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
>> index 9e846ce4ef9c..ff735c04e236 100644
>> --- a/arch/arm64/kernel/rsi.c
>> +++ b/arch/arm64/kernel/rsi.c
>> @@ -14,8 +14,10 @@
>> #include <asm/mem_encrypt.h>
>> #include <asm/pgtable.h>
>> #include <asm/rsi.h>
>> +#include <asm/rhi.h>
>>
>> static struct realm_config config;
>> +static unsigned long ipa_change_alignment = PAGE_SIZE;
>>
>> unsigned long prot_ns_shared;
>> EXPORT_SYMBOL(prot_ns_shared);
>> @@ -139,6 +141,11 @@ static int realm_ioremap_hook(phys_addr_t phys, size_t size, pgprot_t *prot)
>> return 0;
>> }
>>
>> +unsigned long realm_get_hyp_pagesize(void)
>> +{
>> + return ipa_change_alignment;
>> +}
>
> Again, this has nothing to do with the hypervisor, but the host. And
> ipa_change_alignment is still a wording I can't wrap my small head
> around.
>
>> +
>> void __init arm64_rsi_init(void)
>> {
>> if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
>> @@ -147,6 +154,12 @@ void __init arm64_rsi_init(void)
>> return;
>> if (WARN_ON(rsi_get_realm_config(&config)))
>> return;
>> +
>> + ipa_change_alignment = rhi_get_ipa_change_alignment();
>> + /* If we don't get a correct alignment response, don't enable realm */
>> + if (!ipa_change_alignment)
>> + return;
>
> But at the same time, you override a global value with an error, and
> then paper over it in mem_decrypt_granule_size()...
>
I believe I received similar feedback on my previous version as well,
which I didn’t quite follow.
rhi_get_ipa_change_alignment() only returns an error when the host
returns a size that is not 4K-aligned. Otherwise, it returns the
host-determined size, or defaults to guest PAGE_SIZE if the RHI call
itself is not supported.
ipa_change_align = hyp_pagesize_rhicall.gprs[0];
/* This error needs special handling in the caller */
if (ipa_change_align & (SZ_4K - 1))
return 0;
return ipa_change_align;
err_out:
/*
* For failure condition assume host is built with 4K page size
* and hence ipa change alignment can be guest PAGE_SIZE.
*/
return PAGE_SIZE;
>
>> +
>> prot_ns_shared = __phys_to_pte_val(BIT(config.ipa_bits - 1));
>>
>> if (arm64_ioremap_prot_hook_register(realm_ioremap_hook))
>> diff --git a/arch/arm64/mm/mem_encrypt.c b/arch/arm64/mm/mem_encrypt.c
>> index 38c62c9e4e74..f5d64bc29c20 100644
>> --- a/arch/arm64/mm/mem_encrypt.c
>> +++ b/arch/arm64/mm/mem_encrypt.c
>> @@ -59,3 +59,11 @@ int set_memory_decrypted(unsigned long addr, int numpages)
>> return crypt_ops->decrypt(addr, numpages);
>> }
>> EXPORT_SYMBOL_GPL(set_memory_decrypted);
>> +
>> +size_t mem_decrypt_granule_size(void)
>> +{
>> + if (is_realm_world())
>> + return max(PAGE_SIZE, realm_get_hyp_pagesize());
>
> If you didn't mess with ipa_change_alignment above, you shouldn't need
> this max().
>
size_t mem_decrypt_granule_size(void)
{
if (is_realm_world())
return max(PAGE_SIZE, realm_get_hyp_pagesize());
return PAGE_SIZE;
}
That needs to use max(), because we should align to the guest PAGE_SIZE
if it is larger than the host-specified alignment value.
-aneesh
^ permalink raw reply
* Re: [PATCH v21 08/13] mfd: core: Add firmware-node support to MFD cells
From: Bartosz Golaszewski @ 2026-04-28 12:51 UTC (permalink / raw)
To: Shivendra Pratap
Cc: linux-pm, linux-kernel, linux-arm-msm, linux-arm-kernel,
devicetree, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik, Greg Kroah-Hartman,
Kathiravan Thirumoorthy, Srinivas Kandagatla, Sebastian Reichel,
Mark Rutland, Lorenzo Pieralisi, Rafael J. Wysocki,
Daniel Lezcano, Christian Loehle, Ulf Hansson, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Arnd Bergmann, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer, Sudeep Holla
In-Reply-To: <c0677503-8073-4940-8eb0-c06b34f843d2@oss.qualcomm.com>
On Tue, Apr 28, 2026 at 2:18 PM Shivendra Pratap
<shivendra.pratap@oss.qualcomm.com> wrote:
>
>
>
> On 28-04-2026 13:33, Bartosz Golaszewski wrote:
> > On Mon, 27 Apr 2026 19:34:48 +0200, Shivendra Pratap
> > <shivendra.pratap@oss.qualcomm.com> said:
> >> MFD core has no way to register a child device using an explicit firmware
> >> node. This prevents drivers from registering child nodes when those nodes
> >> do not define a compatible string. One such example is the PSCI
> >> "reboot-mode" node, which omits a compatible string as it describes
> >> boot-states provided by the underlying firmware.
> >>
> >> Extend struct mfd_cell with an optional fwnode pointer and attach it to the
> >> child device during registration when no firmware node is already assigned.
> >>
> >> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> >> ---
> >
> > In the following patch you use this and violate the supposed constness of
> > MFD cells. This also mean you need to modify the mfd_cell at run-time. I would
> > prefer introducing a field in mfd_cell: bool use_parent_fwnode which would
> > indicate to MFD core that - in case no fwnode was assigned from other sources:
> > DT or software node - it should reuse the parent MFD device's node.
>
> Have one doubt on this, When we fallback to use_parent_fwnode for cell:
> psci-reboot-mode, at psci_reboot_mode_probe(), pDev->dev->of_node point
> to psci node.
>
> But we want dev->of_node to point to "reboot-mode" node. This may need
> an explicit assignment again of of_node?
>
Ah, sorry you're right. I'd like to avoid having to modify the
mfd_cell entry at run-time if possible.
How about a callback in mfd_cell like:
struct fwnode_handle *(*get_fwnode)(struct device *parent);
If set, it would be called from MFD core and would do the name lookup
and return the fwnode which would then be assigned to the cell device?
Bart
^ permalink raw reply
* Re: [QUESTION] Is the ARM SMMU v3 implementation designed to always ignore SSID when SSID_VALID == 0?
From: Joonwon Kang @ 2026-04-28 12:51 UTC (permalink / raw)
To: robin.murphy
Cc: baolu.lu, cychu, hhchung, iommu, jgg, joonwonkang, joro, jpb,
linux-arm-kernel, linux-kernel, stimim, will
In-Reply-To: <d860b6a9-e4a9-494f-821d-8b0a347e1591@arm.com>
> On 28/04/2026 12:14 pm, Joonwon Kang wrote:
> > Thanks for your prompt and insightful answer!
> >
> >> Hi,
> >>
> >> On Tue, Apr 28, 2026 at 07:38:59AM +0000, Joonwon Kang wrote:
> >>> Hi team,
> >>>
> >>> According to the ARM SMMU v3 spec, I believe that SSID should always be
> >>> ignored when SSID_VALID == 0 and the current ARM SMMU v3 module
> >>> implementation in the kernel seems to comply with this without exception.
> >>> For example, when handling an event from SMMU, the implementation checks
> >>> SSID_VALID(SSV) first and ignores SSID accordingly. If there is any
> >>> exception to this rule, I believe it is a bug.
> >>
> >> Indeed
> >
> > Acknowledged.
> >
> >>
> >>> Is it true for all the current and future cases? In other words, is it
> >>> **mandatory** that the ARM SMMU v3 implementation ignores SSID when
> >>> SSID_VALID == 0? or there might be some cases where the implementation
> >>> needs to refer to SSID even when SSID_VALID == 0?
> >>>
> >>> Asking this question since our HW may not be able to clear SSID when
> >>> SSID_VALID == 0 and so there might be some garbage value in SSID at some
> >>> point of time(the HW will have a correct SSID when SSID_VALID == 1,
> >>> though). If the ARM SMMU v3 implementation is to refer to that garbage
> >>> value for any reason, the result would be devastating.
> >>
> >> At least according to the architecture, SubstreamID is ignored when SSV=0.
> >> The SMMU is allowed to propagate the garbage:
> >>
> >> 7.3 Event record
> >>
> >> * SSV: The SubstreamID validity flag
> >> - 0: No SubstreamID was provided with the transaction and the SubstreamID field is UNKNOWN.
> >>
> >> But the driver will ignore it.
> >>
> >> Same for PRI queue but in that case the page request wouldn't have a PASID
> >> TLP prefix.
> >
> > Although the PRI request without PASID may cause unpleasant ATC flush with
> > SSV clear in this case, it does not lead to the implementation referring
> > to the garbage SSID. Is this understanding correct? And while this case
> > seems to be handled solely by the ARM SMMU v3 implementation, do you see
> > if there is additional care required on our device driver for this?
>
> A transaction with SSV==0 does not have a SubstreamID, therefore by
> definition there is nothing that an SMMU could validly attempt to do
> with a SubstreamID that does not exist. Sure, implementations can have
> bugs, but I'd expect any such bug in this regard should be sufficiently
> obvious that it most likely wouldn't get past architectural validation
> in the first place.
>
It makes a lot of sense.
> If you want to know the exact behaviour of Arm's implementations then
> you're best off asking Arm support, but since this piqued my curiosity
> too, I can save you the trouble - I checked with my contacts on the
> design team, and indeed our SMMUs should ignore the SSID value entirely
> when SSV==0 and just treat it as 0 (e.g. in event records).
Thank you very much for saving me the effort and confirming this. I also
acknowledge that it will be best to ask the Arm support with regards to
the exact behavior of Arm's implementation.
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH] arm64: dts: ti: k3-j721s2-som-p0: add bootph-pre-ram property to pmic@4c
From: Kumar, Udit @ 2026-04-28 12:57 UTC (permalink / raw)
To: Thomas Richard, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Thomas Petazzoni, linux-arm-kernel, devicetree, linux-kernel,
gregory.clement, richard.genoud, a-kumar2
In-Reply-To: <3a78ff9c-e70e-47c2-b356-2bf9d75bc372@bootlin.com>
On 4/28/2026 5:36 PM, Thomas Richard wrote:
> On 4/28/26 12:15 PM, Kumar, Udit wrote:
>>
>>
>> On 4/28/2026 2:23 PM, Thomas Richard (TI) wrote:
>>> On j721s2, pmic@4c is needed to exit the DDR from retention after
>>
>> pmic@4c to PMIC-A to align with schematic, please
>
> You mean PMIC-B.
>
Yes,
> Best Regards,
> Thomas
^ permalink raw reply
* Re: [PATCH v2 4/6] firmware: samsung: acpm: Fix memory ordering race in RX path
From: Tudor Ambarus @ 2026-04-28 12:57 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, stable
In-Reply-To: <6bba950c-5527-4613-8c16-b52534bc75a5@kernel.org>
Hi, Krzysztof,
Thanks for the review! I indeed missed something in the acquire path,
details below.
On 4/28/26 12:52 PM, Krzysztof Kozlowski wrote:
> On 27/04/2026 17:04, Tudor Ambarus wrote:
>> Sashiko identified a memory ordering race in RX path [1].
>>
>> When draining the RX queue or reading saved responses, the driver uses
>> clear_bit() to release the sequence number back to the available pool.
>> However, on weakly ordered architectures like ARM64, clear_bit() does
>> not provide implicit memory barriers.
>
> And it does not have to if entire access is synchronized by other locks.
Right.
> You need to analyze also this and mention here path which is not
> synchronized and uses these weakly ordered atomic operations.
>
The TX path is protected by tx_lock, and the RX path is protected by
rx_lock. Because the bitmap_seqnum is modified by the RX thread
(clearing the bit) and the TX thread (setting the bit), the bitmap is
accessed across two different lock domains. Therefore, from the
bitmap's perspective, the synchronization is entirely lockless, and
explicit memory barriers are required. I'll add a comment in the
commit message.
>>
>> This allows the CPU to reorder instructions, making the cleared bit
>> globally visible before the preceding memory operations (memcpy() or
>> __ioread32_copy()) have completed. If a concurrent thread allocates the
>> newly freed sequence number, it can execute acpm_prepare_xfer() and
>> zero out the buffer via memset() while the RX thread is still actively
>> reading from it, leading to silent data corruption.
>>
>> Fix this by replacing clear_bit() with clear_bit_unlock() across the
>> RX path. This provides release semantics, guaranteeing that all prior
>> memory reads and writes are fully completed and visible before the
>> sequence number is marked as free.
>
> Barriers should be paired and release is paired with acquire.
> bitmap_seqnum() is used with test_bit() and a separate set_bit(), which
> do not have acquire semantics, although in some calls it is within lock.
> Problem is I guess acpm_dequeue_by_polling() which is called without any
> locks.
>
> This means that other thread won't see updated values.
>
> I think you also need to investigate and fix that acquire path.
:) thanks for the challenge!
In acpm_dequeue_by_polling(), zero-lenght messages (rxcnt == 0) can have
their bits cleared by a concurrent thread draining the queue. If we have
our thread sitting in the do...while loop and calling test_bit() we risk
speculative execution of the caller's subsequent instructions before the
bit actually flips to zero. The fix is to s/test_bit()/test_bit_acquire().
In what concerns acpm_prepare_xfer(), where we use set_bit(), I find it
safe as it is, I don't think we need an acquire barrier. By the time the
test_bit() loop observes a 0, the RX's clear_bit_unlock() has guaranteed
that the payload was copied out. The rx_data->cmd buffer is dead.
Another thing that I thought about was about the reordering of memset
and set_bit in acpm_prepare_xfer(), but even there, the internal
execution order doesn't matter. Both are guaranteed to be completed
before writel (wmb). One may notice that I even reordered the memset and
set_bit in patch 6/6.
Also, test_bit() in acpm_prepare_xfer() will be replaced in patch 6/6
by find_next_zero_bit(), they are functionally equivalent.
I'll send a v3, s/test_bit()/test_bit_acquire()/ in RX path and update
the commit message with the details described above.
Cheers,
ta
^ permalink raw reply
* Re: [PATCH v21 08/13] mfd: core: Add firmware-node support to MFD cells
From: Shivendra Pratap @ 2026-04-28 13:03 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-pm, linux-kernel, linux-arm-msm, linux-arm-kernel,
devicetree, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik, Greg Kroah-Hartman,
Kathiravan Thirumoorthy, Srinivas Kandagatla, Sebastian Reichel,
Mark Rutland, Lorenzo Pieralisi, Rafael J. Wysocki,
Daniel Lezcano, Christian Loehle, Ulf Hansson, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Arnd Bergmann, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer, Sudeep Holla
In-Reply-To: <CAMRc=MdxpSXiqAn-8Az4ig4N8TFVdE9psacPVG9J9KehuFnbwA@mail.gmail.com>
On 28-04-2026 18:21, Bartosz Golaszewski wrote:
> On Tue, Apr 28, 2026 at 2:18 PM Shivendra Pratap
> <shivendra.pratap@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 28-04-2026 13:33, Bartosz Golaszewski wrote:
>>> On Mon, 27 Apr 2026 19:34:48 +0200, Shivendra Pratap
>>> <shivendra.pratap@oss.qualcomm.com> said:
>>>> MFD core has no way to register a child device using an explicit firmware
>>>> node. This prevents drivers from registering child nodes when those nodes
>>>> do not define a compatible string. One such example is the PSCI
>>>> "reboot-mode" node, which omits a compatible string as it describes
>>>> boot-states provided by the underlying firmware.
>>>>
>>>> Extend struct mfd_cell with an optional fwnode pointer and attach it to the
>>>> child device during registration when no firmware node is already assigned.
>>>>
>>>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>>>> ---
>>>
>>> In the following patch you use this and violate the supposed constness of
>>> MFD cells. This also mean you need to modify the mfd_cell at run-time. I would
>>> prefer introducing a field in mfd_cell: bool use_parent_fwnode which would
>>> indicate to MFD core that - in case no fwnode was assigned from other sources:
>>> DT or software node - it should reuse the parent MFD device's node.
>>
>> Have one doubt on this, When we fallback to use_parent_fwnode for cell:
>> psci-reboot-mode, at psci_reboot_mode_probe(), pDev->dev->of_node point
>> to psci node.
>>
>> But we want dev->of_node to point to "reboot-mode" node. This may need
>> an explicit assignment again of of_node?
>>
>
> Ah, sorry you're right. I'd like to avoid having to modify the
> mfd_cell entry at run-time if possible.
>
> How about a callback in mfd_cell like:
>
> struct fwnode_handle *(*get_fwnode)(struct device *parent);
>
> If set, it would be called from MFD core and would do the name lookup
> and return the fwnode which would then be assigned to the cell device?
sure. thanks. We can make it a callback from MFD core.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v2 5/6] firmware: samsung: acpm: Fix out-of-bounds read and infinite loop in RX path
From: Tudor Ambarus @ 2026-04-28 13:04 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, stable
In-Reply-To: <20260427-acpm-fixes-sashiko-reports-v2-5-1ff8de94a997@linaro.org>
FYI, I checked sashiko's review on the set, and I shall act on this patch
and extend the checks for tx_front >= achan->qlen and add zero length checks
for qlen and mlen that were read from SRAM. I'll do that in v3.
The rest of the review feedback doesn't apply, so together with the changes
proposed in patch 4/6 that will be all.
Cheers,
ta
^ permalink raw reply
* Re: [PATCH v4 1/4] kernel: param: initialize module_kset before do_initcalls()
From: Shashank Balaji @ 2026-04-28 13:07 UTC (permalink / raw)
To: Gary Guo, Thierry Reding, Jonathan Hunter
Cc: Suzuki K Poulose, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Richard Cochran, Jonathan Corbet, Shuah Khan,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Mike Leach, Leo Yan, Rahul Bukte, linux-kernel,
coresight, linux-arm-kernel, driver-core, rust-for-linux,
linux-doc, Daniel Palmer, Tim Bird, linux-modules, linux-tegra
In-Reply-To: <DI4QQA6EGIA1.N8WRFWVKG91S@garyguo.net>
Adding Tegra maintainers.
On Tue, Apr 28, 2026 at 12:10:50PM +0100, Gary Guo wrote:
> On Tue Apr 28, 2026 at 1:37 AM BST, Shashank Balaji wrote:
> > Hi Gary,
> >
> > On Mon, Apr 27, 2026 at 02:29:55PM +0100, Gary Guo wrote:
> >> On Mon Apr 27, 2026 at 3:41 AM BST, Shashank Balaji wrote:
> >> > module_kset is initialized in param_sysfs_init(), a subsys_initcall. A number
> >> > of platform drivers register themselves prior to subsys_initcalls
> >> > (tegra194_cbb_driver registers in a pure_initcall, for example). With an
> >> > upcoming patch ("driver core: platform: set mod_name in driver registration")
> >> > that sets their mod_name in struct device_driver, lookup_or_create_module_kobject()
> >> > will be called for those drivers, which calls kset_find_obj(module_kset, mod_name).
> >> > This causes a null deref because module_kset isn't alive yet.
> >> >
> >> > Fix this by initializing module_kset in do_basic_setup() before do_initcalls().
> >> > Modernize the pr_warn while we're at it.
> >> >
> >> > Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >> > Suggested-by: Gary Guo <gary@garyguo.net>
> >>
> >> I didn't suggest this change :)
> >>
> >> I suggested `pure_initcall`, which is just a one line change.
> >
> > Oops, sorry about the misattribution.
> >
> >> diff --git a/kernel/params.c b/kernel/params.c
> >> index 74d620bc2521..ac088d4b09a9 100644
> >> --- a/kernel/params.c
> >> +++ b/kernel/params.c
> >> @@ -957,7 +957,7 @@ static int __init param_sysfs_init(void)
> >>
> >> return 0;
> >> }
> >> -subsys_initcall(param_sysfs_init);
> >> +pure_initcall(param_sysfs_init);
> >>
> >> /*
> >> * param_sysfs_builtin_init - add sysfs version and parameter
> >>
> >> pure_initcall is level 0 so it happens before all other init calls. Does it not
> >> work?
> >
> > tegra194_cbb_driver registers itself in a pure_initcall too. We wouldn't
> > want the ordering of its registration and module_kset init to be link order
> > dependent.
>
> It's the only device driver that does this. And I don't think it's supposed to.
>
> >From documentation:
>
> > A "pure" initcall has no dependencies on anything else, and purely
> > initializes variables that couldn't be statically initialized.
>
> I understand that given large amount of drivers registering themselves during
> core/arch_initcall that there might be regressions if all of them are moved, but
> surely we can demote these two specific tegra driver to core/postcore_initcall?
> This will still be called earlier than init_machine call which happens during
> arch_initcall.
>
> Looks like the tegra CBB driver is just doing error logging anyway.
That's a good point, Gary. Thanks!
Hi Thierry and Jonathan,
You can find the context for this email in this patch:
https://lore.kernel.org/all/20260427-acpi_mod_name-v4-1-22b42240c9bf@sony.com/
TL;DR: tegra194_cbb_driver and tegra234_cbb_driver are the only drivers
registering themselves as early as in a pure_initcall. This is a problem
on two fronts:
1. Philosophical: As Gary pointed out, pure_initcalls are intended to purely
initialize variables that couldn't be statically initialized. But these
are doing driver registrations.
2. module_kset not initialized at pure_initcall stage: This is needed to
set the module sysfs symlink. Since module_kset is not alive yet during
pure_initcalls, registering these drivers panics the kernel.
We would like to do the tegra cbb driver registration in a core_initcall
(or some later initcall works too), and move module_kset initialization
to a pure_initcall. Like this:
diff --git a/drivers/soc/tegra/cbb/tegra194-cbb.c b/drivers/soc/tegra/cbb/tegra194-cbb.c
index ab75d50cc85c..2f69e104c838 100644
--- a/drivers/soc/tegra/cbb/tegra194-cbb.c
+++ b/drivers/soc/tegra/cbb/tegra194-cbb.c
@@ -2342,7 +2342,7 @@ static int __init tegra194_cbb_init(void)
{
return platform_driver_register(&tegra194_cbb_driver);
}
-pure_initcall(tegra194_cbb_init);
+core_initcall(tegra194_cbb_init);
static void __exit tegra194_cbb_exit(void)
{
diff --git a/drivers/soc/tegra/cbb/tegra234-cbb.c b/drivers/soc/tegra/cbb/tegra234-cbb.c
index fb26f085f691..785072fa4e85 100644
--- a/drivers/soc/tegra/cbb/tegra234-cbb.c
+++ b/drivers/soc/tegra/cbb/tegra234-cbb.c
@@ -1774,7 +1774,7 @@ static int __init tegra234_cbb_init(void)
{
return platform_driver_register(&tegra234_cbb_driver);
}
-pure_initcall(tegra234_cbb_init);
+core_initcall(tegra234_cbb_init);
static void __exit tegra234_cbb_exit(void)
{
Would this work?
Thanks,
Shashank
^ permalink raw reply related
* Re: [PATCH v2 07/11] drm/bridge: lt9611: switch to of_drm_get_bridge_by_endpoint()
From: Gyeyoung Baek @ 2026-04-28 13:18 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tian Tao, Xinwei Kong,
Sumit Semwal, John Stultz, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Tomi Valkeinen, Michal Simek, Hui Pu, Ian Ray, Thomas Petazzoni,
dri-devel, linux-kernel, linux-arm-msm, freedreno,
linux-arm-kernel
In-Reply-To: <20260428-drm-bridge-alloc-getput-panel_or_bridge-v2-7-4300744a1c47@bootlin.com>
>
> @@ -1058,7 +1057,11 @@ static int lt9611_parse_dt(struct device *dev,
>
> lt9611->ac_mode = of_property_read_bool(dev->of_node, "lt,ac-mode");
>
> - return drm_of_find_panel_or_bridge(dev->of_node, 2, -1, NULL, <9611->next_bridge);
> + lt9611->bridge.next_bridge = of_drm_get_bridge_by_endpoint(dev->of_node, 2, -1);
> + if (IS_ERR(lt9611->bridge.next_bridge))
> + return PTR_ERR(lt9611->bridge.next_bridge);
> +
> + return 0;
> }
Hello Luca,
Could you take a look at this alternative?
------
struct drm_bridge *next_bridge =
of_drm_get_bridge_by_endpoint(dev->of_node, 2, -1);
if (IS_ERR(next_bridge))
return PTR_ERR(next_bridge);
lt9611->bridge.next_bridge = next_bridge;
return 0;
------
I think it reads a bit cleaner and avoids holding the ERR_PTR in the struct.
--
Thanks,
Gyeyoung
^ permalink raw reply
* Re: [PATCH v2 08/11] drm/bridge: adv7511: switch to of_drm_get_bridge_by_endpoint()
From: Luca Ceresoli @ 2026-04-28 13:19 UTC (permalink / raw)
To: Biju Das, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Rob Clark, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Sean Paul, Marijn Suijten, Tian Tao,
Xinwei Kong, Sumit Semwal, John Stultz, Andrzej Hajda,
Neil Armstrong, Robert Foss, laurent.pinchart, Jonas Karlman,
Jernej Skrabec, tomi.valkeinen, Michal Simek
Cc: Hui Pu, Ian Ray, Thomas Petazzoni,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <TY3PR01MB1134674FDD088299A4382D3D286372@TY3PR01MB11346.jpnprd01.prod.outlook.com>
On Tue Apr 28, 2026 at 1:58 PM CEST, Biju Das wrote:
> Hi all,
>
>> -----Original Message-----
>> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Biju Das
>> Sent: 28 April 2026 12:50
>> Subject: RE: [PATCH v2 08/11] drm/bridge: adv7511: switch to of_drm_get_bridge_by_endpoint()
>>
>>
>> Hi,
>>
>> Thanks for the patch.
>>
>> > -----Original Message-----
>> > From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>> > Luca Ceresoli
>> > Sent: 28 April 2026 10:16
>> > Subject: [PATCH v2 08/11] drm/bridge: adv7511: switch to
>> > of_drm_get_bridge_by_endpoint()
>> >
>> > This driver calls drm_of_find_panel_or_bridge() with a NULL pointer in
>> > the @panel parameter, thus using a reduced feature set of that function.
>> > Replace this call with the simpler of_drm_get_bridge_by_endpoint().
>> >
>> > Since of_drm_get_bridge_by_endpoint() increases the refcount of the
>> > returned bridge, ensure it is put on removal. To achieve this, instead
>> > of adding an explicit drm_bridge_put(), migrate to the bridge::next_bridge pointer which is
>> automatically put when the bridge is eventually freed.
>> >
>> > Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>> > ---
>> > drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 -
>> > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 11 +++++------
>> > 2 files changed, 5 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> > b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> > index 8be7266fd4f4..12c95198d9a4 100644
>> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> > @@ -354,7 +354,6 @@ struct adv7511 {
>> > enum drm_connector_status status;
>> > bool powered;
>> >
>> > - struct drm_bridge *next_bridge;
>> > struct drm_display_mode curr_mode;
>> >
>> > unsigned int f_tmds;
>> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> > index 6bd76c1fb007..498e38579a0f 100644
>> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> > @@ -851,8 +851,8 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge,
>> > struct adv7511 *adv = bridge_to_adv7511(bridge);
>> > int ret = 0;
>> >
>> > - if (adv->next_bridge) {
>> > - ret = drm_bridge_attach(encoder, adv->next_bridge, bridge,
>> > + if (adv->bridge.next_bridge) {
>> > + ret = drm_bridge_attach(encoder, adv->bridge.next_bridge, bridge,
>> > flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>> > if (ret)
>> > return ret;
>> > @@ -1251,10 +1251,9 @@ static int adv7511_probe(struct i2c_client
>> > *i2c)
>> >
>> > memset(&link_config, 0, sizeof(link_config));
>> >
>> > - ret = drm_of_find_panel_or_bridge(dev->of_node, 1, -1, NULL,
>> > - &adv7511->next_bridge);
>> > - if (ret && ret != -ENODEV)
>> > - return ret;
>> > + adv7511->bridge.next_bridge = of_drm_get_bridge_by_endpoint(dev->of_node, 1, -1);
>> > + if (IS_ERR(adv7511->bridge.next_bridge) && PTR_ERR(adv7511->bridge.next_bridge) != -ENODEV)
>> > + return PTR_ERR(adv7511->bridge.next_bridge);
>>
>> Does it crash, if the error is -EPROBE_DEFER?
>
> I see a crash with patch [1], which is fixed by avoiding the direct assignment.
Ah, dammit! Good catch, thanks for the quick testing and follow-up!
Indeed this driver assumes next_bridge is either NULL or a valid pointer,
but due to the 'if(IS_ERR() && some_other_condition)' now it can also be
-ENODEV (not -EPROBE_DEFER, but that's irrelevant).
This affects the msm and zynqmp_dp patches equally.
I'm sending a v3 soon with these fixed. I'm just not sure which approach to
use to fix (same for all the 3 patches). Alternatives are:
1. -ENODEV is accepted, set next_bridge to NULL when it happens:
- if (IS_ERR(adv7511->bridge.next_bridge) && PTR_ERR(adv7511->bridge.next_bridge) != -ENODEV)
- return PTR_ERR(adv7511->bridge.next_bridge);
+ if (IS_ERR(adv7511->bridge.next_bridge)) {
+ if (PTR_ERR(adv7511->bridge.next_bridge) == -ENODEV)
+ adv7511->bridge.next_bridge = NULL;
+ else
+ return PTR_ERR(adv7511->bridge.next_bridge);
+ }
2. let nexxt_bridge hold -ENODEV but ignore it when it is used (only in
the attach op, for all 3 drivers):
- if (adv->bridge.next_bridge) {
+ if (!IS_ERR_OR_NULL(adv->bridge.next_bridge)) {
While the latter approach involves less code, it might let errors sneak in
in case new usages of next_bridge are added with just a NULL check.
Opinions about the two?
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Yeoreum Yun @ 2026-04-28 13:21 UTC (permalink / raw)
To: Paul Moore
Cc: Mimi Zohar, roberto.sassu, Jonathan McDowell,
linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, jmorris, serge, dmitry.kasatkin,
eric.snowberg, jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <CAHC9VhS_WgwhW_NDO91LoTeSzdieGqbwqnwPq8KpavH1_Lwi7g@mail.gmail.com>
Hi Paul,
> On Fri, Apr 24, 2026 at 6:49 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Fri, 2026-04-24 at 18:10 -0400, Paul Moore wrote:
> > > (I'm assuming you meant initcall and not syscall above, but if you're
> > > talking about something else, please let me know.)
> > >
> > > Saying that you aren't comfortable moving IMA initialization to
> > > late-sync is inconsistent with allowing IMA initialization to be
> > > deferred to late-sync. Either it is okay to initialize IMA in
> > > late-sync or it isn't. You must pick one.
> >
> > Yes, we're discussing late_initcall and late_initcall_sync.
> >
> > I prefer to look at it as being pragmatic. I'd rather err on the side of caution
> > and not move the syscall to late_initcall_sync, than move it.
>
> If you were truly erring on the side of caution you wouldn't allow
> late-sync initialization without knowing if it was safe or not.
> Determine whether IMA initialization is safe at late-sync. If it is
> safe, move the init to late-sync; if not, keep it at late and figure
> out another mechanism to sync with the TPM availability. If needed,
> you could probably use the LSM notifier to enable the TPM driver to
> signal when it is up and running.
I don't think LSM notifier wouldn't be good since it a one time
notification for initailisation and it wouldn't tell properly
whehter TPM isn't present in system or present unless functions
ima_init() are rewritten to discern the "TPM deferred" and
"TPM doesn't exist" in the system (e.x) boot-aggregate log creation.
One question, though.
In the end, for systems where the TPM has already been probed by late_initcall(),
init_ima() continues to be called at late_initcall(), while the above approach
is introduced for systems where the TPM is not properly initialized by that point.
If init_ima(), which used to be called at late_initcall(),
were instead called at late_initcall_sync(), could this break system integration?
In my view, both late_initcall and late_initcall_sync run during the do_basic_setup() phase,
so it doesn’t seem like this would cause tampering or affect things like the creation of the boot-aggregate log.
Is there any particular reason why init_ima() must be called specifically at late_initcall()?
Thanks.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH v2] crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A
From: Marek Behún @ 2026-04-28 13:24 UTC (permalink / raw)
To: Thorsten Blum
Cc: Marek Behún, Bill Cox, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Linus Walleij,
Ard Biesheuvel, stable, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <afCo9PbDpTYeqGd4@linux.dev>
Hi Thorsten,
Bill also wrote about ATSHA204A [1]
My best guess as to what's going on here is that the device has a
ring-oscillator based entropy source, but that it generates only a few bits
of entropy for each use. It seems to be called before generating each
32-byte "random" value, which is why the second set of 32-bit values have
more possible values, and the 3rd has even more. However, the number of
unique values in the final column of 32*N byte values is always equal to
the number of unique values of the entire string of bytes.
If this is true that the device generates <256 true random bits and then
mixes in non-volatile pseudorandom number generator to produce 256 bits,
then the quality should not be set to full 1024.
Marek
[1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html
On Tue, Apr 28, 2026 at 02:32:52PM +0200, Thorsten Blum wrote:
>
> Bill wrote in his review:
>
> "If I made no mistake (and I do make a lot), the "random" data from
> the Atmel ATSHA204A is highly predictable when you disable the seed
> update to EEPROM."
>
> However, the atmel-sha204a driver doesn't operate the device in that
> mode. It uses the Random command with seed updates enabled, which is
> also what the datasheet recommends for highest security:
>
> "Microchip recommends that the EEPROM seed always be updated."
>
> So the reported behavior doesn't reflect how the driver uses the device.
>
> Thanks,
> Thorsten
^ permalink raw reply
* Re: [PATCH net] net: airoha: Move entries to queue head in case of DMA mapping failure in airoha_dev_xmit()
From: Paolo Abeni @ 2026-04-28 13:25 UTC (permalink / raw)
To: Lorenzo Bianconi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Jacob Keller
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260428-airoha-xmit-unmap-error-path-v1-1-aec44c6765c1@kernel.org>
On 4/28/26 10:44 AM, Lorenzo Bianconi wrote:
> In order to respect the original descriptor order and avoid any
> potential IOMMU fault or memory corruption, move pending queue entries
> to the head of hw queue tx_list if the DMA mapping of current inflight
> packet fails in airoha_dev_xmit routine.
>
> Fixes: 3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order DMA tx descriptors")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 5effb4a4ae84..82018a085e46 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2123,14 +2123,14 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> return NETDEV_TX_OK;
>
> error_unmap:
> - while (!list_empty(&tx_list)) {
> + list_for_each_entry(e, &tx_list, list) {
> e = list_first_entry(&tx_list, struct airoha_queue_entry,
> list);
Coccinelle says:
+/srv/nipa-builds-contest/testing/wt-cocci/drivers/net/ethernet/airoha/airoha_eth.c:2123:1-20:
iterator with update on line 2124
I guess you should additionally drop the statement above.
/P
^ permalink raw reply
* [RESEND PATCH v2 2/2] PCI: mvebu: Keep child node refcnt for probe duration
From: Krzysztof Kozlowski @ 2026-04-28 13:27 UTC (permalink / raw)
To: Thomas Petazzoni, Pali Rohár, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-arm-kernel, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260428132708.95998-3-krzysztof.kozlowski@oss.qualcomm.com>
Driver in probe() first iterates over child device nodes, storing the OF
node pointer but does not take the reference to it for the remaining
part of the probe where it is used.
The pointer thus could become invalid if children OF nodes are being
removed from the Devicetree, e.g. by removing OF overlay, while the
probe is being executed. That's is highly theoretical issue, thus it
does not look like bug with any effect.
Nevertheless, make the code logically correct, so acquire the OF node
refcnt for entire lifetime of the device, since the pointer is stored in
each port state container structure.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v2:
1. New patch
Note: Not a fix, because practical impact is absolutely zero since
of_node_get is a noop.
---
drivers/pci/controller/pci-mvebu.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 4d3c97b62fe0..7fb9c7393588 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -1236,6 +1236,11 @@ static void mvebu_pcie_port_clk_put(void *data)
clk_put(port->clk);
}
+static void mvebu_pcie_port_of_node_put(void *data)
+{
+ of_node_put(data);
+}
+
static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
struct mvebu_pcie_port *port, struct device_node *child)
{
@@ -1482,7 +1487,11 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
else if (ret == 0)
continue;
- port->dn = child;
+ port->dn = of_node_get(child);
+ ret = devm_add_action_or_reset(dev, mvebu_pcie_port_of_node_put,
+ child);
+ if (ret)
+ return ret;
i++;
}
pcie->nports = i;
--
2.51.0
^ permalink raw reply related
* [RESEND PATCH v2 1/2] PCI: mvebu: Simplify with scoped for each OF child loop
From: Krzysztof Kozlowski @ 2026-04-28 13:27 UTC (permalink / raw)
To: Thomas Petazzoni, Pali Rohár, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-arm-kernel, linux-kernel
Cc: Krzysztof Kozlowski
Use scoped for-each loop when iterating over device nodes to make code a
bit simpler.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v2:
None
v1:
https://lore.kernel.org/all/20260102124900.64528-4-krzysztof.kozlowski@oss.qualcomm.com/
---
drivers/pci/controller/pci-mvebu.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index a72aa57591c0..4d3c97b62fe0 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -1452,7 +1452,6 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
struct mvebu_pcie *pcie;
struct pci_host_bridge *bridge;
struct device_node *np = dev->of_node;
- struct device_node *child;
int num, i, ret;
bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct mvebu_pcie));
@@ -1474,16 +1473,14 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
return -ENOMEM;
i = 0;
- for_each_available_child_of_node(np, child) {
+ for_each_available_child_of_node_scoped(np, child) {
struct mvebu_pcie_port *port = &pcie->ports[i];
ret = mvebu_pcie_parse_port(pcie, port, child);
- if (ret < 0) {
- of_node_put(child);
+ if (ret < 0)
return ret;
- } else if (ret == 0) {
+ else if (ret == 0)
continue;
- }
port->dn = child;
i++;
@@ -1493,6 +1490,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
for (i = 0; i < pcie->nports; i++) {
struct mvebu_pcie_port *port = &pcie->ports[i];
int irq = port->intx_irq;
+ struct device_node *child;
child = port->dn;
if (!child)
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v4 2/3] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
From: Marc Zyngier @ 2026-04-28 13:31 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: linux-kernel, iommu, linux-coco, linux-arm-kernel, kvmarm,
Catalin Marinas, Jason Gunthorpe, Marek Szyprowski, Robin Murphy,
Steven Price, Suzuki K Poulose, Thomas Gleixner, Will Deacon
In-Reply-To: <yq5aa4un1dju.fsf@kernel.org>
On Tue, 28 Apr 2026 13:20:53 +0100,
Aneesh Kumar K.V <aneesh.kumar@kernel.org> wrote:
>
> Marc Zyngier <maz@kernel.org> writes:
>
> > On Mon, 27 Apr 2026 07:31:07 +0100,
> > "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org> wrote:
> >>
> >> When running private-memory guests, the guest kernel must apply additional
> >> constraints when allocating buffers that are shared with the hypervisor.
> >>
> >> These shared buffers are also accessed by the host kernel and therefore
> >> must be aligned to the host’s page size, and have a size that is a multiple
> >> of the host page size.
> >>
> >> On non-secure hosts, set_guest_memory_attributes() tracks memory at the
> >> host PAGE_SIZE granularity. This creates a mismatch when the guest applies
> >> attributes at 4K boundaries while the host uses 64K pages. In such cases,
> >> set_guest_memory_attributes() call returns -EINVAL, preventing the
> >> conversion of memory regions from private to shared.
> >>
> >> Architectures such as Arm can tolerate realm physical address space
> >> (protected memory) PFNs being mapped as shared memory, as incorrect
> >> accesses are detected and reported as GPC faults. However, relying on this
> >> mechanism is unsafe and can still lead to kernel crashes.
> >>
> >> This is particularly likely when guest_memfd allocations are mmapped and
> >> accessed from userspace. Once exposed to userspace, we cannot guarantee
> >> that applications will only access the intended 4K shared region rather
> >> than the full 64K page mapped into their address space. Such userspace
> >> addresses may also be passed back into the kernel and accessed via the
> >> linear map, resulting in a GPC fault and a kernel crash.
> >>
> >> With CCA, although Stage-2 mappings managed by the RMM still operate at a
> >> 4K granularity, shared pages must nonetheless be aligned to the
> >> host-managed page size and sized as whole host pages to avoid the issues
> >> described above.
> >
> > I thought that was being fixed, and that there was now a strong
> > guarantee that RMM and host are aligned on the page size. Even more,
> > S2 is totally irrelevant here. The only thing that matters is the host
> > page size vs the guest page size. Nothing else.
> >
>
> Yes, the latest RMM update includes the ability to change the granule
> size.
>
> The section above in the commit message was intended to explain that the
> S2 mapping size is irrelevant. I agree it is not clear as written, so I
> will reword it to improve clarity.
Even better, remove it. Nothing CCA-specific should be in this patch.
[...]
> >> static struct gen_pool *itt_pool;
> >> @@ -268,11 +272,13 @@ static void *itt_alloc_pool(int node, int size)
> >> if (addr)
> >> break;
> >>
> >> - page = its_alloc_pages_node(node, GFP_KERNEL | __GFP_ZERO, 0);
> >> + page = its_alloc_pages_node(node, GFP_KERNEL | __GFP_ZERO,
> >> + get_order(mem_decrypt_granule_size()));
> >
> > You already taught its_alloc_pages_node() about the decrypt granule
> > size stuff. I don't think we need to see more of it (and you don't
> > mess with the call that is just above it).
> >
> >> if (!page)
> >> break;
> >>
> >> - gen_pool_add(itt_pool, (unsigned long)page_address(page), PAGE_SIZE, node);
> >> + gen_pool_add(itt_pool, (unsigned long)page_address(page),
> >> + mem_decrypt_granule_size(), node);
> >
> > I'd rather see something like mem_decrypt_align(PAGE_SIZE), which
> > keeps the intent clear.
> >
>
> The helper was added based on feedback from a previous version. I assume
> you are suggesting that only this caller should switch?
I don't know what you mean by 'this'. What I'd like to see is this
last hunk be changed to:
gen_pool_add(itt_pool, (unsigned long)page_address(page),
mem_decrypt_align(PAGE_SIZE), node);
and the previous hunk simply dropped.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* RE: [PATCH v2 08/11] drm/bridge: adv7511: switch to of_drm_get_bridge_by_endpoint()
From: Biju Das @ 2026-04-28 13:31 UTC (permalink / raw)
To: Luca Ceresoli, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Tian Tao, Xinwei Kong, Sumit Semwal, John Stultz,
Andrzej Hajda, Neil Armstrong, Robert Foss, laurent.pinchart,
Jonas Karlman, Jernej Skrabec, tomi.valkeinen, Michal Simek
Cc: Hui Pu, Ian Ray, Thomas Petazzoni,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <DI4TGV2WURTY.39OXE7WWKRLA1@bootlin.com>
Hi Luca,
> -----Original Message-----
> From: Luca Ceresoli <luca.ceresoli@bootlin.com>
> Sent: 28 April 2026 14:20
> Subject: Re: [PATCH v2 08/11] drm/bridge: adv7511: switch to of_drm_get_bridge_by_endpoint()
>
> On Tue Apr 28, 2026 at 1:58 PM CEST, Biju Das wrote:
> > Hi all,
> >
> >> -----Original Message-----
> >> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf
> >> Of Biju Das
> >> Sent: 28 April 2026 12:50
> >> Subject: RE: [PATCH v2 08/11] drm/bridge: adv7511: switch to
> >> of_drm_get_bridge_by_endpoint()
> >>
> >>
> >> Hi,
> >>
> >> Thanks for the patch.
> >>
> >> > -----Original Message-----
> >> > From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf
> >> > Of Luca Ceresoli
> >> > Sent: 28 April 2026 10:16
> >> > Subject: [PATCH v2 08/11] drm/bridge: adv7511: switch to
> >> > of_drm_get_bridge_by_endpoint()
> >> >
> >> > This driver calls drm_of_find_panel_or_bridge() with a NULL pointer
> >> > in the @panel parameter, thus using a reduced feature set of that function.
> >> > Replace this call with the simpler of_drm_get_bridge_by_endpoint().
> >> >
> >> > Since of_drm_get_bridge_by_endpoint() increases the refcount of the
> >> > returned bridge, ensure it is put on removal. To achieve this,
> >> > instead of adding an explicit drm_bridge_put(), migrate to the
> >> > bridge::next_bridge pointer which is
> >> automatically put when the bridge is eventually freed.
> >> >
> >> > Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> >> > ---
> >> > drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 -
> >> > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 11 +++++------
> >> > 2 files changed, 5 insertions(+), 7 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> >> > b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> >> > index 8be7266fd4f4..12c95198d9a4 100644
> >> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> >> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> >> > @@ -354,7 +354,6 @@ struct adv7511 {
> >> > enum drm_connector_status status;
> >> > bool powered;
> >> >
> >> > - struct drm_bridge *next_bridge;
> >> > struct drm_display_mode curr_mode;
> >> >
> >> > unsigned int f_tmds;
> >> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> > index 6bd76c1fb007..498e38579a0f 100644
> >> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> > @@ -851,8 +851,8 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge,
> >> > struct adv7511 *adv = bridge_to_adv7511(bridge);
> >> > int ret = 0;
> >> >
> >> > - if (adv->next_bridge) {
> >> > - ret = drm_bridge_attach(encoder, adv->next_bridge, bridge,
> >> > + if (adv->bridge.next_bridge) {
> >> > + ret = drm_bridge_attach(encoder, adv->bridge.next_bridge,
> >> > +bridge,
> >> > flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> >> > if (ret)
> >> > return ret;
> >> > @@ -1251,10 +1251,9 @@ static int adv7511_probe(struct i2c_client
> >> > *i2c)
> >> >
> >> > memset(&link_config, 0, sizeof(link_config));
> >> >
> >> > - ret = drm_of_find_panel_or_bridge(dev->of_node, 1, -1, NULL,
> >> > - &adv7511->next_bridge);
> >> > - if (ret && ret != -ENODEV)
> >> > - return ret;
> >> > + adv7511->bridge.next_bridge = of_drm_get_bridge_by_endpoint(dev->of_node, 1, -1);
> >> > + if (IS_ERR(adv7511->bridge.next_bridge) && PTR_ERR(adv7511->bridge.next_bridge) != -ENODEV)
> >> > + return PTR_ERR(adv7511->bridge.next_bridge);
> >>
> >> Does it crash, if the error is -EPROBE_DEFER?
> >
> > I see a crash with patch [1], which is fixed by avoiding the direct assignment.
>
> Ah, dammit! Good catch, thanks for the quick testing and follow-up!
>
> Indeed this driver assumes next_bridge is either NULL or a valid pointer, but due to the 'if(IS_ERR()
> && some_other_condition)' now it can also be -ENODEV (not -EPROBE_DEFER, but that's irrelevant).
>
> This affects the msm and zynqmp_dp patches equally.
>
> I'm sending a v3 soon with these fixed. I'm just not sure which approach to use to fix (same for all
> the 3 patches). Alternatives are:
>
> 1. -ENODEV is accepted, set next_bridge to NULL when it happens:
>
> - if (IS_ERR(adv7511->bridge.next_bridge) && PTR_ERR(adv7511->bridge.next_bridge) != -
> ENODEV)
> - return PTR_ERR(adv7511->bridge.next_bridge);
> + if (IS_ERR(adv7511->bridge.next_bridge)) {
> + if (PTR_ERR(adv7511->bridge.next_bridge) == -ENODEV)
> + adv7511->bridge.next_bridge = NULL;
> + else
> + return PTR_ERR(adv7511->bridge.next_bridge);
The point is you cannot return PTR_ERR as it will lead to crash, if it is
direct assignment.
if (IS_ERR(adv7511->bridge.next_bridge)) {
int err = PTR_ERR(adv7511->bridge.next_bridge);
adv7511->bridge.next_bridge = NULL;
return err;
}
Cheers,
Biju
> 2. let nexxt_bridge hold -ENODEV but ignore it when it is used (only in
> the attach op, for all 3 drivers):
>
> - if (adv->bridge.next_bridge) {
> + if (!IS_ERR_OR_NULL(adv->bridge.next_bridge)) {
>
> While the latter approach involves less code, it might let errors sneak in in case new usages of
> next_bridge are added with just a NULL check.
>
> Opinions about the two?
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* Re: [PATCH 5/5] remoteproc: imx: use device node name as processor name
From: Daniel Baluta @ 2026-04-28 13:36 UTC (permalink / raw)
To: Jiafei Pan, andersson, mathieu.poirier, peng.fan, Frank.Li,
s.hauer, kernel, festevam, imx, linux-arm-kernel, linux-kernel
Cc: Zhiqiang.Hou, mingkai.hu
In-Reply-To: <20260428090819.17761-6-Jiafei.Pan@nxp.com>
On 4/28/26 12:08, Jiafei Pan wrote:
> [You don't often get email from jiafei.pan@nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> As currently there are maybe multiple remote processors, so change from
> using fixed name to using device node name as remote processor name in
> order to make them can be distinguished by through of name in sys
> filesystem.
>
> Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index e8d239bef5c9..17026e390e88 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -1357,7 +1357,7 @@ static int imx_rproc_probe(struct platform_device *pdev)
> int ret;
>
> /* set some other name then imx */
I think you can also remove the comment above.
> - rproc = devm_rproc_alloc(dev, "imx-rproc", &imx_rproc_ops,
> + rproc = devm_rproc_alloc(dev, np->name, &imx_rproc_ops,
> NULL, sizeof(*priv));
> if (!rproc)
> return -ENOMEM;
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH] pwm: atmel-tcb: Remove unneeded semicolon
From: Uwe Kleine-König @ 2026-04-28 13:36 UTC (permalink / raw)
To: Chen Ni
Cc: nicolas.ferre, alexandre.belloni, claudiu.beznea, linux-pwm,
linux-arm-kernel
In-Reply-To: <20260428075329.1234735-1-nichen@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 474 bytes --]
Hello,
On Tue, Apr 28, 2026 at 03:53:29PM +0800, Chen Ni wrote:
> - goto err_disable_clk;;
> + goto err_disable_clk;
Oh, that is my fault. If you're ok I'd add
This was introduced in commit 68637b68afcc ("pwm: atmel-tcb:
Cache clock rates and mark chip as atomic") in Uwe's adaption of
Sangyun's original patch.
to the commit log. I'll apply it then to my fixes branch but not send it
to Linus. But if something more urgent pops up I'll send it along.
Thanks,
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64/entry: Fix arm64-specific rseq brokenness
From: Mark Rutland @ 2026-04-28 13:40 UTC (permalink / raw)
To: Jinjie Ruan
Cc: Mathias Stearn, Linus Torvalds, Catalin Marinas, Will Deacon,
Thomas Gleixner, Mathieu Desnoyers, Peter Zijlstra, Boqun Feng,
Paul E. McKenney, Chris Kennelly, Dmitry Vyukov, regressions,
linux-kernel, linux-arm-kernel, Ingo Molnar, Blake Oler
In-Reply-To: <21b50a60-0cbf-43ee-b6d1-318cba206aea@huawei.com>
On Tue, Apr 28, 2026 at 09:39:56AM +0800, Jinjie Ruan wrote:
> On 4/25/2026 12:45 AM, Mark Rutland wrote:
> > From 79b65cbbfa20aa2cb0bc248591fab5459cdc101b Mon Sep 17 00:00:00 2001
> > From: Mark Rutland <mark.rutland@arm.com>
> > Date: Thu, 23 Apr 2026 16:51:12 +0100
> > Subject: [PATCH] arm64/entry: Fix arm64-specific rseq brokenness
> >
> > Mathias Stearn reports that since v6.19, there are two big issues
> > affecting rseq:
> >
> > (1) On arm64 specifically, rseq critical sections aren't aborted when
> > they should be.
> >
> > (2) The 'cpu_id_start' field is no longer written by the kernel in all
> > cases it used to be, including some cases where TCMalloc depends on
> > the kernel clobbering the field.
> >
> > This patch fixes issue #1. This patch DOES NOT fix issue #2, which will
> > need to be addressed by other patches.
> >
> > The arm64-specific brokenness is a result of commits:
> >
> > 2fc0e4b4126c ("rseq: Record interrupt from user space")
> > 39a167560a61 ("rseq: Optimize event setting")
> >
> > The first commit failed to add a call to rseq_note_user_irq_entry() on
> > arm64. Thus arm64 never sets rseq_event::user_irq to record that it may
> > be necessary to abort an active rseq critical section upon return to
> > userspace. On its own, this commit had no functional impact as the value
> > of rseq_event::user_irq was not consumed.
> >
> > The second commit relied upon rseq_event::user_irq to determine whether
> > or not to bother to perform rseq work when returning to userspace. As
> > rseq_event::user_irq wasn't set on arm64, this work would be skipped,
> > and consequently an active rseq critical section would not be aborted.
> >
> > Fix this by giving arm64 syscall-specific entry/exit paths, and
> > performing the relevant logic in syscall and non-syscall paths,
> > including calling rseq_note_user_irq_entry() for non-syscall entry.
> >
> > Currently arm64 cannot use syscall_enter_from_user_mode(),
> > syscall_exit_to_user_mode(), and irqentry_exit_to_user_mode(), due to
> > ordering constraints with exception masking, and risk of ABI breakage
> > for syscall tracing/audit/etc. For the moment the entry/exit logic is
> > left as arm64-specific, but mirroring the generic code.
> >
> > I intend to follow up with refactoring/cleanup, as we did for kernel
> > mode entry paths in commit:
> >
> > 041aa7a85390 ("entry: Split preemption from irqentry_exit_to_kernel_mode()")
> >
> > ... which will allow arm64 to use the GENERIC_IRQ_ENTRY functions directly.
> >
> > Fixes: 39a167560a61 ("rseq: Optimize event setting")
> > Reported-by: Mathias Stearn <mathias@mongodb.com>
> > Link: https://lore.kernel.org/regressions/CAHnCjA25b+nO2n5CeifknSKHssJpPrjnf+dtr7UgzRw4Zgu=oA@mail.gmail.com/
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Chris Kennelly <ckennelly@google.com>
> > Cc: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Will Deacon <will@kernel.org>
> > ---
> > arch/arm64/kernel/entry-common.c | 29 ++++++++++++++++++++++-------
> > include/linux/irq-entry-common.h | 8 --------
> > include/linux/rseq_entry.h | 19 -------------------
> > 3 files changed, 22 insertions(+), 34 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> > index cb54335465f66..65ade1f1544f6 100644
> > --- a/arch/arm64/kernel/entry-common.c
> > +++ b/arch/arm64/kernel/entry-common.c
> > @@ -62,6 +62,12 @@ static void noinstr arm64_exit_to_kernel_mode(struct pt_regs *regs,
> > irqentry_exit_to_kernel_mode_after_preempt(regs, state);
> > }
> >
> > +static __always_inline void arm64_syscall_enter_from_user_mode(struct pt_regs *regs)
> > +{
> > + enter_from_user_mode(regs);
> > + mte_disable_tco_entry(current);
>
> Did we skip sme_enter/exit_from_user_mode() on the syscall path on
> purpose? Not very familiar with ARM64 SME.
> > +}
That was by accident. I originally wrote the fix on a kernel that lacked
those functions, and I missed them when rebasing the fix.
I'll go fix that up for v2.
> > +
> > /*
> > * Handle IRQ/context state management when entering from user mode.
> > * Before this function is called it is not safe to call regular kernel code,
> > @@ -70,20 +76,29 @@ static void noinstr arm64_exit_to_kernel_mode(struct pt_regs *regs,
> > static __always_inline void arm64_enter_from_user_mode(struct pt_regs *regs)
> > {
> > enter_from_user_mode(regs);
> > + rseq_note_user_irq_entry();
>
> Can we just use irqentry_enter_from_user_mode() instead?
I've deliberately used enter_from_user_mode() here to keep things
balanced (i.e. enter_from_user_mode() pairs directly with
exit_to_user_mode()). We cannot use irqentry_exit_to_user_mode() as
explained in the commit message.
I'll update the commit message to make that a bit clearer.
[...]
> Otherwise, looks fine to me.
Great; thanks for taking a look.
Mark.
^ permalink raw reply
* Re: [PATCH 6/8] KVM: arm64: Propagate stage-2 map failure on host->guest donation
From: Will Deacon @ 2026-04-28 13:45 UTC (permalink / raw)
To: Fuad Tabba
Cc: maz, oliver.upton, james.morse, suzuki.poulose, yuzenghui,
qperret, vdonnefort, catalin.marinas, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <20260428103008.696141-7-tabba@google.com>
On Tue, Apr 28, 2026 at 11:30:06AM +0100, Fuad Tabba wrote:
> __pkvm_host_donate_guest() flips the host stage-2 PTE for the donated
> page to a non-valid annotation (KVM_HOST_INVALID_PTE_TYPE_DONATION,
> owner = PKVM_ID_GUEST) via host_stage2_set_owner_metadata_locked()
> and then calls kvm_pgtable_stage2_map() to install the matching guest
> stage-2 mapping. The map's return value was wrapped in WARN_ON() and
> otherwise discarded.
>
> At EL2 in nVHE/pKVM, WARN_ON() is not warn-and-continue: it expands
> to a BRK that enters the invalid-host-el2 vector and branches to
> hyp_panic(), declared __noreturn. WARN_ON of a reachable failure at
> EL2 is a panic primitive, not a debug aid.
>
> kvm_pgtable_stage2_map() can fail in reachable ways even at PAGE_SIZE
> granularity: __pkvm_host_donate_guest() verifies PKVM_NOPAGE for the
> guest IPA before the map, meaning no valid stage-2 entry exists. The
> walker must allocate new page-table pages from the vcpu memcache to
> install the mapping, returning -ENOMEM if exhausted. The host
> controls the vcpu memcache via the topup interface, so an
> under-provisioned donation request converts a recoverable error into
> a fatal hyp panic.
>
> Capture the stage-2 map return value and propagate it. The walker
> may have installed partial leaf entries for the IPA before failing,
> so unmap the range to clear them; otherwise the guest would retain
> stage-2 access to a page the host is about to reclaim as
> PKVM_PAGE_OWNED. Then roll back the host stage-2 mutation: the only
> forward mutation is host_stage2_set_owner_metadata_locked() flipping
> the host vmemmap from PKVM_PAGE_OWNED to PKVM_NOPAGE and the host
> stage-2 PTE from idmap to invalid+annotation.
> host_stage2_set_owner_locked(_, _, PKVM_ID_HOST) restores both.
>
> The rollback calls host_stage2_set_owner_locked() under WARN_ON.
> This is the correct use: host_stage2_set_owner_metadata_locked()
> just wrote the host leaf PTE as an invalid+annotation entry, so the
> reverse idmap rewrite cannot require new page-table allocation — it
> rewrites the leaf in-place. The WARN_ON asserts an impossible state
> under correct EL2 execution, semantically distinct from the misuse
> being fixed.
>
> Fixes: 1e579adca177 ("KVM: arm64: Introduce __pkvm_host_donate_guest()")
> Signed-off-by: Fuad Tabba <tabba@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/mem_protect.c | 27 ++++++++++++++++++++++++---
> 1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index 7044913a0758..b8c57a95e9bf 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -1391,9 +1391,30 @@ int __pkvm_host_donate_guest(u64 pfn, u64 gfn, struct pkvm_hyp_vcpu *vcpu)
> meta = host_stage2_encode_gfn_meta(vm, gfn);
> WARN_ON(host_stage2_set_owner_metadata_locked(phys, PAGE_SIZE,
> PKVM_ID_GUEST, meta));
> - WARN_ON(kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys,
> - pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_OWNED),
> - &vcpu->vcpu.arch.pkvm_memcache, 0));
> + ret = kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys,
> + pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_OWNED),
> + &vcpu->vcpu.arch.pkvm_memcache, 0);
> + if (ret) {
> + /*
> + * Stage-2 map can fail mid-walk (e.g. -ENOMEM from the
> + * memcache), leaving partial leaf entries installed in the
> + * guest stage-2. Tear them down before rolling back the host
> + * stage-2; otherwise the guest would retain access to a page
> + * the host is about to reclaim as PKVM_PAGE_OWNED.
> + */
> + kvm_pgtable_stage2_unmap(&vm->pgt, ipa, PAGE_SIZE);
Whoa, whoa, whoa.
First of all, this is mapping a single page, so the comment talking about
"leaf entries" (plural) is bogus. If an operation to map a single page
fails, then it makes no sense to try unmapping the mapping which we
failed to create. What do you expect it to do?
On the other hand, if we extend this to handle ranges in future (which
presumably we'll want as part of the THP support) then wouldn't this
mean that a concurrent vCPU could have transiently written to the pages
that _did_ get mapped, and now we're going to give those back to the
host? That's really not ok! We're relying on these WARN_ON()s being
fatal and they shouldn't fail because we perform all the permission
checks first, in a separate pass.
If you want to improve this, then I think the options are either:
1. Check that the the memcache is topped up first
2. Poison the page (similar to the forced-reclaim path)
3. Tell the host about the pages it's lost and maybe it can leak them
(I vote for (1))
But we absolutely cannot do the simple rollback for the ownership
changes; that's why the code is written to do the checks up-front. Your
other patches at the end of this series have different flavours of the
same issue.
If it's just about keeping the LLM happy, then either fix the LLM or
make these BUG_ON() (in conjunction with (1) above).
Will
^ permalink raw reply
* Re: [PATCH 3/5] drivers: remoteproc: imx: add autoboot support for A-core remoteproc
From: Daniel Baluta @ 2026-04-28 13:49 UTC (permalink / raw)
To: Jiafei Pan, andersson, mathieu.poirier, peng.fan, Frank.Li,
s.hauer, kernel, festevam, imx, linux-arm-kernel, linux-kernel
Cc: Zhiqiang.Hou, mingkai.hu
In-Reply-To: <20260428090819.17761-4-Jiafei.Pan@nxp.com>
On 4/28/26 12:08, Jiafei Pan wrote:
> [You don't often get email from jiafei.pan@nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
>
> Add autoboot support for Cortex-A Core remoteproc.
>
> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Please also add your Signed-off-by tag here.
See: https://developercertificate.org/
^ 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