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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b086a02c-624f-4225-a9fb-164095742ce9@linaro.org>
Date: Tue, 26 Mar 2024 07:41:25 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Josua Mayer <josua@...id-run.com>, Andrew Lunn <andrew@...n.ch>,
 Gregory Clement <gregory.clement@...tlin.com>,
 Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
 Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>
Cc: Yazan Shhady <yazan.shhady@...id-run.com>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130
 clearfog boards

On 25/03/2024 21:12, Josua Mayer wrote:
> Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski:
>> On 22/03/2024 11:08, Josua Mayer wrote:
>>> Am 21.03.24 um 22:47 schrieb Josua Mayer:
>>>> Add bindings for SolidRun Clearfog boards, using a new SoM based on
>>>> CN9130 SoC.
>>>> The carrier boards are identical to the older Armada 388 based Clearfog
>>>> boards. For consistency the carrier part of compatible strings are
>>>> copied, including the established "-a1" suffix.
>>>>
>>>> Signed-off-by: Josua Mayer <josua@...id-run.com>
>>>> ---
>>>>  .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml        | 12 ++++++++++++
>>>>  1 file changed, 12 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>> index 16d2e132d3d1..36bdfd1bedd9 100644
>>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>> @@ -82,4 +82,16 @@ properties:
>>>>            - const: marvell,armada-ap807-quad
>>>>            - const: marvell,armada-ap807
>>>>  
>>>> +      - description:
>>>> +          SolidRun CN9130 clearfog family single-board computers
>>>> +        items:
>>>> +          - enum:
>>>> +              - solidrun,clearfog-base-a1
>>>> +              - solidrun,clearfog-pro-a1
>>>> +          - const: solidrun,clearfog-a1
>>>> +          - const: solidrun,cn9130-sr-som
>>>> +          - const: marvell,cn9130
>>>> +          - const: marvell,armada-ap807-quad
>>>> +          - const: marvell,armada-ap807
>>>> +
>>>>  additionalProperties: true
>>> Before merging I would like some feedback about adding
>>> another product later, to ensure the compatibles above
>>> are adequate? In particular:
>>> - sequence of soc, cp, carrier compatibles
>>> - name of som compatible
>>>
>>> Draft for future bindings:
>>>       - description:
>>>           SolidRun CN9130 SoM based single-board computers
>>>           with 1 external CP on the Carrier.
>>>         items:
>>>           - enum:
>>>               - solidrun,cn9131-solidwan
>>>           - const: marvell,cn9131
>>>           - const: solidrun,cn9130-sr-som
>> This does not look correct. cn9131 is not compatible with your som.
> This is partially my question.
> I considered changing the som to "cn913x-sr-som".
> 
> The SoM itself is always 9130, it contains the base SoC
> with 1x AP and 1x CP in a single chip.
> 9131 and 9132 <happen> on the carrier boards.

No wildcards, but if the SoM name is 9130 then use 9130.
The problem is that you use cn9130 SoC as fallback.

> 
>>
>>>           - const: marvell,cn9130
>> SoCs are compatible only in some cases, e.g. one is a subset of another
>> like stripped out of modem. Are you sure this is your case?
> This is more complex, CN9131 and CN9132 are not single SoCs.
> A "9132" is instantiated by connecting two southbridge chips
> via a Marvell defined bus, each providing additional IO
> such as network, i2c, gpio.
> 
> Note that even the first, "9130", while a single chip, contains two dies:
> An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c),
> and a "CP" (Communication Processor I assume) with lots of IO.
> This CP as far as I know today is identical to the southbridges
> mentioned above.

OK, but how does it affect compatibility between them? Which parts are
the same? Or how much is shared?

> 
>>>           - const: marvell,armada-ap807-quad
>>>           - const: marvell,armada-ap807
>> Anyway, 6 compatibles is beyond useful amount. What are you expressing
>> here?
> I copied this part from the examples earlier in the file, such as:
>       - description: Armada CN9132 SoC with two external CPs
>         items:
>           - const: marvell,cn9132
>           - const: marvell,cn9131
>           - const: marvell,cn9130
>           - const: marvell,armada-ap807-quad
>           - const: marvell,armada-ap807
>>  Why is this even armada ap807?
> We noticed ap807 != ap806 (cn913x != 8040),
> because the thermal sensor coefficients converting
> raw values to celsius differed.

That's also not the best example. Might be correct but also looks
over-complicated. The point of board-level compatibles is to identify
machine and its common parts. It has little impact inside of kernel (at
least should be almost no users inside!), but there can be some users,
e.g. firmware or user-space.

This claims that cn9132 is compatible with ap807, so you have exactly
the same base. The same base is not CPU! It's about the S in SoC, so
"System". Could firmware use marvell,armada-ap807 compatible to properly
detect type of system and treat all these boards as ap807?

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ