From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lithops.sigma-star.at (mailout.nod.at [116.203.167.152]) (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 2751635836E for ; Thu, 2 Jul 2026 05:39:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=116.203.167.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782970771; cv=none; b=P8JP27+67F7+vRAIhPHt0QLT42IGJskaWA5ojRR6hoB0XjDm9aB13BNERF3PRgoKM57+RD9xH74OrfEOajuL1mFCjBi4eCUS+7KZnE1xRqqKtyuj1752OcWHl4YVHICCSCI85U5Sk6Ck68qRn/UPmNzf9eh2JKi5WLsWs8JMXxQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782970771; c=relaxed/simple; bh=Y4HuDK7RNQ2rk/r6AEJLDtJKomFozQaSgeImVwI3/TE=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=ablFF21/HVV139jXFpCCGsRk8l4eVMMmLM7Wug1NniDn7JY2ySKy619j8KG3PQ7/lWqT+cX5s5sFgmV9c1UJmUrjmbM2NW4M7ylJbalAf6p40/YrgkTMwJmZ+Nr2dj0Ezx5jOUlwjK2pWlAbKsDxqYl5HJrxO4aRuavcWNhEaFU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at; spf=fail smtp.mailfrom=nod.at; arc=none smtp.client-ip=116.203.167.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nod.at Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 398D8FB320; Thu, 2 Jul 2026 07:39:20 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id k-fFA6pOdMFv; Thu, 2 Jul 2026 07:39:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id C72C29CF2B; Thu, 2 Jul 2026 07:39:18 +0200 (CEST) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pAp5O9xOri5n; Thu, 2 Jul 2026 07:39:18 +0200 (CEST) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id 8E25A2A87F7; Thu, 2 Jul 2026 07:39:18 +0200 (CEST) Date: Thu, 2 Jul 2026 07:39:18 +0200 (CEST) From: Richard Weinberger To: Chris Packham Cc: Takahiro Kuwano , Ronan Dalton , Miquel Raynal , pratyush , linux-kernel , Vignesh Raghavendra , linux-mtd , Michael Walle , Aryan Srivastava Message-ID: <490633873.5619.1782970758317.JavaMail.zimbra@nod.at> In-Reply-To: References: <2b8390c0aaae4203af318f9a5edbb0eb@infineon.com> <20260701020856.217664-1-ronan.dalton@alliedtelesis.co.nz> <490fc98b2996487fba3abd62176bb1dd@infineon.com> <8baaf8a603f7f351b4f7acb7a2df4cb60be9f083.camel@alliedtelesis.co.nz> <99731a393e5649e692afe57f59d5926b@infineon.com> Subject: Re: [PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support" Precedence: bulk X-Mailing-List: linux-kernel@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 X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF151 (Linux)/8.8.12_GA_3809) Thread-Topic: Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support" Thread-Index: AQHdBRJ8+HvBPYSwmEi4Lf0sk+8LHLZV9jcAgADe8oCAAER1AIAAEDcAgACAk4CAAQSDAIAAFjqAgAAHAgDqoturHg== ----- Urspr=C3=BCngliche Mail ----- > Von: "Chris Packham" >>> On Wed, 2026-07-01 at 09:49 +0000, Takahiro.Kuwano@infineon.com wrote: >>>> I didn't mean any kernel features, but we can dump tmpfs contents >>>> from/to FRAM chip (exposed as NVMEM device) by 'dd'. Doesn't it meet >>>> your system's requirement? >>> Do you mean something like creating a tmpfs and then say, using `tar` >>> and copying the data to nvmem with dd and restoring this data at boot? >> Yes, I meant something like that (sorry, my comment was still not clear)= . >> Hope that's worth considering. >=20 > It won't quite work. Because we have requirements involving ensuring > when a file is erased it is gone ASAP (i.e. shred). It's all a bit of > security theater because in reality the safest thing would be to keep > such secrets in a TPM or protected with a key stored in a TPM. Do you really need (POSIX) file system semantics? You could partition the FRAM into cells and then work with them. e.g. Just dd into it and erase it when needed... Maybe the NVMEM cells mechanism needs some polishing but this sounds reasonable to me. Thanks, //richard