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 2DDE1C433FE for ; Thu, 18 Nov 2021 07:08:28 +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 0D4B0619E5 for ; Thu, 18 Nov 2021 07:08:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0D4B0619E5 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 22C3E82F5E; Thu, 18 Nov 2021 08:08:25 +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=1637219305; bh=zEOjNcieUybfJl8cSy3ipuDGmmM1TT3XnX2uzf8hJts=; h=To:cc:From:Subject:In-reply-to:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=qVnuN5EwlBXRa6VUhqMU0W8OokvP8+MQ0NL1TnOnqVARyc+H1eR7KFpP0s7JCt9Zn yhejuwi5cxiPzJqGAsCZitWAHFKuejnyAsPijDFRALzO53y3otYS+Cd/kXVduKL04I FisySXd4Z6tgOXEKIKTE2rkzzpIi/rahIgmrgTsLUWurgM+MVWibLRGkPgqS+q0zHR aEu8tRBXrS61xt1syqfcvSyE1BWuWyrGYuOHXoxuKW/AWIQSBohufeoGDMoCGdqH9V r5z/SoKbpNIUPMZFAJenKguPoT7S7Jh+SDNekylQU7Cy7KedH31JxZv07ymYBnzNtb AhHHbpHfH+r/A== 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 63241800AA for ; Thu, 18 Nov 2021 08:08:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1637219303; bh=zEOjNcieUybfJl8cSy3ipuDGmmM1TT3XnX2uzf8hJts=; h=To:cc:From:Subject:In-reply-to:References:Date:From; b=Gy6nADh5IWl8nZNnQf8I8sf9Yz+8UCc3HHoWmifD742Vb6v0Lqk+XTaWeKKaP403d L+oBWXdxEuobjrKNQxKfVm8Vmir3a+Nvq2dihTnIbaNokh/9B2dN7Qhdhawy91X1pZ lQmzDktMZjiTcvPGgu0iJcaNrpva55qbpdGz01c+Fn7KqkZh3rMIrri9sov1xOlq3r rrAntz660lSmvGiLTOFVS9km+SVofzWShp07upb22nXSonmzmVciJWq+7YeL26bdA4 6DRnjo6nuv1f8MwBHzJ3t8HrnxiNwKupm+3IQFiMFJrMx+1OTrsqA7XXpbcUvfZTDy ZoeQWyRTqE4qQ== Received: by janitor.denx.de (Postfix, from userid 108) id CF9B3A02B9; Thu, 18 Nov 2021 08:08:22 +0100 (CET) Received: from gemini.denx.de (gemini.denx.de [10.4.0.2]) by janitor.denx.de (Postfix) with ESMTPS id 8102CA00A2; Thu, 18 Nov 2021 08:08:14 +0100 (CET) Received: from gemini.denx.de (localhost [IPv6:::1]) by gemini.denx.de (Postfix) with ESMTP id 183921E0CB7; Thu, 18 Nov 2021 08:08:14 +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: <20211117161545.GA24579@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> <1836596.1637164587@gemini.denx.de> <20211117161545.GA24579@bill-the-cat> Comments: In-reply-to Tom Rini message dated "Wed, 17 Nov 2021 11:15:45 -0500." Date: Thu, 18 Nov 2021 08:08:14 +0100 Message-ID: <1889944.1637219294@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 <20211117161545.GA24579@bill-the-cat> you wrote: > > Yes, you're changing behavior by requiring this change, and fwiw I > suggested a slightly different fix-up here of deleting the device tree > properties if it's a random MAC, in Michael's patch just disabling the > feature on the platforms he cares about. Of course fixing a bug will change behaviour; that's the intention of the fix. Technically there is no difference between the user setting "ethaddr" manually to a locally administered MAC address or doing this automatically in some code or script. In all cases setting "ethaddr" means: hey, this is my MAC address, please use it. > I've asked Neil to chime in on the amlogic cases after talking on IRC, > but the short answer was for prior to fuse/serial# reading support for a > non-random MAC. Possibly other SoCs in a similar situation. It is perfectly OK for U-Boot to start with a random MAC address, use this for a while, and change it so something else later. This is what may happen at production: say the MAC address is stored in some EEPROM or fuses, which are initially empty, so U-Boot will use a random MAC address, download it's board specific date (serial#, MAC address, ...) over network, programm it into the respective storage devices, and switch to using the new "official" MAC address. > I don't mean this in a super snarky way, but I'm more concerned about > the implications of changing our documented albeit slightly inconsistent > behavior than I am about some of the myriad of technically feasible > environment variable names we've also in theory supported. For about > half the time we've supported device trees, the solution to "I need to > use a random MAC" was "run tools/gen_eth_addr, setenv, saveenv". This is indeed what seems a straightforward approach to me. The problem here is that this needs to be done manually. CONFIG_NET_RANDOM_ETHADDR is the attempt to do the same automatically, except that it falls short of setting the "ethaddr" environment variable. I consider this a bug. > For > the second half of the time, it was the same, but with a side of "or note > the random MAC from console logs and use that". Yes, and it should be clear that this is not a reasonable approach. It thwarts the original intent of the NET_RANDOM_ETHADDR patch to do thing in an automated, scriptable way. I see this actually as a manifestation of the bug that ethaddr does not get set. At this point the problem was recognized, but instead of properly fixing it, a poor workaround was documented. > We're about to > introduce the 3rd variant. I'd feel a whole lot better about taking in > a v2 of this patch that correct the help (and maybe updates > doc/README.enetaddr!) if someone could report back on what's going on > with the layerscape, imx* and socfpga platforms. There's in fact a > number of platforms enabling it that I'm pretty sure DENX has or had the > hardware on, so can we get some spot checking done there? I will check and provide an update later, but from the best of my knowledge none of the boards we ported actually need or use this feature. This is just a copy&paste mess. > If we can > drop from 250 platforms to 50 platforms with some level of confidence we > understand why are setting NET_RANDOM_ETHADDR, I'd be a lot less worried > we're about to introduce another change that we won't found out messed > up a bunch of people on until some new work-around is accepted in to > Linux or something. Well, this work-around in Linux is because there have been incnsistent ways how to store the MAC address in the device tree. This has nothing to do with our problem here - Linux has no way to know whether a locally administered MAC address has been assigned by the user for a specific purpose, or if it has been generated randomly. Actually it does not even care. 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 You know that feeling when you're leaning back on a stool and it starts to tip over? Well, that's how I feel all the time. - Steven Wright