[PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Changming Huang]

Add DT Binding doc for semtech sx1301

Signed-off-by: Changming Huang <jerry.huang@nxp.com>
---
changes in v4:
  - rename example node, adjust description
changes in v3:
  - add the dt-bindings

 .../bindings/spi/semtech,sx1301.yaml          | 45 +++++++++++++++++++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/semtech,sx1301.yaml

diff --git a/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml b/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
new file mode 100644
index 000000000000..420fe8d23a1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/semtech,sx1301.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Semtech sx1301 SPI controller bindings
+
+maintainers:
+  - Changming Huang <jerry.huang@nxp.com>
+
+allOf:
+  - $ref: "spi-controller.yaml"
+
+properties:
+  compatible:
+    const: semtech,sx1301
+
+  reg:
+    maxItems: 1
+
+  spi-max-frequency: true
+
+  fsl,spi-cs-sck-delay: true
+
+  fsl,spi-sck-cs-delay: true
+
+required:
+  - compatible
+  - reg
+  - spi-max-frequency
+
+additionalProperties: false
+
+examples:
+  - |
+    spi@0 {
+      compatible = "semtech,sx1301";
+      reg = <0>;
+      spi-max-frequency = <2000000>;
+      fsl,spi-cs-sck-delay = <1000000>;
+      fsl,spi-sck-cs-delay = <50>;
+    };
+
+...
-- 
2.25.1

[PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Changming Huang]

Add DT Binding doc for semtech sx1301

Signed-off-by: Changming Huang <jerry.huang@nxp.com>
---
changes in v4:
  - rename example node, adjust description
changes in v3:
  - add the dt-bindings

 .../bindings/spi/semtech,sx1301.yaml          | 45 +++++++++++++++++++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/semtech,sx1301.yaml

diff --git a/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml b/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
new file mode 100644
index 000000000000..420fe8d23a1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/semtech,sx1301.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Semtech sx1301 SPI controller bindings
+
+maintainers:
+  - Changming Huang <jerry.huang@nxp.com>
+
+allOf:
+  - $ref: "spi-controller.yaml"
+
+properties:
+  compatible:
+    const: semtech,sx1301
+
+  reg:
+    maxItems: 1
+
+  spi-max-frequency: true
+
+  fsl,spi-cs-sck-delay: true
+
+  fsl,spi-sck-cs-delay: true
+
+required:
+  - compatible
+  - reg
+  - spi-max-frequency
+
+additionalProperties: false
+
+examples:
+  - |
+    spi@0 {
+      compatible = "semtech,sx1301";
+      reg = <0>;
+      spi-max-frequency = <2000000>;
+      fsl,spi-cs-sck-delay = <1000000>;
+      fsl,spi-sck-cs-delay = <50>;
+    };
+
+...
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/2 v4] arm64: dts: fsl-ls1028a: add dspi2 support

[Changming Huang]

Enable MikroBUS SPI port.

Signed-off-by: Changming Huang <jerry.huang@nxp.com>
---
changes in v3:
  - add the dt-bindings

 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index 68c31cb8eead..6d0508d5abd0 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -117,6 +117,19 @@ &duart1 {
 	status = "okay";
 };
 
+&dspi2 {
+	bus-num = <2>;
+	status = "okay";
+
+	mikrobus@0 {
+		compatible = "semtech,sx1301";
+		reg = <0>;
+		spi-max-frequency = <2000000>;
+		fsl,spi-cs-sck-delay = <1000000>;
+		fsl,spi-sck-cs-delay = <50>;
+	};
+};
+
 &enetc_mdio_pf3 {
 	sgmii_phy0: ethernet-phy@2 {
 		reg = <0x2>;
-- 
2.25.1

[PATCH 2/2 v4] arm64: dts: fsl-ls1028a: add dspi2 support

[Changming Huang]

Enable MikroBUS SPI port.

Signed-off-by: Changming Huang <jerry.huang@nxp.com>
---
changes in v3:
  - add the dt-bindings

 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index 68c31cb8eead..6d0508d5abd0 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -117,6 +117,19 @@ &duart1 {
 	status = "okay";
 };
 
+&dspi2 {
+	bus-num = <2>;
+	status = "okay";
+
+	mikrobus@0 {
+		compatible = "semtech,sx1301";
+		reg = <0>;
+		spi-max-frequency = <2000000>;
+		fsl,spi-cs-sck-delay = <1000000>;
+		fsl,spi-sck-cs-delay = <50>;
+	};
+};
+
 &enetc_mdio_pf3 {
 	sgmii_phy0: ethernet-phy@2 {
 		reg = <0x2>;
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Krzysztof Kozlowski]

On 20/04/2022 09:31, Changming Huang wrote:
> Add DT Binding doc for semtech sx1301
> 
> Signed-off-by: Changming Huang <jerry.huang@nxp.com>
> ---
> changes in v4:
>   - rename example node, adjust description
> changes in v3:
>   - add the dt-bindings
> 
>  .../bindings/spi/semtech,sx1301.yaml          | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
> 
> diff --git a/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml b/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
> new file mode 100644
> index 000000000000..420fe8d23a1e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/semtech,sx1301.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Semtech sx1301 SPI controller bindings

This is still wrong.

Please also answer Michael's comments.

Best regards,
Krzysztof

Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Krzysztof Kozlowski]

On 20/04/2022 09:31, Changming Huang wrote:
> Add DT Binding doc for semtech sx1301
> 
> Signed-off-by: Changming Huang <jerry.huang@nxp.com>
> ---
> changes in v4:
>   - rename example node, adjust description
> changes in v3:
>   - add the dt-bindings
> 
>  .../bindings/spi/semtech,sx1301.yaml          | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
> 
> diff --git a/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml b/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
> new file mode 100644
> index 000000000000..420fe8d23a1e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/semtech,sx1301.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Semtech sx1301 SPI controller bindings

This is still wrong.

Please also answer Michael's comments.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Jerry Huang]

Best Regards
Jerry Huang

-----Original Message-----
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> 
Sent: 2022年4月20日 20:06
To: Jerry Huang <jerry.huang@nxp.com>; broonie@kernel.org; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; linux-spi@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; linux-arm-kernel@lists.infradead.org
Subject: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

Caution: EXT Email

On 20/04/2022 09:31, Changming Huang wrote:
> Add DT Binding doc for semtech sx1301
>
> Signed-off-by: Changming Huang <jerry.huang@nxp.com>
> ---
> changes in v4:
>   - rename example node, adjust description changes in v3:
>   - add the dt-bindings
>
>  .../bindings/spi/semtech,sx1301.yaml          | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
>
> diff --git a/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml 
> b/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
> new file mode 100644
> index 000000000000..420fe8d23a1e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: 
> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> +cetree.org%2Fschemas%2Fspi%2Fsemtech%2Csx1301.yaml%23&amp;data=05%7C0
> +1%7Cjerry.huang%40nxp.com%7C5fe40f1226344390810c08da22c629cc%7C686ea1
> +d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860531744722352%7CUnknown%7CT
> +WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> +I6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=22w71yaEE9QdRNdIzaNr5NcfGbTVbh0lNB
> +btch1n4e4%3D&amp;reserved=0
> +$schema: 
> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&amp;data=05%7C01%7Cjerry.hua
> +ng%40nxp.com%7C5fe40f1226344390810c08da22c629cc%7C686ea1d3bc2b4c6fa92
> +cd99c5c301635%7C0%7C0%7C637860531744722352%7CUnknown%7CTWFpbGZsb3d8ey
> +JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> +00%7C%7C%7C&amp;sdata=3XpGR4clLkzdKDh%2Fi26i4LQuuAYJ7E9%2Fv34lKn7%2Fa
> +4o%3D&amp;reserved=0
> +
> +title: Semtech sx1301 SPI controller bindings

This is still wrong.

Please also answer Michael's comments.

[Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
BLE P click: https://www.mikroe.com/ble-p-click
BEE click: https://www.mikroe.com/bee-click 
Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
So the name "semtech sx1301" is not correct for this node.

How about "mikroe, spi-dev" or any suggestion about it?


Best regards,
Krzysztof

RE: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Jerry Huang]

Best Regards
Jerry Huang

-----Original Message-----
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> 
Sent: 2022年4月20日 20:06
To: Jerry Huang <jerry.huang@nxp.com>; broonie@kernel.org; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; linux-spi@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; linux-arm-kernel@lists.infradead.org
Subject: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

Caution: EXT Email

On 20/04/2022 09:31, Changming Huang wrote:
> Add DT Binding doc for semtech sx1301
>
> Signed-off-by: Changming Huang <jerry.huang@nxp.com>
> ---
> changes in v4:
>   - rename example node, adjust description changes in v3:
>   - add the dt-bindings
>
>  .../bindings/spi/semtech,sx1301.yaml          | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
>
> diff --git a/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml 
> b/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
> new file mode 100644
> index 000000000000..420fe8d23a1e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: 
> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> +cetree.org%2Fschemas%2Fspi%2Fsemtech%2Csx1301.yaml%23&amp;data=05%7C0
> +1%7Cjerry.huang%40nxp.com%7C5fe40f1226344390810c08da22c629cc%7C686ea1
> +d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860531744722352%7CUnknown%7CT
> +WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> +I6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=22w71yaEE9QdRNdIzaNr5NcfGbTVbh0lNB
> +btch1n4e4%3D&amp;reserved=0
> +$schema: 
> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&amp;data=05%7C01%7Cjerry.hua
> +ng%40nxp.com%7C5fe40f1226344390810c08da22c629cc%7C686ea1d3bc2b4c6fa92
> +cd99c5c301635%7C0%7C0%7C637860531744722352%7CUnknown%7CTWFpbGZsb3d8ey
> +JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> +00%7C%7C%7C&amp;sdata=3XpGR4clLkzdKDh%2Fi26i4LQuuAYJ7E9%2Fv34lKn7%2Fa
> +4o%3D&amp;reserved=0
> +
> +title: Semtech sx1301 SPI controller bindings

This is still wrong.

Please also answer Michael's comments.

[Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
BLE P click: https://www.mikroe.com/ble-p-click
BEE click: https://www.mikroe.com/bee-click 
Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
So the name "semtech sx1301" is not correct for this node.

How about "mikroe, spi-dev" or any suggestion about it?


Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Krzysztof Kozlowski]

On 21/04/2022 11:11, Jerry Huang wrote:
> Please also answer Michael's comments.
> 
> [Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
> BLE P click: https://www.mikroe.com/ble-p-click
> BEE click: https://www.mikroe.com/bee-click 
> Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
> So the name "semtech sx1301" is not correct for this node.

I asked to remove the words "Devicetree bindings" and this was not finished.

Now you mention that entire name of device is wrong... It's confusing. I
don't know what device you are describing here. I expect you know. :)

What is this binding about exactly?

> How about "mikroe, spi-dev" or any suggestion about it?


Best regards,
Krzysztof

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Krzysztof Kozlowski]

On 21/04/2022 11:11, Jerry Huang wrote:
> Please also answer Michael's comments.
> 
> [Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
> BLE P click: https://www.mikroe.com/ble-p-click
> BEE click: https://www.mikroe.com/bee-click 
> Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
> So the name "semtech sx1301" is not correct for this node.

I asked to remove the words "Devicetree bindings" and this was not finished.

Now you mention that entire name of device is wrong... It's confusing. I
don't know what device you are describing here. I expect you know. :)

What is this binding about exactly?

> How about "mikroe, spi-dev" or any suggestion about it?


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Jerry Huang]

Best Regards
Jerry Huang

-----Original Message-----
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> 
Sent: 2022年4月21日 17:18
To: Jerry Huang <jerry.huang@nxp.com>; broonie@kernel.org; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; linux-spi@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; linux-arm-kernel@lists.infradead.org
Subject: Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

Caution: EXT Email

On 21/04/2022 11:11, Jerry Huang wrote:
> Please also answer Michael's comments.
>
> [Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
> BLE P click: 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> mikroe.com%2Fble-p-click&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C0a
> 1869e140a74bdfdad108da2377d636%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C637861294862753519%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdat
> a=%2FwswKJZxub37vxhjuDJ1iigspSPpb1U0kUQDxSaz5Yw%3D&amp;reserved=0
> BEE click: 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> mikroe.com%2Fbee-click&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C0a18
> 69e140a74bdfdad108da2377d636%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> 0%7C637861294862753519%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=
> bE7kpCsNBxoEumCJDbWif%2FX6Ya9px%2BGzWAqPTJ918QI%3D&amp;reserved=0
> Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
> So the name "semtech sx1301" is not correct for this node.

I asked to remove the words "Devicetree bindings" and this was not finished.

Now you mention that entire name of device is wrong... It's confusing. I don't know what device you are describing here. I expect you know. :)

What is this binding about exactly?
[Jerry Huang] 
I double checked the SPI device used on MikcroBus, which is not sx1301.
Now we have two MikcroBus click boards, BEE click and BLE P click, both of them have the SPI interface through MikcroBus.
So I can't use the previous name "semtech, sx1301".

> How about "mikroe, spi-dev" or any suggestion about it?


Best regards,
Krzysztof

RE: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Jerry Huang]

Best Regards
Jerry Huang

-----Original Message-----
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> 
Sent: 2022年4月21日 17:18
To: Jerry Huang <jerry.huang@nxp.com>; broonie@kernel.org; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; linux-spi@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; linux-arm-kernel@lists.infradead.org
Subject: Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

Caution: EXT Email

On 21/04/2022 11:11, Jerry Huang wrote:
> Please also answer Michael's comments.
>
> [Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
> BLE P click: 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> mikroe.com%2Fble-p-click&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C0a
> 1869e140a74bdfdad108da2377d636%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C637861294862753519%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdat
> a=%2FwswKJZxub37vxhjuDJ1iigspSPpb1U0kUQDxSaz5Yw%3D&amp;reserved=0
> BEE click: 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> mikroe.com%2Fbee-click&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C0a18
> 69e140a74bdfdad108da2377d636%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> 0%7C637861294862753519%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=
> bE7kpCsNBxoEumCJDbWif%2FX6Ya9px%2BGzWAqPTJ918QI%3D&amp;reserved=0
> Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
> So the name "semtech sx1301" is not correct for this node.

I asked to remove the words "Devicetree bindings" and this was not finished.

Now you mention that entire name of device is wrong... It's confusing. I don't know what device you are describing here. I expect you know. :)

What is this binding about exactly?
[Jerry Huang] 
I double checked the SPI device used on MikcroBus, which is not sx1301.
Now we have two MikcroBus click boards, BEE click and BLE P click, both of them have the SPI interface through MikcroBus.
So I can't use the previous name "semtech, sx1301".

> How about "mikroe, spi-dev" or any suggestion about it?


Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Michael Walle]

On 21/04/2022 11:11, Jerry Huang wrote:
>> Please also answer Michael's comments.
>> 
>> [Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
>> BLE P click: https://www.mikroe.com/ble-p-click
>> BEE click: https://www.mikroe.com/bee-click 
>> Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
>> So the name "semtech sx1301" is not correct for this node.
>
> I asked to remove the words "Devicetree bindings" and this was not finished.
> 
> Now you mention that entire name of device is wrong... It's confusing. I
> don't know what device you are describing here. I expect you know. :)
> 
> What is this binding about exactly?

I *think* it's just exposing the mikrobus connector as an spidev device.
There was a former attempt by Vladimir here [1]. Now as it the nature
of such a connector that you can connect a myriad of devices there, it
doesn't really make sense to have a just particular one described. What
happens if that one will switch from spidev to a real driver in the
kernel? So using "spidev" for the compatible would be the first reflex.
But as described in the spidev driver this is plain wrong (and also causes
a warning/info message it) because it should describe the actual hardware.

Thus I proposed to use DT overlays which are loaded according to what
is actually attached to the header, so a real driver could be loaded.

But there *could* be a sane default which then could be replaced in
an DT overlay. Like "mirkobus-socket" or similar, which might expose
spidev. Actually it is more than just SPI, there is GPIO and resets and
I2C. Maybe it should be an MFD? I don't know. But that is something for
the DT maintainers to decide if they'll allow such "generic" devices.

-michael

[1] https://lore.kernel.org/linux-devicetree/20200318001603.9650-13-olteanv@gmail.com/

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Michael Walle]

On 21/04/2022 11:11, Jerry Huang wrote:
>> Please also answer Michael's comments.
>> 
>> [Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
>> BLE P click: https://www.mikroe.com/ble-p-click
>> BEE click: https://www.mikroe.com/bee-click 
>> Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
>> So the name "semtech sx1301" is not correct for this node.
>
> I asked to remove the words "Devicetree bindings" and this was not finished.
> 
> Now you mention that entire name of device is wrong... It's confusing. I
> don't know what device you are describing here. I expect you know. :)
> 
> What is this binding about exactly?

I *think* it's just exposing the mikrobus connector as an spidev device.
There was a former attempt by Vladimir here [1]. Now as it the nature
of such a connector that you can connect a myriad of devices there, it
doesn't really make sense to have a just particular one described. What
happens if that one will switch from spidev to a real driver in the
kernel? So using "spidev" for the compatible would be the first reflex.
But as described in the spidev driver this is plain wrong (and also causes
a warning/info message it) because it should describe the actual hardware.

Thus I proposed to use DT overlays which are loaded according to what
is actually attached to the header, so a real driver could be loaded.

But there *could* be a sane default which then could be replaced in
an DT overlay. Like "mirkobus-socket" or similar, which might expose
spidev. Actually it is more than just SPI, there is GPIO and resets and
I2C. Maybe it should be an MFD? I don't know. But that is something for
the DT maintainers to decide if they'll allow such "generic" devices.

-michael

[1] https://lore.kernel.org/linux-devicetree/20200318001603.9650-13-olteanv@gmail.com/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Jerry Huang]

Best Regards
Jerry Huang

-----Original Message-----
From: Michael Walle <michael@walle.cc> 
Sent: 2022年4月21日 17:44
To: krzysztof.kozlowski@linaro.org
Cc: broonie@kernel.org; devicetree@vger.kernel.org; Jerry Huang <jerry.huang@nxp.com>; krzysztof.kozlowski+dt@linaro.org; Leo Li <leoyang.li@nxp.com>; linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-spi@vger.kernel.org; robh+dt@kernel.org; shawnguo@kernel.org; Vladimir Oltean <olteanv@gmail.com>; Michael Walle <michael@walle.cc>
Subject: Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

Caution: EXT Email

On 21/04/2022 11:11, Jerry Huang wrote:
>> Please also answer Michael's comments.
>>
>> [Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
>> BLE P click: 
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .mikroe.com%2Fble-p-click&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C
>> 39106c035c374b5ec60608da237b883f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
>> C0%7C1%7C637861310738684479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp
>> ;sdata=rsETzlFhfe2hyRAiQOL4KHAQ4vwh%2FFrYzroZ%2B0ccSMw%3D&amp;reserve
>> d=0 BEE click: 
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .mikroe.com%2Fbee-click&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C39
>> 106c035c374b5ec60608da237b883f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
>> %7C1%7C637861310738684479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;s
>> data=LEmwF46B9GYD%2BcpGoxpiGTnMgvTbLHP4IUirGR78A5U%3D&amp;reserved=0
>> Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
>> So the name "semtech sx1301" is not correct for this node.
>
> I asked to remove the words "Devicetree bindings" and this was not finished.
>
> Now you mention that entire name of device is wrong... It's confusing. 
> I don't know what device you are describing here. I expect you know. 
> :)
>
> What is this binding about exactly?

I *think* it's just exposing the mikrobus connector as an spidev device.
There was a former attempt by Vladimir here [1]. Now as it the nature of such a connector that you can connect a myriad of devices there, it doesn't really make sense to have a just particular one described. What happens if that one will switch from spidev to a real driver in the kernel? So using "spidev" for the compatible would be the first reflex.
But as described in the spidev driver this is plain wrong (and also causes a warning/info message it) because it should describe the actual hardware.

Thus I proposed to use DT overlays which are loaded according to what is actually attached to the header, so a real driver could be loaded.

But there *could* be a sane default which then could be replaced in an DT overlay. Like "mirkobus-socket" or similar, which might expose spidev. Actually it is more than just SPI, there is GPIO and resets and I2C. Maybe it should be an MFD? I don't know. But that is something for the DT maintainers to decide if they'll allow such "generic" devices.

-michael

[Jerry Huang] 
Thank a lot, Michael.
Yes, there are I2C, Uart (or GPIO) and SPI interface in MikcroBus socket. 

Krzysztof,
How about 
compatible = "mikcroe,mikcroe-socket"?
or how about Vladimir's patch?



[1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-devicetree%2F20200318001603.9650-13-olteanv%40gmail.com%2F&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C39106c035c374b5ec60608da237b883f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637861310738684479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=Y166YDGSpEX0wtUQE8V7ql8atkb79BmG9Y5mXb8KWJM%3D&amp;reserved=0

RE: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Jerry Huang]

Best Regards
Jerry Huang

-----Original Message-----
From: Michael Walle <michael@walle.cc> 
Sent: 2022年4月21日 17:44
To: krzysztof.kozlowski@linaro.org
Cc: broonie@kernel.org; devicetree@vger.kernel.org; Jerry Huang <jerry.huang@nxp.com>; krzysztof.kozlowski+dt@linaro.org; Leo Li <leoyang.li@nxp.com>; linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-spi@vger.kernel.org; robh+dt@kernel.org; shawnguo@kernel.org; Vladimir Oltean <olteanv@gmail.com>; Michael Walle <michael@walle.cc>
Subject: Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

Caution: EXT Email

On 21/04/2022 11:11, Jerry Huang wrote:
>> Please also answer Michael's comments.
>>
>> [Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
>> BLE P click: 
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .mikroe.com%2Fble-p-click&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C
>> 39106c035c374b5ec60608da237b883f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
>> C0%7C1%7C637861310738684479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp
>> ;sdata=rsETzlFhfe2hyRAiQOL4KHAQ4vwh%2FFrYzroZ%2B0ccSMw%3D&amp;reserve
>> d=0 BEE click: 
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .mikroe.com%2Fbee-click&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C39
>> 106c035c374b5ec60608da237b883f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
>> %7C1%7C637861310738684479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;s
>> data=LEmwF46B9GYD%2BcpGoxpiGTnMgvTbLHP4IUirGR78A5U%3D&amp;reserved=0
>> Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
>> So the name "semtech sx1301" is not correct for this node.
>
> I asked to remove the words "Devicetree bindings" and this was not finished.
>
> Now you mention that entire name of device is wrong... It's confusing. 
> I don't know what device you are describing here. I expect you know. 
> :)
>
> What is this binding about exactly?

I *think* it's just exposing the mikrobus connector as an spidev device.
There was a former attempt by Vladimir here [1]. Now as it the nature of such a connector that you can connect a myriad of devices there, it doesn't really make sense to have a just particular one described. What happens if that one will switch from spidev to a real driver in the kernel? So using "spidev" for the compatible would be the first reflex.
But as described in the spidev driver this is plain wrong (and also causes a warning/info message it) because it should describe the actual hardware.

Thus I proposed to use DT overlays which are loaded according to what is actually attached to the header, so a real driver could be loaded.

But there *could* be a sane default which then could be replaced in an DT overlay. Like "mirkobus-socket" or similar, which might expose spidev. Actually it is more than just SPI, there is GPIO and resets and I2C. Maybe it should be an MFD? I don't know. But that is something for the DT maintainers to decide if they'll allow such "generic" devices.

-michael

[Jerry Huang] 
Thank a lot, Michael.
Yes, there are I2C, Uart (or GPIO) and SPI interface in MikcroBus socket. 

Krzysztof,
How about 
compatible = "mikcroe,mikcroe-socket"?
or how about Vladimir's patch?



[1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-devicetree%2F20200318001603.9650-13-olteanv%40gmail.com%2F&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C39106c035c374b5ec60608da237b883f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637861310738684479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=Y166YDGSpEX0wtUQE8V7ql8atkb79BmG9Y5mXb8KWJM%3D&amp;reserved=0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Krzysztof Kozlowski]

On 21/04/2022 11:44, Michael Walle wrote:
> On 21/04/2022 11:11, Jerry Huang wrote:
>>> Please also answer Michael's comments.
>>>
>>> [Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
>>> BLE P click: https://www.mikroe.com/ble-p-click
>>> BEE click: https://www.mikroe.com/bee-click 
>>> Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
>>> So the name "semtech sx1301" is not correct for this node.
>>
>> I asked to remove the words "Devicetree bindings" and this was not finished.
>>
>> Now you mention that entire name of device is wrong... It's confusing. I
>> don't know what device you are describing here. I expect you know. :)
>>
>> What is this binding about exactly?
> 
> I *think* it's just exposing the mikrobus connector as an spidev device.
> There was a former attempt by Vladimir here [1]. 

That explains a lot, thanks! It's a pity it was not described here.

> Now as it the nature
> of such a connector that you can connect a myriad of devices there, it
> doesn't really make sense to have a just particular one described. What
> happens if that one will switch from spidev to a real driver in the
> kernel? So using "spidev" for the compatible would be the first reflex.
> But as described in the spidev driver this is plain wrong (and also causes
> a warning/info message it) because it should describe the actual hardware.

spidev device nodes are in general allowed, using the specific
compatible for a real device attached to the SPI.

Here it seems clearly that it's not the case. Using roghm,dh2228fv as a
"spidev" compatible for something else was wrong.

Adding another device - sx1301 - also does not look correct, if it is
not there.

> 
> Thus I proposed to use DT overlays which are loaded according to what
> is actually attached to the header, so a real driver could be loaded.
> 
> But there *could* be a sane default which then could be replaced in
> an DT overlay. Like "mirkobus-socket" or similar, which might expose
> spidev. Actually it is more than just SPI, there is GPIO and resets and
> I2C. Maybe it should be an MFD? I don't know. But that is something for
> the DT maintainers to decide if they'll allow such "generic" devices.

I think if you have DT overlay, you can add device node and there is no
need for placeholder, right?

Best regards,
Krzysztof

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Krzysztof Kozlowski]

On 21/04/2022 11:44, Michael Walle wrote:
> On 21/04/2022 11:11, Jerry Huang wrote:
>>> Please also answer Michael's comments.
>>>
>>> [Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
>>> BLE P click: https://www.mikroe.com/ble-p-click
>>> BEE click: https://www.mikroe.com/bee-click 
>>> Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
>>> So the name "semtech sx1301" is not correct for this node.
>>
>> I asked to remove the words "Devicetree bindings" and this was not finished.
>>
>> Now you mention that entire name of device is wrong... It's confusing. I
>> don't know what device you are describing here. I expect you know. :)
>>
>> What is this binding about exactly?
> 
> I *think* it's just exposing the mikrobus connector as an spidev device.
> There was a former attempt by Vladimir here [1]. 

That explains a lot, thanks! It's a pity it was not described here.

> Now as it the nature
> of such a connector that you can connect a myriad of devices there, it
> doesn't really make sense to have a just particular one described. What
> happens if that one will switch from spidev to a real driver in the
> kernel? So using "spidev" for the compatible would be the first reflex.
> But as described in the spidev driver this is plain wrong (and also causes
> a warning/info message it) because it should describe the actual hardware.

spidev device nodes are in general allowed, using the specific
compatible for a real device attached to the SPI.

Here it seems clearly that it's not the case. Using roghm,dh2228fv as a
"spidev" compatible for something else was wrong.

Adding another device - sx1301 - also does not look correct, if it is
not there.

> 
> Thus I proposed to use DT overlays which are loaded according to what
> is actually attached to the header, so a real driver could be loaded.
> 
> But there *could* be a sane default which then could be replaced in
> an DT overlay. Like "mirkobus-socket" or similar, which might expose
> spidev. Actually it is more than just SPI, there is GPIO and resets and
> I2C. Maybe it should be an MFD? I don't know. But that is something for
> the DT maintainers to decide if they'll allow such "generic" devices.

I think if you have DT overlay, you can add device node and there is no
need for placeholder, right?

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Michael Walle]

Am 2022-04-21 13:08, schrieb Krzysztof Kozlowski:
>> But there *could* be a sane default which then could be replaced in
>> an DT overlay. Like "mirkobus-socket" or similar, which might expose
>> spidev. Actually it is more than just SPI, there is GPIO and resets 
>> and
>> I2C. Maybe it should be an MFD? I don't know. But that is something 
>> for
>> the DT maintainers to decide if they'll allow such "generic" devices.
> 
> I think if you have DT overlay, you can add device node and there is no
> need for placeholder, right?

Yes, that is certainly correct. I was thinking of the user
experience. Sometimes you have eval board with that connector
to tinker around with different modules. Therefore I thought it
would be nice to have an userspace spi device by default for
first steps and tinkering.

There is UART which you can use by just opening the tty. There is
I2C which you can use by the i2ctools. There are GPIOs and PWM
which can also be used either by sysfs or the gpio-utils. But there
is no SPI device which can be used by the spi-tools.

But as I said, that is something up to you to decide :)

-michael

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Michael Walle]

Am 2022-04-21 13:08, schrieb Krzysztof Kozlowski:
>> But there *could* be a sane default which then could be replaced in
>> an DT overlay. Like "mirkobus-socket" or similar, which might expose
>> spidev. Actually it is more than just SPI, there is GPIO and resets 
>> and
>> I2C. Maybe it should be an MFD? I don't know. But that is something 
>> for
>> the DT maintainers to decide if they'll allow such "generic" devices.
> 
> I think if you have DT overlay, you can add device node and there is no
> need for placeholder, right?

Yes, that is certainly correct. I was thinking of the user
experience. Sometimes you have eval board with that connector
to tinker around with different modules. Therefore I thought it
would be nice to have an userspace spi device by default for
first steps and tinkering.

There is UART which you can use by just opening the tty. There is
I2C which you can use by the i2ctools. There are GPIOs and PWM
which can also be used either by sysfs or the gpio-utils. But there
is no SPI device which can be used by the spi-tools.

But as I said, that is something up to you to decide :)

-michael

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Rob Herring]

On Thu, Apr 21, 2022 at 11:44:21AM +0200, Michael Walle wrote:
> On 21/04/2022 11:11, Jerry Huang wrote:
> >> Please also answer Michael's comments.
> >> 
> >> [Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
> >> BLE P click: https://www.mikroe.com/ble-p-click
> >> BEE click: https://www.mikroe.com/bee-click 
> >> Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
> >> So the name "semtech sx1301" is not correct for this node.
> >
> > I asked to remove the words "Devicetree bindings" and this was not finished.
> > 
> > Now you mention that entire name of device is wrong... It's confusing. I
> > don't know what device you are describing here. I expect you know. :)
> > 
> > What is this binding about exactly?
> 
> I *think* it's just exposing the mikrobus connector as an spidev device.
> There was a former attempt by Vladimir here [1]. Now as it the nature
> of such a connector that you can connect a myriad of devices there, it
> doesn't really make sense to have a just particular one described. What
> happens if that one will switch from spidev to a real driver in the
> kernel? So using "spidev" for the compatible would be the first reflex.
> But as described in the spidev driver this is plain wrong (and also causes
> a warning/info message it) because it should describe the actual hardware.
> 
> Thus I proposed to use DT overlays which are loaded according to what
> is actually attached to the header, so a real driver could be loaded.
> 
> But there *could* be a sane default which then could be replaced in
> an DT overlay. Like "mirkobus-socket" or similar, which might expose
> spidev. Actually it is more than just SPI, there is GPIO and resets and
> I2C. Maybe it should be an MFD? I don't know. But that is something for
> the DT maintainers to decide if they'll allow such "generic" devices.

generic devices, no. MFD, no. 

What's needed here is a connector node (and driver) for the mikrobus 
socket. The connector node's purpose is to decouple the host DT from 
add-on board overlay DT. Something like this:

connector {
	// And a more specific compatible if pins can have alt funcs?
	// Spec version needed?
	compatible = "mikrobus-socket"; 

	// Will need regulators defined if child devices expect 
	// regulators
	vcc-33-supply = <&reg33>;
	vcc-5-supply = <&reg5v>;

	i2c-parent = <&i2c1>; // Already a defined property
	spi-parent = <&spi0>; // New

	// RST pin
	reset-gpios = <&gpio 4 0>;
	
	// remap 'INT' (index 0) to host interrupt
	#interrupt-cells = <2>;
	#address-cells = <0>;
	interrupt-map = <0 0 &gpio 3 0>;

	spi {
		//devices
	};

	i2c {

	};
};

The DT spec defines 'foo-map' properties extending interrupt-map. 
Currently only GPIO is defined. We might want to do the same thing for 
PWM. Or we make the connector node both a PWM consumer and provider.

Rob

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Rob Herring]

On Thu, Apr 21, 2022 at 11:44:21AM +0200, Michael Walle wrote:
> On 21/04/2022 11:11, Jerry Huang wrote:
> >> Please also answer Michael's comments.
> >> 
> >> [Jerry Huang] I double checked the MikroBus devices, we used two MikcroBus devices:
> >> BLE P click: https://www.mikroe.com/ble-p-click
> >> BEE click: https://www.mikroe.com/bee-click 
> >> Both of them are SPI interface connect to ls1028ardb through MiKcroBus interface.
> >> So the name "semtech sx1301" is not correct for this node.
> >
> > I asked to remove the words "Devicetree bindings" and this was not finished.
> > 
> > Now you mention that entire name of device is wrong... It's confusing. I
> > don't know what device you are describing here. I expect you know. :)
> > 
> > What is this binding about exactly?
> 
> I *think* it's just exposing the mikrobus connector as an spidev device.
> There was a former attempt by Vladimir here [1]. Now as it the nature
> of such a connector that you can connect a myriad of devices there, it
> doesn't really make sense to have a just particular one described. What
> happens if that one will switch from spidev to a real driver in the
> kernel? So using "spidev" for the compatible would be the first reflex.
> But as described in the spidev driver this is plain wrong (and also causes
> a warning/info message it) because it should describe the actual hardware.
> 
> Thus I proposed to use DT overlays which are loaded according to what
> is actually attached to the header, so a real driver could be loaded.
> 
> But there *could* be a sane default which then could be replaced in
> an DT overlay. Like "mirkobus-socket" or similar, which might expose
> spidev. Actually it is more than just SPI, there is GPIO and resets and
> I2C. Maybe it should be an MFD? I don't know. But that is something for
> the DT maintainers to decide if they'll allow such "generic" devices.

generic devices, no. MFD, no. 

What's needed here is a connector node (and driver) for the mikrobus 
socket. The connector node's purpose is to decouple the host DT from 
add-on board overlay DT. Something like this:

connector {
	// And a more specific compatible if pins can have alt funcs?
	// Spec version needed?
	compatible = "mikrobus-socket"; 

	// Will need regulators defined if child devices expect 
	// regulators
	vcc-33-supply = <&reg33>;
	vcc-5-supply = <&reg5v>;

	i2c-parent = <&i2c1>; // Already a defined property
	spi-parent = <&spi0>; // New

	// RST pin
	reset-gpios = <&gpio 4 0>;
	
	// remap 'INT' (index 0) to host interrupt
	#interrupt-cells = <2>;
	#address-cells = <0>;
	interrupt-map = <0 0 &gpio 3 0>;

	spi {
		//devices
	};

	i2c {

	};
};

The DT spec defines 'foo-map' properties extending interrupt-map. 
Currently only GPIO is defined. We might want to do the same thing for 
PWM. Or we make the connector node both a PWM consumer and provider.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Michael Walle]

Am 2022-04-21 16:23, schrieb Rob Herring:

> What's needed here is a connector node (and driver) for the mikrobus
> socket. The connector node's purpose is to decouple the host DT from
> add-on board overlay DT. Something like this:

Funny I had a similar idea to have a connector with all the
properties, but I failed to see how that would be of any help.

Do you mind an example of such an overlay? Judging by the spi
and i2c subnode, I guess it will amend the connector node and
fill in it's devices?

And all the child device properties will reference the connector,
correct?

> connector {
> 	// And a more specific compatible if pins can have alt funcs?
> 	// Spec version needed?
> 	compatible = "mikrobus-socket";
> 
> 	// Will need regulators defined if child devices expect
> 	// regulators
> 	vcc-33-supply = <&reg33>;
> 	vcc-5-supply = <&reg5v>;
> 
> 	i2c-parent = <&i2c1>; // Already a defined property
> 	spi-parent = <&spi0>; // New

uart/serial needed too?

> 
> 	// RST pin
> 	reset-gpios = <&gpio 4 0>;
> 
> 	// remap 'INT' (index 0) to host interrupt
> 	#interrupt-cells = <2>;
> 	#address-cells = <0>;
> 	interrupt-map = <0 0 &gpio 3 0>;
> 
> 	spi {

For example:

my-device@0 {
   reg = <0>;  // really needed? there is only one SPI CS line
   compatible = "my-device";
   reset-gpios = // may be left unset if it's optional, but what
                 // what if it is a required property and in hardware
                 // its connected to the RST pin of the module?
   other-gpios = <&connector 2>;
   vdd-supply = // what comes here? <&connector VCC_33>?
   interrupts-extended = <&connector 0 ..>;
}

-michael

> 		//devices
> 	};
> 
> 	i2c {
> 
> 	};
> };
> 
> The DT spec defines 'foo-map' properties extending interrupt-map.
> Currently only GPIO is defined. We might want to do the same thing for
> PWM. Or we make the connector node both a PWM consumer and provider.
> 
> Rob

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Michael Walle]

Am 2022-04-21 16:23, schrieb Rob Herring:

> What's needed here is a connector node (and driver) for the mikrobus
> socket. The connector node's purpose is to decouple the host DT from
> add-on board overlay DT. Something like this:

Funny I had a similar idea to have a connector with all the
properties, but I failed to see how that would be of any help.

Do you mind an example of such an overlay? Judging by the spi
and i2c subnode, I guess it will amend the connector node and
fill in it's devices?

And all the child device properties will reference the connector,
correct?

> connector {
> 	// And a more specific compatible if pins can have alt funcs?
> 	// Spec version needed?
> 	compatible = "mikrobus-socket";
> 
> 	// Will need regulators defined if child devices expect
> 	// regulators
> 	vcc-33-supply = <&reg33>;
> 	vcc-5-supply = <&reg5v>;
> 
> 	i2c-parent = <&i2c1>; // Already a defined property
> 	spi-parent = <&spi0>; // New

uart/serial needed too?

> 
> 	// RST pin
> 	reset-gpios = <&gpio 4 0>;
> 
> 	// remap 'INT' (index 0) to host interrupt
> 	#interrupt-cells = <2>;
> 	#address-cells = <0>;
> 	interrupt-map = <0 0 &gpio 3 0>;
> 
> 	spi {

For example:

my-device@0 {
   reg = <0>;  // really needed? there is only one SPI CS line
   compatible = "my-device";
   reset-gpios = // may be left unset if it's optional, but what
                 // what if it is a required property and in hardware
                 // its connected to the RST pin of the module?
   other-gpios = <&connector 2>;
   vdd-supply = // what comes here? <&connector VCC_33>?
   interrupts-extended = <&connector 0 ..>;
}

-michael

> 		//devices
> 	};
> 
> 	i2c {
> 
> 	};
> };
> 
> The DT spec defines 'foo-map' properties extending interrupt-map.
> Currently only GPIO is defined. We might want to do the same thing for
> PWM. Or we make the connector node both a PWM consumer and provider.
> 
> Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Rob Herring]

On Thu, Apr 21, 2022 at 10:16 AM Michael Walle <michael@walle.cc> wrote:
>
> Am 2022-04-21 16:23, schrieb Rob Herring:
>
> > What's needed here is a connector node (and driver) for the mikrobus
> > socket. The connector node's purpose is to decouple the host DT from
> > add-on board overlay DT. Something like this:
>
> Funny I had a similar idea to have a connector with all the
> properties, but I failed to see how that would be of any help.
>
> Do you mind an example of such an overlay? Judging by the spi
> and i2c subnode, I guess it will amend the connector node and
> fill in it's devices?

Right.

>
> And all the child device properties will reference the connector,
> correct?

Right.

>
> > connector {
> >       // And a more specific compatible if pins can have alt funcs?
> >       // Spec version needed?
> >       compatible = "mikrobus-socket";
> >
> >       // Will need regulators defined if child devices expect
> >       // regulators
> >       vcc-33-supply = <&reg33>;
> >       vcc-5-supply = <&reg5v>;
> >
> >       i2c-parent = <&i2c1>; // Already a defined property
> >       spi-parent = <&spi0>; // New
>
> uart/serial needed too?

Yes. Serial has the extra issue in the kernel that tty vs. serdev are
mutually exclusive and decided by presence or not of a child node for
the UART. That would need some work to dynamically switch. I think I
have some old patches doing that, but they probably break some aspects
of TTY expectations.

>
> >
> >       // RST pin
> >       reset-gpios = <&gpio 4 0>;
> >
> >       // remap 'INT' (index 0) to host interrupt
> >       #interrupt-cells = <2>;
> >       #address-cells = <0>;
> >       interrupt-map = <0 0 &gpio 3 0>;
> >
> >       spi {
>
> For example:
>
> my-device@0 {
>    reg = <0>;  // really needed? there is only one SPI CS line

Yes, needed.

>    compatible = "my-device";
>    reset-gpios = // may be left unset if it's optional, but what
>                  // what if it is a required property and in hardware
>                  // its connected to the RST pin of the module?

Probably should not be required and the connector driver manages it.

>    other-gpios = <&connector 2>;
>    vdd-supply = // what comes here? <&connector VCC_33>?

That has to be figured out, but *-supply doesn't take arg cells
currently. Probably the connector needs to define its own regulator
nodes.

>    interrupts-extended = <&connector 0 ..>;
> }

Rob

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Rob Herring]

On Thu, Apr 21, 2022 at 10:16 AM Michael Walle <michael@walle.cc> wrote:
>
> Am 2022-04-21 16:23, schrieb Rob Herring:
>
> > What's needed here is a connector node (and driver) for the mikrobus
> > socket. The connector node's purpose is to decouple the host DT from
> > add-on board overlay DT. Something like this:
>
> Funny I had a similar idea to have a connector with all the
> properties, but I failed to see how that would be of any help.
>
> Do you mind an example of such an overlay? Judging by the spi
> and i2c subnode, I guess it will amend the connector node and
> fill in it's devices?

Right.

>
> And all the child device properties will reference the connector,
> correct?

Right.

>
> > connector {
> >       // And a more specific compatible if pins can have alt funcs?
> >       // Spec version needed?
> >       compatible = "mikrobus-socket";
> >
> >       // Will need regulators defined if child devices expect
> >       // regulators
> >       vcc-33-supply = <&reg33>;
> >       vcc-5-supply = <&reg5v>;
> >
> >       i2c-parent = <&i2c1>; // Already a defined property
> >       spi-parent = <&spi0>; // New
>
> uart/serial needed too?

Yes. Serial has the extra issue in the kernel that tty vs. serdev are
mutually exclusive and decided by presence or not of a child node for
the UART. That would need some work to dynamically switch. I think I
have some old patches doing that, but they probably break some aspects
of TTY expectations.

>
> >
> >       // RST pin
> >       reset-gpios = <&gpio 4 0>;
> >
> >       // remap 'INT' (index 0) to host interrupt
> >       #interrupt-cells = <2>;
> >       #address-cells = <0>;
> >       interrupt-map = <0 0 &gpio 3 0>;
> >
> >       spi {
>
> For example:
>
> my-device@0 {
>    reg = <0>;  // really needed? there is only one SPI CS line

Yes, needed.

>    compatible = "my-device";
>    reset-gpios = // may be left unset if it's optional, but what
>                  // what if it is a required property and in hardware
>                  // its connected to the RST pin of the module?

Probably should not be required and the connector driver manages it.

>    other-gpios = <&connector 2>;
>    vdd-supply = // what comes here? <&connector VCC_33>?

That has to be figured out, but *-supply doesn't take arg cells
currently. Probably the connector needs to define its own regulator
nodes.

>    interrupts-extended = <&connector 0 ..>;
> }

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Jerry Huang]

>-----Original Message-----
>From: Rob Herring <robh@kernel.org>
>Sent: 2022年4月22日 3:08
>To: Michael Walle <michael@walle.cc>
>Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>; Mark Brown
><broonie@kernel.org>; devicetree@vger.kernel.org; Jerry Huang
><jerry.huang@nxp.com>; Krzysztof Kozlowski
><krzysztof.kozlowski+dt@linaro.org>; Leo Li <leoyang.li@nxp.com>;
>linux-arm-kernel <linux-arm-kernel@lists.infradead.org>;
>linux-kernel@vger.kernel.org; linux-spi <linux-spi@vger.kernel.org>; Shawn Guo
><shawnguo@kernel.org>; Vladimir Oltean <olteanv@gmail.com>
>Subject: Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301
>
>Caution: EXT Email
>
>On Thu, Apr 21, 2022 at 10:16 AM Michael Walle <michael@walle.cc> wrote:
>>
>> Am 2022-04-21 16:23, schrieb Rob Herring:
>>
>> > What's needed here is a connector node (and driver) for the mikrobus
>> > socket. The connector node's purpose is to decouple the host DT from
>> > add-on board overlay DT. Something like this:
>>
>> Funny I had a similar idea to have a connector with all the
>> properties, but I failed to see how that would be of any help.
>>
>> Do you mind an example of such an overlay? Judging by the spi and i2c
>> subnode, I guess it will amend the connector node and fill in it's
>> devices?
>
>Right.
>
>>
>> And all the child device properties will reference the connector,
>> correct?
>
>Right.
>
>>
>> > connector {
>> >       // And a more specific compatible if pins can have alt funcs?
>> >       // Spec version needed?
>> >       compatible = "mikrobus-socket";
>> >
>> >       // Will need regulators defined if child devices expect
>> >       // regulators
>> >       vcc-33-supply = <&reg33>;
>> >       vcc-5-supply = <&reg5v>;
>> >
>> >       i2c-parent = <&i2c1>; // Already a defined property
>> >       spi-parent = <&spi0>; // New
>>
>> uart/serial needed too?
>
>Yes. Serial has the extra issue in the kernel that tty vs. serdev are mutually
>exclusive and decided by presence or not of a child node for the UART. That would
>need some work to dynamically switch. I think I have some old patches doing that,
>but they probably break some aspects of TTY expectations.
>
>>
>> >
>> >       // RST pin
>> >       reset-gpios = <&gpio 4 0>;
>> >
>> >       // remap 'INT' (index 0) to host interrupt
>> >       #interrupt-cells = <2>;
>> >       #address-cells = <0>;
>> >       interrupt-map = <0 0 &gpio 3 0>;
>> >
>> >       spi {
>>
>> For example:
>>
>> my-device@0 {
>>    reg = <0>;  // really needed? there is only one SPI CS line
>
>Yes, needed.
>
>>    compatible = "my-device";
>>    reset-gpios = // may be left unset if it's optional, but what
>>                  // what if it is a required property and in hardware
>>                  // its connected to the RST pin of the module?
>
>Probably should not be required and the connector driver manages it.
>
>>    other-gpios = <&connector 2>;
>>    vdd-supply = // what comes here? <&connector VCC_33>?
>
>That has to be figured out, but *-supply doesn't take arg cells currently. Probably
>the connector needs to define its own regulator nodes.
>
>>    interrupts-extended = <&connector 0 ..>; }
>
So, how to handle the MkcroBus connector? Any suggestion for following?
&dspi2 {
        bus-num = <2>;
        status = "okay";

        /* MikcroBus1 */
        spi@0 {
                compatible = "mikcroe,mikcroe-socket";
                reg = <0>;
                spi-max-frequency = <2000000>;
                fsl,spi-cs-sck-delay = <1000000>;
                fsl,spi-sck-cs-delay = <50>;
        };
};

RE: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Jerry Huang]

>-----Original Message-----
>From: Rob Herring <robh@kernel.org>
>Sent: 2022年4月22日 3:08
>To: Michael Walle <michael@walle.cc>
>Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>; Mark Brown
><broonie@kernel.org>; devicetree@vger.kernel.org; Jerry Huang
><jerry.huang@nxp.com>; Krzysztof Kozlowski
><krzysztof.kozlowski+dt@linaro.org>; Leo Li <leoyang.li@nxp.com>;
>linux-arm-kernel <linux-arm-kernel@lists.infradead.org>;
>linux-kernel@vger.kernel.org; linux-spi <linux-spi@vger.kernel.org>; Shawn Guo
><shawnguo@kernel.org>; Vladimir Oltean <olteanv@gmail.com>
>Subject: Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301
>
>Caution: EXT Email
>
>On Thu, Apr 21, 2022 at 10:16 AM Michael Walle <michael@walle.cc> wrote:
>>
>> Am 2022-04-21 16:23, schrieb Rob Herring:
>>
>> > What's needed here is a connector node (and driver) for the mikrobus
>> > socket. The connector node's purpose is to decouple the host DT from
>> > add-on board overlay DT. Something like this:
>>
>> Funny I had a similar idea to have a connector with all the
>> properties, but I failed to see how that would be of any help.
>>
>> Do you mind an example of such an overlay? Judging by the spi and i2c
>> subnode, I guess it will amend the connector node and fill in it's
>> devices?
>
>Right.
>
>>
>> And all the child device properties will reference the connector,
>> correct?
>
>Right.
>
>>
>> > connector {
>> >       // And a more specific compatible if pins can have alt funcs?
>> >       // Spec version needed?
>> >       compatible = "mikrobus-socket";
>> >
>> >       // Will need regulators defined if child devices expect
>> >       // regulators
>> >       vcc-33-supply = <&reg33>;
>> >       vcc-5-supply = <&reg5v>;
>> >
>> >       i2c-parent = <&i2c1>; // Already a defined property
>> >       spi-parent = <&spi0>; // New
>>
>> uart/serial needed too?
>
>Yes. Serial has the extra issue in the kernel that tty vs. serdev are mutually
>exclusive and decided by presence or not of a child node for the UART. That would
>need some work to dynamically switch. I think I have some old patches doing that,
>but they probably break some aspects of TTY expectations.
>
>>
>> >
>> >       // RST pin
>> >       reset-gpios = <&gpio 4 0>;
>> >
>> >       // remap 'INT' (index 0) to host interrupt
>> >       #interrupt-cells = <2>;
>> >       #address-cells = <0>;
>> >       interrupt-map = <0 0 &gpio 3 0>;
>> >
>> >       spi {
>>
>> For example:
>>
>> my-device@0 {
>>    reg = <0>;  // really needed? there is only one SPI CS line
>
>Yes, needed.
>
>>    compatible = "my-device";
>>    reset-gpios = // may be left unset if it's optional, but what
>>                  // what if it is a required property and in hardware
>>                  // its connected to the RST pin of the module?
>
>Probably should not be required and the connector driver manages it.
>
>>    other-gpios = <&connector 2>;
>>    vdd-supply = // what comes here? <&connector VCC_33>?
>
>That has to be figured out, but *-supply doesn't take arg cells currently. Probably
>the connector needs to define its own regulator nodes.
>
>>    interrupts-extended = <&connector 0 ..>; }
>
So, how to handle the MkcroBus connector? Any suggestion for following?
&dspi2 {
        bus-num = <2>;
        status = "okay";

        /* MikcroBus1 */
        spi@0 {
                compatible = "mikcroe,mikcroe-socket";
                reg = <0>;
                spi-max-frequency = <2000000>;
                fsl,spi-cs-sck-delay = <1000000>;
                fsl,spi-sck-cs-delay = <50>;
        };
};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Rob Herring]

On Thu, Apr 21, 2022 at 09:11:59AM +0000, Jerry Huang wrote:
> 
> 
> 
> Best Regards
> Jerry Huang
> 
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> 
> Sent: 2022年4月20日 20:06
> To: Jerry Huang <jerry.huang@nxp.com>; broonie@kernel.org; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; linux-spi@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; linux-arm-kernel@lists.infradead.org
> Subject: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301
> 
> Caution: EXT Email

Please fix your email client/setup to not change the subject, use the 
right reply quoting (1 line, not quoting To, Subject, etc.), and 
not corrupting urls.

Rob

Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Rob Herring]

On Thu, Apr 21, 2022 at 09:11:59AM +0000, Jerry Huang wrote:
> 
> 
> 
> Best Regards
> Jerry Huang
> 
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> 
> Sent: 2022年4月20日 20:06
> To: Jerry Huang <jerry.huang@nxp.com>; broonie@kernel.org; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; linux-spi@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; linux-arm-kernel@lists.infradead.org
> Subject: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301
> 
> Caution: EXT Email

Please fix your email client/setup to not change the subject, use the 
right reply quoting (1 line, not quoting To, Subject, etc.), and 
not corrupting urls.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Rob Herring]

On Wed, 20 Apr 2022 15:31:45 +0800, Changming Huang wrote:
> Add DT Binding doc for semtech sx1301
> 
> Signed-off-by: Changming Huang <jerry.huang@nxp.com>
> ---
> changes in v4:
>   - rename example node, adjust description
> changes in v3:
>   - add the dt-bindings
> 
>  .../bindings/spi/semtech,sx1301.yaml          | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-sck-cs-delay: True is not of type 'object'
	hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
	from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-sck-cs-delay: More than one condition true in oneOf schema:
	{'description': 'Vendor specific properties must have a type and '
	                'description unless they have a defined, common '
	                'suffix.',
	 'oneOf': [{'additionalProperties': False,
	            'description': 'A vendor boolean property can use "type: '
	                           'boolean"',
	            'properties': {'deprecated': True,
	                           'description': True,
	                           'type': {'const': 'boolean'}},
	            'required': ['type', 'description']},
	           {'additionalProperties': False,
	            'description': 'A vendor string property with exact values '
	                           'has an implicit type',
	            'oneOf': [{'required': ['enum']}, {'required': ['const']}],
	            'properties': {'const': {'type': 'string'},
	                           'deprecated': True,
	                           'description': True,
	                           'enum': {'items': {'type': 'string'}}},
	            'required': ['description']},
	           {'description': 'A vendor property needs a $ref to '
	                           'types.yaml',
	            'oneOf': [{'required': ['$ref']}, {'required': ['allOf']}],
	            'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'},
	                           'allOf': {'items': [{'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'}},
	                                                'required': ['$ref']}]}},
	            'required': ['description']},
	           {'description': 'A vendor property can have a $ref to a a '
	                           '$defs schema',
	            'properties': {'$ref': {'pattern': '^#/(definitions|$defs)/'}},
	            'required': ['$ref']}],
	 'type': 'object'}
	hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
	from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-cs-sck-delay: True is not of type 'object'
	hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
	from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-cs-sck-delay: More than one condition true in oneOf schema:
	{'description': 'Vendor specific properties must have a type and '
	                'description unless they have a defined, common '
	                'suffix.',
	 'oneOf': [{'additionalProperties': False,
	            'description': 'A vendor boolean property can use "type: '
	                           'boolean"',
	            'properties': {'deprecated': True,
	                           'description': True,
	                           'type': {'const': 'boolean'}},
	            'required': ['type', 'description']},
	           {'additionalProperties': False,
	            'description': 'A vendor string property with exact values '
	                           'has an implicit type',
	            'oneOf': [{'required': ['enum']}, {'required': ['const']}],
	            'properties': {'const': {'type': 'string'},
	                           'deprecated': True,
	                           'description': True,
	                           'enum': {'items': {'type': 'string'}}},
	            'required': ['description']},
	           {'description': 'A vendor property needs a $ref to '
	                           'types.yaml',
	            'oneOf': [{'required': ['$ref']}, {'required': ['allOf']}],
	            'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'},
	                           'allOf': {'items': [{'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'}},
	                                                'required': ['$ref']}]}},
	            'required': ['description']},
	           {'description': 'A vendor property can have a $ref to a a '
	                           '$defs schema',
	            'properties': {'$ref': {'pattern': '^#/(definitions|$defs)/'}},
	            'required': ['$ref']}],
	 'type': 'object'}
	hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
	from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: ignoring, error in schema: properties: fsl,spi-cs-sck-delay
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dts:22.11-21: Warning (reg_format): /example-0/spi@0:reg: property has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: example-0: spi@0:reg:0: [0] is too short
	From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb:0:0: /example-0/spi@0: failed to match any schema with compatible: ['semtech,sx1301']

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Rob Herring]

On Wed, 20 Apr 2022 15:31:45 +0800, Changming Huang wrote:
> Add DT Binding doc for semtech sx1301
> 
> Signed-off-by: Changming Huang <jerry.huang@nxp.com>
> ---
> changes in v4:
>   - rename example node, adjust description
> changes in v3:
>   - add the dt-bindings
> 
>  .../bindings/spi/semtech,sx1301.yaml          | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-sck-cs-delay: True is not of type 'object'
	hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
	from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-sck-cs-delay: More than one condition true in oneOf schema:
	{'description': 'Vendor specific properties must have a type and '
	                'description unless they have a defined, common '
	                'suffix.',
	 'oneOf': [{'additionalProperties': False,
	            'description': 'A vendor boolean property can use "type: '
	                           'boolean"',
	            'properties': {'deprecated': True,
	                           'description': True,
	                           'type': {'const': 'boolean'}},
	            'required': ['type', 'description']},
	           {'additionalProperties': False,
	            'description': 'A vendor string property with exact values '
	                           'has an implicit type',
	            'oneOf': [{'required': ['enum']}, {'required': ['const']}],
	            'properties': {'const': {'type': 'string'},
	                           'deprecated': True,
	                           'description': True,
	                           'enum': {'items': {'type': 'string'}}},
	            'required': ['description']},
	           {'description': 'A vendor property needs a $ref to '
	                           'types.yaml',
	            'oneOf': [{'required': ['$ref']}, {'required': ['allOf']}],
	            'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'},
	                           'allOf': {'items': [{'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'}},
	                                                'required': ['$ref']}]}},
	            'required': ['description']},
	           {'description': 'A vendor property can have a $ref to a a '
	                           '$defs schema',
	            'properties': {'$ref': {'pattern': '^#/(definitions|$defs)/'}},
	            'required': ['$ref']}],
	 'type': 'object'}
	hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
	from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-cs-sck-delay: True is not of type 'object'
	hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
	from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-cs-sck-delay: More than one condition true in oneOf schema:
	{'description': 'Vendor specific properties must have a type and '
	                'description unless they have a defined, common '
	                'suffix.',
	 'oneOf': [{'additionalProperties': False,
	            'description': 'A vendor boolean property can use "type: '
	                           'boolean"',
	            'properties': {'deprecated': True,
	                           'description': True,
	                           'type': {'const': 'boolean'}},
	            'required': ['type', 'description']},
	           {'additionalProperties': False,
	            'description': 'A vendor string property with exact values '
	                           'has an implicit type',
	            'oneOf': [{'required': ['enum']}, {'required': ['const']}],
	            'properties': {'const': {'type': 'string'},
	                           'deprecated': True,
	                           'description': True,
	                           'enum': {'items': {'type': 'string'}}},
	            'required': ['description']},
	           {'description': 'A vendor property needs a $ref to '
	                           'types.yaml',
	            'oneOf': [{'required': ['$ref']}, {'required': ['allOf']}],
	            'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'},
	                           'allOf': {'items': [{'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'}},
	                                                'required': ['$ref']}]}},
	            'required': ['description']},
	           {'description': 'A vendor property can have a $ref to a a '
	                           '$defs schema',
	            'properties': {'$ref': {'pattern': '^#/(definitions|$defs)/'}},
	            'required': ['$ref']}],
	 'type': 'object'}
	hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
	from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: ignoring, error in schema: properties: fsl,spi-cs-sck-delay
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dts:22.11-21: Warning (reg_format): /example-0/spi@0:reg: property has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: example-0: spi@0:reg:0: [0] is too short
	From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb:0:0: /example-0/spi@0: failed to match any schema with compatible: ['semtech,sx1301']

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Jerry Huang]

Best Regards
Jerry Huang

-----Original Message-----
From: Rob Herring <robh@kernel.org> 
Sent: 2022年4月20日 21:30
To: Jerry Huang <jerry.huang@nxp.com>
Cc: Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org; linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; krzysztof.kozlowski+dt@linaro.org; linux-arm-kernel@lists.infradead.org; robh+dt@kernel.org; devicetree@vger.kernel.org; broonie@kernel.org
Subject: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

Caution: EXT Email

On Wed, 20 Apr 2022 15:31:45 +0800, Changming Huang wrote:
> Add DT Binding doc for semtech sx1301
>
> Signed-off-by: Changming Huang <jerry.huang@nxp.com>
> ---
> changes in v4:
>   - rename example node, adjust description changes in v3:
>   - add the dt-bindings
>
>  .../bindings/spi/semtech,sx1301.yaml          | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
>

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-sck-cs-delay: True is not of type 'object'
        hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
        from schema $id: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fvendor-props.yaml%23&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=LJ%2FuvDhfQl3lgMd0zVeuX64bQWfLIAocCj5REq5A3so%3D&amp;reserved=0
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-sck-cs-delay: More than one condition true in oneOf schema:
        {'description': 'Vendor specific properties must have a type and '
                        'description unless they have a defined, common '
                        'suffix.',
         'oneOf': [{'additionalProperties': False,
                    'description': 'A vendor boolean property can use "type: '
                                   'boolean"',
                    'properties': {'deprecated': True,
                                   'description': True,
                                   'type': {'const': 'boolean'}},
                    'required': ['type', 'description']},
                   {'additionalProperties': False,
                    'description': 'A vendor string property with exact values '
                                   'has an implicit type',
                    'oneOf': [{'required': ['enum']}, {'required': ['const']}],
                    'properties': {'const': {'type': 'string'},
                                   'deprecated': True,
                                   'description': True,
                                   'enum': {'items': {'type': 'string'}}},
                    'required': ['description']},
                   {'description': 'A vendor property needs a $ref to '
                                   'types.yaml',
                    'oneOf': [{'required': ['$ref']}, {'required': ['allOf']}],
                    'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'},
                                   'allOf': {'items': [{'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'}},
                                                        'required': ['$ref']}]}},
                    'required': ['description']},
                   {'description': 'A vendor property can have a $ref to a a '
                                   '$defs schema',
                    'properties': {'$ref': {'pattern': '^#/(definitions|$defs)/'}},
                    'required': ['$ref']}],
         'type': 'object'}
        hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
        from schema $id: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fvendor-props.yaml%23&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=LJ%2FuvDhfQl3lgMd0zVeuX64bQWfLIAocCj5REq5A3so%3D&amp;reserved=0
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-cs-sck-delay: True is not of type 'object'
        hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
        from schema $id: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fvendor-props.yaml%23&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=LJ%2FuvDhfQl3lgMd0zVeuX64bQWfLIAocCj5REq5A3so%3D&amp;reserved=0
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-cs-sck-delay: More than one condition true in oneOf schema:
        {'description': 'Vendor specific properties must have a type and '
                        'description unless they have a defined, common '
                        'suffix.',
         'oneOf': [{'additionalProperties': False,
                    'description': 'A vendor boolean property can use "type: '
                                   'boolean"',
                    'properties': {'deprecated': True,
                                   'description': True,
                                   'type': {'const': 'boolean'}},
                    'required': ['type', 'description']},
                   {'additionalProperties': False,
                    'description': 'A vendor string property with exact values '
                                   'has an implicit type',
                    'oneOf': [{'required': ['enum']}, {'required': ['const']}],
                    'properties': {'const': {'type': 'string'},
                                   'deprecated': True,
                                   'description': True,
                                   'enum': {'items': {'type': 'string'}}},
                    'required': ['description']},
                   {'description': 'A vendor property needs a $ref to '
                                   'types.yaml',
                    'oneOf': [{'required': ['$ref']}, {'required': ['allOf']}],
                    'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'},
                                   'allOf': {'items': [{'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'}},
                                                        'required': ['$ref']}]}},
                    'required': ['description']},
                   {'description': 'A vendor property can have a $ref to a a '
                                   '$defs schema',
                    'properties': {'$ref': {'pattern': '^#/(definitions|$defs)/'}},
                    'required': ['$ref']}],
         'type': 'object'}
        hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
        from schema $id: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fvendor-props.yaml%23&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=LJ%2FuvDhfQl3lgMd0zVeuX64bQWfLIAocCj5REq5A3so%3D&amp;reserved=0
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: ignoring, error in schema: properties: fsl,spi-cs-sck-delay
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dts:22.11-21: Warning (reg_format): /example-0/spi@0:reg: property has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: example-0: spi@0:reg:0: [0] is too short
        From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb:0:0: /example-0/spi@0: failed to match any schema with compatible: ['semtech,sx1301']

doc reference errors (make refcheckdocs):

See https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=WTdBfNjqzZBsnUBcRahew10JM84KqTEpI4bWNtHcKKU%3D&amp;reserved=0

This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

[Jerry Huang] 
After correcting the name of compatible, I will run the command to check this binding file.

RE: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

[Jerry Huang]

Best Regards
Jerry Huang

-----Original Message-----
From: Rob Herring <robh@kernel.org> 
Sent: 2022年4月20日 21:30
To: Jerry Huang <jerry.huang@nxp.com>
Cc: Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org; linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; krzysztof.kozlowski+dt@linaro.org; linux-arm-kernel@lists.infradead.org; robh+dt@kernel.org; devicetree@vger.kernel.org; broonie@kernel.org
Subject: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301

Caution: EXT Email

On Wed, 20 Apr 2022 15:31:45 +0800, Changming Huang wrote:
> Add DT Binding doc for semtech sx1301
>
> Signed-off-by: Changming Huang <jerry.huang@nxp.com>
> ---
> changes in v4:
>   - rename example node, adjust description changes in v3:
>   - add the dt-bindings
>
>  .../bindings/spi/semtech,sx1301.yaml          | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/spi/semtech,sx1301.yaml
>

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-sck-cs-delay: True is not of type 'object'
        hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
        from schema $id: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fvendor-props.yaml%23&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=LJ%2FuvDhfQl3lgMd0zVeuX64bQWfLIAocCj5REq5A3so%3D&amp;reserved=0
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-sck-cs-delay: More than one condition true in oneOf schema:
        {'description': 'Vendor specific properties must have a type and '
                        'description unless they have a defined, common '
                        'suffix.',
         'oneOf': [{'additionalProperties': False,
                    'description': 'A vendor boolean property can use "type: '
                                   'boolean"',
                    'properties': {'deprecated': True,
                                   'description': True,
                                   'type': {'const': 'boolean'}},
                    'required': ['type', 'description']},
                   {'additionalProperties': False,
                    'description': 'A vendor string property with exact values '
                                   'has an implicit type',
                    'oneOf': [{'required': ['enum']}, {'required': ['const']}],
                    'properties': {'const': {'type': 'string'},
                                   'deprecated': True,
                                   'description': True,
                                   'enum': {'items': {'type': 'string'}}},
                    'required': ['description']},
                   {'description': 'A vendor property needs a $ref to '
                                   'types.yaml',
                    'oneOf': [{'required': ['$ref']}, {'required': ['allOf']}],
                    'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'},
                                   'allOf': {'items': [{'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'}},
                                                        'required': ['$ref']}]}},
                    'required': ['description']},
                   {'description': 'A vendor property can have a $ref to a a '
                                   '$defs schema',
                    'properties': {'$ref': {'pattern': '^#/(definitions|$defs)/'}},
                    'required': ['$ref']}],
         'type': 'object'}
        hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
        from schema $id: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fvendor-props.yaml%23&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=LJ%2FuvDhfQl3lgMd0zVeuX64bQWfLIAocCj5REq5A3so%3D&amp;reserved=0
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-cs-sck-delay: True is not of type 'object'
        hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
        from schema $id: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fvendor-props.yaml%23&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=LJ%2FuvDhfQl3lgMd0zVeuX64bQWfLIAocCj5REq5A3so%3D&amp;reserved=0
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: properties:fsl,spi-cs-sck-delay: More than one condition true in oneOf schema:
        {'description': 'Vendor specific properties must have a type and '
                        'description unless they have a defined, common '
                        'suffix.',
         'oneOf': [{'additionalProperties': False,
                    'description': 'A vendor boolean property can use "type: '
                                   'boolean"',
                    'properties': {'deprecated': True,
                                   'description': True,
                                   'type': {'const': 'boolean'}},
                    'required': ['type', 'description']},
                   {'additionalProperties': False,
                    'description': 'A vendor string property with exact values '
                                   'has an implicit type',
                    'oneOf': [{'required': ['enum']}, {'required': ['const']}],
                    'properties': {'const': {'type': 'string'},
                                   'deprecated': True,
                                   'description': True,
                                   'enum': {'items': {'type': 'string'}}},
                    'required': ['description']},
                   {'description': 'A vendor property needs a $ref to '
                                   'types.yaml',
                    'oneOf': [{'required': ['$ref']}, {'required': ['allOf']}],
                    'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'},
                                   'allOf': {'items': [{'properties': {'$ref': {'pattern': 'types.yaml#/definitions/'}},
                                                        'required': ['$ref']}]}},
                    'required': ['description']},
                   {'description': 'A vendor property can have a $ref to a a '
                                   '$defs schema',
                    'properties': {'$ref': {'pattern': '^#/(definitions|$defs)/'}},
                    'required': ['$ref']}],
         'type': 'object'}
        hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
        from schema $id: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fvendor-props.yaml%23&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=LJ%2FuvDhfQl3lgMd0zVeuX64bQWfLIAocCj5REq5A3so%3D&amp;reserved=0
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.yaml: ignoring, error in schema: properties: fsl,spi-cs-sck-delay
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dts:22.11-21: Warning (reg_format): /example-0/spi@0:reg: property has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb: example-0: spi@0:reg:0: [0] is too short
        From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
Documentation/devicetree/bindings/spi/semtech,sx1301.example.dtb:0:0: /example-0/spi@0: failed to match any schema with compatible: ['semtech,sx1301']

doc reference errors (make refcheckdocs):

See https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F&amp;data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=WTdBfNjqzZBsnUBcRahew10JM84KqTEpI4bWNtHcKKU%3D&amp;reserved=0

This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

[Jerry Huang] 
After correcting the name of compatible, I will run the command to check this binding file.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel