Document the device tree binding for a new board named "EVK" based on
the Qualcomm Hamoa-IoT platform.
The "hamoa" name refers to a family of SoCs that share the same silicon
die but are offered in multiple speed bins. The specific SoC used in
this board is the x1e80100, which represents one such bin within the
Hamoa family.
Although "qcom,hamoa-iot-evk" is introduced as the board-specific
compatible, the fallback compatible remains "qcom,x1e80100" to preserve
compatibility with existing in-kernel drivers and software that already
depend on this identifier.
Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 47a7b1cb3cac1150bcde8c2e2e23f2db256ab082..f004019c5691e0a9a3d56a0e3af395314ceb3745 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1161,6 +1161,7 @@ properties:
- lenovo,yoga-slim7x
- microsoft,romulus13
- microsoft,romulus15
+ - qcom,hamoa-iot-evk
- qcom,x1e80100-crd
- qcom,x1e80100-qcp
- const: qcom,x1e80100
--
2.34.1On 24/07/2025 10:15, Yijie Yang wrote: > Document the device tree binding for a new board named "EVK" based on > the Qualcomm Hamoa-IoT platform. What is hamoa-iot? Later patches claim this is a SoM, so explain here why you are not expecting it to be used outside of EVK (not following standard SoM rules like every other vendor)? > > The "hamoa" name refers to a family of SoCs that share the same silicon > die but are offered in multiple speed bins. The specific SoC used in > this board is the x1e80100, which represents one such bin within the > Hamoa family. Isn't this obvious from the schema? > > Although "qcom,hamoa-iot-evk" is introduced as the board-specific > compatible, the fallback compatible remains "qcom,x1e80100" to preserve > compatibility with existing in-kernel drivers and software that already > depend on this identifier. Not relevant. This is x1e80100 SoC. We do not explain that microsoft,romulus15 is using fallback x1e80100, do we? You explain less relevant topics but you do not explain the main concerns here. It does not matter how you name your board. Can be hamoa, can be lemans - we don't care about board names. > > Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> > --- > Documentation/devicetree/bindings/arm/qcom.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml > index 47a7b1cb3cac1150bcde8c2e2e23f2db256ab082..f004019c5691e0a9a3d56a0e3af395314ceb3745 100644 > --- a/Documentation/devicetree/bindings/arm/qcom.yaml > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml > @@ -1161,6 +1161,7 @@ properties: > - lenovo,yoga-slim7x > - microsoft,romulus13 > - microsoft,romulus15 > + - qcom,hamoa-iot-evk > - qcom,x1e80100-crd > - qcom,x1e80100-qcp > - const: qcom,x1e80100 > Best regards, Krzysztof
On 7/25/25 8:55 AM, Krzysztof Kozlowski wrote: > On 24/07/2025 10:15, Yijie Yang wrote: >> Document the device tree binding for a new board named "EVK" based on >> the Qualcomm Hamoa-IoT platform. > > What is hamoa-iot? Marketing > > Later patches claim this is a SoM, so explain here why you are not > expecting it to be used outside of EVK (not following standard SoM rules > like every other vendor)? The SoM is unsurprisingly called... hamoa-iot-som. EVK is the reference carrier board. The expectation is that more boards will be added in the future, as the SoM is adopted by third parties. Konrad
On 2025-07-25 14:55, Krzysztof Kozlowski wrote: > On 24/07/2025 10:15, Yijie Yang wrote: >> Document the device tree binding for a new board named "EVK" based on >> the Qualcomm Hamoa-IoT platform. > > What is hamoa-iot? > > Later patches claim this is a SoM, so explain here why you are not > expecting it to be used outside of EVK (not following standard SoM rules > like every other vendor)? The SoM can be used outside of the EVK. Regarding the standard SoM rules you mentioned—are you referring to the expectation that a SoM should have its own compatible string, such as 'qcom,hamoa-iot-som'? > >> >> The "hamoa" name refers to a family of SoCs that share the same silicon >> die but are offered in multiple speed bins. The specific SoC used in >> this board is the x1e80100, which represents one such bin within the >> Hamoa family. > > Isn't this obvious from the schema? This is the first patch set where the Hamoa code name is introduced, so I’d like to clarify the relationship between the Hamoa family and the SoC ID. Additionally, I want to explain why the compatible string includes both the board’s code name and the SoC name. > >> >> Although "qcom,hamoa-iot-evk" is introduced as the board-specific >> compatible, the fallback compatible remains "qcom,x1e80100" to preserve >> compatibility with existing in-kernel drivers and software that already >> depend on this identifier. > > Not relevant. This is x1e80100 SoC. We do not explain that > microsoft,romulus15 is using fallback x1e80100, do we? Same as above. > > You explain less relevant topics but you do not explain the main > concerns here. It does not matter how you name your board. Can be hamoa, > can be lemans - we don't care about board names. > I will add more details to describe the relationship between the board and the SoM. This is what people are most concerned about, right? >> >> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> >> --- >> Documentation/devicetree/bindings/arm/qcom.yaml | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml >> index 47a7b1cb3cac1150bcde8c2e2e23f2db256ab082..f004019c5691e0a9a3d56a0e3af395314ceb3745 100644 >> --- a/Documentation/devicetree/bindings/arm/qcom.yaml >> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml >> @@ -1161,6 +1161,7 @@ properties: >> - lenovo,yoga-slim7x >> - microsoft,romulus13 >> - microsoft,romulus15 >> + - qcom,hamoa-iot-evk >> - qcom,x1e80100-crd >> - qcom,x1e80100-qcp >> - const: qcom,x1e80100 >> > > > Best regards, > Krzysztof -- Best Regards, Yijie
On 25/07/2025 10:03, Yijie Yang wrote: > > > On 2025-07-25 14:55, Krzysztof Kozlowski wrote: >> On 24/07/2025 10:15, Yijie Yang wrote: >>> Document the device tree binding for a new board named "EVK" based on >>> the Qualcomm Hamoa-IoT platform. >> >> What is hamoa-iot? >> >> Later patches claim this is a SoM, so explain here why you are not >> expecting it to be used outside of EVK (not following standard SoM rules >> like every other vendor)? > > The SoM can be used outside of the EVK. Regarding the standard SoM rules > you mentioned—are you referring to the expectation that a SoM should > have its own compatible string, such as 'qcom,hamoa-iot-som'? Yes. We already discussed this with qcom last time for other soc/som. Just look how all other vendors do it. > >> >>> >>> The "hamoa" name refers to a family of SoCs that share the same silicon >>> die but are offered in multiple speed bins. The specific SoC used in >>> this board is the x1e80100, which represents one such bin within the >>> Hamoa family. >> >> Isn't this obvious from the schema? > > This is the first patch set where the Hamoa code name is introduced, so > I’d like to clarify the relationship between the Hamoa family and the > SoC ID. Additionally, I want to explain why the compatible string > includes both the board’s code name and the SoC name. There is no SoC name here. The SoC name stays the same and you do not change it just because your internal policy changes every X years. > >> >>> >>> Although "qcom,hamoa-iot-evk" is introduced as the board-specific >>> compatible, the fallback compatible remains "qcom,x1e80100" to preserve >>> compatibility with existing in-kernel drivers and software that already >>> depend on this identifier. >> >> Not relevant. This is x1e80100 SoC. We do not explain that >> microsoft,romulus15 is using fallback x1e80100, do we? > > Same as above. > >> >> You explain less relevant topics but you do not explain the main >> concerns here. It does not matter how you name your board. Can be hamoa, >> can be lemans - we don't care about board names. >> > > I will add more details to describe the relationship between the board > and the SoM. This is what people are most concerned about, right? No. Drop all references to Hamoa because it is irrelevant. You do not get to change existing bindings or existing meanings just because you decided to use some other model names. Best regards, Krzysztof
© 2016 - 2025 Red Hat, Inc.