| Message ID | 20220420073146.38086-1-jerry.huang@nxp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2,v4] dt-bindings: dspi: added for semtech sx1301 | expand |
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
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.
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&data=05%7C0 > +1%7Cjerry.huang%40nxp.com%7C5fe40f1226344390810c08da22c629cc%7C686ea1 > +d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860531744722352%7CUnknown%7CT > +WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC > +I6Mn0%3D%7C3000%7C%7C%7C&sdata=22w71yaEE9QdRNdIzaNr5NcfGbTVbh0lNB > +btch1n4e4%3D&reserved=0 > +$schema: > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=05%7C01%7Cjerry.hua > +ng%40nxp.com%7C5fe40f1226344390810c08da22c629cc%7C686ea1d3bc2b4c6fa92 > +cd99c5c301635%7C0%7C0%7C637860531744722352%7CUnknown%7CTWFpbGZsb3d8ey > +JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30 > +00%7C%7C%7C&sdata=3XpGR4clLkzdKDh%2Fi26i4LQuuAYJ7E9%2Fv34lKn7%2Fa > +4o%3D&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
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&data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LJ%2FuvDhfQl3lgMd0zVeuX64bQWfLIAocCj5REq5A3so%3D&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&data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LJ%2FuvDhfQl3lgMd0zVeuX64bQWfLIAocCj5REq5A3so%3D&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&data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LJ%2FuvDhfQl3lgMd0zVeuX64bQWfLIAocCj5REq5A3so%3D&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&data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LJ%2FuvDhfQl3lgMd0zVeuX64bQWfLIAocCj5REq5A3so%3D&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&data=05%7C01%7Cjerry.huang%40nxp.com%7C4ceedab3225f4b6502ff08da22d1dcd5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637860581994654416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WTdBfNjqzZBsnUBcRahew10JM84KqTEpI4bWNtHcKKU%3D&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.
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
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&data=05%7C01%7Cjerry.huang%40nxp.com%7C0a > 1869e140a74bdfdad108da2377d636%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0% > 7C0%7C637861294862753519%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat > a=%2FwswKJZxub37vxhjuDJ1iigspSPpb1U0kUQDxSaz5Yw%3D&reserved=0 > BEE click: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > mikroe.com%2Fbee-click&data=05%7C01%7Cjerry.huang%40nxp.com%7C0a18 > 69e140a74bdfdad108da2377d636%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C > 0%7C637861294862753519%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ > QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata= > bE7kpCsNBxoEumCJDbWif%2FX6Ya9px%2BGzWAqPTJ918QI%3D&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
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/
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&data=05%7C01%7Cjerry.huang%40nxp.com%7C >> 39106c035c374b5ec60608da237b883f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7 >> C0%7C1%7C637861310738684479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM >> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C& >> ;sdata=rsETzlFhfe2hyRAiQOL4KHAQ4vwh%2FFrYzroZ%2B0ccSMw%3D&reserve >> d=0 BEE click: >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >> .mikroe.com%2Fbee-click&data=05%7C01%7Cjerry.huang%40nxp.com%7C39 >> 106c035c374b5ec60608da237b883f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0 >> %7C1%7C637861310738684479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA >> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&s >> data=LEmwF46B9GYD%2BcpGoxpiGTnMgvTbLHP4IUirGR78A5U%3D&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&data=05%7C01%7Cjerry.huang%40nxp.com%7C39106c035c374b5ec60608da237b883f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637861310738684479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=Y166YDGSpEX0wtUQE8V7ql8atkb79BmG9Y5mXb8KWJM%3D&reserved=0
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
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
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 = <®33>; vcc-5-supply = <®5v>; 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
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
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 = <®33>; > vcc-5-supply = <®5v>; > > 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
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 = <®33>; > > vcc-5-supply = <®5v>; > > > > 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
>-----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 = <®33>; >> > vcc-5-supply = <®5v>; >> > >> > 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>; }; };
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>; + }; + +...
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