* 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 v4 02/15] mm: Make empty_zero_page __ro_after_init
From: Mike Rapoport @ 2026-04-28 12:27 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-kernel, will, catalin.marinas,
mark.rutland, Ard Biesheuvel, Ryan Roberts, Anshuman Khandual,
Liz Prucka, Seth Jenkins, Kees Cook, David Hildenbrand,
Andrew Morton, linux-mm, linux-hardening
In-Reply-To: <20260427153416.2103979-19-ardb+git@google.com>
On Mon, Apr 27, 2026 at 05:34:19PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> The empty zero page is used to back any kernel or user space mapping
> that is supposed to remain cleared, and so the page itself is never
> supposed to be modified.
>
> So make it __ro_after_init rather than __page_aligned_bss: on most
> architectures, this ensures that both the kernel's mapping of it and any
> aliases that are accessible via the kernel direct (linear) map are
> mapped read-only, and cannot be used (inadvertently or maliciously) to
> corrupt the contents of the zero page.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> mm/mm_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/mm_init.c b/mm/mm_init.c
> index f9f8e1af921c..6ca01ed2a5a4 100644
> --- a/mm/mm_init.c
> +++ b/mm/mm_init.c
> @@ -57,7 +57,7 @@ unsigned long zero_page_pfn __ro_after_init;
> EXPORT_SYMBOL(zero_page_pfn);
>
> #ifndef __HAVE_COLOR_ZERO_PAGE
> -uint8_t empty_zero_page[PAGE_SIZE] __page_aligned_bss;
> +uint8_t empty_zero_page[PAGE_SIZE] __ro_after_init __aligned(PAGE_SIZE);
> EXPORT_SYMBOL(empty_zero_page);
>
> struct page *__zero_page __ro_after_init;
> --
> 2.54.0.rc2.544.gc7ae2d5bb8-goog
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v4 2/3] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
From: Aneesh Kumar K.V @ 2026-04-28 12:22 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-kernel, iommu, linux-coco, linux-arm-kernel, kvmarm,
Catalin Marinas, Marc Zyngier, Marek Szyprowski, Robin Murphy,
Steven Price, Suzuki K Poulose, Thomas Gleixner, Will Deacon
In-Reply-To: <20260427134903.GA740385@ziepe.ca>
Jason Gunthorpe <jgg@ziepe.ca> writes:
> On Mon, Apr 27, 2026 at 12:01:07PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> When running private-memory guests, the guest kernel must apply additional
>> constraints when allocating buffers that are shared with the hypervisor.
>
> This patch has way too much stuff in it.
>
> I think your patch structure should be changed around
>
> 1) Patch to add mem_decrypt_granule_size(), and explain it as
> the alignment & size of what can be passed to
> set_memory_encrypted/decrypted()
>
> 2) Add support for mem_decrypt_granule_size() to ARM
>
> Then patches going caller by caller of set_memory_decrypted() to make
> them follow the new rule:
>
> 3) its
>
> 4) swiotlb
>
> 3) dma_alloc_coherent
>
> etc.
>
> don't forget about the new dma buf heaps too:
>
> drivers/dma-buf/heaps/system_heap.c: ret = set_memory_decrypted(addr, nr_pages);
>
> It is worth calling out in the cover letter that all the ARM CCA
> relevant places are fixed but drivers/hv/ is left for future.
>
>> @@ -33,18 +32,30 @@ int arm64_mem_crypt_ops_register(const struct arm64_mem_crypt_ops *ops)
>>
>> int set_memory_encrypted(unsigned long addr, int numpages)
>> {
>> - if (likely(!crypt_ops) || WARN_ON(!PAGE_ALIGNED(addr)))
>> + if (likely(!crypt_ops))
>> return 0;
>>
>> + if (WARN_ON(!IS_ALIGNED(addr, mem_decrypt_granule_size())))
>> + return -EINVAL;
>> +
>> + if (WARN_ON(!IS_ALIGNED(numpages << PAGE_SHIFT, mem_decrypt_granule_size())))
>> + return -EINVAL;
>> +
>> return crypt_ops->encrypt(addr, numpages);
>> }
>> EXPORT_SYMBOL_GPL(set_memory_encrypted);
>>
>> int set_memory_decrypted(unsigned long addr, int numpages)
>> {
>> - if (likely(!crypt_ops) || WARN_ON(!PAGE_ALIGNED(addr)))
>> + if (likely(!crypt_ops))
>> return 0;
>>
>> + if (WARN_ON(!IS_ALIGNED(addr, mem_decrypt_granule_size())))
>> + return -EINVAL;
>> +
>> + if (WARN_ON(!IS_ALIGNED(numpages << PAGE_SHIFT, mem_decrypt_granule_size())))
>> + return -EINVAL;
>> +
>> return crypt_ops->decrypt(addr, numpages);
>> }
>> EXPORT_SYMBOL_GPL(set_memory_decrypted);
>
> This should go in the ARM patch adding mem_decrypt_granule_size() to CCA
>
>> diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
>> index 07584c5e36fb..1e01c9ac697f 100644
>> --- a/include/linux/mem_encrypt.h
>> +++ b/include/linux/mem_encrypt.h
>> @@ -11,6 +11,8 @@
>> #define __MEM_ENCRYPT_H__
>>
>> #ifndef __ASSEMBLY__
>> +#include <linux/align.h>
>> +#include <vdso/page.h>
>>
>> #ifdef CONFIG_ARCH_HAS_MEM_ENCRYPT
>>
>> @@ -54,6 +56,18 @@
>> #define dma_addr_canonical(x) (x)
>> #endif
>>
>> +#ifndef mem_decrypt_granule_size
>> +static inline size_t mem_decrypt_granule_size(void)
>> +{
>> + return PAGE_SIZE;
>> +}
>> +#endif
>> +
>> +static inline size_t mem_decrypt_align(size_t size)
>> +{
>> + return ALIGN(size, mem_decrypt_granule_size());
>> +}
>> +
>> #endif /* __ASSEMBLY__ */
>>
>> #endif /* __MEM_ENCRYPT_H__ */
>
> I know it seems a bit small, but put this in its own patch and explain
> how it works. I'd also like to see a kdoc here, and add a kdoc to
> set_memory_decrypted() that links back so people have a better chance
> to know about this.
>
Okay, I’ll update all the above in the next revision.
-aneesh
^ permalink raw reply
* Re: [PATCH v3] gpu: ipu-v3: clean up kernel-doc warnings
From: Helge Deller @ 2026-04-28 12:22 UTC (permalink / raw)
To: Randy Dunlap, dri-devel; +Cc: imx, linux-arm-kernel, linux-fbdev
In-Reply-To: <20260427183236.656902-1-rdunlap@infradead.org>
On 4/27/26 20:32, Randy Dunlap wrote:
> Correct all kernel-doc warnings:
> - fix a typedef kernel-doc comment
> - mark a list_head as private
> - use Returns: for function return values
>
> Warning: include/video/imx-ipu-image-convert.h:31 struct member 'list' not
> described in 'ipu_image_convert_run'
> ....
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> v2: add Reviewed-by, update Cc: list, rebase, resend
> v3: rebase & resend
>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: Helge Deller <deller@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
>
> include/video/imx-ipu-image-convert.h | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
applied to fbdev git tree.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v22 5/8] dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY
From: Luca Ceresoli @ 2026-04-28 12:21 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, dri-devel, devicetree, linux-kernel, linux-phy,
imx, linux-arm-kernel, linux, Alexander Stein, Ying Liu
In-Reply-To: <f6rf5d6nhglkwendf5yvaklfn2ovlwkqstsz7vvl5zefibtiun@wic7bchohmwv>
Hello Laurentiu,
On Mon Apr 27, 2026 at 4:35 PM CEST, Laurentiu Palcu wrote:
> Hi Luca,
>
> On Mon, Apr 27, 2026 at 02:59:47PM +0200, Luca Ceresoli wrote:
>> Hello Laurentiu,
>>
>> On Fri Apr 24, 2026 at 1:07 PM CEST, Laurentiu Palcu wrote:
>> > From: Sandor Yu <Sandor.yu@nxp.com>
>> >
>> > Add bindings for Freescale iMX8MQ DP and HDMI PHY.
>> >
>> > Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
>> > Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
>> > ---
>> > .../bindings/phy/fsl,imx8mq-hdptx-phy.yaml | 80 ++++++++++++++++++++++
>> > 1 file changed, 80 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-hdptx-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-hdptx-phy.yaml
>> > new file mode 100644
>> > index 0000000000000..a24435139b8b3
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-hdptx-phy.yaml
>> > @@ -0,0 +1,80 @@
>> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> > +%YAML 1.2
>> > +---
>> > +$id: http://devicetree.org/schemas/phy/fsl,imx8mq-hdptx-phy.yaml#
>> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> > +
>> > +title: Cadence HDP-TX DP/HDMI PHY for Freescale i.MX8MQ SoC
>> > +
>> > +maintainers:
>> > + - Sandor Yu <sandor.yu@nxp.com>
>>
>> Based on what you said in the cover, I guess this line will have to be
>> changed. Are you willing to maintain this binding?
>
> Yes, I'll update it in the next iteration.
>
>>
>> > +description:
>> > + The Cadence HDP-TX DP/HDMI PHY is a child node of the MHDP8501 bridge,
>> > + sharing the same MMIO region as the parent bridge node.
>> > +
>> > +properties:
>> > + compatible:
>> > + const: fsl,imx8mq-hdptx-phy
>> > +
>> > + clocks:
>> > + items:
>> > + - description: PHY reference clock.
>> > + - description: APB clock.
>> > +
>> > + clock-names:
>> > + items:
>> > + - const: ref
>> > + - const: apb
>> > +
>> > + "#phy-cells":
>> > + const: 0
>> > +
>> > +required:
>> > + - compatible
>> > + - clocks
>> > + - clock-names
>> > + - "#phy-cells"
>> > +
>> > +additionalProperties: false
>> > +
>> > +examples:
>> > + - |
>> > + #include <dt-bindings/clock/imx8mq-clock.h>
>> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> > +
>> > + display-bridge@32c00000 {
>> > + compatible = "fsl,imx8mq-mhdp8501";
>> > + reg = <0x32c00000 0x100000>;
>> > + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
>> > + <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
>> > + interrupt-names = "plug_in", "plug_out";
>> > + clocks = <&clk IMX8MQ_CLK_DISP_APB_ROOT>;
>> > + phys = <&dp_phy>;
>> > +
>> > + ports {
>> > + #address-cells = <1>;
>> > + #size-cells = <0>;
>>
>> The ports are not mentioned in the properties. I'm not a DT maintainer, but
>> I think they should, e.g. to mention which port is the input and which is
>> the output.
>>
>> > +
>> > + port@0 {
>> > + reg = <0>;
>> > + endpoint {
>> > + remote-endpoint = <&dcss_out>;
>> > + };
>> > + };
>> > +
>> > + port@1 {
>> > + reg = <1>;
>> > + endpoint {
>> > + data-lanes = <2 1 0 3>;
>>
>> Having a remote-endpoint property would be nice here, to make the example
>> more complete.
>
> The ports and the remote endpoints are documented in the bridge binding...
Ah, my bad, I reviewed too quickly and mixed the phy and bridge bindings in
my mind, sorry.
>
> However, I believe I screwed this example up by adding the entire bridge node,
> instead of just a simple:
>
> mhdp {
> phy {
> compatible = "fsl,imx8mq-hdptx-phy";
> #phy-cells = <0>;
> clocks = <&hdmi_phy_27m>, <&clk IMX8MQ_CLK_DISP_APB_ROOT>;
> clock-names = "ref", "apb";
> };
> };
>
> I'll simplify the example in the next iteration.
Yes, I think it would make sense to do it.
Thanks,
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v4 2/3] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
From: Aneesh Kumar K.V @ 2026-04-28 12:20 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: <86zf2ozrb8.wl-maz@kernel.org>
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.
>
>>
>> Introduce a new helper, mem_decrypt_align(), to allow callers to enforce
>> the required alignment and size constraints for shared buffers.
>>
>> The architecture-specific implementation of mem_decrypt_align() will be
>> provided in a follow-up patch.
>>
>> Note on restricted-dma-pool:
>> rmem_swiotlb_device_init() uses reserved-memory regions described by
>> firmware. Those regions are not changed in-kernel to satisfy host granule
>> alignment. This is intentional: we do not expect restricted-dma-pool
>> allocations to be used with CCA. If restricted-dma-pool is intended for CCA
>> shared use, firmware must provide base/size aligned to the host IPA-change
>> granule.
>>
>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>> ---
>> arch/arm64/mm/mem_encrypt.c | 19 +++++++++++++++----
>> drivers/irqchip/irq-gic-v3-its.c | 20 +++++++++++++-------
>> include/linux/mem_encrypt.h | 14 ++++++++++++++
>> kernel/dma/contiguous.c | 10 ++++++++++
>> kernel/dma/direct.c | 16 ++++++++++++++--
>> kernel/dma/pool.c | 4 +++-
>> kernel/dma/swiotlb.c | 21 +++++++++++++--------
>> 7 files changed, 82 insertions(+), 22 deletions(-)
>>
>
> [...]
>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index 291d7668cc8d..239d7e3bc16f 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -213,16 +213,17 @@ static gfp_t gfp_flags_quirk;
>> static struct page *its_alloc_pages_node(int node, gfp_t gfp,
>> unsigned int order)
>> {
>> + unsigned int new_order;
>> struct page *page;
>> int ret = 0;
>>
>> - page = alloc_pages_node(node, gfp | gfp_flags_quirk, order);
>> -
>> + new_order = get_order(mem_decrypt_align((PAGE_SIZE << order)));
>> + page = alloc_pages_node(node, gfp | gfp_flags_quirk, new_order);
>> if (!page)
>> return NULL;
>>
>> ret = set_memory_decrypted((unsigned long)page_address(page),
>> - 1 << order);
>> + 1 << new_order);
>> /*
>> * If set_memory_decrypted() fails then we don't know what state the
>> * page is in, so we can't free it. Instead we leak it.
>> @@ -241,13 +242,16 @@ static struct page *its_alloc_pages(gfp_t gfp, unsigned int order)
>>
>> static void its_free_pages(void *addr, unsigned int order)
>> {
>> + int new_order;
>> +
>> + new_order = get_order(mem_decrypt_align((PAGE_SIZE << order)));
>> /*
>> * If the memory cannot be encrypted again then we must leak the pages.
>> * set_memory_encrypted() will already have WARNed.
>> */
>> - if (set_memory_encrypted((unsigned long)addr, 1 << order))
>> + if (set_memory_encrypted((unsigned long)addr, 1 << new_order))
>> return;
>> - free_pages((unsigned long)addr, order);
>> + free_pages((unsigned long)addr, new_order);
>> }
>>
>
> Here's the non-obfuscated version of the two hunks above (and let it
> be on the record that New Order is a terrible, overrated band):
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 291d7668cc8da..a4d555aaee241 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -216,6 +216,7 @@ static struct page *its_alloc_pages_node(int node, gfp_t gfp,
> struct page *page;
> int ret = 0;
>
> + order = get_order(mem_decrypt_align(PAGE_SIZE << order));
> page = alloc_pages_node(node, gfp | gfp_flags_quirk, order);
>
> if (!page)
> @@ -245,6 +246,7 @@ static void its_free_pages(void *addr, unsigned int order)
> * If the memory cannot be encrypted again then we must leak the pages.
> * set_memory_encrypted() will already have WARNed.
> */
> + order = get_order(mem_decrypt_align(PAGE_SIZE << order));
> if (set_memory_encrypted((unsigned long)addr, 1 << order))
> return;
> free_pages((unsigned long)addr, order);
>
I will include this in the next revision.
>> 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?
-aneesh
^ permalink raw reply
* [PATCH 2/2] coresight: etm4x: Refactor pm_save_enable handling
From: James Clark @ 2026-04-28 12:18 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, Leo Yan, Alexander Shishkin,
Mathieu Poirier
Cc: coresight, linux-arm-kernel, linux-kernel, James Clark
In-Reply-To: <20260428-james-cs-ete-pm_save_enable-v1-0-c7a90ca6f43b@linaro.org>
pm_save_enable is a global module parameter used as a user input, but at
the same time is modified on probe. There are some theoretical scenarios
where the DT for one device says to save and another says not to which
result in one device not allocating save state memory but later trying
to save if probing happens in a certain order. We also couldn't warn if
the module parameter is used for ETE because the input value is
overwritten, then for the next device it looks like the user had set
a value triggering a warning.
Fix it by treating the module parameter strictly as user input and
adding a new per device pm_save boolean, and then add the warning that
couldn't be added before.
Signed-off-by: James Clark <james.clark@linaro.org>
---
drivers/hwtracing/coresight/coresight-etm4x-core.c | 22 ++++++++++++++++------
drivers/hwtracing/coresight/coresight-etm4x.h | 1 +
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index a7fb680dd383..915f348620d8 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -1366,20 +1366,30 @@ static void etm4_fixup_wrong_ccitmin(struct etmv4_drvdata *drvdata)
}
}
+/*
+ * Take the global pm_save_enable module argument and setup the CPU PM save
+ * setting for this device.
+ */
static int etm4_init_pm_save(struct device *dev, struct etmv4_drvdata *drvdata)
{
if (etm4x_is_ete(drvdata)) {
+ if (pm_save_enable)
+ dev_warn_once(dev, "pm_save_enable module option is only for ETM4\n");
+
/*
* Always do PM save for ETE. It always uses system registers
* which will be lost on CPU power down.
*/
- pm_save_enable = PARAM_PM_SAVE_SELF_HOSTED;
+ drvdata->pm_save = true;
} else if (pm_save_enable == PARAM_PM_SAVE_FIRMWARE) {
- pm_save_enable = coresight_loses_context_with_cpu(dev) ?
- PARAM_PM_SAVE_SELF_HOSTED : PARAM_PM_SAVE_NEVER;
+ drvdata->pm_save = coresight_loses_context_with_cpu(dev);
+ } else if (pm_save_enable == PARAM_PM_SAVE_SELF_HOSTED) {
+ drvdata->pm_save = true;
+ } else {
+ drvdata->pm_save = false;
}
- if (pm_save_enable != PARAM_PM_SAVE_NEVER) {
+ if (drvdata->pm_save) {
drvdata->save_state = devm_kmalloc(dev,
sizeof(struct etmv4_save_state),
GFP_KERNEL);
@@ -2037,7 +2047,7 @@ static int etm4_cpu_save(struct etmv4_drvdata *drvdata)
{
int ret = 0;
- if (pm_save_enable != PARAM_PM_SAVE_SELF_HOSTED)
+ if (!drvdata->pm_save)
return 0;
/*
@@ -2152,7 +2162,7 @@ static void __etm4_cpu_restore(struct etmv4_drvdata *drvdata)
static void etm4_cpu_restore(struct etmv4_drvdata *drvdata)
{
- if (pm_save_enable != PARAM_PM_SAVE_SELF_HOSTED)
+ if (!drvdata->pm_save)
return;
if (coresight_get_mode(drvdata->csdev))
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index 89d81ce4e04e..6472677f3098 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -1078,6 +1078,7 @@ struct etmv4_drvdata {
bool lpoverride : 1;
bool skip_power_up : 1;
bool paused : 1;
+ bool pm_save : 1;
u64 trfcr;
struct etmv4_config config;
struct etmv4_save_state *save_state;
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] coresight: ete: Always save state on power down
From: James Clark @ 2026-04-28 12:18 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, Leo Yan, Alexander Shishkin,
Mathieu Poirier
Cc: coresight, linux-arm-kernel, linux-kernel, James Clark
In-Reply-To: <20260428-james-cs-ete-pm_save_enable-v1-0-c7a90ca6f43b@linaro.org>
ETE registers are always system registers so it's highly unlikely there
will be an implementation that preserves them on CPU power down. Also
the ETE DT binding never documented
"arm,coresight-loses-context-with-cpu" so nobody would have legitimately
been able to use that binding to fix it.
Fix it by hard coding the setting for ETE and add a warning if the user
tried to use the module parameter. Don't add a warning if
loses-context-with-cpu is present in the DT as it's not a documented
binding anyway. etm4_init_pm_save() needs to happen after drvdata is
initialised so etm4x_is_ete() can be called.
This fixes the following error when using Coresight with ACPI on the FVP
which supports CPU PM:
coresight ete0: External agent took claim tag
WARNING: drivers/hwtracing/coresight/coresight-core.c:248 at coresight_disclaim_device_unlocked+0xe0/0xe8, CPU#0: perf/117
Fixes: 35e1c9163e02 ("coresight: ete: Add support for ETE tracing")
Signed-off-by: James Clark <james.clark@linaro.org>
---
drivers/hwtracing/coresight/coresight-etm4x-core.c | 41 +++++++++++++++-------
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index d565a73f0042..a7fb680dd383 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -56,10 +56,11 @@ MODULE_PARM_DESC(boot_enable, "Enable tracing on boot");
#define PARAM_PM_SAVE_NEVER 1 /* never save any state */
#define PARAM_PM_SAVE_SELF_HOSTED 2 /* save self-hosted state only */
+/* Save option for ETM4. ETE ignores this option and always saves */
static int pm_save_enable = PARAM_PM_SAVE_FIRMWARE;
module_param(pm_save_enable, int, 0444);
MODULE_PARM_DESC(pm_save_enable,
- "Save/restore state on power down: 1 = never, 2 = self-hosted");
+ "Save/restore state on power down: 1 = never, 2 = self-hosted. ETM4 only.");
static struct etmv4_drvdata *etmdrvdata[NR_CPUS];
static void etm4_set_default_config(struct etmv4_config *config);
@@ -1365,6 +1366,30 @@ static void etm4_fixup_wrong_ccitmin(struct etmv4_drvdata *drvdata)
}
}
+static int etm4_init_pm_save(struct device *dev, struct etmv4_drvdata *drvdata)
+{
+ if (etm4x_is_ete(drvdata)) {
+ /*
+ * Always do PM save for ETE. It always uses system registers
+ * which will be lost on CPU power down.
+ */
+ pm_save_enable = PARAM_PM_SAVE_SELF_HOSTED;
+ } else if (pm_save_enable == PARAM_PM_SAVE_FIRMWARE) {
+ pm_save_enable = coresight_loses_context_with_cpu(dev) ?
+ PARAM_PM_SAVE_SELF_HOSTED : PARAM_PM_SAVE_NEVER;
+ }
+
+ if (pm_save_enable != PARAM_PM_SAVE_NEVER) {
+ drvdata->save_state = devm_kmalloc(dev,
+ sizeof(struct etmv4_save_state),
+ GFP_KERNEL);
+ if (!drvdata->save_state)
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
static void etm4_init_arch_data(void *info)
{
u32 etmidr0;
@@ -2247,6 +2272,9 @@ static int etm4_add_coresight_dev(struct etm4_init_arg *init_arg)
return -ENOMEM;
etm4_set_default(&drvdata->config);
+ ret = etm4_init_pm_save(dev, drvdata);
+ if (ret)
+ return ret;
pdata = coresight_get_platform_data(dev);
if (IS_ERR(pdata))
@@ -2305,17 +2333,6 @@ static int etm4_probe(struct device *dev)
if (ret)
return ret;
- if (pm_save_enable == PARAM_PM_SAVE_FIRMWARE)
- pm_save_enable = coresight_loses_context_with_cpu(dev) ?
- PARAM_PM_SAVE_SELF_HOSTED : PARAM_PM_SAVE_NEVER;
-
- if (pm_save_enable != PARAM_PM_SAVE_NEVER) {
- drvdata->save_state = devm_kmalloc(dev,
- sizeof(struct etmv4_save_state), GFP_KERNEL);
- if (!drvdata->save_state)
- return -ENOMEM;
- }
-
raw_spin_lock_init(&drvdata->spinlock);
drvdata->cpu = coresight_get_cpu(dev);
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] coresight: ete: Always save state on power down
From: James Clark @ 2026-04-28 12:18 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, Leo Yan, Alexander Shishkin,
Mathieu Poirier
Cc: coresight, linux-arm-kernel, linux-kernel, James Clark
Fix PM save on ETE, which is an issue that showed up on the FVP when
booted with ACPI and the newly enabled idle states. Then refactor to
clarify and avoid any probe order issues.
Signed-off-by: James Clark <james.clark@linaro.org>
---
James Clark (2):
coresight: ete: Always save state on power down
coresight: etm4x: Refactor pm_save_enable handling
drivers/hwtracing/coresight/coresight-etm4x-core.c | 55 ++++++++++++++++------
drivers/hwtracing/coresight/coresight-etm4x.h | 1 +
2 files changed, 42 insertions(+), 14 deletions(-)
---
base-commit: 971f3474f8898ae8bbab19a9b547819a5e6fbcf1
change-id: 20260420-james-cs-ete-pm_save_enable-4e994e35cdac
Best regards,
--
James Clark <james.clark@linaro.org>
^ permalink raw reply
* Re: [PATCH v2] crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A
From: Ard Biesheuvel @ 2026-04-28 12:18 UTC (permalink / raw)
To: Marek Behún, Bill Cox
Cc: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Linus Walleij, stable,
linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <25ntssyy6t5uwxlwfpmrpzpcq6xv62l643hflf26hxi6lv5wqu@6vub6ysczjvd>
Hi Marek,
On Tue, 28 Apr 2026, at 13:18, 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.
>
According to Landon Cox, the Atmel engineer, the hashlet has a ATSHA204 not
ATSHA204A ([2] in the original post)
> 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?
>
So Bill recommends against using the ATSHA204 based on his hands-on experience,
and extrapolates this to ATSHA204A/ATECC/etc based on the fact that the wording
in the data sheet description looks similar.
OTOH, the Atmel engineer claiming to have been involved in constructing these
parts acknowledges the ATSHA204 issue, and claims that the other parts are not
affected in the same way.
I don't think we should be using the quality field as a reflection of our
assessment whether this engineer is lying or speaking the truth, or the
likelihood that the RNG is backdoored. It is a quality metric not a trust metric.
So if the RNG is flawed and does not produce perfect entropy, we should set
the quality value to reflect this. If the device is compromised, it should
be avoided entirely, and what the driver does is irrelevant.
IOW, let the user decide - if they choose to use the device, don't cripple
it based on our skepticism alone.
^ permalink raw reply
* Re: [PATCH v21 08/13] mfd: core: Add firmware-node support to MFD cells
From: Shivendra Pratap @ 2026-04-28 12:17 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=Mf+-04Zr7jjRoaxTzO3LKSMyQ7DzxJc=dHNSyThEUiq_Q@mail.gmail.com>
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?
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH] iommu/rockchip: disable fetch dte time limit
From: Sven Püschel @ 2026-04-28 12:15 UTC (permalink / raw)
To: Shawn Lin, Joerg Roedel, Will Deacon, Robin Murphy,
Heiko Stuebner
Cc: iommu, linux-arm-kernel, linux-rockchip, linux-kernel, Simon Xue,
kernel
In-Reply-To: <cea54dcb-6236-4363-8b46-e2213a190894@pengutronix.de>
Hi,
pinging this Patch, as I didn't receive any more feedback/reviews. The
feedback only affects the comment and doesn't affect the commit,
therefore I currently don't see a reason for a v2.
We've noticed that this patches fixes hangups when using the RGA3
peripheral on the rk3588 (where I'm in the process of upstreaming a
driver [1], which depends on this changeset). Based on the vendor commit
messages, it should also fix VOP and screen black issues.
Sincerely
Sven
[1]
https://lore.kernel.org/linux-media/20260428-spu-rga3-v5-0-eb7f5d019d86@pengutronix.de/
On 11/28/25 8:26 AM, Sven Püschel wrote:
>
> On 11/27/25 5:32 AM, Shawn Lin wrote:
>> 在 2025/11/26 星期三 19:45, Sven Püschel 写道:
>>> From: Simon Xue <xxm@rock-chips.com>
>>>
>>> Disable the Bit 31 of the AUTO_GATING iommu register, as it causes
>>> hangups with the RGA3 (Raster Graphics Acceleration 3) peripheral.
>>> The RGA3 register description of the TRM already states that the bit
>>> must be set to 1. The vendor kernel sets the bit unconditionally to
>>> 1 to fix VOP (Video Output Processor) screen black issues. This patch
>>> squashes the 2 vendor kernel commits with the following commit
>>> messages:
>>>
>>> Master fetch data and cpu update page table may work in parallel, may
>>> have the following procedure:
>>>
>>> master cpu
>>> fetch dte update page tabl
>>> | |
>>> (make dte invalid) <- zap iotlb entry
>>> | |
>>> fetch dte again
>>> (make dte invalid) <- zap iotlb entry
>>> | |
>>> fetch dte again
>>> (make dte invalid) <- zap iotlb entry
>>> | |
>>> fetch dte again
>>> (make iommu block) <- zap iotlb entry
>>>
>>> New iommu version has the above bug, if fetch dte consecutively four
>>> times, then it will be blocked. Fortunately, we can set bit 31 of
>>> register MMU_AUTO_GATING to 1 to make it work as old version which does
>>> not have this issue.
>>>
>>> This issue only appears on RV1126 so far, so make a workaround
>>> dedicated
>>> to "rockchip,rv1126" machine type.
>>>
>>> iommu/rockchip: fix vop blocked and screen black on RK356X and RK3588
>>>
>>> RK3568 and RK3588 has the same issue as RV1126/RV1109 that caused by
>>> dte fetch time limit, So we can set BIT(31) of register 0x24 default
>>> to 1 as a workaround.
>>>
>>> Signed-off-by: Simon Xue <xxm@rock-chips.com>
>>> Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
>>> ---
>>> During testing of a newly developed driver for the RGA3 peripheral [1]
>>> (Raster Graphic Acceleration 3) of the RK3588 some sporadic hangs
>>> have been observed. The upstream rockchip-iommu driver is used to
>>> handle
>>> the RGA3 IOMMU register space.
>>>
>>> After a closer look at the TRM for the RK3588, the RGA3 iommu register
>>> description of the RGA3_MMU_AUTO_GATING register (offset 0x24) mentions
>>
>> It's 0xF24 per RGA3 chapter.
>
> yeah, sorry. I was already thinking relative to the rga3 iommu address
> space in my head, but didn't really mention that the chapter says
> 0xF24 with the iommu related registers starting at 0xF00.
>
> Sincerely
> Sven
>
>>
>>> a mmu_bug_fixed_disable bit, which must be set to 1 but defaults to 0.
>>>
>>> Looking at the commits in the vendor kernel, the bit is unconditionally
>>> set to 1 and mentions that it fixes a blocked VOP (Video Output
>>> Processor) [3]. Therefore squash the relevant vendor commits
>>> [2] and [3] into a single patch, combine the commit messages and keep
>>> the Signed-off-by line from the original author.
>>>
>>> [1]
>>> https://lore.kernel.org/all/20251007-spu-rga3-v1-0-36ad85570402@pengutronix.de/
>>> [2]
>>> https://github.com/rockchip-linux/kernel/commit/7f8158fb41b5cc8e738aaeebc3637c50ebd74cae
>>> [3]
>>> https://github.com/rockchip-linux/kernel/commit/6a355e5f9a2069a2309e240791bc3aad63b7324e
>>> ---
>>> drivers/iommu/rockchip-iommu.c | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/iommu/rockchip-iommu.c
>>> b/drivers/iommu/rockchip-iommu.c
>>> index 0861dd469bd86..2d0dabb0d101a 100644
>>> --- a/drivers/iommu/rockchip-iommu.c
>>> +++ b/drivers/iommu/rockchip-iommu.c
>>> @@ -76,6 +76,8 @@
>>> #define SPAGE_ORDER 12
>>> #define SPAGE_SIZE (1 << SPAGE_ORDER)
>>> +#define DISABLE_FETCH_DTE_TIME_LIMIT BIT(31)
>>> +
>>> /*
>>> * Support mapping any size that fits in one page table:
>>> * 4 KiB to 4 MiB
>>> @@ -930,6 +932,7 @@ static int rk_iommu_enable(struct rk_iommu *iommu)
>>> struct iommu_domain *domain = iommu->domain;
>>> struct rk_iommu_domain *rk_domain = to_rk_domain(domain);
>>> int ret, i;
>>> + u32 auto_gate;
>>> ret = clk_bulk_enable(iommu->num_clocks, iommu->clocks);
>>> if (ret)
>>> @@ -948,6 +951,11 @@ static int rk_iommu_enable(struct rk_iommu *iommu)
>>> rk_ops->mk_dtentries(rk_domain->dt_dma));
>>> rk_iommu_base_command(iommu->bases[i], RK_MMU_CMD_ZAP_CACHE);
>>> rk_iommu_write(iommu->bases[i], RK_MMU_INT_MASK,
>>> RK_MMU_IRQ_MASK);
>>> +
>>> + /* Workaround for iommu blocked, BIT(31) default to 1 */
>>> + auto_gate = rk_iommu_read(iommu->bases[i],
>>> RK_MMU_AUTO_GATING);
>>> + auto_gate |= DISABLE_FETCH_DTE_TIME_LIMIT;
>>> + rk_iommu_write(iommu->bases[i], RK_MMU_AUTO_GATING,
>>> auto_gate);
>>> }
>>> ret = rk_iommu_enable_paging(iommu);
>>>
>>> ---
>>> base-commit: 30f09200cc4aefbd8385b01e41bde2e4565a6f0e
>>> change-id: 20251126-spu-iommudtefix-cd0c5244c74a
>>>
>>> Best regards,
>>
>>
^ permalink raw reply
* Re: [QUESTION] Is the ARM SMMU v3 implementation designed to always ignore SSID when SSID_VALID == 0?
From: Robin Murphy @ 2026-04-28 12:15 UTC (permalink / raw)
To: Joonwon Kang, jpb
Cc: baolu.lu, cychu, hhchung, iommu, jgg, joro, linux-arm-kernel,
linux-kernel, stimim, will
In-Reply-To: <20260428111442.1584248-1-joonwonkang@google.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.
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).
Thanks,
Robin.
^ permalink raw reply
* Re: [PATCH] pinctrl: qcom: Make important drivers default
From: Krzysztof Kozlowski @ 2026-04-28 12:06 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Bjorn Andersson, Konrad Dybcio, linux-arm-kernel,
linux-kernel, linux-arm-msm, linux-gpio
In-Reply-To: <CAD++jL=yCM80YHV3bKTVVfNoYsbTLJ9oV=3sJ8JcL6ftvWa3_g@mail.gmail.com>
On 27/04/2026 22:18, Linus Walleij wrote:
>>
>> 3. arm multi_v7 defconfig: enable drivers necessary to boot ARM 32-bit
>> platforms, which are already enabled on qcom_defconfig.
>>
>> 4. COMPILE_TEST builds: enable by default all drivers for arm or arm64
>> builds, whenever ARCH_QCOM is selected. This has impact on build
>> time and feels logical, because if one selects ARCH_QCOM then
>> probably by default wants to build test it entirely. Kernels with
>> COMPILE_TEST are not supposed to be used for booting.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> Way better like this.
> Reviewed-by: Linus Walleij <linusw@kernel.org>
I think this should rather go through your tree, because new drivers are
coming and some other changes from me might be touching similar lines.
Well, defconfig also might be changed in parallel, so obviously someone
will need to handle conflicts.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: ti: k3-j721s2-som-p0: add bootph-pre-ram property to pmic@4c
From: Thomas Richard @ 2026-04-28 12:06 UTC (permalink / raw)
To: Kumar, Udit, 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: <6aa8fd45-ec3d-4bd7-9b13-6c00e4fd4efc@ti.com>
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.
Best Regards,
Thomas
^ 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 11:58 UTC (permalink / raw)
To: Biju Das, 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: <TY3PR01MB113466B70BFD2899AB0CF47AD86372@TY3PR01MB11346.jpnprd01.prod.outlook.com>
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.
[1] https://lore.kernel.org/linux-renesas-soc/20260421172910.218497-4-biju.das.jz@bp.renesas.com/
+ next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
+ if (IS_ERR(next_bridge))
+ return dev_err_probe(dev, PTR_ERR(next_bridge),
+ "failed to get next bridge\n");
+
+ lvds->bridge.next_bridge = next_bridge;
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH 1/4] arm64: dts: marvell: samsung-coreprimevelte: Increase touchscreen voltage
From: Karel Balej @ 2026-04-28 11:52 UTC (permalink / raw)
To: Duje Mihanović
Cc: linux-arm-kernel, devicetree, linux-kernel, David Wronek,
phone-devel, ~postmarketos/upstreaming, Duje Mihanović,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260409-cprime-dt-fixes-v6-20-v1-1-8df6f88942c8@dujemihanovic.xyz>
Duje Mihanović, 2026-04-09T23:17:24+02:00:
> From: Duje Mihanović <duje@dujemihanovic.xyz>
>
> The old 1.9V setting was found to be insufficient in certain
> environments (in my case cold ones), causing the touchscreen to register
> ghost touches and mostly ignore actual touches. Increase the voltage to
> 2.5V to correct the issue.
>
> Fixes: ec958b5b18c8 ("arm64: dts: samsung,coreprimevelte: add touchscreen")
> Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
> ---
> arch/arm64/boot/dts/marvell/mmp/pxa1908-samsung-coreprimevelte.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Karel Balej <balejk@matfyz.cz>
^ 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 11:49 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: <20260428-drm-bridge-alloc-getput-panel_or_bridge-v2-8-4300744a1c47@bootlin.com>
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?
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH v2 05/11] drm/bridge: chrontel-ch7033: switch to of_drm_get_bridge_by_endpoint()
From: Dmitry Baryshkov @ 2026-04-28 11:36 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-5-4300744a1c47@bootlin.com>
On Tue, Apr 28, 2026 at 11:15:51AM +0200, Luca Ceresoli wrote:
> 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/chrontel-ch7033.c | 28 +++++++++++++---------------
> 1 file changed, 13 insertions(+), 15 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 11/11] drm: of: forbid bridge-only calls to drm_of_find_panel_or_bridge()
From: Dmitry Baryshkov @ 2026-04-28 11:35 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-11-4300744a1c47@bootlin.com>
On Tue, Apr 28, 2026 at 11:15:57AM +0200, Luca Ceresoli wrote:
> Up to now drm_of_find_panel_or_bridge() can be called with a bridge pointer
> only, a panel pointer only, or both a bridge and a panel pointers. The
> logic to handle all the three cases is somewhat complex to read however.
>
> Now all bridge-only callers have been converted to
> of_drm_get_bridge_by_endpoint(), which is simpler and handles bridge
> refcounting. So forbid new bridge-only users by mandating a non-NULL panel
> pointer in the docs and in the sanity checks along with a warning.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
> drivers/gpu/drm/drm_of.c | 26 ++++++++++++--------------
> 1 file changed, 12 insertions(+), 14 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 09/11] drm/bridge: lt8713sx: switch to of_drm_get_bridge_by_endpoint()
From: Dmitry Baryshkov @ 2026-04-28 11:34 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-9-4300744a1c47@bootlin.com>
On Tue, Apr 28, 2026 at 11:15:55AM +0200, Luca Ceresoli wrote:
> 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/lontium-lt8713sx.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 08/11] drm/bridge: adv7511: switch to of_drm_get_bridge_by_endpoint()
From: Dmitry Baryshkov @ 2026-04-28 11:34 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-8-4300744a1c47@bootlin.com>
On Tue, Apr 28, 2026 at 11:15:54AM +0200, Luca Ceresoli wrote:
> 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(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 07/11] drm/bridge: lt9611: switch to of_drm_get_bridge_by_endpoint()
From: Dmitry Baryshkov @ 2026-04-28 11:32 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>
On Tue, Apr 28, 2026 at 11:15:53AM +0200, Luca Ceresoli wrote:
> 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/lontium-lt9611.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 06/11] drm/bridge: lontium-lt9611uxc: switch to of_drm_get_bridge_by_endpoint()
From: Dmitry Baryshkov @ 2026-04-28 11:31 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-6-4300744a1c47@bootlin.com>
On Tue, Apr 28, 2026 at 11:15:52AM +0200, Luca Ceresoli wrote:
> 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/lontium-lt9611uxc.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 03/11] drm/msm/hdmi: switch to of_drm_get_bridge_by_endpoint()
From: Dmitry Baryshkov @ 2026-04-28 11:31 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-3-4300744a1c47@bootlin.com>
On Tue, Apr 28, 2026 at 11:15:49AM +0200, Luca Ceresoli wrote:
> 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.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
> drivers/gpu/drm/msm/hdmi/hdmi.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ 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