linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arend Van Spriel <arend.vanspriel@broadcom.com>
To: Hector Martin <marcan@marcan.st>, Jonas Gorski <jonas.gorski@gmail.com>
Cc: "'Hector Martin' via BRCM80211-DEV-LIST,PDL"
	<brcm80211-dev-list.pdl@broadcom.com>,
	"Arend van Spriel" <aspriel@gmail.com>,
	"Franky Lin" <franky.lin@broadcom.com>,
	"Hante Meuleman" <hante.meuleman@broadcom.com>,
	"Kalle Valo" <kvalo@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Alexander Prutskov" <alep@cypress.com>,
	"Ian Lin" <ian.lin@infineon.com>,
	"Joseph chuang" <jiac@cypress.com>,
	"Sven Peter" <sven@svenpeter.dev>,
	"Alyssa Rosenzweig" <alyssa@rosenzweig.io>,
	"Aditya Garg" <gargaditya08@live.com>,
	asahi@lists.linux.dev, linux-wireless@vger.kernel.org,
	SHA-cyfmac-dev-list@infineon.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, "Rafał Miłecki" <rafal@milecki.pl>,
	"Hauke Mehrtens" <hauke@hauke-m.de>
Subject: Re: [PATCH v2 1/5] brcmfmac: Drop all the RAW device IDs
Date: Wed, 08 Feb 2023 07:41:23 +0100	[thread overview]
Message-ID: <1862fc1e650.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com> (raw)
In-Reply-To: <349fe17a-f754-a39a-d094-f07330618fcd@marcan.st>

[-- Attachment #1: Type: text/plain, Size: 4389 bytes --]

On February 8, 2023 5:02:32 AM Hector Martin <marcan@marcan.st> wrote:

> On 05/02/2023 22.02, Hector Martin wrote:
>> On 05/02/2023 21.44, Jonas Gorski wrote:
>>> On Sun, 5 Feb 2023 at 07:58, Arend Van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>>
>>>> - stale Cypress emails
>>>>
>>>> On February 5, 2023 3:50:41 AM Hector Martin <marcan@marcan.st> wrote:
>>>>
>>>>> On 03/02/2023 02.19, Arend Van Spriel wrote:
>>>>>> On February 2, 2023 6:25:28 AM "'Hector Martin' via BRCM80211-DEV-LIST,PDL"
>>>>>> <brcm80211-dev-list.pdl@broadcom.com> wrote:
>>>>>>
>>>>>>> On 31/01/2023 23.17, Jonas Gorski wrote:
>>>>>>>> On Tue, 31 Jan 2023 at 12:36, Hector Martin <marcan@marcan.st> wrote:
>>>>>>>>>
>>>>>>>>> These device IDs are only supposed to be visible internally, in devices
>>>>>>>>> without a proper OTP. They should never be seen in devices in the wild,
>>>>>>>>> so drop them to avoid confusion.
>>>>>>>>
>>>>>>>> I think these can still show up in embedded platforms where the
>>>>>>>> OTP/SPROM is provided on-flash.
>>>>>>>>
>>>>>>>> E.g. https://forum.archive.openwrt.org/viewtopic.php?id=55367&p=4
>>>>>>>> shows this bootlog on an BCM4709A0 router with two BCM43602 wifis:
>>>>>>>>
>>>>>>>> [    3.237132] pci 0000:01:00.0: [14e4:aa52] type 00 class 0x028000
>>>>>>>> [    3.237174] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>>>>>>>> [    3.237199] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>>>>>>>> [    3.237302] pci 0000:01:00.0: supports D1 D2
>>>>>>>> ...
>>>>>>>> [    3.782384] pci 0001:03:00.0: [14e4:aa52] type 00 class 0x028000
>>>>>>>> [    3.782440] pci 0001:03:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
>>>>>>>> [    3.782474] pci 0001:03:00.0: reg 0x18: [mem 0x00000000-0x003fffff 64bit]
>>>>>>>> [    3.782649] pci 0001:03:00.0: supports D1 D2
>>>>>>>>
>>>>>>>> 0xaa52 == 43602 (BRCM_PCIE_43602_RAW_DEVICE_ID)
>>>>>>>>
>>>>>>>> Rafał can probably provide more info there.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Jonas
>>>>>>>
>>>>>>> Arend, any comments on these platforms?
>>>>>>
>>>>>> Huh? I already replied to that couple of days ago or did I only imagine
>>>>>> doing that.
>>>>>
>>>>> I don't see any replies from you on the lists (or my inbox) to Jonas' email.
>>>>
>>>> Accidentally sent that reply to internal mailing list. So quoting myself here:
>>>>
>>>> """
>>>> Shaking the tree helps ;-) What is meant by "OTP/SPROM is provided
>>>> on-flash"? I assume you mean that it is on the host side and the wifi PCIe
>>>> device can not access it when it gets powered up. Maybe for this scenario
>>>> we should have a devicetree compatible to configure the device id, but that
>>>> does not help any current users of these platforms. Thanks for providing
>>>> this info.
>>>
>>> That's what I meant, the wifi chip itself does not have any (valid)
>>> OTP/SPROM attached/populated, and requires the driver to setup the
>>> values at runtime based on the host SoC's flash contents (most likely
>>> NVRAM contents).
>>>
>>> This was the case in about 99% of embedded systems based on MIPS
>>> bcm47xx/bcm63xx, where the wifi chips then always identified
>>> themselves with their raw chip IDs as PCI device IDs (even leading to
>>> one or two ID conflicts ...).
>>>
>>> I have to admit I don't know how much this is still an issue on
>>> current (ARM) systems, but at least that one BCM4709A one suggests
>>> this is still happening in "recent" designs. Probably because it saves
>>> half a cent per board or so ;-)
>>>
>>> Regards
>>> Jonas
>>
>> As far as I know the OTP is built into the chips themselves, and even
>> Apple (who refuses to put per-device calibration data in OTP these days
>> and loads it from DT) still manages to burn in the proper device ID and
>> basic info at least... so I'm not sure how this saves any money. I
>> thought chips weren't supposed to even leave Broadcom without at least
>> an ID burned in?
>>
>> - Hector
>
> I'd like to move forward with this. Should I send a v3 without the RAW
> ID removal?

Yeah. Need to consider the options for solving this.

Programming the OTP is a manufacturing step done by OEM so I think they 
save having to implement that step in production and it is not so much chip 
cost saving.

Our proprietary driver is setup so it is probed for any PCI device with 
network class and then it uses NVRAM to obtain the PCI devid.

Regards,
Arend



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

  reply	other threads:[~2023-02-08  6:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-31 11:28 [PATCH v2 0/5] BCM4355/4364/4377 support & identification fixes Hector Martin
2023-01-31 11:28 ` [PATCH v2 1/5] brcmfmac: Drop all the RAW device IDs Hector Martin
2023-01-31 13:18   ` Arend van Spriel
2023-01-31 14:17   ` Jonas Gorski
2023-02-02  5:25     ` Hector Martin
2023-02-02 17:19       ` Arend Van Spriel
2023-02-05  2:50         ` Hector Martin
2023-02-05  6:58           ` Arend Van Spriel
2023-02-05 12:44             ` Jonas Gorski
2023-02-05 13:02               ` Hector Martin
2023-02-08  4:02                 ` Hector Martin
2023-02-08  6:41                   ` Arend Van Spriel [this message]
2023-01-31 11:28 ` [PATCH v2 2/5] wifi: brcmfmac: Rename Cypress 89459 to BCM4355 Hector Martin
2023-01-31 11:28 ` [PATCH v2 3/5] brcmfmac: pcie: Add IDs/properties for BCM4355 Hector Martin
2023-01-31 11:28 ` [PATCH v2 4/5] brcmfmac: pcie: Add IDs/properties for BCM4377 Hector Martin
2023-01-31 11:28 ` [PATCH v2 5/5] brcmfmac: pcie: Perform correct BCM4364 firmware selection Hector Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1862fc1e650.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=SHA-cyfmac-dev-list@infineon.com \
    --cc=alep@cypress.com \
    --cc=alyssa@rosenzweig.io \
    --cc=asahi@lists.linux.dev \
    --cc=aspriel@gmail.com \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=franky.lin@broadcom.com \
    --cc=gargaditya08@live.com \
    --cc=hante.meuleman@broadcom.com \
    --cc=hauke@hauke-m.de \
    --cc=ian.lin@infineon.com \
    --cc=jiac@cypress.com \
    --cc=jonas.gorski@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rafal@milecki.pl \
    --cc=sven@svenpeter.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).