linux-kernel - Re: [PATCH v2 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] [day] [month] [year] [list]

Date:   Thu, 16 Dec 2021 09:29:36 +0530
From:   Aswath Govindraju <a-govindraju@...com>
To:     Rob Herring <robh@...nel.org>
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 v2 1/2] dt-bindings: phy: ti,tcan104x-can: Document
 mux-states property

Hi Rob,

On 16/12/21 2:10 am, Rob Herring wrote:
> On Tue, Dec 14, 2021 at 07:59:07PM +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       | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
>> index 6107880e5246..7b9216e43b58 100644
>> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
>> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
>> @@ -37,6 +37,15 @@ properties:
>>        max bit rate supported in bps
>>      minimum: 1
>>  
>> +  mux-states:
>> +    description:
>> +      mux controller node to route the signals from controller to
>> +      transceiver. Two arguments can be present depending on the
>> +      mux chip. If one argument is used then it represents the state
>> +      to be set on the mux-chip. If there are two arguments then the
>> +      first argument is the control line and the second argument is
>> +      its corresponding state to be set, on the mux-chip.
>> +
> 
> You are still describing how the mux-states works. What the cells 
> contain and how many are opaque to this binding. Here you need to 
> describe how many muxes you have and what they are controlling as that 
> is what is specific to this binding. If there is only one, this boils 
> down to 'maxItems: 1'. It's just like reg, interrupts, clocks, etc.
> 


Got it. Thank you for the clarification. Amending the description to the
following,

  mux-states:
    description:
      mux controller node to route the signals from controller to
      transceiver.
    maxItems: 1

Thanks,
Aswath

>>  required:
>>    - compatible
>>    - '#phy-cells'
>> @@ -53,4 +62,5 @@ examples:
>>        max-bitrate = <5000000>;
>>        standby-gpios = <&wakeup_gpio1 16 GPIO_ACTIVE_LOW>;
>>        enable-gpios = <&main_gpio1 67 GPIO_ACTIVE_HIGH>;
>> +      mux-states = <&mux0 1>;
>>      };
>> -- 
>> 2.17.1
>>
>>