Re: [PATCH 1/2] dt-bindings: phy: ti,tcan104x-can: Document mux-states property
From: Rob Herring <robh@kernel.org>
Date: 2021-12-13 20:19:54
Also in:
linux-devicetree, linux-phy, lkml
On Thu, Dec 02, 2021 at 06:40:01PM +0530, Aswath Govindraju wrote:
quoted hunk ↗ jump to hunk
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 <redacted> --- .../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