From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.214.170 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793295218; b=NltZcV27shXDoaFNzUNZ54QD6KZvxRsvkrcn9qMABa0R6AzYMrENir629S3QHOgAOwoX ei+OM6suWg5CkeklrsN9Bg53sK+ZKHOJrORYQd9dmOqD2p2/8q5dIefbiYeL7qz8E4GmS /hb0YPPkAeWvILUWmIEqec7DoaMj7oghw1/XrdYNUJlAhBP6/hjYY1Rx0go9fB1ZAABpv Sodt7VrROOalExxnyOvHb6L8vz1xHc25Gqf3gj1UEZ1c9Pe/oAyx56v0W0H2Hd8PaST0X OrEU8F2oy+Zq5H74V8V/+cTpy8Hy62iR/UNdD9qgIINOVduUxfQ83aKdAaPW3+9rqvA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793295218; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:References: Content-Language:From:In-Reply-To:Content-Type: Content-Transfer-Encoding; bh=uuZVr2dDD8L7r8hiDqf/9pAQVEjMjpBKtDSDj+H9kVI=; b=WO0PMaOzDdExLhWUi8MvOqd6E4+6P7obAn0xdJovBvaXFCV5uUL76jmkgLNZ6et8Hffu P2BsEMiiwMCdKNLiHhLZXF2h9CRpoxxrmLs9+MtUSwIyrh368PXY0pOqocGCpYXiLaccN /UeaHKdX30eKMnw+bWDZe5k0pgAMJN1T0D3wB0l88GAteBvImyfOBAPpIx3ftZ8w7GGMt j3kgCCjXN0yyuWuSRQilGviX0HQWktOHUTOVqD2lKPZVYjlF+q1o5Tpq3G+E3duweDGee LcU32cf940irHz+yx/Tw4i2uFHn4mAVR+UVoTLyPCIx1IoPfN3jXQ9+XlTjb7Co+7uw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b="K9Lg2hR/"; arc=none smtp.remote-ip=209.85.214.170 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 82600606A31A for ; Thu, 29 Oct 2026 17:33:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 82600606A31A Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=K9Lg2hR/ Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-2ea7987517aso15766995ad.0 for ; Thu, 29 Oct 2026 10:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1793295218; x=1793900018; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=uuZVr2dDD8L7r8hiDqf/9pAQVEjMjpBKtDSDj+H9kVI=; b=K9Lg2hR/BcJ3lcLhlIPYRwiKpVggLgPBY7jwOhmSKQBwZ8ZUmwigu084YPVxYiPJ39 W14DEurU0hHITVNzc0ooaUCuTFlJ/A4cB7VLjfO2t8tUk6tawb9Jr61kbcJkJHcG9EYW /++a6lcYtlnEhP+e4ChCLdocYZhEpThs6tXBfATq9gZbfH2CVqNrchEzkByYr1tuUEjw /EB21+Ztw6Uw4LBCfhivfX0/cQeanJUVc89i5c9EA4L9jQlU3n+Y2ZF8yhxrC5u+fVYj gIGWJNkW+UB0pnvXA7lsERKUBGue+2tL6T5YvsI5BPd0PNEA51o/RqYWZIGGmYiVYpt5 5Jqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793295218; x=1793900018; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=uuZVr2dDD8L7r8hiDqf/9pAQVEjMjpBKtDSDj+H9kVI=; b=Dm73nAjGZWPtLucuNvoI87OUxhvusgPocQV+dEnoct+nHbR/8uVIbpBPW8Bqv63cnY TXAPL4aHbdVgWDU9qE1ZmeDGdLUWXH/F60pztGOweil8PBC6sgnLR+nD+UBCc2M4eaES s6LzmY0Dt/tBnk+awh9QNf4IkppAFlGLskvxgDit+7WJI00z2dafEX6cSGAt4Ge9gEFP Ir/D0WIeZHEUeyeMPzcDmfCbzKIZ1G59yvEwxyhOG8esVrqto1wGuISZRCmm72r6WA4G 4YJ0xK/Mhwt7Oy+TWCt7tdTXAIhYVAd1GY6cPEHpkGl9CR8GnhI//c1CYCqDDOyOCEyd 8BHQ== X-Forwarded-Encrypted: i=1; AKwUvBzhvllWy6HWWOQBpyvv+lrRBgvnPz7MsjNVM/CK9tGA4EqPIoMI2eAaiZvt+i9NDURTO2scfUV0OQD8n9I=@vger.kernel.org X-Gm-Message-State: AFq9FYKwxyBXVR1IqGR3aD7xLKyZXM+wjgaLKWXscILg8hFbilqhXzEP srKz2avOdKI27/jNOd6k3zdIe2p/rveKnKYtVCj+KjQb+1ji5nKMTGU7 X-Gm-Gg: AYBFou0wSflkno4vsDfRyDWHmQNX6u3JMi4vMwMS2FG5OMimGUFnqLrC1q6RyGcMLLp Qz0phi8XhbwHShjH8AnDW8n3wvXkW9kWvRzXWOGemDIM07yMrQvQ/LgOFj0uffIesiF5CqD/8xp qTr0WjfMHVrmb+PRUj6s0ebayBqD/LUVT0+D0M+v07XAMWU2TOeDfHabdIkvmN3l6OuIiBCuWrO 58291GY6tdxPSeJ7xCHG4FtX9rCgPvToTWdsQpQhPTtNYTMEzWWYYX55l0MOi7Ei6CuhYNXT5r9 uyd9+K2krupbWeyuCM575XTnKO+iVjWr9f3svsk7rylgjY5DRkY+DzZomiM7n30XcHfdNwmZna0 GROFGuAEz/CHtRMxK339+XgCw2f/dpydw3H/ELnfKs390rNHLxPY6ScyS5x/VMGSca14SJ1oPTA B0jljZv+He9lyMPoe4/c4sFUQvJ/AFeeRrxp3ZW1cgyXjX8jpQt3ubI/OFWZseeuSAZfWJfWhAL my3QxxOjxpOTL46IbhENIJVlBsKsiTdknGtzlZq4JTr+VogtY18qR/oHUFX+4hI4ITgtKC3lj9m 4QZcw3YVkLE3OL4pZPPdXuNHda+sXng/2GNE1z5fv5koCQLPaJyOtwNG X-Received: by 2002:a17:903:37c7:b0:2e8:b5b2:a9f9 with SMTP id d9443c01a7336-2eb364e9f75mr553035ad.37.1793295217825; Thu, 29 Oct 2026 10:33:37 -0700 (PDT) Received: from [10.67.48.245] ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2eb3630396asm295325ad.35.2026.10.29.10.33.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2026 10:33:36 -0700 (PDT) Message-ID: Date: Thu, 29 Oct 2026 10:33:32 -0700 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net 06/11] net: au1000: assign a valid MAC address without platform data To: netdev-bot+sashiko@kernel.org Cc: netdev@vger.kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, hkallweit1@gmail.com, linux@armlinux.org.uk, shaojijie@huawei.com, horms@kernel.org, runyu.xiao@seu.edu.cn, mmyangfl@gmail.com, hvr@gnu.org, jeff@garzik.org, danny.kukawka@bisect.de, mugunthanvnm@ti.com, sebastian.hesselbarth@gmail.com, linux-kernel@vger.kernel.org, manuel.lauss@gmail.com References: <20261027223140.3774570-7-f.fainelli@gmail.com> <179329051563.3134.3476237104312720828@kernel.org> Content-Language: en-US, fr-FR From: Florian Fainelli In-Reply-To: <179329051563.3134.3476237104312720828@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/29/26 09:15, netdev-bot+sashiko@kernel.org wrote: > Thank you for your contribution! Sashiko AI review found more severe > issue(s) in other patches of this series. This mail is only an FYI, in case > you want to address the nit picks below when you respin. > > Low priority / nit picks for your consideration: > > - [Low] The code change is correct, but the commit message overstates its > impact. > > -- > > net: au1000: assign a valid MAC address without platform data > > This commit adds a call to eth_hw_addr_random() in the no-platform-data > branch of au1000_probe(). Without it, dev_addr stays all zeroes and > eth_validate_addr() refuses to open the device. > >> The supported no-platform-data path leaves dev_addr as all zeroes. The >> device can register but eth_validate_addr() prevents it from opening. > > [ ... ] > >> Fixes: 7718f2c27dbd ("au1000_eth: use eth_hw_addr_random() instead of random_ether_addr()") > > [Severity: Low] > The code change itself looks fine. Is "supported" the right word for this > path, though, and does a Fixes: tag fit here? > > As far as I can tell, no in-tree configuration reaches the !pd branch in > au1000_probe(). The only "au1000-eth" platform devices in the tree are in > arch/mips/alchemy/common/platform.c, and both set platform data > statically: > > au1xxx_eth0_device: > .platform_data = &au1xxx_eth0_platform_data, > > au1xxx_eth1_device: > .platform_data = &au1xxx_eth1_platform_data, > > board-mtx1.c only copies replacement pdata into those static structs > through au1xxx_override_eth_cfg(). au1000_eth_driver has no > of_match_table either, so device tree can't create an instance without > pdata. > > On in-tree boards, a missing or invalid PROM MAC leaves pd->mac zeroed. > That case already takes the existing else branch: > > if (is_valid_ether_addr(pd->mac)) { > eth_hw_addr_set(dev, pd->mac); > } else { > /* Set a random MAC since no valid provided by platform_data. */ > eth_hw_addr_random(dev); > } > > So it looks like only out-of-tree board code that registers the device > without platform data can hit the zero MAC failure. > > Could the commit message describe this as a latent fix for users without > pdata? Without in-tree users, would net-next without the Fixes: tag be a > better fit than a stable backport? > Agreed that “supported” overstates the in-tree impact. I’ll describe this as a latent regression in the no-platform-data fallback. I’ll retain the Fixes tag because that commit removed the unconditional random-address initialization, introducing this behavior. -- Florian