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 19CA1C433F5 for ; Mon, 11 Oct 2021 10:56:55 +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 3399A60EB4 for ; Mon, 11 Oct 2021 10:56:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3399A60EB4 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 676D583172; Mon, 11 Oct 2021 12:56:51 +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="RPnfm3NB"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D30CE80607; Mon, 11 Oct 2021 12:56:49 +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 DBEF0831DB for ; Mon, 11 Oct 2021 12:56:44 +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 069C461038; Mon, 11 Oct 2021 10:56:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633949801; bh=HoJTiTXF5fThVUa+EzZGaLg+w4JGZs56o+CSloCHLpU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RPnfm3NBSYGrxU7MSN8XFTwRIStDtyMOsAHs70mCZBFumVz8YZ49iqBps64ZRRuw0 xk+0AQnKacEmtbc5kYGJQ9I6PzJUMnmSXL34VYDoaKmt5HiYIaR+TrAnnlOdMwwY7M ktVzi2dcwEK6HQ9R2GzjxuNZgAcKFdBcTS4ke8bw7tREZxreL/ykWRBeeI6+7sKyBt YfLnooWTT3Os5jVeBlb6aHwH1C5pbcqjEYuFxDVCyQg8aMFswd68W/RaS6d0p1fbLc 34pY5+nX2rWiIfwj5NsY2sZ6CP170vPDQmpOCYVFeoV0IvkIK1AYSXMi36UqSA3RAv hioAyVIMtS+lA== Date: Mon, 11 Oct 2021 12:56:34 +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: <20211011125634.32dab223@dellmb> In-Reply-To: References: <20211008120924.247765-1-robert.marko@sartura.hr> <20211008125355.y7dwnpt4tfbnfbyj@pali> <20211008180629.vw2azj7k7ydg67sr@pali> <20211009114238.749090e8@thinkpad> <20211009102923.ciosatafanhqdssq@pali> 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 12:19:07 +0200 Luka Kovacic wrote: > Hello Pali, > > > Something like this? compatible = "marvell,hw-info" > > This compatible string looks good to me. > We will send a new patch version, which implements the discussed DT > functionality. > > > > I am sure Luka knows more about the format than me. > > The Marvell hw_info partition is very similar to the U-Boot > environment. The only difference is in the separator between the > "key=value" pairs, which is 0x20/space in the case of hw_info. > This is also prevents us to hard-code the parameter addresses in the > device tree, because they can move around. > > The checksum is stored before the hw_info environment - this would > have to be investigated further to implement checksum verification. These differences between Marvell's version and U-Boot's standard environment version can be specified in device-tree (via compatible or other properties) and handled by one driver. A driver for nvmem provider of standard U-Boot env could have this binding (with "denx,u-boot-env" as compatible, changing it to "marvell,hw-info" would make it work with spaces instead of '=' as separator): spi-flash { blah blah blah; partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; hw-info@18000 { compatible = "denx,u-boot-env"; reg = <0x18000 0x1000>; label = "hw-info"; eth0_mac_addr: ethaddr { compatible = "mac-address-string"; name = "ethaddr"; }; eth1_mac_addr: eth1addr { compatible = "mac-address-string"; name = "eth1addr"; }; }; }; }; ethernet@30000 { nvmem-cells = <ð0_mac_addr>; nvmem-cell-names = "mac-address"; }; On Turris MOX, we have the MAC address of the device stored in One-Time-Programmable memory accesible only by the secure coprocessor, which Linux communicates with via the turris-mox-rwtm kernel driver. Currently this driver does not register itself as a nvmem provider, and so isn't use by the ethernet controller driver to get MAC addresses. MAC addresses are currently read by U-Boot board code and the controller keeps these to Linux. But I plan to extend the turris-mox-rwtm driver to also provide MAC addresses via nvmem API, and then specify in device-tree ð1 { nvmem-cells = <&rwtm_eth1_mac>; nvmem-cell-names = "address"; }; Maybe in the future you will also want to implement this in Linux. It could be done simply by adding a new type of nvmem provider, with compatible = "marvell,hw-info". Luka, what do you think? Marek