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
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 <[email protected]>
---
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
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 <[email protected]>
---
.../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
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 <[email protected]>
> ---
> .../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
>
>
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 <[email protected]>
>> ---
>> .../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
>>
>>