From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Conor.Dooley@microchip.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, Daire.McNamara@microchip.com,
Shravan.Chippa@microchip.com
Cc: paul.walmsley@sifive.com, palmer@dabbelt.com,
aou@eecs.berkeley.edu, Cyril.Jean@microchip.com,
Lewis.Hanly@microchip.com, Praveen.Kumar@microchip.com,
wg@aries-embedded.de, Hugh.Breslin@microchip.com,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/9] dt-bindings: riscv: microchip: document the aries m100pfsevp
Date: Tue, 30 Aug 2022 20:47:54 +0300 [thread overview]
Message-ID: <a494ab3f-fc43-e1c7-e30f-09838d743ed5@linaro.org> (raw)
In-Reply-To: <8ae5c383-1c04-e16e-83a6-26861640deb1@microchip.com>
On 30/08/2022 20:35, Conor.Dooley@microchip.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@microchip.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
next prev parent reply other threads:[~2022-08-30 17:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-30 10:17 [PATCH v2 0/9] New PolarFire SoC devkit devicetrees & 22.09 reference design updates Conor Dooley
2022-08-30 10:17 ` [PATCH v2 1/9] dt-bindings: riscv: microchip: document icicle reference design Conor Dooley
2022-08-30 10:17 ` [PATCH v2 2/9] dt-bindings: riscv: microchip: document the aries m100pfsevp Conor Dooley
2022-08-30 14:37 ` Krzysztof Kozlowski
2022-08-30 15:25 ` Conor.Dooley
2022-08-30 16:55 ` Krzysztof Kozlowski
2022-08-30 16:59 ` Conor.Dooley
2022-08-30 17:30 ` Krzysztof Kozlowski
2022-08-30 17:35 ` Conor.Dooley
2022-08-30 17:47 ` Krzysztof Kozlowski [this message]
2022-08-30 17:55 ` Conor.Dooley
2022-08-30 10:17 ` [PATCH v2 3/9] dt-bindings: riscv: microchip: document the sev kit Conor Dooley
2022-08-30 10:17 ` [PATCH v2 4/9] riscv: dts: microchip: add pci dma ranges for the icicle kit Conor Dooley
2022-08-30 10:18 ` [PATCH v2 5/9] riscv: dts: microchip: move the mpfs' pci node to -fabric.dtsi Conor Dooley
2022-08-30 10:18 ` [PATCH v2 6/9] riscv: dts: microchip: icicle: update pci address properties Conor Dooley
2022-08-30 10:44 ` Ben Dooks
2022-08-30 12:06 ` Conor.Dooley
2022-08-30 10:18 ` [PATCH v2 7/9] riscv: dts: microchip: icicle: re-jig fabric peripheral addresses Conor Dooley
2022-08-30 10:18 ` [PATCH v2 8/9] riscv: dts: microchip: add sevkit device tree Conor Dooley
2022-08-30 10:18 ` [PATCH v2 9/9] riscv: dts: microchip: add a devicetree for aries' m100pfsevp Conor Dooley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a494ab3f-fc43-e1c7-e30f-09838d743ed5@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=Conor.Dooley@microchip.com \
--cc=Cyril.Jean@microchip.com \
--cc=Daire.McNamara@microchip.com \
--cc=Hugh.Breslin@microchip.com \
--cc=Lewis.Hanly@microchip.com \
--cc=Praveen.Kumar@microchip.com \
--cc=Shravan.Chippa@microchip.com \
--cc=aou@eecs.berkeley.edu \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
--cc=wg@aries-embedded.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).