[PATCH v2 0/3] can: mcp251xfd: add XSTBYEN transceiver standby control

[PATCH v2 0/3] can: mcp251xfd: add XSTBYEN transceiver standby control

[Viken Dadhaniya]

This series adds support for the MCP251xFD's dedicated transceiver standby
control function via the XSTBYEN bit, and enables it on the QCS6490 RB3
Gen2 board.

The MCP251xFD has a hardware-managed transceiver standby control on the
INT0/GPIO0/XSTBY pin. When XSTBYEN is enabled, the hardware automatically
drives the pin low when the controller is active and high when it enters
Sleep mode, providing automatic standby control of an external CAN
transceiver without software intervention.

Testing was performed on the QCS6490 RB3 Gen2 board with a PCAN-USB FD
adapter, confirming that:
- The transceiver is active (pin LOW) when the controller is in
  normal mode
- CAN communication works correctly
- The pin is automatically managed on sleep/wake transitions

---
v1 -> v2:

- Drop the gpio-hog approach as suggested by Dmitry.
- Enable hardware‑managed transceiver standby control via the appropriate
  Device Tree property.

v1 Link: https://lore.kernel.org/all/20260108125200.2803112-1-viken.dadhaniya@oss.qualcomm.com/
---

Viken Dadhaniya (3):
  dt-bindings: can: mcp251xfd: add microchip,xstbyen property
  can: mcp251xfd: add support for XSTBYEN transceiver standby control
  arm64: dts: qcom: qcs6490-rb3gen2: Enable CAN bus controller

 .../bindings/net/can/microchip,mcp251xfd.yaml |  8 +++++
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts  | 22 ++++++++++++++
 .../net/can/spi/mcp251xfd/mcp251xfd-core.c    | 30 +++++++++++++++++++
 drivers/net/can/spi/mcp251xfd/mcp251xfd.h     |  1 +
 4 files changed, 61 insertions(+)

-- 
2.34.1

[PATCH v2 1/3] dt-bindings: can: mcp251xfd: add microchip,xstbyen property

[Viken Dadhaniya]

Add the boolean property 'microchip,xstbyen' to enable the dedicated
transceiver standby control function on the INT0/GPIO0/XSTBY pin of
the MCP251xFD family.

Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
v1 -> v2:

- Drop the gpio-hog approach as suggested by Dmitry.
- Add the microchip,xstbyen property to enable transceiver standby control.

v1 Link: https://lore.kernel.org/all/20260108125200.2803112-2-viken.dadhaniya@oss.qualcomm.com/
---
---
 .../devicetree/bindings/net/can/microchip,mcp251xfd.yaml  | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
index 2d13638ebc6a..28e494262cd9 100644
--- a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
@@ -44,6 +44,14 @@ properties:
       signals a pending RX interrupt.
     maxItems: 1
 
+  microchip,xstbyen:
+    type: boolean
+    description:
+      If present, configure the INT0/GPIO0/XSTBY pin as transceiver standby
+      control. The pin is driven low when the controller is active and high
+      when it enters Sleep mode, allowing automatic standby control of an
+      external CAN transceiver connected to this pin.
+
   spi-max-frequency:
     description:
       Must be half or less of "clocks" frequency.
-- 
2.34.1

[PATCH v2 2/3] can: mcp251xfd: add support for XSTBYEN transceiver standby control

[Viken Dadhaniya]

The MCP251xFD has a dedicated transceiver standby control function on
the INT0/GPIO0/XSTBY pin, controlled by the XSTBYEN bit in IOCON.
When enabled, the hardware automatically manages the transceiver
standby state: the pin is driven low when the controller is active
and high when it enters Sleep mode.

Enable this feature when the 'microchip,xstbyen' device tree property
is present.

Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
 .../net/can/spi/mcp251xfd/mcp251xfd-core.c    | 30 +++++++++++++++++++
 drivers/net/can/spi/mcp251xfd/mcp251xfd.h     |  1 +
 2 files changed, 31 insertions(+)

diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
index 9c86df08c2c5..7a152acf4931 100644
--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
+++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
@@ -764,6 +764,29 @@ static void mcp251xfd_chip_stop(struct mcp251xfd_priv *priv,
 	mcp251xfd_chip_set_mode(priv, MCP251XFD_REG_CON_MODE_CONFIG);
 }
 
+static int mcp251xfd_chip_xstbyen_enable(const struct mcp251xfd_priv *priv)
+{
+	/* Configure the INT0/GPIO0/XSTBY pin as transceiver standby control:
+	 *
+	 * - XSTBYEN=1: route the pin to the transceiver standby function
+	 * - TRIS0=0:   set output direction; the reset default is 1 (input),
+	 *              which leaves the pin floating HIGH and keeps the
+	 *              transceiver in standby regardless of XSTBYEN
+	 * - LAT0=0:    drive pin LOW => transceiver active (not in standby)
+	 *
+	 * All three bits are included in the mask; only XSTBYEN is set in
+	 * val, so TRIS0 and LAT0 are cleared to 0 atomically.
+	 *
+	 * Once configured, the hardware automatically drives the pin HIGH
+	 * on Sleep mode entry and LOW on Sleep mode exit.
+	 */
+	return regmap_update_bits(priv->map_reg, MCP251XFD_REG_IOCON,
+				  MCP251XFD_REG_IOCON_XSTBYEN |
+				  MCP251XFD_REG_IOCON_TRIS0 |
+				  MCP251XFD_REG_IOCON_LAT0,
+				  MCP251XFD_REG_IOCON_XSTBYEN);
+}
+
 static int mcp251xfd_chip_start(struct mcp251xfd_priv *priv)
 {
 	int err;
@@ -800,6 +823,12 @@ static int mcp251xfd_chip_start(struct mcp251xfd_priv *priv)
 	if (err)
 		goto out_chip_stop;
 
+	if (priv->xstbyen) {
+		err = mcp251xfd_chip_xstbyen_enable(priv);
+		if (err)
+			goto out_chip_stop;
+	}
+
 	return 0;
 
 out_chip_stop:
@@ -2271,6 +2300,7 @@ static int mcp251xfd_probe(struct spi_device *spi)
 	priv->pll_enable = pll_enable;
 	priv->reg_vdd = reg_vdd;
 	priv->reg_xceiver = reg_xceiver;
+	priv->xstbyen = device_property_present(&spi->dev, "microchip,xstbyen");
 	priv->devtype_data = *(struct mcp251xfd_devtype_data *)spi_get_device_match_data(spi);
 
 	/* Errata Reference:
diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd.h b/drivers/net/can/spi/mcp251xfd/mcp251xfd.h
index 085d7101e595..d3f4704e2678 100644
--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd.h
+++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd.h
@@ -672,6 +672,7 @@ struct mcp251xfd_priv {
 	struct gpio_desc *rx_int;
 	struct clk *clk;
 	bool pll_enable;
+	bool xstbyen;
 	struct regulator *reg_vdd;
 	struct regulator *reg_xceiver;
 
-- 
2.34.1

Re: [PATCH v2 2/3] can: mcp251xfd: add support for XSTBYEN transceiver standby control

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]

On 16.03.2026 18:49:49, Viken Dadhaniya wrote:
> The MCP251xFD has a dedicated transceiver standby control function on
> the INT0/GPIO0/XSTBY pin, controlled by the XSTBYEN bit in IOCON.

Please add a check to mcp251xfd_gpio_request() that GPIO0 cannot be used
with xstbyen.

> When enabled, the hardware automatically manages the transceiver
> standby state: the pin is driven low when the controller is active
> and high when it enters Sleep mode.
>
> Enable this feature when the 'microchip,xstbyen' device tree property
> is present.
>
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
>  .../net/can/spi/mcp251xfd/mcp251xfd-core.c    | 30 +++++++++++++++++++
>  drivers/net/can/spi/mcp251xfd/mcp251xfd.h     |  1 +
>  2 files changed, 31 insertions(+)
>
> diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> index 9c86df08c2c5..7a152acf4931 100644
> --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> @@ -764,6 +764,29 @@ static void mcp251xfd_chip_stop(struct mcp251xfd_priv *priv,
>  	mcp251xfd_chip_set_mode(priv, MCP251XFD_REG_CON_MODE_CONFIG);
>  }
>
> +static int mcp251xfd_chip_xstbyen_enable(const struct mcp251xfd_priv *priv)
> +{
> +	/* Configure the INT0/GPIO0/XSTBY pin as transceiver standby control:
> +	 *
> +	 * - XSTBYEN=1: route the pin to the transceiver standby function
> +	 * - TRIS0=0:   set output direction; the reset default is 1 (input),
> +	 *              which leaves the pin floating HIGH and keeps the
> +	 *              transceiver in standby regardless of XSTBYEN
> +	 * - LAT0=0:    drive pin LOW => transceiver active (not in standby)
> +	 *
> +	 * All three bits are included in the mask; only XSTBYEN is set in
> +	 * val, so TRIS0 and LAT0 are cleared to 0 atomically.
> +	 *
> +	 * Once configured, the hardware automatically drives the pin HIGH
> +	 * on Sleep mode entry and LOW on Sleep mode exit.
> +	 */

What does the pin do in Config mode?

> +	return regmap_update_bits(priv->map_reg, MCP251XFD_REG_IOCON,
> +				  MCP251XFD_REG_IOCON_XSTBYEN |
> +				  MCP251XFD_REG_IOCON_TRIS0 |
> +				  MCP251XFD_REG_IOCON_LAT0,
> +				  MCP251XFD_REG_IOCON_XSTBYEN);
> +}
> +
>  static int mcp251xfd_chip_start(struct mcp251xfd_priv *priv)
>  {
>  	int err;
> @@ -800,6 +823,12 @@ static int mcp251xfd_chip_start(struct mcp251xfd_priv *priv)
>  	if (err)
>  		goto out_chip_stop;
>
> +	if (priv->xstbyen) {
> +		err = mcp251xfd_chip_xstbyen_enable(priv);
> +		if (err)
> +			goto out_chip_stop;
> +	}
> +

You should configure the pin before bringing the controller into normale mode.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 2/3] can: mcp251xfd: add support for XSTBYEN transceiver standby control

[Viken Dadhaniya]

On 3/16/2026 7:21 PM, Marc Kleine-Budde wrote:
> On 16.03.2026 18:49:49, Viken Dadhaniya wrote:
>> The MCP251xFD has a dedicated transceiver standby control function on
>> the INT0/GPIO0/XSTBY pin, controlled by the XSTBYEN bit in IOCON.
> 
> Please add a check to mcp251xfd_gpio_request() that GPIO0 cannot be used
> with xstbyen.

Sure, Will update in next patch.

> 
>> When enabled, the hardware automatically manages the transceiver
>> standby state: the pin is driven low when the controller is active
>> and high when it enters Sleep mode.
>>
>> Enable this feature when the 'microchip,xstbyen' device tree property
>> is present.
>>
>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
>> ---
>>  .../net/can/spi/mcp251xfd/mcp251xfd-core.c    | 30 +++++++++++++++++++
>>  drivers/net/can/spi/mcp251xfd/mcp251xfd.h     |  1 +
>>  2 files changed, 31 insertions(+)
>>
>> diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
>> index 9c86df08c2c5..7a152acf4931 100644
>> --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
>> +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
>> @@ -764,6 +764,29 @@ static void mcp251xfd_chip_stop(struct mcp251xfd_priv *priv,
>>  	mcp251xfd_chip_set_mode(priv, MCP251XFD_REG_CON_MODE_CONFIG);
>>  }
>>
>> +static int mcp251xfd_chip_xstbyen_enable(const struct mcp251xfd_priv *priv)
>> +{
>> +	/* Configure the INT0/GPIO0/XSTBY pin as transceiver standby control:
>> +	 *
>> +	 * - XSTBYEN=1: route the pin to the transceiver standby function
>> +	 * - TRIS0=0:   set output direction; the reset default is 1 (input),
>> +	 *              which leaves the pin floating HIGH and keeps the
>> +	 *              transceiver in standby regardless of XSTBYEN
>> +	 * - LAT0=0:    drive pin LOW => transceiver active (not in standby)
>> +	 *
>> +	 * All three bits are included in the mask; only XSTBYEN is set in
>> +	 * val, so TRIS0 and LAT0 are cleared to 0 atomically.
>> +	 *
>> +	 * Once configured, the hardware automatically drives the pin HIGH
>> +	 * on Sleep mode entry and LOW on Sleep mode exit.
>> +	 */
> 
> What does the pin do in Config mode?

In Config mode, the pin is controlled by LAT0. Since we set LAT0=0,
the pin is LOW (transceiver active), ensuring the transceiver is
ready before entering Normal mode.

> 
>> +	return regmap_update_bits(priv->map_reg, MCP251XFD_REG_IOCON,
>> +				  MCP251XFD_REG_IOCON_XSTBYEN |
>> +				  MCP251XFD_REG_IOCON_TRIS0 |
>> +				  MCP251XFD_REG_IOCON_LAT0,
>> +				  MCP251XFD_REG_IOCON_XSTBYEN);
>> +}
>> +
>>  static int mcp251xfd_chip_start(struct mcp251xfd_priv *priv)
>>  {
>>  	int err;
>> @@ -800,6 +823,12 @@ static int mcp251xfd_chip_start(struct mcp251xfd_priv *priv)
>>  	if (err)
>>  		goto out_chip_stop;
>>
>> +	if (priv->xstbyen) {
>> +		err = mcp251xfd_chip_xstbyen_enable(priv);
>> +		if (err)
>> +			goto out_chip_stop;
>> +	}
>> +
> 
> You should configure the pin before bringing the controller into normale mode.

Sure, Will update in next patch.

> 
> regards,
> Marc
> 

[PATCH v2 3/3] arm64: dts: qcom: qcs6490-rb3gen2: Enable CAN bus controller

[Viken Dadhaniya]

Enable the MCP2518FD CAN controller on the QCS6490 RB3 Gen2 platform.
The controller is connected via SPI3 and uses a 40 MHz oscillator.

The setup was tested with CAN-FD loopback and actual data transfer
using an external PCAN-USB FD adapter.

Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
v1 -> v2:

- Drop the gpio-hog property.
- Add the microchip,xstbyen property to enable transceiver standby control.

v1 Link: https://lore.kernel.org/all/20260108125200.2803112-3-viken.dadhaniya@oss.qualcomm.com/
---
---
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 22 ++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
index e3d2f01881ae..245961722f84 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
@@ -44,6 +44,14 @@ chosen {
 		stdout-path = "serial0:115200n8";
 	};
 
+	clocks {
+		mcp2518fd_osc: can-clk {
+			compatible = "fixed-clock";
+			clock-frequency = <40000000>;
+			#clock-cells = <0>;
+		};
+	};
+
 	dp-connector {
 		compatible = "dp-connector";
 		label = "DP";
@@ -1151,6 +1159,20 @@ platform {
 	};
 };
 
+&spi3 {
+	status = "okay";
+
+	can@0 {
+		compatible = "microchip,mcp2518fd";
+		reg = <0>;
+		interrupts-extended = <&tlmm 7 IRQ_TYPE_LEVEL_LOW>;
+		clocks = <&mcp2518fd_osc>;
+		spi-max-frequency = <10000000>;
+		vdd-supply = <&vreg_l11c_2p8>;
+		microchip,xstbyen;
+	};
+};
+
 &swr2 {
 	status = "okay";
 
-- 
2.34.1

Re: [PATCH v2 3/3] arm64: dts: qcom: qcs6490-rb3gen2: Enable CAN bus controller

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]

On 16.03.2026 18:49:50, Viken Dadhaniya wrote:
> Enable the MCP2518FD CAN controller on the QCS6490 RB3 Gen2 platform.
> The controller is connected via SPI3 and uses a 40 MHz oscillator.
>
> The setup was tested with CAN-FD loopback and actual data transfer
> using an external PCAN-USB FD adapter.

IIRC a board DT update should go independent of the driver update.

> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
> v1 -> v2:
>
> - Drop the gpio-hog property.
> - Add the microchip,xstbyen property to enable transceiver standby control.
>
> v1 Link: https://lore.kernel.org/all/20260108125200.2803112-3-viken.dadhaniya@oss.qualcomm.com/
> ---
> ---
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 22 ++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index e3d2f01881ae..245961722f84 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -44,6 +44,14 @@ chosen {
>  		stdout-path = "serial0:115200n8";
>  	};
>
> +	clocks {
> +		mcp2518fd_osc: can-clk {
> +			compatible = "fixed-clock";
> +			clock-frequency = <40000000>;
> +			#clock-cells = <0>;
> +		};
> +	};
> +
>  	dp-connector {
>  		compatible = "dp-connector";
>  		label = "DP";
> @@ -1151,6 +1159,20 @@ platform {
>  	};
>  };
>
> +&spi3 {
> +	status = "okay";
> +
> +	can@0 {
> +		compatible = "microchip,mcp2518fd";
> +		reg = <0>;
> +		interrupts-extended = <&tlmm 7 IRQ_TYPE_LEVEL_LOW>;
> +		clocks = <&mcp2518fd_osc>;
> +		spi-max-frequency = <10000000>;

Why do you limit the frequency to 10 MHz? Is this a HW limitation?

With a 40 MHz clock the chip supports up to 17 MHz (not 20 MHz due to
the erratum).

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 3/3] arm64: dts: qcom: qcs6490-rb3gen2: Enable CAN bus controller

[Viken Dadhaniya]

On 3/16/2026 6:59 PM, Marc Kleine-Budde wrote:
> On 16.03.2026 18:49:50, Viken Dadhaniya wrote:
>> Enable the MCP2518FD CAN controller on the QCS6490 RB3 Gen2 platform.
>> The controller is connected via SPI3 and uses a 40 MHz oscillator.
>>
>> The setup was tested with CAN-FD loopback and actual data transfer
>> using an external PCAN-USB FD adapter.
> 
> IIRC a board DT update should go independent of the driver update.

Sure, I will send the device tree changes separately.

> 
>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
>> ---
>> v1 -> v2:
>>
>> - Drop the gpio-hog property.
>> - Add the microchip,xstbyen property to enable transceiver standby control.
>>
>> v1 Link: https://lore.kernel.org/all/20260108125200.2803112-3-viken.dadhaniya@oss.qualcomm.com/
>> ---
>> ---
>>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 22 ++++++++++++++++++++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> index e3d2f01881ae..245961722f84 100644
>> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> @@ -44,6 +44,14 @@ chosen {
>>  		stdout-path = "serial0:115200n8";
>>  	};
>>
>> +	clocks {
>> +		mcp2518fd_osc: can-clk {
>> +			compatible = "fixed-clock";
>> +			clock-frequency = <40000000>;
>> +			#clock-cells = <0>;
>> +		};
>> +	};
>> +
>>  	dp-connector {
>>  		compatible = "dp-connector";
>>  		label = "DP";
>> @@ -1151,6 +1159,20 @@ platform {
>>  	};
>>  };
>>
>> +&spi3 {
>> +	status = "okay";
>> +
>> +	can@0 {
>> +		compatible = "microchip,mcp2518fd";
>> +		reg = <0>;
>> +		interrupts-extended = <&tlmm 7 IRQ_TYPE_LEVEL_LOW>;
>> +		clocks = <&mcp2518fd_osc>;
>> +		spi-max-frequency = <10000000>;
> 
> Why do you limit the frequency to 10 MHz? Is this a HW limitation?
> 
> With a 40 MHz clock the chip supports up to 17 MHz (not 20 MHz due to
> the erratum).

The 10 MHz was overly conservative. Testing on this board shows:

  spi-max-frequency = <14000000>: actual SCK = 12.8 MHz  => OK
  spi-max-frequency = <15000000>: actual SCK = 15.0 MHz  => FAIL

Any SCK >= 14.7 MHz fails to initialize the MCP251xFD on this board,
so 12.8 MHz is the highest reliable SCK within the erratum limit of
17 MHz.

Will update to spi-max-frequency = <14000000>.

> 
> Marc
> 

Re: [PATCH v2 3/3] arm64: dts: qcom: qcs6490-rb3gen2: Enable CAN bus controller

[Konrad Dybcio]

On 3/16/26 2:19 PM, Viken Dadhaniya wrote:
> Enable the MCP2518FD CAN controller on the QCS6490 RB3 Gen2 platform.
> The controller is connected via SPI3 and uses a 40 MHz oscillator.
> 
> The setup was tested with CAN-FD loopback and actual data transfer
> using an external PCAN-USB FD adapter.
> 
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad