Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp558020iof; Mon, 6 Jun 2022 08:28:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxEtoaAVOVgNAOS6rXo9aqCNYyev6OGHk3oFd/og+N3INiKUq8LY4FjbZN73e4o512AOM28 X-Received: by 2002:a17:903:248:b0:155:e8c6:8770 with SMTP id j8-20020a170903024800b00155e8c68770mr24008605plh.129.1654529321234; Mon, 06 Jun 2022 08:28:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654529321; cv=none; d=google.com; s=arc-20160816; b=DfW0Rn6i5k1Aus7EwYjMEOVM8xgIafMhqrViCdoK/IXTpd4jpTm/oa0BQn6Be7jPCd DUXRooA2dj3X6o99X0vu+XhlWVpeISKJYSOcmkWnmiSvUDFw2VQqfB2FXAoKYrYB+Lm+ utcaeQNVBCKM8K5CcN7A6wV4/kY4dnNGxXdBtgkNBzcZ7L/pw5Pxr+TeuIojQaA8H+Wm 7XUorztTasmMZ0d0PHWfSTOyadkzJtBPpYcmE/SId8EZCrc8EBkGqu5biqbvXzbWgGyL lN7GutSUVrRiyqeLQubWKdqskuvf6RJevYywkrLSnLJYFCMFNkMsQBYSYh9NTrYKve22 JswQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:to:from:dkim-signature; bh=9WxVflAaLaQGVLZDTYjr1bfsD9KjPcYDpao0PwOqVUc=; b=U/+aJM05fOsyFPypyvBAJ5nr10sLnE6ICXqpgxxgxKlWUjRtcKJxjASo41RRLjbsJJ WTA4TJOthsoPdJFhwigboJCGutXAtTTumrLXKRrau6RgZaxM6xJxF9YD6C+fF6fqeJ9Z fGU4ffE4yIpWfqNGLvDlIbAFiZbLNJT86f2r+kn8umyTZPON2PcGKeQPtQ4DJvpxlCw6 jqrVHbF6mkOc3BvJDN+Krojg/Js/NcwXX/O7SROPPME2lghRz12X+fKe0MKkIty194cF haPrjCqCWvJRT7TWT+OupXLOfrtMF2+fy32CPxLAvpkT3WpbL4Zr3q+swVpWW8KBibP4 C0OA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=NX12efPE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id w23-20020a170902d71700b001640bfb2b6dsi19620319ply.70.2022.06.06.08.28.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jun 2022 08:28:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=NX12efPE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 717B613B2F8; Mon, 6 Jun 2022 08:15:12 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240354AbiFFPOo (ORCPT + 99 others); Mon, 6 Jun 2022 11:14:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47744 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240340AbiFFPOm (ORCPT ); Mon, 6 Jun 2022 11:14:42 -0400 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DB51102753; Mon, 6 Jun 2022 08:14:41 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id kq6so16560459ejb.11; Mon, 06 Jun 2022 08:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=9WxVflAaLaQGVLZDTYjr1bfsD9KjPcYDpao0PwOqVUc=; b=NX12efPEOw77FAgI0EpL6qcSUxPue8/LVvXK9QbgUpJVaK3qv88l6h2tQZVbnbB2yu GkUeXNMCDyVgA20UpT/iVnJJh2DbilU2A4w0kZ/5TbMWW0dHYHtOE/+hf/TIyZtvkQvT ZrNjULLfeEcahHtbhykUyy3jAshh3eZ5fvFT7Q5Zo6YvZtT2e+sYo6064RPK035zjsTP fgggUgPCL2iVeSboRaM7hx1BUvODAzevS127njr+aQ38c/S5umEU7holMW9+LOuB2/o3 sFacaOC2y8MBEVOZKS/QDowghmgaZfRvZdvaS+F2dsJyzjwB4AmGiy3fGKC1atVySPLA KTtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=9WxVflAaLaQGVLZDTYjr1bfsD9KjPcYDpao0PwOqVUc=; b=qbdX6IG0EEWU5yaGdPhUhQ7lCJAoGKhAp1OzUnqdCvG+W5wx9ANQ5A8zHhquUvDKQ2 7DiZ5CKUbirICIzisouqrXhC8LHDg7bnf16/vVB4gqVb5DkEwRBSHCSs3yzaiXrT5vu8 HPrmRLYkl84ZHv8f3Jgv7xcQLvb3/OZnN2f4mDcK0cInGmJtglKqxFfMiLMT2J6njUj+ pFYU7aNgIhWoVTllKOtN7/hJzEoeneT9Qfr9j9bKsN9BO7WSOeFqlL8STKkR7OIE+vx4 6Rvtsil9E/8vc2uj2SG0hdOEajCFFpL7wX37UVaXf32nX6psQ1HFE2FjIOYHflBml/qM Vu5Q== X-Gm-Message-State: AOAM533IjENfQAuyBxFDsHAPeYZpFyl3A2W7Fba/yJfAVH708jqwNxYy qjX+1VFuHH9ZteJ2jeUbYtE= X-Received: by 2002:a17:907:608f:b0:6f6:1155:99ab with SMTP id ht15-20020a170907608f00b006f6115599abmr21289023ejc.306.1654528479498; Mon, 06 Jun 2022 08:14:39 -0700 (PDT) Received: from localhost.localdomain (93-42-70-190.ip85.fastwebnet.it. [93.42.70.190]) by smtp.googlemail.com with ESMTPSA id be5-20020a0564021a2500b0042e09f44f81sm7494001edb.38.2022.06.06.08.14.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jun 2022 08:14:38 -0700 (PDT) From: Ansuel Smith To: Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Rob Herring , Krzysztof Kozlowski , Greg Kroah-Hartman , Jens Axboe , Ansuel Smith , =?UTF-8?q?=EF=BF=BDecki?= , Manivannan Sadhasivam , linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v5 0/3] Add nvmem support for dynamic partitions Date: Mon, 6 Jun 2022 17:14:14 +0200 Message-Id: <20220606151417.19227-1-ansuelsmth@gmail.com> X-Mailer: git-send-email 2.36.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This very small series comes to fix the very annyoing problem of partitions declared by parser at runtime NOT supporting nvmem cells definition. The current implementation is very generic. The idea is to provide an of node if defined for everyone and not strictly limit this to nvmem stuff. But still the actual change is done only for nvmem-cells mtd. (just to make sure) This can totally change by removing the compatible check. The idea here is that a user can still use these dynamic parsers instead of declaring a fixed-partition and also declare how nvmem-cells are defined for the partition. This live with the assumption that dynamic partition have always the same name and they are known. (this is the case for smem-part partition that would require a bootloader reflash to change and for parsers like cmdlinepart where the name is always the same.) With this assumption, it's easy to fix this problem. Just introduce a new partition node that will declare just these special partition. Mtdcore then will check if these special declaration are present and connect the dynamic partition with the OF node present in the dts. Nvmem will automagically find the OF node and cells will be works based on the data provided by the parser. The initial idea was to create a special nvmem driver with a special compatible where a user would declare the mtd partition name and this driver would search it and register the nvmem cells but that became difficult really fast, mtd notifier system is problematic for this kind of stuff. So here is the better implementation. A variant of this is already tested on openwrt where we have devices that use cmdlinepart. (that current variant have defined in the dts the exact copy of cmdlinepart in the fixed-partition scheme and we patched the cmdlinepart parser to scan this fixed-partition node (that is ignored as cmdlinepart have priority) and connect the dynamic partition with the dts node) I provided an example of this in the documentation commit. In short it's needed to add to the partitions where the compatible parser is declared, a partition with just the label declared (instead of the reg). Then declare some nvmem-cells and it will all work at runtime. Mtdcore will check if a node with the same label is present and assign an OF node to the MTD. I currently tested this on my device that have smem-part and the gmac driver use nvmem to get the mac-address. This works correctly and the same address is provided. v5: - Simplify Documentation and move it generic partition.yaml - Split commit and move smem example to dedicated commit. v4: - Make it simple. No suffix. Make label mandatory again. - Update Documentation with new implementation. - Rename files to a better and correct name v3: - Fix warning from bot (function not declared as static) - Updated code to support also node name - Made partition label optional v2: - Simplify this. Drop dynamic-partition - Fix problem with parser with ko - Do not pollude mtd_get_of_node - Fix problem with Documentation Ansuel Smith (3): dt-bindings: mtd: partitions: Support label only partition dt-bindings: mtd: partitions: add additional example for qcom,smem-part mtd: core: introduce of support for dynamic partitions .../bindings/mtd/partitions/partition.yaml | 16 +++++- .../mtd/partitions/qcom,smem-part.yaml | 27 ++++++++++ drivers/mtd/mtdcore.c | 49 +++++++++++++++++++ 3 files changed, 90 insertions(+), 2 deletions(-) -- 2.36.1