On Tue, May 12, 2026 at 8:39 AM Liviu Dudau <[email protected]> wrote: > > On Tue, May 12, 2026 at 04:11:11PM +0200, Boris Brezillon wrote: > > On Tue, 12 May 2026 14:47:27 +0100 > > Liviu Dudau <[email protected]> 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 <[email protected]> wrote: > > > > > > > > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote: > > > > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct > > > > > > > panthor_device *ptdev) > > > > > > > return ret; > > > > > > > } > > > > > > > > > > > > > > + /* If a protected heap name is specified but not found, defer > > > > > > > the probe until created */ > > > > > > > + if (protected_heap_name && strlen(protected_heap_name)) { > > > > > > > > > > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is > > > > > > the > > > > > > name is "" already? > > > > > > > > > > If dma_heap_find() will fail, then the whole probe with fail too. > > > > > This check prevents that. > > > > > > > > Yeah, that's also a questionable design choice. I mean, we can > > > > currently probe and boot the FW even though we never setup the > > > > protected FW sections, so why should we defer the probe here? Can't we > > > > just retry the next time a group with the protected bit is created and > > > > fail if we can find a protected heap? > > > > > > The problem we have with the current firmware is that it does a number of > > > setup steps at "boot" > > > time only. One of the steps is preparing its internal structures for when > > > it enters protected > > > mode and it stores them in the buffer passed in at firmware loading. We > > > cannot later run the > > > process when we have a group with protected mode set. > > > > No, but we can force a full/slow reset and have that thing > > re-initialized, can't we? I mean, that's basically what we do when a > > fast reset fails: we re-initialize all the sections and reset again, at > > which point the FW should start from a fresh state, and be able to > > properly initialize the protected-related stuff if protected sections > > are populated. Am I missing something? > > Right, we can do that. For some reason I keep associating the reset with the > error handling and not with "normal" operations. I kind of hope we end up with either
- panthor knows the exact heap to use and fails with EPROBE_DEFER if the heap is missing, or - panthor gets a dma-buf from userspace and does the full reset - userspace also needs to provide a dma-buf for each protected group for the suspend buffer than something in-between. The latter is more ad-hoc and basically kicks the issue to the userspace. For the former, expressing the relation in DT seems to be the best, but only if possible :-). Otherwise, a kconfig option (instead of module param) should be easier to work with. Looking at the userspace implementation, can we also have an panthor ioctl to return the heap to userspace? A dma-heap ioctl to query the heap size is also lacking. > > Best regards, > Liviu > > > -- > ==================== > | I would like to | > | fix the world, | > | but they're not | > | giving me the | > \ source code! / > --------------- > ¯\_(ツ)_/¯ >
