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 02AB6C433EF for ; Sat, 9 Oct 2021 09:42: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 E06A060F5E for ; Sat, 9 Oct 2021 09:42:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E06A060F5E 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 C08728364A; Sat, 9 Oct 2021 11:42: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="sBkY/Nui"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E270C83625; Sat, 9 Oct 2021 11:42: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 4491A8364A for ; Sat, 9 Oct 2021 11:42:45 +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 8C87E60F5E; Sat, 9 Oct 2021 09:42:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633772563; bh=YgLtJYrLCRzx8Wsn1n7ACh8EEQqqmERH3ipzjy0QVnk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sBkY/NuiVqme7RauNJIX7liGX7QtZtaQaQ0g2LajiFicCb++sMj/HQeS0nCCBQZmY hb4/L5PBQh8qnyaJn6NvHLPT0bp8zGwCYI/EcDjCB/dxHuREhIVyjVccvrog8M1IcO ti9zkBI+emimnfm0SEUS3tiNyUfkMgsr8aVzYZ+saCHPEsIf0ESMREV/UDUUERsumP TI/zAP/u1r4UuzM6Oiv7UjElc093yzcBW6LkhDO8DBAeq+n5ekmMMvNoZbprrpsCHW RT4XZ6Fc7t/rZhVWxDi2yMMcbk8LOVgGzUnSo3PlQPg8SqswZudVtey8Zxzp2zqbnv fhGoUw1NlRZpQ== Date: Sat, 9 Oct 2021 11:42:38 +0200 From: Marek =?UTF-8?B?QmVow7pu?= To: Pali =?UTF-8?B?Um9ow6Fy?= Cc: Luka Kovacic , Robert Marko , u-boot@lists.denx.de, Stefan Roese , Luka Perkov Subject: Re: [PATCH 1/2] arm: mvebu: Implement the mac command (Marvell hw_info) Message-ID: <20211009114238.749090e8@thinkpad> In-Reply-To: <20211008180629.vw2azj7k7ydg67sr@pali> References: <20211008120924.247765-1-robert.marko@sartura.hr> <20211008125355.y7dwnpt4tfbnfbyj@pali> <20211008180629.vw2azj7k7ydg67sr@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 > > > > +config MVEBU_MAC_HW_INFO_OFFSET > > > > + hex "Marvell hw_info (mac) SPI flash offset" > > > > + depends on MVEBU_MAC_HW_INFO > > > > + default 0x3E0000 > > > > + help > > > > + This option defines the SPI flash offset of the Marvell > > > > + hw_info area. This defaults to 0x3E0000 on most Armada > > > > + A3720 platforms. > > > > > > Have you tried to specify this offset directly into DTS file? Because > > > in DTS file is already specified this hw info partition and it seems > > > like that this kind of information belongs to DTS. > > > > I haven't encountered a board, which has a different offset so far. > > This can be treated as a nicer way of defining this offset, rather > > than just hard-coding it in the source code itself. > > > > In case there are more boards with this partition, a way of defining > > the offset in the DTS can be added later and this value can then > > be used as a default. > > +Marek > > My understanding is that all these definitions, like memory address > spaces, partitions, etc... belong to DTS file (or plat structures for > boards which do not use DT) and not into source code or config options > as they are describing hw layout. > > There is ongoing process to move / convert SPI partitions from source > files and config defines into DTS files, so for me this looks like a > step backward... > > But I would like to hear opinion also from other people. This should be done in device tree. Device tree has bindings for such things. You should be able to do something like this: spi-flash@1 { partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; board_info: board-info@3E0000 { compatible = "nvmem-cells"; label = "board-info"; reg = <0x3E0000 0x1000>; read-only; #address-cells = <1>; #size-cells = <1>; mac_addr_eth0: mac-addr1@0 { reg = <0x0 0x6>; }; mac_addr_eth1: mac-addr2@1 { reg = <0x6 0x6>; }; }; }; }; ethernet@30000 { nvmem-cells = <&mac_addr_eth0>; nvmem-cell-names = "mac-address"; }; Look at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml Also we need to add nvmem API into U-Boot and get rid of the ad-hoc efuse/mac/hw_mac nonsense. Marek