[PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor

[Boris Brezillon]

On Tue, 12 May 2026 14:47:27 +0100
Liviu Dudau <liviu.dudau at arm.com> wrote:

> On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote:
> > On Thu, 7 May 2026 11:02:26 +0200
> > Marcin Ślusarz <marcin.slusarz at arm.com> wrote:
> >   
> > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:  
> > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > > > >  			return ret;
> > > > >  	}
> > > > >  
> > > > > +	/* If a protected heap name is specified but not found, defer the probe until created */
> > > > > +	if (protected_heap_name && strlen(protected_heap_name)) {    
> > > > 
> > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> > > > name is "" already?    
> > > 
> > > If dma_heap_find() will fail, then the whole probe with fail too.
> > > This check prevents that.  
> > 
> > Yeah, that's also a questionable design choice. I mean, we can
> > currently probe and boot the FW even though we never setup the
> > protected FW sections, so why should we defer the probe here? Can't we
> > just retry the next time a group with the protected bit is created and
> > fail if we can find a protected heap?  
> 
> The problem we have with the current firmware is that it does a number of setup steps at "boot"
> time only. One of the steps is preparing its internal structures for when it enters protected
> mode and it stores them in the buffer passed in at firmware loading. We cannot later run the
> process when we have a group with protected mode set.

No, but we can force a full/slow reset and have that thing
re-initialized, can't we? I mean, that's basically what we do when a
fast reset fails: we re-initialize all the sections and reset again, at
which point the FW should start from a fresh state, and be able to
properly initialize the protected-related stuff if protected sections
are populated. Am I missing something?