From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E82823D290; Tue, 12 May 2026 14:11:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778595081; cv=none; b=FJq2P/4Odfwksq+g1Mfq+QJlSlK51QSIeiazqGnNWVcIWZgh04WEyaZEZ6v8ss7Q+le4VLdaw0jIchSPmLCMGFw3ZQ89HuavgQHL07cItfpwTm0krwxrm70oC6p5nvNr9QeXNJ8LNWK2Eh4KlQkcDpikG5FMbAu6kGUPcALvRs0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778595081; c=relaxed/simple; bh=ffnSOLr6GBRvN/RNrGZcqdQPL9WDigCoPM7fdgwRrkM=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=utD2q8rveIjiANTbj2Dbe7XvWvVEeJLixgS89rWdpGoA2VfNfAYm6mcKDboCD+hDXoCrL5yg4HsBizQJ7InE/qu83yckVn/IZn03kZuGdmUYUpErvw4AMoKThTRW02f/5yVL5YNOZ7nGKIgAfagm8uxJbMoLjWwRJpQRbs9oxJ8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=HfiHYnEs; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="HfiHYnEs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1778595078; bh=ffnSOLr6GBRvN/RNrGZcqdQPL9WDigCoPM7fdgwRrkM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=HfiHYnEsvlaGP8rXHMzyPOvqqCmbexRYDSqS7YdPq/NwKBFXqNQZucTJlKvSPvs6N bQEhjDnFB5iHZ4TngCrePrDeNE6o6Bvgpxllw0d75usAc1NR6HvluYWni2NJopiDRI 86qPMBksnJSMJEmIc3ojTu/JVZgi9qGmlmiXngJlggUUebkB/TGJRfiBJwLD84rFDV OnhnS4h4nXnGTF6iC75b1H6EoiUE3RyNWTM4C+t0TL2mN2b3Niq51V/iGCXGpEwWjk 52R8MJIdUqkeCRYwCPvihSkxBzJYZqA/D5pKKdhsATj+Rl5B7QS6Pp/8xc0d4UHxn6 V/S1XclaHmC1g== Received: from fedora (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 50EAF17E040C; Tue, 12 May 2026 16:11:17 +0200 (CEST) Date: Tue, 12 May 2026 16:11:11 +0200 From: Boris Brezillon To: Liviu Dudau Cc: Marcin =?UTF-8?B?xZpsdXNhcno=?= , Ketil Johnsen , David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Jonathan Corbet , Shuah Khan , Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T.J. Mercier" , Christian =?UTF-8?B?S8O2bmln?= , Steven Price , Daniel Almeida , Alice Ryhl , Matthias Brugger , AngeloGioacchino Del Regno , dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Florent Tomasin , nd@arm.com Subject: Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor Message-ID: <20260512161111.0cb7000e@fedora> In-Reply-To: References: <20260505140516.1372388-1-ketil.johnsen@arm.com> <20260505140516.1372388-5-ketil.johnsen@arm.com> <20260505181523.49a3d85c@fedora> <20260507135356.5428d50d@fedora> Organization: Collabora X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 12 May 2026 14:47:27 +0100 Liviu Dudau wrote: > On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote: > > On Thu, 7 May 2026 11:02:26 +0200 > > Marcin =C5=9Alusarz wrote: > > =20 > > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote: =20 > > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_devic= e *ptdev) > > > > > return ret; > > > > > } > > > > > =20 > > > > > + /* If a protected heap name is specified but not found, defer t= he probe until created */ > > > > > + if (protected_heap_name && strlen(protected_heap_name)) { =20 > > > >=20 > > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is = the > > > > name is "" already? =20 > > >=20 > > > If dma_heap_find() will fail, then the whole probe with fail too. > > > This check prevents that. =20 > >=20 > > 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? =20 >=20 > 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 c= annot 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?