From patchwork Tue Mar 5 20:23:07 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Golle X-Patchwork-Id: 13582983 Received: from pidgin.makrotopia.org (pidgin.makrotopia.org [185.142.180.65]) (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 713381272CC; Tue, 5 Mar 2024 20:24:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.142.180.65 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709670244; cv=none; b=MH8kBei/SGd/7zUQhhdaLrNiPo9GDPlmrXx8kOuAsEfR0D7RT87MohBQ1OfYrOkV/huXxYXU/nrfZpsT8Tmt1fqN33R36iKDAaUdI67qUNeJ5GBZvNgFq9sSomuNLhK72jX60L0HQVHW+tiVtUPuv4PN1BB+BI/3zR+Iw9x3NnA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709670244; c=relaxed/simple; bh=2Xnx+UxJNe1jbb9epdvb8xlWEdXQg0apHljlHnmwwvY=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=AlTbf7m84sbw0hzBNhWiVcVW9qHO4+kLt6cw4F0Q9mZWR4gaZQQu4sKOFXe+9J8ti+fnGBFeUjTfcvqdUFPw9x2TxaT2CGWHsZsq7lSwf+NwA+B/gczJfNwpoHla7YgdE/mOOvgHQNg+gUTYNIUQG0yvB/tP5lMl4nClbeGTLmg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org; spf=pass smtp.mailfrom=makrotopia.org; arc=none smtp.client-ip=185.142.180.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=makrotopia.org Received: from local by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.96.2) (envelope-from ) id 1rhbJf-0001Ly-1n; Tue, 05 Mar 2024 20:23:11 +0000 Date: Tue, 5 Mar 2024 20:23:07 +0000 From: Daniel Golle To: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Ulf Hansson , Jens Axboe , Daniel Golle , Dave Chinner , Jan Kara , Thomas =?iso-8859-1?q?Wei=DFschuh?= , Christian Brauner , Li Lingfeng , Damien Le Moal , Min Li , Adrian Hunter , Hannes Reinecke , Christian Loehle , Avri Altman , Bean Huo , Yeqi Fu , Victor Shih , Christophe JAILLET , "Ricardo B. Marliere" , Greg Kroah-Hartman , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org, linux-block@vger.kernel.org Cc: Diping Zhang , Jianhui Zhao , Jieying Zeng , Chad Monroe , Adam Fox , John Crispin Subject: [RFC PATCH v2 0/8] nvmem: add block device NVMEM provider Message-ID: Precedence: bulk X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline 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 block devices 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. This series is meant to open the discussion on how exactly the device tree schema for block devices and partitions may look like, and even if using the block layer to back the NVMEM device is at all the way to go -- to me it seemed to be a good solution because it will be reuable e.g. for (normal, software GPT or MBR) partitions of an NVMe SSD. This series has previously been submitted on July 19th 2023[1] and most of the basic idea did not change since. However, the recent introduction of bdev_file_open_by_dev() allow to get rid of most use of block layer internals which supposedly was the main objection raised by Christoph Hellwig back then. Most of the other comments received for in the first RFC have also been addressed, however, what remains is the use of class_interface (lacking an alternative way to get notifications about addition or removal of block devices from the system). As this has been criticized in the past I'm specifically interested in suggestions on how to solve this in another way -- ideally without having to implement a whole new way for in-kernel notifications of appearing or disappearing block devices... And, in a way just like in case of MTD and UBI, I believe acting as an NVMEM provider *is* a functionality which belongs to the block layer itself and, other than e.g. filesystems, is inconvenient to implement elsewhere. [1]: https://patchwork.kernel.org/project/linux-block/list/?series=767565 Daniel Golle (8): dt-bindings: block: add basic bindings for block devices block: partitions: populate fwnode block: add new genhd flag GENHD_FL_NVMEM block: implement NVMEM provider dt-bindings: mmc: mmc-card: add block device nodes mmc: core: set card fwnode_handle mmc: block: set fwnode of disk devices mmc: block: set GENHD_FL_NVMEM .../bindings/block/block-device.yaml | 22 +++ .../devicetree/bindings/block/partition.yaml | 51 +++++ .../devicetree/bindings/block/partitions.yaml | 20 ++ .../devicetree/bindings/mmc/mmc-card.yaml | 45 +++++ block/Kconfig | 9 + block/Makefile | 1 + block/blk-nvmem.c | 175 ++++++++++++++++++ block/partitions/core.c | 41 ++++ drivers/mmc/core/block.c | 8 + drivers/mmc/core/bus.c | 2 + include/linux/blkdev.h | 2 + 11 files changed, 376 insertions(+) create mode 100644 Documentation/devicetree/bindings/block/block-device.yaml create mode 100644 Documentation/devicetree/bindings/block/partition.yaml create mode 100644 Documentation/devicetree/bindings/block/partitions.yaml create mode 100644 block/blk-nvmem.c