lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 12 Sep 2022 11:59:17 +0000
From:   Alvin Šipraga <ALSI@...g-olufsen.dk>
To:     Russell King <rmk+kernel@...linux.org.uk>
CC:     Arend van Spriel <aspriel@...il.com>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        "asahi@...ts.linux.dev" <asahi@...ts.linux.dev>,
        "brcm80211-dev-list.pdl@...adcom.com" 
        <brcm80211-dev-list.pdl@...adcom.com>,
        "David S. Miller" <davem@...emloft.net>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Hector Martin <marcan@...can.st>,
        Jakub Kicinski <kuba@...nel.org>,
        Kalle Valo <kvalo@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rafa__ Mi__ecki <zajec5@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        "SHA-cyfmac-dev-list@...ineon.com" <SHA-cyfmac-dev-list@...ineon.com>,
        Sven Peter <sven@...npeter.dev>,
        van Spriel <arend@...adcom.com>
Subject: Re: [PATCH wireless-next v2 01/12] dt-bindings: net: bcm4329-fmac:
 Add Apple properties & chips

On Mon, Sep 12, 2022 at 10:52:41AM +0100, Russell King wrote:
> From: Hector Martin <marcan@...can.st>
> 
> This binding is currently used for SDIO devices, but these chips are
> also used as PCIe devices on DT platforms and may be represented in the
> DT. Re-use the existing binding and add chip compatibles used by Apple
> T2 and M1 platforms (the T2 ones are not known to be used in DT
> platforms, but we might as well document them).
> 
> Then, add properties required for firmware selection and calibration on
> M1 machines.
> 
> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
> Signed-off-by: Hector Martin <marcan@...can.st>
> Reviewed-by: Mark Kettenis <kettenis@...nbsd.org>
> Reviewed-by: Rob Herring <robh@...nel.org>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> ---
>  .../net/wireless/brcm,bcm4329-fmac.yaml       | 39 +++++++++++++++++--
>  1 file changed, 35 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> index 53b4153d9bfc..fec1cc9b9a08 100644
> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> @@ -4,7 +4,7 @@
>  $id: http://devicetree.org/schemas/net/wireless/brcm,bcm4329-fmac.yaml#
>  $schema: http://devicetree.org/meta-schemas/core.yaml#
>  
> -title: Broadcom BCM4329 family fullmac wireless SDIO devices
> +title: Broadcom BCM4329 family fullmac wireless SDIO/PCIE devices
>  
>  maintainers:
>    - Arend van Spriel <arend@...adcom.com>
> @@ -41,11 +41,17 @@ title: Broadcom BCM4329 family fullmac wireless SDIO devices
>                - cypress,cyw4373-fmac
>                - cypress,cyw43012-fmac
>            - const: brcm,bcm4329-fmac
> -      - const: brcm,bcm4329-fmac
> +      - enum:
> +          - brcm,bcm4329-fmac
> +          - pci14e4,43dc  # BCM4355
> +          - pci14e4,4464  # BCM4364
> +          - pci14e4,4488  # BCM4377
> +          - pci14e4,4425  # BCM4378
> +          - pci14e4,4433  # BCM4387
>  
>    reg:
> -    description: SDIO function number for the device, for most cases
> -      this will be 1.
> +    description: SDIO function number for the device (for most cases
> +      this will be 1) or PCI device identifier.
>  
>    interrupts:
>      maxItems: 1
> @@ -85,6 +91,31 @@ title: Broadcom BCM4329 family fullmac wireless SDIO devices
>        takes precedence.
>      type: boolean
>  
> +  brcm,cal-blob:
> +    $ref: /schemas/types.yaml#/definitions/uint8-array
> +    description: A per-device calibration blob for the Wi-Fi radio. This
> +      should be filled in by the bootloader from platform configuration
> +      data, if necessary, and will be uploaded to the device if present.

Is this a leftover from a previous revision of the patchset? Because as
far as I can tell, the CLM blob is (still) being loaded via firmware,
and no additional parsing has been added for this particular OF
property. Should it be dropped?

The rest looks quite OK.

Kind regards,
Alvin

> +
> +  brcm,board-type:
> +    $ref: /schemas/types.yaml#/definitions/string
> +    description: Overrides the board type, which is normally the compatible of
> +      the root node. This can be used to decouple the overall system board or
> +      device name from the board type for WiFi purposes, which is used to
> +      construct firmware and NVRAM configuration filenames, allowing for
> +      multiple devices that share the same module or characteristics for the
> +      WiFi subsystem to share the same firmware/NVRAM files. On Apple platforms,
> +      this should be the Apple module-instance codename prefixed by "apple,",
> +      e.g. "apple,honshu".

nit: s/WiFi/Wi-Fi/

> +
> +  apple,antenna-sku:
> +    $ref: /schemas/types.yaml#/definitions/string
> +    description: Antenna SKU used to identify a specific antenna configuration
> +      on Apple platforms. This is use to build firmware filenames, to allow
> +      platforms with different antenna configs to have different firmware and/or
> +      NVRAM. This would normally be filled in by the bootloader from platform
> +      configuration data.
> +
>  required:
>    - compatible
>    - reg
> -- 
> 2.30.2
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ