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 AA43E25F98B for ; Fri, 3 Jul 2026 05:46:07 +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=1783057570; cv=none; b=VVUp97KL3fCO5Sba46pXPrggaN4yOzeJkUkGowhBPm2XAMstlbIIOfGr+3Hq0JoykBFVzl31WuXi49SfLn/T8bJnFpEfLk4h3uytT+wsZmPzVEp+9jKuK43xhXQEGyAluN3eCGSx0Zg3JX0s9npYVtU/InFWGKZ06lqq2A1dXu8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783057570; c=relaxed/simple; bh=+J9fBWQHKC9dOkVvq/zE18ffCMzzwjXfmB6216cGopw=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=llJXb4hhdFM75czSZq3TmQrtftsV0x6PZJu1Jnik1ps7wyoVNk0fvhVAvv4fMswWeK6zCmIjYzW3HyrxZxVJ+mLiLxL+h7AIAhnhHdJud7sfNRcp2dTMMJt3IPHke+/7dTtPte1zIkCj4o2tbZ5vzpdKuQXrewijxCWoB4vdJ3o= 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 B664C2A87F7; Fri, 3 Jul 2026 07:45:58 +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 8xxTYfod0syk; Fri, 3 Jul 2026 07:45:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 27014FB322; Fri, 3 Jul 2026 07:45:57 +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 0dtgxY-WTfaK; Fri, 3 Jul 2026 07:45:57 +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 0557FD5C97; Fri, 3 Jul 2026 07:45:57 +0200 (CEST) Date: Fri, 3 Jul 2026 07:45:56 +0200 (CEST) From: Richard Weinberger To: Ronan Dalton Cc: Chris Packham , Miquel Raynal , Takahiro Kuwano , pratyush , linux-kernel , Vignesh Raghavendra , linux-mtd , Aryan Srivastava , Michael Walle Message-ID: <183302295.10735.1783057556804.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> <490633873.5619.1782970758317.JavaMail.zimbra@nod.at> 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+8LHLZV9jcAgADe8oCAAER1AIAAEDcAgACAk4CAAQSDAIAAFjqAgAAHAgDqoturHpVef02A8b9b3lU= ----- Urspr=C3=BCngliche Mail ----- > Von: "Ronan Dalton" > On Thu, 2026-07-02 at 07:39 +0200, Richard Weinberger wrote: >> 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. >=20 > Yes, that could work for secrets storage. However we also store > persistent logs and DHCP leases on this flash to minimize read/writes > on the main flash, and this data is stored as files of varying lengths. > A filesystem provides the most straightforward way of storing this data > for us. But the storage (FRAM) you chose is not suitable for any real filesystem. In a previous mail you said you use ext2 on it. I have a hard time to see how using ext2 on top of mtdblock on an FRAM does not end in a disaster. > That's not to say we couldn't develop some system of using the nvmem > device as a backend for this data. This may be something we look at in > the future. Maybe FUSE can help with building a super simple filesystem which provides just enough to fulfill your use case. Thanks, //richard