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 6C8F4C433EF for ; Mon, 15 Nov 2021 15:15:17 +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 7C65361AA2 for ; Mon, 15 Nov 2021 15:15:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7C65361AA2 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 A05B9836E0; Mon, 15 Nov 2021 16:15:14 +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=1636989315; bh=LeXWttCH6rJhlkJzcZPpgZSX4zTKg4CFcH/vKgDrNX0=; h=To:cc:From:Subject:In-reply-to:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=uQs1geqxLScRUEEf4ujbGpYzLI08UNTV9ttwev/VgB3X78cxe+W+4KuoVzP0rx87s nDjfKhBBOOpnpQX9nJZxWHbJUknxkXXGG2J5ifW/F44+fFiE6P3gJMa+UD/FPrRaW7 ZuU7C7c+znISgwjcHAiU2lBbXE7EiD++Xm+Edc/ePnELP7XdHJzEzplYBHoTesAZqV w4mvEfmabyZRvzsXvf1NDr+A6O4i4obxoV6fMnvGspY6EkfLq9D3pdoNoub9AGvO4u VWduBP3slz7uI8Rmw2k6ABXt9+JEax+zItfR/JHf0KfhNqOuBhx0+fyNELwv9RnJIf VUV7MOsHpMZjA== 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 8A1FD836DA for ; Mon, 15 Nov 2021 16:15:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1636989312; bh=LeXWttCH6rJhlkJzcZPpgZSX4zTKg4CFcH/vKgDrNX0=; h=To:cc:From:Subject:In-reply-to:References:Date:From; b=m+NHVOMrnd5tIdi0OGrELDN7+HMqmDYaimQLBR7WEfQNhSuo09wB71HQX7W2oju0z 7tolChkruo9gy5GJwrbrdll9Obk3PsM8DvLyY3mCxItWlkiG5fsIVX/bDHLMjKJ/LF BTMXKzJFwbQnGdJF3wDmpxXE9fgbJcAoEf6xRnaRCorKzcoybkV4nBqJSej4C5yi60 jqRZ9Y/PBLlr9DzF5FS9F5GzRO837JDYlq/1nN5RN2Ehf1IHBq7SpRI849kaAqLS57 m7EqqBb+hbSMm9lEVfqhmsLkm0FBTgUXndiIHToayUw1y1FCgfi2IrCDc3Er7fmMOS Gt5e5f6u68h4w== Received: by janitor.denx.de (Postfix, from userid 108) id D3609A02B9; Mon, 15 Nov 2021 16:15:11 +0100 (CET) Received: from gemini.denx.de (gemini.denx.de [10.4.0.2]) by janitor.denx.de (Postfix) with ESMTPS id 1C1F5A0050; Mon, 15 Nov 2021 16:15:02 +0100 (CET) Received: from gemini.denx.de (localhost [IPv6:::1]) by gemini.denx.de (Postfix) with ESMTP id E116B1E0CB7; Mon, 15 Nov 2021 16:15:01 +0100 (CET) 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, Tom Rini From: Wolfgang Denk Subject: Re: [PATCH RFC] cmd: fix net list command MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8bit In-reply-to: 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> Comments: In-reply-to Michael Walle message dated "Mon, 15 Nov 2021 15:52:51 +0100." Date: Mon, 15 Nov 2021 16:15:01 +0100 Message-ID: <1649428.1636989301@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 Michael, In message you wrote: > > What is the will of the user in this case? In which case? When the user does not bother to set a specific MAC address and let the system gernerate a random one? Well it is his (maybe concious, maybe not) decision... > It is the will of the > developer to make the board more robust. Maybe, maybe not. Often this is just a convenient method for the board manufacturer to provision his boards with valid data. If it makes sense to ship boards in such a state to the end user is another question. > > Maybe you explain what exactly the ``error with "net list"'' is, > > Michal mentioned it here [1]. Yes, and he also provided a valuable and correct comment: | And if you don't want to use this feature just don't enable it via | CONFIG_NET_RANDOM_ETHADDR. This say all, no patches needed. > > considering the fact that it is U-Boot which determins the > > "correct" MAC address and passes it to Linux. 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. > > 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. Why do you continue to claim that the MAC address used in U-Boot is not valid? Of course it is. This is similar to the situation where appliances sip with default passwords like ADMIN/ADMIN. The user can ignore the documentation which has bright red warning notes in CAPITAL LETTRRS that he *must* configure secure passwords... > It is really just > for having netconsole running (or maybe you'll need networking for > to rescue your failed EEPROM or whatever). This is one of many possible use cases. Board provisioning is another one. > I think, we have to distiguish between two use cases here: > (1) make networking in u-boot work "somehow", to have a last > resort recovery, esp. required for netconsole where > the user cannot set the mac address by hand. > (2) normal use case, where drivers simply doesn't have any > other source for the mac address and need to fall back > to a random one. There are many more use cases. And it may be intentional to use a random MAC address. There is this old rule: "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn If you don't like it, then disable the feature. It is nonstandard anyway, i. e. only intended for special cases / qualified users. 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 day-to-day travails of the IBM programmer are so amusing to most of us who are fortunate enough never to have been one - like watching Charlie Chaplin trying to cook a shoe.