Message ID | cover.1702770711.git.daniel@makrotopia.org |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-2404-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:24d3:b0:fb:cd0c:d3e with SMTP id r19csp477499dyi; Sat, 16 Dec 2023 16:10:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IEfVNYL3UZ8DKLdc82Gmm8bIaJlI3Ewa/p+5C3beYZ8tSpMmsruSwsMPLtUxgth60IcWqnY X-Received: by 2002:a05:6808:1708:b0:3b8:bb04:dab5 with SMTP id bc8-20020a056808170800b003b8bb04dab5mr15094248oib.52.1702771808750; Sat, 16 Dec 2023 16:10:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702771808; cv=none; d=google.com; s=arc-20160816; b=0nbnItUKeefMN4/ta7K5cYGq96B0Liusb7V8elg+AwwNA1nNW5wf+Foc5q0uk8BKvi 9oQfSkbkDDXfWktbunnbge/105aXXsmlPslhM2bVvf4TdmA3TX6zKB6NKHmkLjTNolUb nzVY+m7vnSFw7jChzjuGn4qMz8arfKrMfp2DsorVAfphwvY5CVyKxNREvyg6q1GHRoqm ii20+B6v+TK1vbEDwjt+wyAVyoTfO4FyDZj9cebaa3fH00dR9ci1DNu/Odr2/GLtN7AR IODVarCwnScbDbaFOJLeRuiq4GdhCzsTetd/pMt2sQowi8A3qgdu3C1DC9E/rP9E2gEQ jjkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-disposition:mime-version:list-unsubscribe:list-subscribe :list-id:precedence:message-id:subject:to:from:date; bh=oWBqoejGpdrbaJR78PMPafG4i7PNDrKjb6OHwkDYexQ=; fh=5bIxX+8Q2F12pGFVmnG3HzpNbtBBrVn5m/ZU/0LXEV8=; b=YC+zICz3wdHMQwittEpk12LR/Pr5R5J+3TcCfXTcIsNaMaoUOLkTgg9JOVj2rDgyDY jrALAXkYhfKs/L3GpZt+yxJVKrqloyGjBi55u2VJBi+yhV7xAq+8BiZ5+n8KnCiBXfT2 1dL1Ai8mUBMOZTaO+EM5RIy4LBCQx0wYubWHZAaSjOdYgvO47TQrkFM0BdWY7jPf0xE1 EZM+iDQaiWGr0wNe3xG2P4S9cCVuIPHIBAGoFntqbx4V/X8qq8tp0EoPqkuFF0jbL03y vQuvLyIGmWWLVWGHhLkpV49ZsnzODiZKgrwpIosm6gsHjeZGvYOEksa/gTWTaHj15kDQ QUzQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-2404-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-2404-ouuuleilei=gmail.com@vger.kernel.org" Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id y129-20020a62ce87000000b006d517288f59si587869pfg.220.2023.12.16.16.10.08 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Dec 2023 16:10:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-2404-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-2404-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-2404-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 7D42B283C8B for <ouuuleilei@gmail.com>; Sun, 17 Dec 2023 00:10:08 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 39772ED8; Sun, 17 Dec 2023 00:09:53 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org 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 C850E366; Sun, 17 Dec 2023 00:09:49 +0000 (UTC) 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 <daniel@makrotopia.org>) id 1rEeie-00064Q-1p; Sun, 17 Dec 2023 00:09:21 +0000 Date: Sun, 17 Dec 2023 00:09:18 +0000 From: Daniel Golle <daniel@makrotopia.org> To: Miquel Raynal <miquel.raynal@bootlin.com>, Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Daniel Golle <daniel@makrotopia.org>, =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= <rafal@milecki.pl>, linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v5 0/7] mtd: ubi: allow UBI volumes to provide NVMEM Message-ID: <cover.1702770711.git.daniel@makrotopia.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785485651999294089 X-GMAIL-MSGID: 1785485651999294089 |
Series |
mtd: ubi: allow UBI volumes to provide NVMEM
|
|
Message
Daniel Golle
Dec. 17, 2023, 12:09 a.m. UTC
Similar to how MAC addresses and Wi-Fi calibration data would be stored inside an MTD partition on devices coming with NOR flash, a UBI volume is used by some vendors in the same way on devices with NAND flash. The goal of this series is to support such embedded Linux devices which got NVMEM bits stored inside a UBI volume. Representing the UBI volume in the Device Tree and adding a phandle to be referenced by NVMEM consumers allows such devices to come up with their correct MAC addresses and device-specific Wi-Fi calibration data loaded. In order for NVMEM bits to be available for other drivers, attaching UBI devices has to be moved from late_initcall (which is too late for other drivers) to happen earlier. As an alternative to the existing kernel cmdline parameter the Device Tree property 'compatible = "linux,ubi";' inside an MTD partition can be used to have that MTD device attached as UBI device. MTD partitions which serve as UBI devices may have a "volumes" subnode with volumes, and volumes may have an "nvmem-layout" object which will trigger the creation of an emulated NVMEM device on top of the UBI volume. In this way, other drivers (think: Ethernet, Wi-Fi) can resolve and acquire NVMEM bits using the usual device tree phandle, just this time the NVMEM content is read from a UBI volume. This series is a follow-up and contains most patches of the previous series "mtd: ubi: behave like a good MTD citizen"[1] which was meant in preparation for implementing the NVMEM provider. [1]: https://patchwork.ozlabs.org/project/linux-mtd/list/?series=353177&state=%2A&archive=both Changes since v4: * split ubi_open_volume_path() breaking out reusable parts for new match_volume_desc() function as suggested by Richard Weinberger. Doing the same for ubi_open_volume_nm() doesn't work as we are working on struct ubi_volume_info in match_volume_desc() while ubi_open_volume_nm() is working on struct ubi_volume. That reduces the common part to a string comparision and length check which doesn't seem worth breaking out of the existing function. * drop patches and changes not strictly needed for NVMEM use-case: - don't handle ubi detach on MTD removal notification. It was not done until now and the locking hell I was facing when trying to implement that is non trivial. - don't relocate the call to ubiblock device creation to the notification handler - change ubiblock only as far as needed to handle creation from cmdline parameter when a volume is added. * improve commit messages and comments Changes since v3: * dt-bindings fixes as requested Changes since v2: * include dt-bindings additions Changes since v1: * include patch to fix exiting Kconfig formatting issues * fix typo and indentation in Kconfig Daniel Golle (7): dt-bindings: mtd: add basic bindings for UBI dt-bindings: mtd: ubi-volume: allow UBI volumes to provide NVMEM mtd: ubi: block: use notifier to create ubiblock from parameter mtd: ubi: attach from device tree mtd: ubi: introduce pre-removal notification for UBI volumes mtd: ubi: populate ubi volume fwnode mtd: ubi: provide NVMEM layer over UBI volumes .../bindings/mtd/partitions/linux,ubi.yaml | 75 +++++++ .../bindings/mtd/partitions/ubi-volume.yaml | 40 ++++ drivers/mtd/ubi/Kconfig | 12 ++ drivers/mtd/ubi/Makefile | 1 + drivers/mtd/ubi/block.c | 136 ++++++------- drivers/mtd/ubi/build.c | 154 ++++++++++---- drivers/mtd/ubi/kapi.c | 56 ++++-- drivers/mtd/ubi/nvmem.c | 188 ++++++++++++++++++ drivers/mtd/ubi/ubi.h | 3 + drivers/mtd/ubi/vmt.c | 44 +++- include/linux/mtd/ubi.h | 2 + 11 files changed, 579 insertions(+), 132 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/partitions/linux,ubi.yaml create mode 100644 Documentation/devicetree/bindings/mtd/partitions/ubi-volume.yaml create mode 100644 drivers/mtd/ubi/nvmem.c