linux-kernel - Re: [PATCH v2 2/9] dt-bindings: riscv: microchip: document the aries m100pfsevp

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: <a494ab3f-fc43-e1c7-e30f-09838d743ed5@linaro.org>
Date:   Tue, 30 Aug 2022 20:47:54 +0300
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Conor.Dooley@...rochip.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, Daire.McNamara@...rochip.com,
        Shravan.Chippa@...rochip.com
Cc:     paul.walmsley@...ive.com, palmer@...belt.com,
        aou@...s.berkeley.edu, Cyril.Jean@...rochip.com,
        Lewis.Hanly@...rochip.com, Praveen.Kumar@...rochip.com,
        wg@...es-embedded.de, Hugh.Breslin@...rochip.com,
        devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/9] dt-bindings: riscv: microchip: document the aries
 m100pfsevp

On 30/08/2022 20:35, Conor.Dooley@...rochip.com wrote:
> On 30/08/2022 18:30, Krzysztof Kozlowski wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> On 30/08/2022 19:59, Conor.Dooley@...rochip.com wrote:
>>>>> w dts were
>>>>> needed so that the gpio-hog could be set correctly. Out of curiosity, I can
>>>>> have the same compatible in multiple devicetrees right? In that case, it
>>>>> would just be "aries,m100pfsevp" here and I could put that in both?
>>>>> Would make things easier..
>>>>
>>>> Depends, but I would say for this case rather not. The compatible should
>>>> identify the board. If the boards are different, one compatible should
>>>> not identify both of them. Imagine U-Boot (or something else) trying to
>>>> match the DTS.
>>>
>>> It is the same board though, the way the bootloader works is that if it
>>> detects an SD-card it will use that to boot from, and if not will fall back
>>> to the emmc.
>>
>> Wait, I might miss that part. So this is exactly the same hardware with
>> the same SoM/SoC, same eMMC and SD card, except that one has plugged
>> this SD card (as it is hot-pluggable)?

Then two thoughts:
1. It is indeed one compatible because it is exactly the same hardware
(I don't consider plugged SD card as part of it, just like plugged USB).

2. Then I don't think you should have two boards in the kernel. It's
fine if bootloaders have two of them or to store an overlay in the
kernel or somewhere. But two boards for the same board differing by
hot-plug setup is not for Linux kernel.


Best regards,
Krzysztof