From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6046EC433FE for ; Wed, 13 Oct 2021 14:45:08 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9233661166 for ; Wed, 13 Oct 2021 14:45:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9233661166 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C76B983590; Wed, 13 Oct 2021 16:45:04 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="aCnvn6eJ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id F106383347; Wed, 13 Oct 2021 16:45:02 +0200 (CEST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 6318B835A1 for ; Wed, 13 Oct 2021 16:44:57 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=kabel@kernel.org Received: by mail.kernel.org (Postfix) with ESMTPSA id 739B061175; Wed, 13 Oct 2021 14:44:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1634136295; bh=yXzTBFbf0M7fBEX8L2nlrrl750ZF7D63jPoYZHZciQU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aCnvn6eJijClSAqEYZu5OOixfhLJ8hjfqvl5yX/e7+fXhcMP9ntoXklP6lOhsLQHL iuu4LYzzCVVeCadGfXv/GWqP0Ht4Ns2zw5clfeXhJMmW/DDELvsguRal5GoWh0wIrl gm5v2HFBBLBH0ezU97dwl6wh5HkdY91GQfQ+C4OGsOXj0Kdp/ALB3IDpXxP3dimrVa riGjpyk67XDjroYxVtZWl4H1rHML+TtBvozXdxXgc6wTlynUtPHOHhi8rPvUOPKoqp KT+r0E0DIzq73TVCi2qKQLt9mhJ2cz+5uE2m/hT7KPHeZ+ytEs6XuxkbGut3+iCRFH h196UcfZVh1sA== Date: Wed, 13 Oct 2021 16:44:51 +0200 From: Marek =?UTF-8?B?QmVow7pu?= To: Luka Kovacic Cc: Pali =?UTF-8?B?Um9ow6Fy?= , Robert Marko , U-Boot-Denx , Stefan Roese , Luka Perkov Subject: Re: [PATCH 1/2] arm: mvebu: Implement the mac command (Marvell hw_info) Message-ID: <20211013164451.2c763e83@dellmb> In-Reply-To: References: <20211008120924.247765-1-robert.marko@sartura.hr> <20211008125355.y7dwnpt4tfbnfbyj@pali> <20211008180629.vw2azj7k7ydg67sr@pali> <20211009114238.749090e8@thinkpad> <20211009102923.ciosatafanhqdssq@pali> <20211011125634.32dab223@dellmb> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On Mon, 11 Oct 2021 18:16:02 +0200 Luka Kovacic wrote: >> eth1_mac_addr: eth1addr { >> compatible = "mac-address-string"; >> name = "eth1addr"; >> }; > > I don't see any better approach than just matching strings to retrieve > values for specific keys (for MACs), so this looks good to me. The `name` property can be omitted, the node name should be used, since it is unique both in DT and in env. MAC addresses will need a special compatible property so that the nvmem driver knows to convert them from 'XX:XX:XX:XX:XX:XX' string to 6-byte value. > I agree, a real nvmem API would be much cleaner than the current > U-Boot implementation, as there is currently no way to > programmatically access these parameters and the implementations have > different user interfaces. > > As there is currently no nvmem framework, I recommend that the basic, > futureproof DT bindings are defined and DT parsing is temporarily > implemented in the hw_info mac command. What do you think? Yes, that is acceptable. > Is anyone already working on a nvmem framework to support nvmem > providers in U-Boot? AFAIK no, but I am planning to look into this. In the meantime implement the hw_info mac command. I will send proposal for dt-binding. Marek