Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp3098155iob; Fri, 6 May 2022 18:44:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzfUQd/um/QZgN7Htf64UyPgS6+sIE1LcA2MP1+DLpKupeRaHEO1UEnlz5GT0Z3sKYTAVvG X-Received: by 2002:a17:907:9614:b0:6f4:9d1b:3276 with SMTP id gb20-20020a170907961400b006f49d1b3276mr5788179ejc.591.1651887844835; Fri, 06 May 2022 18:44:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651887844; cv=none; d=google.com; s=arc-20160816; b=oxfT8XCkQBWHA2BdpcTTVIbv0C9ntqtPCi8MMGbb/bqZibET886tRdMDtr3Yi6PEVB 3XBySZw2EKsXp0Otzu3r1wQT5Txa6QpEdW8ZKXebua9JmIDzwEfOV63qBho/eASrUEoA iEaHBczWft1KzlVoO+oblOOvK/z4OrQ2jy3qHMZk11c6jY40tMYkzxOpqmTcItjVgXI3 qpnb75d2yUWfxdmjevzt+sQjoVExx1bQA3Kqw16Is6ghVRcjrwf10X/XNCK9iQpu7HDq bZ8/i45ndcL5tJbIfMoNxH1wWGF5Z78GwvCGvAks5DM9TxtSIgqoVyGyVOulBnW/kZh4 CzPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=iNwGBhoS8GK4VqCvzCpoLqNjfpnCZ0bV48mMSCzoXjk=; b=bwjvckARrEmALvfStAGnu7RV5Q7ciKnQhq/kIIMqmPwrwLlAl+1z8bwOSWIJ4WpwfF gKUu7HRTeucQ1d6Gqpq3X1ASgOmiqCkMTPfIDZFmFKS2z/xLVrRjg7FPLG95vBPFR6Kw wuM195kwhEH4AwQe5uEstdSkeRGaPQragBhifrHjrhY+sGR46y6wdWiS/SfwL9FNawJ8 aXxjQqnd681CzsSPgE5G/a3Eg5EG0z42StZHh/CVmrHF0fWHEkWLUoYZDMzVvJpdRWT6 seGGsyOiLYZ0O6OKFYkaeyTA7oZ56KK9N4kHb54gzNY2z5L+qsRZEKCN/e/gOgJ9HqhN D90A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id nb7-20020a1709071c8700b006f3a6944ec1si7924009ejc.857.2022.05.06.18.43.38; Fri, 06 May 2022 18:44:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1391635AbiEFMII (ORCPT + 99 others); Fri, 6 May 2022 08:08:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344614AbiEFMIG (ORCPT ); Fri, 6 May 2022 08:08:06 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A839C64BCE for ; Fri, 6 May 2022 05:04:20 -0700 (PDT) Received: from ptz.office.stw.pengutronix.de ([2a0a:edc0:0:900:1d::77] helo=[127.0.0.1]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1nmwgn-0006Fu-Kp; Fri, 06 May 2022 14:04:05 +0200 Message-ID: <3a70f1d8-468f-3292-2ddb-7ae4cdc07e6d@pengutronix.de> Date: Fri, 6 May 2022 14:04:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH V2] nvmem: add driver handling U-Boot environment variables Content-Language: en-US To: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Srinivas Kandagatla , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra Cc: Tom Rini , linux-mtd@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, u-boot@lists.denx.de, devicetree@vger.kernel.org, =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Pengutronix Kernel Team References: <20220503165658.13932-1-zajec5@gmail.com> <79c7891a-9a68-a111-094d-be9804071a9e@pengutronix.de> <318c0814-7f0b-9798-6998-5039094b010d@gmail.com> From: Ahmad Fatoum In-Reply-To: <318c0814-7f0b-9798-6998-5039094b010d@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2a0a:edc0:0:900:1d::77 X-SA-Exim-Mail-From: a.fatoum@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 Hello Rafał, On 05.05.22 07:46, Rafał Miłecki wrote: > On 4.05.2022 11:23, Ahmad Fatoum wrote: >> Hello Rafał, >> >> On 03.05.22 18:56, Rafał Miłecki wrote: >>> From: Rafał Miłecki >>> >>> U-Boot stores its setup as environment variables. It's a list of >>> key-value pairs stored on flash device with a custom header. >>> >>> This commit adds an NVMEM driver that: >>> 1. Provides NVMEM access to environment vars binary data >>> 2. Extracts variables as NVMEM cells >>> >>> It can be used for: >>> 1. Accessing env variables from user-space >> >> Is this already possible? The only interface I know of is the /nvmem >> file in sysfs, but that one is not per cell, but per device. > > Maybe that wasn't precise enough, I should probably write: > 1. Parsing binary data from user-space > > In future I'd like to extend U-Boot's "printenv" tool to support reading > env variables blob using Linux's sysfs as documented in the > Documentation/ABI/stable/sysfs-bus-nvmem So, would you use this interface just to save fw_printenv the hassle of finding the environment (but redoing parsing) or do you intend to preprocess the data too? (e.g. only show the active environment) For your use case, it sound like teaching NVMEM core to export cells as binary sysfs files would be very useful. >>> +    label = of_get_property(np->parent, "label", NULL); >>> +    if (!label) >>> +        label = np->parent->name; >>> + >>> +    priv->mtd = get_mtd_device_nm(label); >>> +    if (IS_ERR(priv->mtd)) { >>> +        dev_err(dev, "Failed to find \"%s\" MTD device: %ld\n", label, PTR_ERR(priv->mtd)); >>> +        return PTR_ERR(priv->mtd); >>> +    } >> >> I am trying to make sense of this using the binding, but I can't. >> Do you have an example device tree fragment? > > This comes from unreleased yet board I'm working on. > > It stores U-Boot env variables in the middle of U-Boot binary. Huh, that's an odd layout. I am not sure whether of_get_property to arrive at the parent is such a good idea though. Doesn't it enforce a limitation that there must not exist two partitions with the same label? Some systems can have a second recovery bootloader for example. Given that these are device tree nodes, wouldn't it be possible to find the MTD by device tree parent instead of via its label? > partitions { >     compatible = "fixed-partitions"; >     #address-cells = <1>; >     #size-cells = <1>; > >     partition@0 { >         label = "loader"; >         reg = <0x0 0x100000>; > >         partition@40000 { >             compatible = "u-boot,env"; >             label = "u-boot-env"; >             reg = <0x40000 0x4000>; >         }; >     }; > >     partition@100000 { >         label = "image"; >         reg = <0x100000 0x1fe00000>; >     }; > }; Thanks, Ahmad -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |