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 AA6AFC433F5 for ; Mon, 25 Oct 2021 22:22:49 +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 0E3CB61039 for ; Mon, 25 Oct 2021 22:22:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0E3CB61039 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 3A5CE8352A; Tue, 26 Oct 2021 00:22:47 +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="fy2hFZKQ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2BCEA83535; Tue, 26 Oct 2021 00:22:45 +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 0004D80F3B for ; Tue, 26 Oct 2021 00:22:41 +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 C616E61039; Mon, 25 Oct 2021 22:22:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1635200558; bh=8uxaicEyNR4/vtd+Iz4JAlytwbskQakkWxWfmP5jyYY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fy2hFZKQ8awKeDNCtmbw04LdpzLuv2GH0CQhqERHJmuYF8LWuYu/Y5cNiLJpPWsay 9AcVMBFxrAI1VLdi6VxeYU+eQPerE8xQ261BGJialJ8onSyqHD71moEB6VfVVGWzAc ++WXqAr52l2mdRSVqalgQi95SRjzLbZij1NLcns1eCswO98sdxG6qMvLYHwhMXYjxv E5tVHwRedlmmTmaH5dqduPHGPmEJHRG0SAsixnehABajRnxz+bSs531Vs/xLG7SgJT lQx0Z7yVtDoaYumZBBzA6nxV5yrLV9MRVztJGFvbU377ns2aPomFWG0pIf7PaKQRNy JgYBiOSn2CW/Q== Date: Tue, 26 Oct 2021 00:22:33 +0200 From: Marek =?UTF-8?B?QmVow7pu?= To: Roman Bacik Cc: U-Boot Mailing List , Bharat Gooty , Joe Hershberger , Ramon Fried Subject: Re: [PATCH v2 1/2] net: brcm: netXtreme driver Message-ID: <20211026002233.21ac0b3a@thinkpad> In-Reply-To: References: <20211022162222.v2.1.I1edaad77041c1300213c307eef6741499504047@changeid> <20211025155838.7b243f1f@thinkpad> 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, 25 Oct 2021 14:35:20 -0700 Roman Bacik wrote: > > - you are introducing custom mechanism for setting / getting PHY > > parameters, via custom specific env variables, for example in the > > set_phy_speed() and set_phy_link() functions, i.e.: > > sprintf(name1, "bnxt_eth%u_phy_speed", bp->cardnum); > > env_set(name1, name); > > > > The whole point of several people in the past few years was to create > > generic mechanisms for such things. We have ethernet PHY DM class, > > you should use this. That way you won't need to introduce custom > > mechanisms to get the infromation, since there are mii/mdio commands. > > These are chip internal settings stored internally in NVM. They are > not modified via mii/mdio. Ah. Well that also shouldn't use custom commands. Unfortunately U-Boot does not have a generic nvmem API yet, but I plan to write nvmem API together with `nvmem` command, which would be generic. As of now, we have the `mac` and `fuse` commands for this (although deprecated and will be removed). If you want to write nvmem interface, you could use the `mac` command. But it will be deprecated once we have nvmem API, would you be willing to rewrite it then? Marek