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

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:   Fri, 22 Apr 2022 02:19:14 +0000
From:   Jerry Huang <jerry.huang@....com>
To:     Rob Herring <robh@...nel.org>, Michael Walle <michael@...le.cc>
CC:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Mark Brown <broonie@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Leo Li <leoyang.li@....com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-spi <linux-spi@...r.kernel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Vladimir Oltean <olteanv@...il.com>
Subject: RE: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech
 sx1301



>-----Original Message-----
>From: Rob Herring <robh@...nel.org>
>Sent: 2022年4月22日 3:08
>To: Michael Walle <michael@...le.cc>
>Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>; Mark Brown
><broonie@...nel.org>; devicetree@...r.kernel.org; Jerry Huang
><jerry.huang@....com>; Krzysztof Kozlowski
><krzysztof.kozlowski+dt@...aro.org>; Leo Li <leoyang.li@....com>;
>linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>;
>linux-kernel@...r.kernel.org; linux-spi <linux-spi@...r.kernel.org>; Shawn Guo
><shawnguo@...nel.org>; Vladimir Oltean <olteanv@...il.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@...le.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>;
        };
};