linux-kernel - Re: [PATCH 1/2] dt-bindings: phy: ti,tcan104x-can: Document mux-states property

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: <Ybeq5dNYjN4GOzdV@robh.at.kernel.org>
Date:   Mon, 13 Dec 2021 14:19:49 -0600
From:   Rob Herring <robh@...nel.org>
To:     Aswath Govindraju <a-govindraju@...com>
Cc:     Wolfgang Grandegger <wg@...ndegger.com>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        Kishon Vijay Abraham I <kishon@...com>,
        Vinod Koul <vkoul@...nel.org>, linux-can@...r.kernel.org,
        linux-phy@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: phy: ti,tcan104x-can: Document
 mux-states property

On Thu, Dec 02, 2021 at 06:40:01PM +0530, Aswath Govindraju wrote:
> On some boards, for routing CAN signals from controller to transceivers,
> muxes might need to be set. This can be implemented using mux-states
> property. Therefore, document the same in the respective bindings.
> 
> Signed-off-by: Aswath Govindraju <a-govindraju@...com>
> ---
>  .../devicetree/bindings/phy/ti,tcan104x-can.yaml    | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> index 6107880e5246..5b2b08016635 100644
> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> @@ -37,6 +37,18 @@ properties:
>        max bit rate supported in bps
>      minimum: 1
>  
> +  mux-states:
> +    description:
> +      mux controller node to route the signals from controller to
> +      transceiver. Depending on the mux chip and the control lines
> +      in it, the first and second parameters can be used for
> +      representing control line and state. The number of arguments
> +      is to be used based on '#mux-state-cells' property in the
> +      mux-controller node. If '#mux-state-cells' is equal to
> +      one then, then the argument to be used would be the state.
> +      If it is set to two, then the first argument is the control
> +      line and the second argument would be its corresponding state.

No need to redefine how a common property works here. What you do need 
to define is how many entries and what they are for if more than 1. 

Rob