On Wed, May 06, 2026 at 02:43:42PM +0200, Nicolas Frattaroli wrote:

On Wednesday, 6 May 2026 12:08:24 Central European Summer Time Maxime Ripard wrote:

...

Hi,

On Tue, May 05, 2026 at 04:05:10PM +0200, Ketil Johnsen wrote:

...

From: Florent Tomasin florent.tomasin@arm.com

This patch allows Panthor to allocate buffer objects from a protected heap. The Panthor driver should be seen as a consumer of the heap and not an exporter.

Protected memory buffers needed by the Panthor driver:

• On CSF FW load, the Panthor driver must allocate a protected buffer object to hold data to use by the FW when in protected mode. This protected buffer object is owned by the device and does not belong to a process.
• On CSG creation, the Panthor driver must allocate a protected suspend buffer object for the FW to store data when suspending the CSG while in protected mode. The kernel owns this allocation and does not allow user space mapping. The format of the data in this buffer is only known by the FW and does not need to be shared with other entities.

The driver will retrieve the protected heap using the name of the heap provided to the driver as module parameter.

I know it's what dma_heap_find asks for, but I wonder if it wouldn't be better in the device tree and lookup through the device node? heaps are going to have a node anyway, right?

This would allow you to have a default that works and not mess to much with the kernel parameters that aren't always easy to change for end-users.

Hopefully the kernel parameters aren't easy to change for end-users on systems that deploy this. :) The use-case is copy protection for embedded devices running on locked-down systems. Though admittedly the mechanism works even on "tampered"-with systems, as long as the underlying hardware implements the access restrictions properly.

I guess it wasn't just about the user tampering it, but also about distros shipping, say, a signed UKI that would support multiple platforms with 42 versions of optee but all using panthor. I'm not sure we can expect a single heap name to work for all of them.

I'm a bit hesitant about making this DT myself. It would solve the problem that panthor could probe before the heap provider and needs to handle deferral by itself, but it does mean that we'd be putting software configuration into the device tree.

Is it? If the system has a protected allocator, and if panthor absolutely needs to allocate from that allocator, it's not software configuration: it's a description of what the platform looks like from Linux PoV.

Or put it differently, it's not more software than optee is, and yet it has its own node.

Having the secure heap be a node with no address would allow the tee (or whatever else) to still dynamically allocate it wherever, and let us handle the dependency relationship between dma heap and GPU, but then we require that tee heap driver implementations play nice with this scheme, and bring OF into the dma_heap APIs.

I mean, it's a dma_heap API that we create so we don't bring anything more to it :)

Maxime