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 7BF16C433F5 for ; Wed, 17 Nov 2021 15:56:41 +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 51D5161B1B for ; Wed, 17 Nov 2021 15:56:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 51D5161B1B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=denx.de 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 79E5B80303; Wed, 17 Nov 2021 16:56:37 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1637164598; bh=UNyQx1eZdgk9nXvTVZEON0OIiZd3s6H5t+vC4Et2m+c=; h=To:cc:From:Subject:In-reply-to:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=fpwDRe+Dtjv6E3wsSLuyg32UR6I2jLbZRGQS/h49rctrsMtzKxWddHNEoOE/UTZ5/ EQzfxYI5ze7V+XYrzwtg4oJvRYG8IjeQ7TrC6LagUS+a4Ofi6sDwviTGOQb49XRja/ JBTckufD3g+WfcKKn8Qihi0gezIJGZ4K3AIyem7FS6/HdB/+iSnChTU/LfaOrUcXiN opLsJ6qN0tH/i7Wo9xsnAzns/89QSO7kQPHYt9fNx2tmcq0pvsZ9vyXU5Ra5sbhwvA RMMisMHlrsb/R4zIWigGrFcHm1RkFG6Pk+4JhK5psgB59Sv3I6A5zWXLyf152xdcud r/y5NrMYUT+3g== Received: from janitor.denx.de (unknown [62.91.23.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: noc@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id B54EA80303 for ; Wed, 17 Nov 2021 16:56:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1637164595; bh=UNyQx1eZdgk9nXvTVZEON0OIiZd3s6H5t+vC4Et2m+c=; h=To:cc:From:Subject:In-reply-to:References:Date:From; b=lEwNZKXBIVUsUje4q3qO22fjv1tIC76Acq+J0oBAH+47wqO2t4R8TxE2XgbETpjnA roHiOcokm3yEYMoNFr0kPYZwyi25pRd+u5IHGt+EpjkaOnO1UVyIxejZAugEulzATG XBCsrCkIcexQKyiN578XUj3GbxMwweUVc+uVOThzOFiCGMxjFQmCFrmBT1X87Lm+SB Bsu3lNOPydRbOOypWdIgTkjDRjcsMr5PHxNMkz+rhQRWZ7XiQOKfkbZZ7RwY32FeAF Ach2fXgTEIlop1EWwO2AGg6ykTKpIau0VbSuo5mlZAOtEbcv9voZEYLuWGmP3/x8Lq 2BnSY6sfCi5fg== Received: by janitor.denx.de (Postfix, from userid 108) id 31CDDA029A; Wed, 17 Nov 2021 16:56:35 +0100 (CET) Received: from gemini.denx.de (gemini.denx.de [10.4.0.2]) by janitor.denx.de (Postfix) with ESMTPS id DE0BDA00AD; Wed, 17 Nov 2021 16:56:27 +0100 (CET) Received: from gemini.denx.de (localhost [IPv6:::1]) by gemini.denx.de (Postfix) with ESMTP id 881C21E0CB7; Wed, 17 Nov 2021 16:56:27 +0100 (CET) To: Tom Rini cc: Ramon Fried , Michael Walle , Michal Simek , Grygorii Strashko , git , Joe Hershberger , Simon Glass , U-Boot Mailing List From: Wolfgang Denk Subject: Re: [PATCH] net: uclass: Save ethernet MAC address when generated MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8bit In-reply-to: <20211117123548.GX24579@bill-the-cat> References: <610dcc295f1f9f8eb609269ac5a2e0d8@walle.cc> <97cbcf456d2fa9572ef0d0c9adc7380b@walle.cc> <20211116141855.GD24579@bill-the-cat> <1739526.1637074605@gemini.denx.de> <20211116184146.GF24579@bill-the-cat> <1797888.1637135092@gemini.denx.de> <20211117115025.GV24579@bill-the-cat> <1820750.1637151898@gemini.denx.de> <20211117123548.GX24579@bill-the-cat> Comments: In-reply-to Tom Rini message dated "Wed, 17 Nov 2021 07:35:48 -0500." Date: Wed, 17 Nov 2021 16:56:27 +0100 Message-ID: <1836596.1637164587@gemini.denx.de> 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 Dear Tom, In message <20211117123548.GX24579@bill-the-cat> you wrote: > > > Why would you expect any "do not use" note? Locally adminitered MAC > > addresses (even when randomly chosen) have been created for good > > reason, so they should be usable. > > Because as been noted in either this thread, or the other long thread, > the user does not want to confuse Linux with this emergency random MAC? Classical answer: Don't do it, then. If the user does not want to pass a MAC address to Linux, he should simply not do it. Deleting "ethaddr" from the environment should be all that's needed. [And if this does not work, then I consider this a bug that should be fixed.] > > I'm afraid I do not understand what exactly you are proposing here? > > I'm objecting to changing our long standing behavior of NOT > automatically passing the random MAC to the OS. That has always been > user opt-in by using tools/gen_eth_addr and "setenv ethaddr ... ; > saveenv". Especially since I don't know how many of those 200+ boards > that enable CONFIG_NET_RANDOM_ETHADDR today are "enabled, but never > used" vs "enabled, random MAC in U-Boot since we don't care/didn't > notice, real MAC in Linux". So yes, another worry is that we have a > class of boards in U-Boot where a random MAC is fine enough since it's > rarely used/needed, but Linux can get the real MAC and now we'll be > blowing that away. Or maybe we just have a ton of boards that > copypasta'd that option in and didn't really think why. Unfortunately we can only speculate about that [my guess is that most of them are just copy/paste while brain in low power mode]. > > But I object to using a MAC address in U-Boot in a way that makes it > > invisible to the user who uses documented APIs ("printenv ethaddr"). > > Well, that's the API we've had for over 10 years, and it was a common > problem in those earlier days with lots of SBCs where it was cheap to > toss in a USB eth controller that didn't store a MAC anywhere. Now > we're I believe hitting this due to FPGA stuff. CONFIG_NET_RANDOM_ETHADDR has been added in 2015 with commit bef1014 "net: Implement random ethaddr fallback in eth.c"; from the changes then I'm not sure if this was even USB related. > > If we use some MAC address, it shall be possible to read it using > > "printenv ethaddr" and to set it using "setenv ethaddr". Anything > > else is inconsistent crap. > > Well, we've been inconsistent about the former for forever and there's > a lot of implications to changing it now. Yes. However, being bug-compatible is something we should not rate too high. [non-random signature used] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de "The net result is a system that is not only binary compatible with 4.3 BSD, but is even bug for bug compatible in almost all features." - Avadit Tevanian, Jr., "Architecture-Independent Virtual Memory Management for Parallel and Distributed Environments: The Mach Approach"