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]
Message-ID: <d3cb7b3782b16029@bloch.sibelius.xs4all.nl>
Date:   Wed, 29 Dec 2021 17:42:17 +0100 (CET)
From:   Mark Kettenis <mark.kettenis@...all.nl>
To:     Hector Martin <marcan@...can.st>
Cc:     kvalo@...eaurora.org, davem@...emloft.net, kuba@...nel.org,
        robh+dt@...nel.org, rafael@...nel.org, lenb@...nel.org,
        aspriel@...il.com, franky.lin@...adcom.com,
        hante.meuleman@...adcom.com, chi-hsien.lin@...ineon.com,
        wright.feng@...ineon.com, chung-hsien.hsu@...ineon.com,
        marcan@...can.st, sven@...npeter.dev, alyssa@...enzweig.io,
        kettenis@...nbsd.org, zajec5@...il.com,
        pieter-paul.giesberts@...adcom.com, linus.walleij@...aro.org,
        hdegoede@...hat.com, linville@...driver.com, dekim@...adcom.com,
        sandals@...stytoothpaste.net, linux-wireless@...r.kernel.org,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
        brcm80211-dev-list.pdl@...adcom.com,
        SHA-cyfmac-dev-list@...ineon.com
Subject: Re: [PATCH 01/34] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips

> From: Hector Martin <marcan@...can.st>
> Cc: Hector Martin <marcan@...can.st>, Sven Peter <sven@...npeter.dev>,
>         Alyssa Rosenzweig <alyssa@...enzweig.io>,
>         Mark Kettenis <kettenis@...nbsd.org>,
>         Rafał Miłecki <zajec5@...il.com>,
>         Pieter-Paul Giesberts <pieter-paul.giesberts@...adcom.com>,
>         Linus Walleij <linus.walleij@...aro.org>,
>         Hans de Goede <hdegoede@...hat.com>,
>         "John W. Linville" <linville@...driver.com>,
>         "Daniel (Deognyoun) Kim" <dekim@...adcom.com>,
>         "brian m. carlson" <sandals@...stytoothpaste.net>,
>         linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
>         devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
>         linux-acpi@...r.kernel.org, brcm80211-dev-list.pdl@...adcom.com,
>         SHA-cyfmac-dev-list@...ineon.com
> Date: Mon, 27 Dec 2021 00:35:51 +0900
> 
> 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.
> 
> Signed-off-by: Hector Martin <marcan@...can.st>
> ---
>  .../net/wireless/brcm,bcm4329-fmac.yaml       | 32 +++++++++++++++++--
>  1 file changed, 29 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> index c11f23b20c4c..2530ff3e7b90 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>
> @@ -36,16 +36,22 @@ properties:
>                - brcm,bcm43455-fmac
>                - brcm,bcm43456-fmac
>                - brcm,bcm4354-fmac
> +              - brcm,bcm4355c1-fmac
>                - brcm,bcm4356-fmac
>                - brcm,bcm4359-fmac
> +              - brcm,bcm4364b2-fmac
> +              - brcm,bcm4364b3-fmac
> +              - brcm,bcm4377b3-fmac
> +              - brcm,bcm4378b1-fmac
> +              - brcm,bcm4387c2-fmac
>                - cypress,cyw4373-fmac
>                - cypress,cyw43012-fmac
>            - const: brcm,bcm4329-fmac
>        - const: brcm,bcm4329-fmac

I suppose this helps with validation of device trees.  However, nodes
for PCI devices are not supposed to have a "compatible" property as
the PCI vendor and device IDs are supposed to be used to identify a
device.

That does raise the question how a schema for additional properties
for PCI device nodes is supposed to be defined...

>    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
> @@ -75,6 +81,26 @@ properties:
>      items:
>        pattern: '^[A-Z][A-Z]-[A-Z][0-9A-Z]-[0-9]+$'
>  
> +  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.
> +
> +  apple,module-instance:
> +    $ref: /schemas/types.yaml#/definitions/string
> +    description: Module codename used to identify a specific board on
> +      Apple platforms. This is used to build the firmware filenames, to allow
> +      different platforms to have different firmware and/or NVRAM config.
> +
> +  apple,antenna-sku:
> +    $def: /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.33.0
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ