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: <2744136e-a6e7-de19-4142-04f7edf0c6ea@gmail.com>
Date:   Mon, 3 Feb 2020 21:29:30 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Maxime Ripard <maxime@...no.tech>,
        Florian Fainelli <f.fainelli@...il.com>
Cc:     linux-arm-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        "maintainer:BROADCOM IPROC ARM ARCHITECTURE" 
        <bcm-kernel-feedback-list@...adcom.com>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        Sugaya Taichi <sugaya.taichi@...ionext.com>,
        Olof Johansson <olof@...om.net>,
        Andrew Jeffery <andrew@...id.au>,
        Lubomir Rintel <lkundrak@...sk>,
        "moderated list:BROADCOM IPROC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        open list <linux-kernel@...r.kernel.org>,
        "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
        <linux-rpi-kernel@...ts.infradead.org>
Subject: Re: [PATCH 11/12] dt-bindings: arm: Document Broadcom SoCs
 'secondary-boot-reg'



On 2/3/2020 12:34 AM, Maxime Ripard wrote:
> On Sun, Feb 02, 2020 at 01:18:26PM -0800, Florian Fainelli wrote:
>> diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
>> index c23c24ff7575..6f56a623c1cd 100644
>> --- a/Documentation/devicetree/bindings/arm/cpus.yaml
>> +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
>> @@ -272,6 +272,22 @@ properties:
>>        While optional, it is the preferred way to get access to
>>        the cpu-core power-domains.
>>
>> +  secondary-boot-reg:
>> +    $ref: '/schemas/types.yaml#/definitions/uint32'
>> +    description: |
>> +      Required for systems that have an "enable-method" property value of
>> +      "brcm,bcm11351-cpu-method", "brcm,bcm23550" or "brcm,bcm-nsp-smp".
>> +
>> +      This includes the following SoCs: |
>> +      BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664, BCM23550
>> +      BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
>> +
>> +      The secondary-boot-reg property is a u32 value that specifies the
>> +      physical address of the register used to request the ROM holding pen
>> +      code release a secondary CPU. The value written to the register is
>> +      formed by encoding the target CPU id into the low bits of the
>> +      physical start address it should jump to.
>> +
> 
> You can make the requirement explicit (and enforced by the schemas) using:
> 
> if:
>   properties:
>     enable-method:
>       contains:
>         enum:
> 	  - brcm,bcm11351-cpu-method
> 	  - brcm,bcm23550
> 	  - brcm,bcm-nsp-smp
> 
> then:
>   required:
>     - secondary-boot-reg

Thanks! That was exactly what I was looking for, it seems to be matching
a bit too greedily though:

  DTC     arch/arm/boot/dts/bcm2836-rpi-2-b.dt.yaml
  CHECK   arch/arm/boot/dts/bcm2836-rpi-2-b.dt.yaml
/home/ff944844/dev/linux/arch/arm/boot/dts/bcm2836-rpi-2-b.dt.yaml:
cpu@0: 'secondary-boot-reg' is a required property
/home/ff944844/dev/linux/arch/arm/boot/dts/bcm2836-rpi-2-b.dt.yaml:
cpu@1: 'secondary-boot-reg' is a required property
/home/ff944844/dev/linux/arch/arm/boot/dts/bcm2836-rpi-2-b.dt.yaml:
cpu@2: 'secondary-boot-reg' is a required property
/home/ff944844/dev/linux/arch/arm/boot/dts/bcm2836-rpi-2-b.dt.yaml:
cpu@3: 'secondary-boot-reg' is a required property
  DTC     arch/arm/boot/dts/bcm2837-rpi-3-a-plus.dt.yaml

not sure why though as your example appears correct.
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ