From patchwork Fri Jul 8 13:37:12 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 12911179 X-Patchwork-Delegate: kvalo@adurom.com 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AAE22CCA47B for ; Fri, 8 Jul 2022 13:37:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238352AbiGHNhd (ORCPT ); Fri, 8 Jul 2022 09:37:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238263AbiGHNhW (ORCPT ); Fri, 8 Jul 2022 09:37:22 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3297B1D312 for ; Fri, 8 Jul 2022 06:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657287439; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xFmf3sfHdPk2cWGRZ8uPYle4j74mEPX+axZeRg0eW3A=; b=IwBrdc86ZDfnuIS69MDY9WhTJU8wmYsFefnMX4CR2ccSNlLjZZuQeE7fxbRx/UlxaLxI8K 0zzc/yiPEDOZcysxmeWDf9f4g1cLXy1Pf/WDEz3rPxpJkLo7fsRZYOisyj7iquqX5lJRFu hphIRdCJFuz992qQ3+JabrhErjdy0Ug= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-125-J0YIVqlFNLGjpFq5IqIt-g-1; Fri, 08 Jul 2022 09:37:16 -0400 X-MC-Unique: J0YIVqlFNLGjpFq5IqIt-g-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9C69F85A587; Fri, 8 Jul 2022 13:37:15 +0000 (UTC) Received: from shalem.redhat.com (unknown [10.39.193.188]) by smtp.corp.redhat.com (Postfix) with ESMTP id 740A7404C324; Fri, 8 Jul 2022 13:37:14 +0000 (UTC) From: Hans de Goede To: Arend van Spriel , Franky Lin , Hante Meuleman , Kalle Valo Cc: Hans de Goede , linux-wireless@vger.kernel.org, brcm80211-dev-list.pdl@broadcom.com, SHA-cyfmac-dev-list@infineon.com Subject: [PATCH 2/2] brcmfmac: Replace default (not configured) MAC with a random MAC Date: Fri, 8 Jul 2022 15:37:12 +0200 Message-Id: <20220708133712.102179-2-hdegoede@redhat.com> In-Reply-To: <20220708133712.102179-1-hdegoede@redhat.com> References: <20220708133712.102179-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On some boards there is no eeprom to hold the nvram, in this case instead a board specific nvram is loaded from /lib/firmware. On most boards the macaddr=... setting in the /lib/firmware nvram file is ignored because the wifi/bt chip has a unique MAC programmed into the chip itself. But in some cases the actual MAC from the /lib/firmware nvram file gets used, leading to MAC conflicts. The MAC addresses in the troublesome nvram files seem to all come from the same nvram file template, so we can detect this by checking for the template nvram file MAC. Detect that the default MAC address is being used and replace it with a random MAC address to avoid MAC address conflicts. Note that udev will detect this is a random MAC based on /sys/class/net/wlan0/addr_assign_type and then replace this with a MAC based on hashing the netdev-name + the machine-id. So that the MAC address is both guaranteed to be unique per machine while it is still the same/persistent at each boot (assuming the default Link.MACAddressPolicy=persistent udev setting). Signed-off-by: Hans de Goede Reviewed-by: Arend van Spriel --- .../broadcom/brcm80211/brcmfmac/common.c | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c index dccd8f4ca1d0..7485e784be2a 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c @@ -201,6 +201,20 @@ int brcmf_c_set_cur_etheraddr(struct brcmf_if *ifp, const u8 *addr) return err; } +/* On some boards there is no eeprom to hold the nvram, in this case instead + * a board specific nvram is loaded from /lib/firmware. On most boards the + * macaddr setting in the /lib/firmware nvram file is ignored because the + * wifibt chip has a unique MAC programmed into the chip itself. + * But in some cases the actual MAC from the /lib/firmware nvram file gets + * used, leading to MAC conflicts. + * The MAC addresses in the troublesome nvram files seem to all come from + * the same nvram file template, so we only need to check for 1 known + * address to detect this. + */ +static const u8 brcmf_default_mac_address[ETH_ALEN] = { + 0x00, 0x90, 0x4c, 0xc5, 0x12, 0x38 +}; + int brcmf_c_preinit_dcmds(struct brcmf_if *ifp) { struct brcmf_pub *drvr = ifp->drvr; @@ -226,6 +240,15 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp) bphy_err(drvr, "Retrieving cur_etheraddr failed, %d\n", err); goto done; } + + if (ether_addr_equal_unaligned(ifp->mac_addr, brcmf_default_mac_address)) { + bphy_err(drvr, "Default MAC is used, replacing with random MAC to avoid conflicts\n"); + eth_random_addr(ifp->mac_addr); + ifp->ndev->addr_assign_type = NET_ADDR_RANDOM; + err = brcmf_c_set_cur_etheraddr(ifp, ifp->mac_addr); + if (err < 0) + goto done; + } } memcpy(ifp->drvr->mac, ifp->mac_addr, sizeof(ifp->drvr->mac));