From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 009.lax.mailroute.net (009.lax.mailroute.net [199.89.1.12]) (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 34BCA78B47; Fri, 22 Mar 2024 19:20:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=199.89.1.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711135205; cv=none; b=fUF+i2G0+lr5n5rdBSYNXBRMBVr21y6h5mGAaxMvGQ/ZlwXVsWA3yhdFmCHGWAMkBBkjoBhJf3ZMrEMwOHLdnd60mZ3N7Z3+zR1CcbDX2yktv/V6+E5CO1AkbMHMxzQ7SgzU6D4IWxs0evOmfrmryhpz6oQvRBXT4oT9tGIQYBQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711135205; c=relaxed/simple; bh=Djvbgk8eOBHycf42hxOtBMANTsV5hvKlJFnxU1y09+0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Td0mizmsc+VWXRslY3ErCgbQUGKOENn7tTeWazD7S75OEDYGc8nDsOlB21J9d7F2F/Yls8yTSYumcmZs28IoQILxhXZHkyHcEbVBubpi37m2P852a66C9SmFiItoOGCXiQ9dN9tAluHOBe3a7wSp4lfo3kakPLtR+orkdSmhQW8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=acm.org; spf=pass smtp.mailfrom=acm.org; dkim=pass (2048-bit key) header.d=acm.org header.i=@acm.org header.b=XBx6eZgU; arc=none smtp.client-ip=199.89.1.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=acm.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=acm.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=acm.org header.i=@acm.org header.b="XBx6eZgU" Received: from localhost (localhost [127.0.0.1]) by 009.lax.mailroute.net (Postfix) with ESMTP id 4V1XGB2MyVzlgVnF; Fri, 22 Mar 2024 19:20:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acm.org; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject :user-agent:mime-version:date:date:message-id:received:received; s=mr01; t=1711135191; x=1713727192; bh=25gd1LQ6Hyviw81xPbwTGNqw rAIn+WLE53FkTKTaE5Q=; b=XBx6eZgU3JSstw3QF+AJu+rKZ05Lqh4HGRUUSQeI X68GeC6FZ7jEibaQuYEjMF8A5aTvsoySUdZXnjNtGsHi13xFW3X1FTewwtIIxP7F NyM+AULWwWqL3Vk5lQnBMtkn2RWES5BKse1KSWtOuhnUGSuyimxCpfkfBVdU3UZr 76L0RRTR+U/i6BJ/Xg0ZAwruLOvOpAR0fgxL7mRPA9bSEryHrfVGK1E4oEjimN5e rG/6Cjdu2fvBVoWdoW+XlifFZn00CfSO45xrgxy7IoSgN7odLpWblDz7BhD1AVTi IOe5/zg20Dw+s3XcctoXnDQwDljdFLALYin39RWs44gUsw== X-Virus-Scanned: by MailRoute Received: from 009.lax.mailroute.net ([127.0.0.1]) by localhost (009.lax [127.0.0.1]) (mroute_mailscanner, port 10029) with LMTP id RPnP1GeUiYtK; Fri, 22 Mar 2024 19:19:51 +0000 (UTC) Received: from [100.96.154.173] (unknown [104.132.1.77]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bvanassche@acm.org) by 009.lax.mailroute.net (Postfix) with ESMTPSA id 4V1XFw69BpzlgTGW; Fri, 22 Mar 2024 19:19:48 +0000 (UTC) Message-ID: <6a59ac6e-cc1f-46de-92d7-f017082d99d2@acm.org> Date: Fri, 22 Mar 2024 12:19:47 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/8] block: implement NVMEM provider Content-Language: en-US To: Daniel Golle Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Ulf Hansson , Jens Axboe , Dave Chinner , Jan Kara , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , Damien Le Moal , Li Lingfeng , Christian Brauner , Christian Heusel , Min Li , Adrian Hunter , Avri Altman , Hannes Reinecke , Christian Loehle , Bean Huo , Yeqi Fu , Victor Shih , Christophe JAILLET , Dominique Martinet , "Ricardo B. Marliere" , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org, linux-block@vger.kernel.org References: From: Bart Van Assche In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/22/24 11:02, Daniel Golle wrote: > On Fri, Mar 22, 2024 at 10:52:17AM -0700, Bart Van Assche wrote: >> On 3/21/24 12:31, Daniel Golle wrote: >>> On embedded devices using an eMMC it is common that one or more (hw/sw) >>> partitions on the eMMC are used to store MAC addresses and Wi-Fi >>> calibration EEPROM data. >>> >>> Implement an NVMEM provider backed by a block device as typically the >>> NVMEM framework is used to have kernel drivers read and use binary data >>> from EEPROMs, efuses, flash memory (MTD), ... >>> >>> In order to be able to reference hardware partitions on an eMMC, add code >>> to bind each hardware partition to a specific firmware subnode. >>> >>> Overall, this enables uniform handling across practially all flash >>> storage types used for this purpose (MTD, UBI, and now also MMC). >>> >>> As part of this series it was necessary to define a device tree schema >>> for block devices and partitions on them, which (similar to how it now >>> works also for UBI volumes) can be matched by one or more properties. >> >> Since this patch series adds code that opens partitions and reads >> from partitions, can that part of the functionality be implemented in >> user space? There is already a mechanism for notifying user space about >> block device changes, namely udev. > > No. Because it has to happen (e.g. for nfsroot to work) before > userland gets initiated: Without Ethernet MAC address (which if often > stored at some raw offset on a partition or hw-partition of an eMMC), > we don't have a way to use nfsroot (because that requires functional > Ethernet), hence userland won't come up. It's a circular dependency > problem which can only be addressed by making sure that everything > needed for Ethernet to come up is provided by the kernel **before** > rootfs (which can be nfsroot) is mounted. How about the initial RAM disk? I think that's where code should occur that reads calibration data from local storage. Thanks, Bart.