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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqJr0fvqL_6CL__Q6aY0AVD+gL4=g46Y=j2r=fJy9jDwGg@mail.gmail.com>
Date:   Thu, 21 Apr 2022 14:08:21 -0500
From:   Rob Herring <robh@...nel.org>
To:     Michael Walle <michael@...le.cc>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Mark Brown <broonie@...nel.org>, devicetree@...r.kernel.org,
        Changming Huang <jerry.huang@....com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Yang-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

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 ..>;
> }

Rob