[PATCH v2 0/2] CAN: Add support for setting mux

[PATCH v2 0/2] CAN: Add support for setting mux

[Aswath Govindraju]

The following series of patches add support for setting
muxes to route signals from CAN controller to transceiver
by reading the property mux-states from the device tree
node

The following series of patches are dependent on,
- https://lkml.org/lkml/2021/12/2/423

Changes since v1:
- Fixed the description for mux-states property in bindings
  file
- appended declaration of variable ret in the end

Aswath Govindraju (2):
  dt-bindings: phy: ti,tcan104x-can: Document mux-states property
  phy: phy-can-transceiver: Add support for setting mux

 .../bindings/phy/ti,tcan104x-can.yaml         | 10 ++++++++
 drivers/phy/Kconfig                           |  1 +
 drivers/phy/phy-can-transceiver.c             | 24 ++++++++++++++++++-
 3 files changed, 34 insertions(+), 1 deletion(-)

-- 
2.17.1

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

[Aswath Govindraju]

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.
+
 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

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

[Rob Herring]

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.

>  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
> 
> 

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

[Aswath Govindraju]

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
>>
>>

[PATCH v2 2/2] phy: phy-can-transceiver: Add support for setting mux

[Aswath Govindraju]

On some boards, for routing CAN signals from controller to transceiver,
muxes might need to be set. Therefore, add support for setting the mux by
reading the mux-states property from the device tree node.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
---
 drivers/phy/Kconfig               |  1 +
 drivers/phy/phy-can-transceiver.c | 24 +++++++++++++++++++++++-
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 82b63e60c5a2..300b0f2b5f84 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -64,6 +64,7 @@ config USB_LGM_PHY
 config PHY_CAN_TRANSCEIVER
 	tristate "CAN transceiver PHY"
 	select GENERIC_PHY
+	select MULTIPLEXER
 	help
 	  This option enables support for CAN transceivers as a PHY. This
 	  driver provides function for putting the transceivers in various
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 6f3fe37dee0e..95c6dbb52da7 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -10,6 +10,7 @@
 #include<linux/module.h>
 #include<linux/gpio.h>
 #include<linux/gpio/consumer.h>
+#include <linux/mux/consumer.h>
 
 struct can_transceiver_data {
 	u32 flags;
@@ -21,13 +22,22 @@ struct can_transceiver_phy {
 	struct phy *generic_phy;
 	struct gpio_desc *standby_gpio;
 	struct gpio_desc *enable_gpio;
+	struct mux_state *mux_state;
 };
 
 /* Power on function */
 static int can_transceiver_phy_power_on(struct phy *phy)
 {
 	struct can_transceiver_phy *can_transceiver_phy = phy_get_drvdata(phy);
-
+	int ret;
+
+	if (can_transceiver_phy->mux_state) {
+		ret = mux_state_select(can_transceiver_phy->mux_state);
+		if (ret) {
+			dev_err(&phy->dev, "Failed to select CAN mux: %d\n", ret);
+			return ret;
+		}
+	}
 	if (can_transceiver_phy->standby_gpio)
 		gpiod_set_value_cansleep(can_transceiver_phy->standby_gpio, 0);
 	if (can_transceiver_phy->enable_gpio)
@@ -45,6 +55,8 @@ static int can_transceiver_phy_power_off(struct phy *phy)
 		gpiod_set_value_cansleep(can_transceiver_phy->standby_gpio, 1);
 	if (can_transceiver_phy->enable_gpio)
 		gpiod_set_value_cansleep(can_transceiver_phy->enable_gpio, 0);
+	if (can_transceiver_phy->mux_state)
+		mux_state_deselect(can_transceiver_phy->mux_state);
 
 	return 0;
 }
@@ -95,6 +107,16 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
 	match = of_match_node(can_transceiver_phy_ids, pdev->dev.of_node);
 	drvdata = match->data;
 
+	if (of_property_read_bool(dev->of_node, "mux-states")) {
+		struct mux_state *mux_state;
+
+		mux_state = devm_mux_state_get(dev, NULL);
+		if (IS_ERR(mux_state))
+			return dev_err_probe(&pdev->dev, PTR_ERR(mux_state),
+					     "failed to get mux\n");
+		can_transceiver_phy->mux_state = mux_state;
+	}
+
 	phy = devm_phy_create(dev, dev->of_node,
 			      &can_transceiver_phy_ops);
 	if (IS_ERR(phy)) {
-- 
2.17.1