From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-180.mta0.migadu.com (out-180.mta0.migadu.com [91.218.175.180]) (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 10AB72E612E for ; Fri, 13 Mar 2026 10:17:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773397024; cv=none; b=py34LFDZboOTAI2rThRmG4nDJAnLX94XKR+mYoPBC7QjMOJ5jcZVGRoxdNz5s5W4J3e1PzWPcm9e63Q0WOoY/VaKdqcr78iMUkfV2whkP904/q2GoNj4iqUxsF3+3NVGf2Aoe6C0SSBRdPkdnvx/LpNfYFsCJsD44GCut2jJ7DI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773397024; c=relaxed/simple; bh=UlGqmig2IhtNH6TCS3uoqoe8axDQ+o7JoHe7fBCIaBw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bX0r+FdKYX+FhVMGcjKNI+Xkr5ywbwxejNFCDzXC861q/x32Vkglg+ZGakKW67vJ0WHjP1EKNUayqausHAmGbViu75BIGXgNERe7wenPNMNhz50kzZduGzuGhcCeiDyzHIrGYgM8Asw+czQ03fdY9BdULnluGpKiCjFEKMmGFck= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool; spf=pass smtp.mailfrom=packett.cool; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b=qMFR/wGM; arc=none smtp.client-ip=91.218.175.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=packett.cool Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b="qMFR/wGM" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packett.cool; s=key1; t=1773397021; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cnv2zs1n1NJvvwgzygTG+a3peXBLg5pti3my1UnuhZ0=; b=qMFR/wGM1bTY3Y0t3IVpsJ9hSEoJ9JlEM6tNvs5lZQmXRV7FXke71RM6wXNtnwPaoEpICP 3XLw+Crc7sjc1FbE5nM52DcMHVZ5X0wZglmVVrYrSdfrOtiLqhruMghDs2abHvR3C1Un8j 1Kagu06pKKacVctLVXBQtyIC2pEypNtcw+Tt0WqrajiuOW2UVNS+b+fZCDRAd9kcElUy06 J8TKetjXtRsJSksCTgNDArqTe03Ua7tEDhcKaFqNQ8xABqvj7aLNTX1He0PHe4eB+F9gAN XLhlNu+4UGF0PHAq/+AOavQf2N4hg65+u61hmolLWwzIeJAJPWkmArSQj9y7uw== Date: Fri, 13 Mar 2026 07:16:48 -0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v2 0/2] mtd: devices: Qualcomm SCM storage support To: Miquel Raynal , Junhao Xie Cc: Bjorn Andersson , Konrad Dybcio , Richard Weinberger , Vignesh Raghavendra , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, Xilin Wu References: <20260126-scm-storage-v2-v2-0-fa045c7e7699@radxa.com> <86F97239DB3D962C+98826904-6649-4c19-815d-73003c046c14@radxa.com> <87ecn7jin5.fsf@bootlin.com> <8B3AF14A70DEB168+16bb085f-6930-45c2-ab70-83eef50624b5@radxa.com> <87jywthpsj.fsf@bootlin.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Val Packett In-Reply-To: <87jywthpsj.fsf@bootlin.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 2/3/26 11:20 AM, Miquel Raynal wrote: >>>> For something like the "DPP" partition, I think it's better to access it >>>> from userspace than from kernel. >>> If it's a MAC address that you are accessing, direct userspace does not >>> sound like a good fit. If I may, NVMEM cells are there exactly for this >>> purpose: identifying the content of a subpart of a storage device in a >>> storage agnostic way. The NVMEM cells are made available to in-kernel >>> drivers (ie. network devices have all the infrastructure to get the MAC >>> address from there) and their content is also exposed to userspace >>> through sysfs now. >> Qualcomm's SPI-NOR boot firmware uses a GPT partition table. The "DPP" >> partition contains a FAT file system, and the MAC address is stored in >> one of these files. >> >> Because the data is stored inside a filesystem rather than at a fixed >> offset, it does not fit well with the NVMEM model, which assumes simple >> offset-based access. > Not anymore, there are nvmem layouts now that are much more > flexible, so if a network driver shall get this MAC address, it is still > doable. > > Otherwise there is no such need, and in the case of a file in a FAT > filesystem, I guess it is preferable to use mtdblock/ubiblock in order > to expose a block device and mount it from userspace. > > Please note that exposing a FAT filesystem on top of a SPI NOR is very > inappropriate. FAT is a block filesystem, not aware of all the MTD > specificities (like bad blocks). FWIW there is an existing widely used solution (workaround?) for the MAC address: dtbloader reads the DPP partition in UEFI and applies the MAC address as a DT fixup. https://github.com/TravMurav/dtbloader/blob/493e7e82025edddab29fe99c2b6ec566f6e01ac1/src/qcom.c#L260 (But this means that any dtbloader alternative such as the systemd UKI stub must also implement the same thing, which is not great.) Reading that code, it does not seem to be a FAT filesystem exactly? It's something called "RWFS" where files have 49-char long names and a 49-char "vendor" string field that's either "QCOM" or "OEM". Also on the rare older devices that have SNOC WiFi/modem but NVMe storage —basically the Surface Pro X— the modem partitions need to be accessed from userspace (rmtfs) and they're stored on the NOR flash. Well, at least in the WiFi-only case even blank files are enough to replace them :) but for cellular I think the IMEI and stuff is there.. So this all sounds supremely annoying, we have a GPT partitioned flash where some specific partitions should be given to the WiFi&BT drivers (as nvmem cells?) but others should be accessible as mtdblock devices in userspace >_< ~val