Subject: Re: [PATCH v2 1/2] dt-bindings: phy: ti,tcan104x-can: Document
 mux-states property
To:     Rob Herring <robh@kernel.org>
CC:     Wolfgang Grandegger <wg@grandegger.com>,
        Marc Kleine-Budde <mkl@pengutronix.de>,
        Kishon Vijay Abraham I <kishon@ti.com>,
        Vinod Koul <vkoul@kernel.org>, <linux-can@vger.kernel.org>,
        <linux-phy@lists.infradead.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
References: <20211214142908.27940-1-a-govindraju@ti.com>
 <20211214142908.27940-2-a-govindraju@ti.com>
 <YbpSy0+x/SnTYUzb@robh.at.kernel.org>
From:   Aswath Govindraju <a-govindraju@ti.com>
Message-ID: <71c926f5-7dd5-b2c3-d31c-fbc7a3d553c4@ti.com>
Date:   Thu, 16 Dec 2021 09:29:36 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <YbpSy0+x/SnTYUzb@robh.at.kernel.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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@ti.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
>>
>>