lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 21 Apr 2022 09:01:04 +0000
From:   Jerry Huang <jerry.huang@....com>
To:     Michael Walle <michael@...le.cc>
CC:     "broonie@...nel.org" <broonie@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>, Leo Li <leoyang.li@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>
Subject: RE: [EXT] Re: [PATCH 1/2 v3] dt-bindings: dspi: added for semtech
 sx1301




Best Regards
Jerry Huang

-----Original Message-----
From: Michael Walle <michael@...le.cc> 
Sent: 2022年4月20日 19:27
To: Jerry Huang <jerry.huang@....com>
Cc: broonie@...nel.org; devicetree@...r.kernel.org; krzysztof.kozlowski+dt@...aro.org; Leo Li <leoyang.li@....com>; linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; linux-spi@...r.kernel.org; robh+dt@...nel.org; shawnguo@...nel.org; Michael Walle <michael@...le.cc>
Subject: [EXT] Re: [PATCH 1/2 v3] dt-bindings: dspi: added for semtech sx1301

Caution: EXT Email

> Add DT Binding doc for semtech sx1301

Please be a bit more elaborate. The sx1301 seems to be an SPI device, some kind of WAN device.
[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.

>
> Signed-off-by: Changming Huang <jerry.huang@....com>
> ---
> 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..f65fb5809218
> --- /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%7Cc45d97643d6b4639d00508da22c0b535%7C686ea1
> +d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637860508327293217%7CUnknown%7CT
> +WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> +I6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=b3gaerVDOI1F3ml3fUlTJ47D2YcDqj6cts
> +0YKCYXqOM%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%7Cc45d97643d6b4639d00508da22c0b535%7C686ea1d3bc2b4c6fa92
> +cd99c5c301635%7C0%7C1%7C637860508327293217%7CUnknown%7CTWFpbGZsb3d8ey
> +JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> +00%7C%7C%7C&amp;sdata=v88eUuFAVfTeoAWyADNYHJ8NwFja5CkYrqWeCndlayY%3D&
> +amp;reserved=0
> +
> +title: Semtech sx1301 devicetree bindings
> +
> +allOf:
> +  - $ref: "spi-controller.yaml"

.. then why does it inherit the spi controllers properties?

Also *some* kind of information what the sx1301 is would be nice.

Anyway, I was about to comment on your patch 2. But maybe I'll just leave it here. On the RDB there is a mikrobus connector, with this, you are going to say "hey there is always a sx1301" module there. What happens if it not there? What if you put another module in that socket?
[Jerry Huang] the name sx1301 is not correct, I think the purpose of it just is to invoke the spidev driver (./drivers/spi/spidev.c)
I will change the compatible name and add it to ./drivers/spi/spidev.c file.

Maybe Krzystof knows better. But it really looks like you want to have device tree overlays here instead of hardcoding exactly one use case.

-michael

> +
> +maintainers:
> +  - Changming Huang <jerry.huang@....com>
> +
> +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:
> +  - |
> +    mikrobus@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
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ