Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp2824106pxb; Mon, 17 Jan 2022 06:32:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJwD6YjM8SuSX9LJNYmE5LHHdI++KpBh9Z876MlstcdOtSciL2Z42obCjyXee1NVskDQak3Q X-Received: by 2002:a05:6a00:21c2:b0:4bc:fb2d:4b6f with SMTP id t2-20020a056a0021c200b004bcfb2d4b6fmr21098460pfj.62.1642429930565; Mon, 17 Jan 2022 06:32:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642429930; cv=none; d=google.com; s=arc-20160816; b=xZQiOu93LUYjxv1UqT/j8pvJP5RjMZISFfigddpDY/16PH1XsAbfnBBwg5XntV8Osb 4J+gU0uz42gloZQC2Q8MYMTeHXwXk4PDCBunet+VWmp7vvht5G+lFQ5rjWeM48gn/ZCp j89sQns+ktBnTL2Ao3NlQkdJxLmHVeirDSGmsFaf1spexVCnWhlmIJFCd5H4jcYqVftq QdlcsVShIaSBSWSY+Bd/h/ljj363OIIkMruFOCeC4Ro4QSjCWOfZhhRDnOGh9RPc8NLz uBqTY668SOStOTTNJQQkagu3WxWbK0ZP89marC+FQPmdItZZLU9uoSVmg5duTWZdyMWt YFsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=mhf0gvmtQtUQxrm/vKKNqIEAAl4mW/N6OhsRPI8m+VY=; b=FoIx9LDsIn5CsAEYJLyBewIwCaUr2HGGn4SJz84cFZl5FDvc/bIN5sB1syR7PvxiAS 2glwb9qM/L+EIdMlKGCYP3UcSCxstaDNCwQJ7FechF9CFv1P0w+3aHkG3AC7z5G4NYfj PAu88m4FulpP5ELuxj6jVxqOW05QWn+cAeVrh3Ne9d/zTHWXujhQ6gvXN+oX5tDecozb /Lf5N8HMMGeYP5M8mDe7KJOXJBSAJcNWcgnX851vYrtr8/B4s+NExBw+Yo31lP2i6Dhl 5dPBozD5gKqolE7VYrLs9wkaYIk5Ot3OIMER9NUPOhAsaGw9eTMvNhusBNnaj0T6SZrR 1Pwg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l18si14718848pfu.179.2022.01.17.06.31.56; Mon, 17 Jan 2022 06:32:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234719AbiAQGgW (ORCPT + 70 others); Mon, 17 Jan 2022 01:36:22 -0500 Received: from marcansoft.com ([212.63.210.85]:51534 "EHLO mail.marcansoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231189AbiAQGgV (ORCPT ); Mon, 17 Jan 2022 01:36:21 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 3D4D73FA5E; Mon, 17 Jan 2022 06:36:11 +0000 (UTC) Subject: Re: [PATCH v2 09/35] brcmfmac: pcie: Perform firmware selection for Apple platforms To: Arend van Spriel , Kalle Valo , "David S. Miller" , Jakub Kicinski , Rob Herring , "Rafael J. Wysocki" , Len Brown , Arend van Spriel , Franky Lin , Hante Meuleman , Chi-hsien Lin , Wright Feng , Dmitry Osipenko Cc: Sven Peter , Alyssa Rosenzweig , Mark Kettenis , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Pieter-Paul Giesberts , Linus Walleij , Hans de Goede , "John W. Linville" , "brian m. carlson" , Andy Shevchenko , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, brcm80211-dev-list.pdl@broadcom.com, SHA-cyfmac-dev-list@infineon.com References: <20220104072658.69756-1-marcan@marcan.st> <20220104072658.69756-10-marcan@marcan.st> <0e169c4e-ce51-3592-f114-46cb3cde1f7d@broadcom.com> From: Hector Martin Message-ID: <61e21977-656c-86b1-9005-a9c792fa824b@marcan.st> Date: Mon, 17 Jan 2022 15:36:09 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <0e169c4e-ce51-3592-f114-46cb3cde1f7d@broadcom.com> Content-Type: text/plain; charset=utf-8 Content-Language: es-ES Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On 09/01/2022 05.03, Arend van Spriel wrote: >> The chip revision nominally comes from OTP on Apple platforms, but it >> can be mapped to the PCI revision number, so we ignore the OTP revision >> and continue to use the existing PCI revision mechanism to identify chip >> revisions, as the driver already does for other chips. Unfortunately, >> the mapping is not consistent between different chip types, so this has >> to be determined experimentally. > > Not sure I understand this. The chip revision comes from the chipcommon > register [1]. Maybe that is what you mean by "PCI revision number". For > some chips it is possible OTP is used to override that. What I mean is the Apple custom OTP segment stores a textual revision number, like "C0". Apple's driver uses this to pick a firmware. There is an ad-hoc mapping between this and the numeric revision (which as you say is present in chipcommon but AFAICT the same number also ends up as the Revision ID in PCI config space). > > Reviewed-by: Arend van Spriel >> Reviewed-by: Linus Walleij >> Signed-off-by: Hector Martin >> --- >> .../broadcom/brcm80211/brcmfmac/pcie.c | 58 ++++++++++++++++++- >> 1 file changed, 56 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c >> index 74c9a4f74813..250e0bd40cb3 100644 >> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c >> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c >> @@ -2094,8 +2094,62 @@ brcmf_pcie_prepare_fw_request(struct brcmf_pciedev_info *devinfo) >> fwreq->domain_nr = pci_domain_nr(devinfo->pdev->bus) + 1; >> fwreq->bus_nr = devinfo->pdev->bus->number; >> >> - brcmf_dbg(PCIE, "Board: %s\n", devinfo->settings->board_type); >> - fwreq->board_types[0] = devinfo->settings->board_type; >> + /* Apple platforms with fancy firmware/NVRAM selection */ >> + if (devinfo->settings->board_type && >> + devinfo->settings->antenna_sku && >> + devinfo->otp.valid) { >> + char *buf; >> + int len; >> + >> + brcmf_dbg(PCIE, "Apple board: %s\n", >> + devinfo->settings->board_type); > > maybe good to use local reference for devinfo->settings->board_type, > which is used several times below. Yup, and also antenna_sku. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub