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 4E1D4C433EF for ; Mon, 15 Nov 2021 13:58:09 +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 BF33E61A70 for ; Mon, 15 Nov 2021 13:58:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BF33E61A70 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 475C98364A; Mon, 15 Nov 2021 14:58:07 +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="PV0+i8iR"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3CFD08353C; Mon, 15 Nov 2021 14:58:05 +0100 (CET) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 AC5DD8364A for ; Mon, 15 Nov 2021 14:58:00 +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-xf2f.google.com with SMTP id v2so11323726qve.11 for ; Mon, 15 Nov 2021 05:58:00 -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=mLx4ollqzTzDh2n4YH6o6YahkJ/47pxC5Mv3hdTNHqg=; b=PV0+i8iRK6vXgYOywd4Z1lY1AU9g0hiEayJ5j9bkHxOp4ghvvbmDaB58ErfkrL0+Qx zbz6Rl72TANI/TzrRWwBW1yQkXQnYhh5Rnegp5F6ONQxqsnhO1/FzDyBWgG+Xr23curU DgwfycUOGKHO4djljbf5TDAR+4V9sIkohKB4s= 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=mLx4ollqzTzDh2n4YH6o6YahkJ/47pxC5Mv3hdTNHqg=; b=KFhPzC7tcXvMqkUS1fVCnllzVvVyq5jgnOs7WgHUO/jMTGqyXHD6u18BTQ8CZz3TFS 9Y8wlfuX+N5T6MidWAzsPHFywPazHCrFuz3MfqDqolvltevIymrAYD3foP0a/TIiMcDY ZdEtavk3FJK8g0tFmCEgCBKRbeRreDKNqt5J5Q9PCugJZOIBgQtzgc2RnRMxIvp/6H5R P+D8i+ORxrxlcA4Iwa0vVlUgRO/T/725hMAdyUXF5wiE/0NymRTPq3fVdAOzLmPWOg4d Ho8U+f42JahfA0oPrghaY/j+gP19K1fO7oJs6AjokvPhB9szOcwxt8UI6AGNpzetod9d kmYA== X-Gm-Message-State: AOAM530bIg5ClAbEbNcYnhDoYQ5v/Z03WhxubGzec7ZhM0EuKaH6IY+t CTkRXuOHOSj0arzgNrUt58zyRA== X-Google-Smtp-Source: ABdhPJw9UTmK1LjZ6eBQHIlFLxgePgknkNDRrwCCmz9o8uF5reMYTC46YVjMUSL07Xec9G/Zag9x1w== X-Received: by 2002:a05:6214:1bc6:: with SMTP id m6mr37865493qvc.14.1636984679396; Mon, 15 Nov 2021 05:57:59 -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 y20sm6909643qkj.24.2021.11.15.05.57.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Nov 2021 05:57:58 -0800 (PST) Date: Mon, 15 Nov 2021 08:57:56 -0500 From: Tom Rini To: Michael Walle Cc: Marek Vasut , u-boot@lists.denx.de, Grygorii Strashko , Michal Simek , fried.dev@gmail.com, joe.hershberger@ni.com, sjg@chromium.org Subject: Re: [PATCH RFC] cmd: fix net list command Message-ID: <20211115135756.GD24579@bill-the-cat> References: <20211115121152.3470910-1-michael@walle.cc> <32aff992-c84b-7b71-b412-7594c2a7d20e@denx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yVXkZ6wLsKv9EYuM" Content-Disposition: inline In-Reply-To: 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 --yVXkZ6wLsKv9EYuM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 15, 2021 at 01:24:34PM +0100, Michael Walle wrote: > Am 2021-11-15 13:15, schrieb Marek Vasut: > > On 11/15/21 1:11 PM, Michael Walle wrote: > > > Don't get the MAC address by the environment, but by the platform data > > > of the udevice. This will fix "net list" if the MAC address is > > > randomly > > > generated and won't change behavior when linux is booted. > > >=20 > > > Signed-off-by: Michael Walle > > > --- > > >=20 > > > Hi, > > >=20 > > > this is a proposal to fix the "net list" in a way that linux still > > > can have > > > its own fallback mechanism of MAC addresses even if the bootloader has > > > CONFIG_NET_RANDOM_ETHADDR enabled. > > >=20 > > > The intention is to replace [1], where if I understood correctly, the > > > intention was to fix "net list". > > >=20 > > > [1] https://lore.kernel.org/u-boot/3996ba2ee4e6ac136c0802dc0df4ef9b17= 50157c.1635506067.git.michal.simek@xilinx.com/ > >=20 > > Does that mean U-Boot and Linux will possibly each have different MAC > > address on the same device ? That is clearly wrong and not how it is > > supposed to work, U-Boot passes its ethaddr/ethNaddr settings to Linux > > so that they would have the same MAC address on the same device. >=20 > Yes they have different ones, but having a random mac address is wrong > in the first place. So IMHO it is more useful to dectect that in linux, > (and there was a good point that usually a user will look at dmesg and > not some u-boot output) than having two different random MAC addresses, > one for u-boot and one for linux. >=20 > Initially that random MAC address thing was supposed to get networking > running in u-boot if there is no ethaddr at all, eg. for network console. > Now we are passing this made up network address to linux, too. Why? Just > because it is wrong to have two different mac addresses? Some drivers > doesn't even probe without one. And we are just masking away this error. > You get this "two different mac addresses" between reboots. Which is also > wrong. This actually strenghten my opinion that this "feature" should > be an u-boot only thing. Do you have some link explaining this use case more clearly, ie why U-Boot is using a random MAC being wrong? We have a number of long standing use cases today where U-Boot generates and uses the random MAC and passes it to Linux and Linux would generate another random MAC, so we avoid that mismatch by making sure Linux does get the random MAC we generate. The BeagleBoard xM is the first one that pops to mind for me, but I believe it's typical on some classes of USB ethernet adapters. --=20 Tom --yVXkZ6wLsKv9EYuM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmGSZ1oACgkQFHw5/5Y0 tyx5EAv+MDsOHo59HcydPijL7/V/VnETNH0LHV+6XeBq92WjmEudMPSREQXGfZRI ejbM7BOLA5MMF67Z5R/nOQcCwhPDEHaIZxzbmsJxJalylmRLlhGQg7rl/lkBsB3N /42yIa9WIegvzG+0pEzFMP9LdtulttJqfeQjzFqwifcTBENi7KsTr4Z738YEvnpJ A0pxDuH/8CWIfC1rSk7lpE6OsaKjHuzfEcLJnVagzUEKkqZJ86mz/kxhuh7EQ3yl YmXRI08pyLuKAySn+DaVXBjvGaRtbM6SnYY6AB4mEuFx3Wiw0VwUobvO9pZPvjNr kPejBF4YfQcpEHavmwEDBXBsItlMolZhfCatMYqq7+yxp5d4/cJc6XJo3x26tdsZ qiwoja4mwe1kWChM5PX1aN3U2OUoFCbmbFSOjbOhLIjlBlbtZZJNSdbZmsxDv9Cw PJbwChyeZdfOQG/4aBcigc0Ra6yqIUJvZxy4UuJHcCRm2hEhhEkBoMnIGej0whBd sgEXFYEo =P3Yc -----END PGP SIGNATURE----- --yVXkZ6wLsKv9EYuM--