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 7E8B9C433F5 for ; Mon, 15 Nov 2021 15:08:23 +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 D5A6C63227 for ; Mon, 15 Nov 2021 15:08:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D5A6C63227 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com 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 2FAB4836F0; Mon, 15 Nov 2021 16:08:21 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="RHEjyR+N"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6151182A73; Mon, 15 Nov 2021 16:08:16 +0100 (CET) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 7B3D1836C3 for ; Mon, 15 Nov 2021 16:07:58 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf29.google.com with SMTP id kl8so7005629qvb.3 for ; Mon, 15 Nov 2021 07:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=XE7Axk8lwRK2vhIicdrGJpF8PbQ1yuCgaeKfL6Bkzlc=; b=RHEjyR+NiOzMFuyux9UX7u4+h40xYkRESmFRgVfBApNi/B4Vt9RvlxiglDOVu9aDrC L9KN6zxL15rewR43WFvmkar5sBOR914MQ32TdlloejLIr/tMU54cGa5QToUAoyjsB6jo VA9DvKa93AqdPeIc8omXwiJBvzXHrs6MJyExg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=XE7Axk8lwRK2vhIicdrGJpF8PbQ1yuCgaeKfL6Bkzlc=; b=AxdU11CSPXetRakWaLqzZT67wjhRF8+rOhz2493NZ6Yj3QEOPNKaV+qyHmjO7nHmNm dgrIiSXmS3tJRP//HEndzUKFsWYcsB44sfWSHCIQsLyZpuQoSrAENte448TAkOyq+Dhq scgcGUInxYEv9E0PhuImasddSPxQmHaunM3VwvJDEfRojrkDboLwNGIEEG3faY0a3Apm 68doMHoWdP5CcCVVYf+KdBWZdSsokX3mKUO6MmU4SHLWcpuWu7JjoiJHc3aFhg5A9058 YQvH2PNREtKNRiCnuEPzL+jbGSGWiQ1rQkxM4F86mY4XS/KXrMm2cSyRBfnb8OQxWCTS QCDQ== X-Gm-Message-State: AOAM530+drWDnEPtdbY2JKhO65zRh2jumkz4Qmsk7nA2sEIXYyx6KQsN yEODkAOuWsNYZIwdvDwQACYZjw== X-Google-Smtp-Source: ABdhPJwjs98Iso2vTCQLPIGQSFYTIrzU2zShan/ulEj+pr/FPaQOeWSmoVM8/qZJNBOsbfXBHT5FAQ== X-Received: by 2002:a05:6214:2482:: with SMTP id gi2mr37094860qvb.59.1636988877031; Mon, 15 Nov 2021 07:07:57 -0800 (PST) Received: from bill-the-cat (2603-6081-7b01-cbda-a11d-dcbb-3b4b-1025.res6.spectrum.com. [2603:6081:7b01:cbda:a11d:dcbb:3b4b:1025]) by smtp.gmail.com with ESMTPSA id m1sm4898119qtk.34.2021.11.15.07.07.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Nov 2021 07:07:56 -0800 (PST) Date: Mon, 15 Nov 2021 10:07:53 -0500 From: Tom Rini To: Michal Simek Cc: Michael Walle , Wolfgang Denk , Marek Vasut , u-boot@lists.denx.de, Grygorii Strashko , fried.dev@gmail.com, joe.hershberger@ni.com, sjg@chromium.org Subject: Re: [PATCH RFC] cmd: fix net list command Message-ID: <20211115150753.GL24579@bill-the-cat> References: <20211115121152.3470910-1-michael@walle.cc> <32aff992-c84b-7b71-b412-7594c2a7d20e@denx.de> <257391f0-9d69-62cc-2353-8f4fc0751d7d@denx.de> <1646331.1636986670@gemini.denx.de> <2a51974b-41cf-56e4-c9c9-e6b699f27f5c@xilinx.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6qzkV7f8p1C1UmUU" Content-Disposition: inline In-Reply-To: <2a51974b-41cf-56e4-c9c9-e6b699f27f5c@xilinx.com> X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.35 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 --6qzkV7f8p1C1UmUU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 15, 2021 at 03:57:51PM +0100, Michal Simek wrote: >=20 >=20 > On 11/15/21 15:52, Michael Walle wrote: > > Hi, > >=20 > > Am 2021-11-15 15:31, schrieb Wolfgang Denk: > > > In message you wrote: > > > >=20 > > > > And again you're masking the error and possible fixes by linux itse= lf. > > > > Seems like this isn't an argument. > > >=20 > > > Respecting the explicit will of the user (i. e using what he > > > configured in U-Boot and passed to the kernel) is not an error.=A0 it > > > is intended and documented behaviour. > >=20 > > What is the will of the user in this case? It is the will of the > > developer to make the board more robust. That is, if there is > > for whatever reason no valid ethernet address found, then there > > will be one generated. That is the sole purpose of the config > > option in question (or maybe I used it completely wrong). So from > > a user perspective, this shouldn't even happen and I doubt he is > > even aware that there will be a random one. (I saw Tom's mail and > > I'm not talking about the USB adapters where this might be the > > normal case.) I might come from a different perspective, but > > users ususally don't look at the serial output. Instead they > > look at the kernel log. And there will be not the slightest > > error, because u-boot will happily fix the missing MAC address > > with a random one. > >=20 > > > > Sorry, if the original intention was to make "net list" work > > > > correctly, then why is there now such a huge fuzz around that > > > > CONFIG_NET_RANDOM_ETHADDR config option and why can't we just > > > > fix the error with "net list" and leave the behavior like it > > > > was for years. > > >=20 > > > Maybe you explain what exactly the ``error with "net list"'' is, > >=20 > > Michal mentioned it here [1]. > >=20 > > > considering the fact that it is U-Boot which determins the > > > "correct" MAC address and passes it to Linux.=A0 And if the user > > > configures U-Boot such that a random MAC address is used, then this > > > _is_ the correct MAC address, as normally (*) U-Boot is just a tool > > > that does what the user requests. > >=20 > > Only that the user doesn't do it but the board developer/OEM. I.e. > > there is no valid MAC address to pass to linux. It is really just > > for having netconsole running (or maybe you'll need networking for > > to rescue your failed EEPROM or whatever). > >=20 > > I think, we have to distiguish between two use cases here: > > =A0(1) make networking in u-boot work "somehow", to have a last > > =A0=A0=A0=A0 resort recovery, esp. required for netconsole where > > =A0=A0=A0=A0 the user cannot set the mac address by hand. > > =A0(2) normal use case, where drivers simply doesn't have any > > =A0=A0=A0=A0 other source for the mac address and need to fall back > > =A0=A0=A0=A0 to a random one. > >=20 > > I agree, for (2) the mac address should be passed to linux. But for > > (1) it shouldn't because it will just mask the error and any fall > > back mechanisms in linux. > > > > -michael > >=20 > > [1] https://lore.kernel.org/u-boot/07b688d8-f05f-d11e-5e3e-e5454e1c9af0= @xilinx.com/ >=20 > As we discussed in previous thread. I think there shouldn't be a problem > when u-boot passes random mac address (in whatever way) but if Linux driv= er > know how to get correct one it should be tried first. If that pass you wi= ll > get new one. If not you will use the one passed from u-boot. I think part of the problem here is that Linux can be inconsistent with how it behaves here? I remember there being some headaches early on with the TI CPSW driver in Linux being allowed to, or not allowed to, figure out where the MAC was. But that was a long time ago now and things are perhaps different now. > And it is up to board designer to decide when it is the right time. I can > imagine that it can be the part of kernel driver or can be purely done in > user space. It might also be the case that in U-Boot some systems that are using NET_RANDOM_ETHADDR that really probably shouldn't? A quick grep shows 253 platforms enabling it today, which feels high for the number of boards in the "we'll never have a valid MAC, need a random one" category. Thinking out loud, perhaps we need an option for "no possible valid MAC on board" and a different option for "random MAC for fall-back only" ? --=20 Tom --6qzkV7f8p1C1UmUU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmGSd8kACgkQFHw5/5Y0 tyxWVwv7BykpNpFeVmC29ClNl1RZOBHuQd8HNI03yWpFoBEmp1ReJA2hR/ZHtrN9 DcZUqws/ZCJ7XyMoB+EXB8eYansL0aX+fAT6EzC+o7BkRNs/Rm/B+HgxCLnjmB5G xLu6LV24tlN97TiAJ96nuzDRBWwgAzPV0XLY+qFW/SucvvF4yH5yg3g+OAPeSVep uy93w6R8ticJxI9AWU//LdGrMdJM0urY7C18+RQHgtyvfmIoYJboURHV5iei3n2w 9h6d2xqPivz1iVYBUMRPvfAVG+os3c8Ya5vzxztE00VeqmpH+3G9MfuCfv5oOqV2 GDIh29S99rVkzbQZO01xj2oLuWtfi03swU3fAHMWQ9SEbxGmC7uuMpPAH6RQcrfq KtxhuyDpZ71GkgKabEXuL1RiLfLX9akD8g2yFQyCroLm3dRNNfQVZFsDrytUW2QH uex+/pUCxQ1og0xS/bbp0IdLQPFz42x0RwywpOWE9SNh1y/0leWFC4sWmG8Tr7hV FRE/OXSp =rMlg -----END PGP SIGNATURE----- --6qzkV7f8p1C1UmUU--