[PATCH v1 0/2] dt-bindings: CAN: MCP251XFD GPIO hog support and QCS6490 CAN enablement

[PATCH v1 0/2] dt-bindings: CAN: MCP251XFD GPIO hog support and QCS6490 CAN enablement

[Viken Dadhaniya]

This series introduces two changes:

1. Extend the MCP251XFD binding to allow GPIO hog child nodes. The
   MCP251XFD family can expose two pins as GPIOs. The binding already
   declares 'gpio-controller' and '#gpio-cells'. Adding a
   'patternProperties' entry permits boards to define hog nodes for default
   GPIO states at boot, which aligns with other GPIO controller bindings
   (e.g., microchip,mpfs-gpio).

2. Enable the MCP2518FD CAN controller on the QCS6490 RB3 Gen2 platform.
   The controller is connected via SPI3 and uses a 40 MHz oscillator.
   A GPIO hog for GPIO0 is included to configure the CAN transceiver in
   Normal mode during boot.
 
Viken Dadhaniya (2):
  dt-bindings: can: microchip,mcp251xfd: allow gpio-hog child nodes
  arm64: dts: qcom: qcs6490-rb3gen2: Enable CAN bus controller

 .../bindings/net/can/microchip,mcp251xfd.yaml |  6 ++++
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts  | 30 +++++++++++++++++++
 2 files changed, 36 insertions(+)

-- 
2.34.1

[PATCH v1 1/2] dt-bindings: can: microchip,mcp251xfd: allow gpio-hog child nodes

[Viken Dadhaniya]

The MCP251XFD can expose two pins as GPIOs. The binding already declares
gpio-controller and #gpio-cells for the device. Whitelist GPIO hog child
nodes using patternProperties so boards can set default GPIO states at
boot via DT, consistent with other GPIO controllers
(e.g. microchip,mpfs-gpio).

Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
 .../devicetree/bindings/net/can/microchip,mcp251xfd.yaml    | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
index 2d13638ebc6a..49d6f6bbe193 100644
--- a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
@@ -54,6 +54,12 @@ properties:
   "#gpio-cells":
     const: 2
 
+patternProperties:
+  "^.+-hog(-[0-9]+)?$":
+    type: object
+    required:
+      - gpio-hog
+
 required:
   - compatible
   - reg
-- 
2.34.1

[PATCH v1 2/2] 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.
A GPIO hog for GPIO0 is included to configure the CAN transceiver in
Normal mode during boot.

Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 30 ++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
index e3d2f01881ae..f2f2925e645a 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,28 @@ 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>;
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		gpio0-hog {
+			gpio-hog;
+			gpios = <0 GPIO_ACTIVE_LOW>;
+			output-high;
+			line-name = "mcp251xfd-gpio0";
+		};
+	};
+};
+
 &swr2 {
 	status = "okay";
 
-- 
2.34.1

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

[Dmitry Baryshkov]

On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
> Normal mode during boot.

The main question is: what is so different between RB3 Gen2 and previous
RB boards which also incorporated this CAN controller? Are there any
board differences or is it that nobody tested the CAN beforehand?

> 
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 30 ++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 

-- 
With best wishes
Dmitry

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

[Manivannan Sadhasivam]

On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
> Normal mode during boot.
> 

It'd be worth mentioning how you tested the controller.

- Mani

> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 30 ++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index e3d2f01881ae..f2f2925e645a 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,28 @@ 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>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +
> +		gpio0-hog {
> +			gpio-hog;
> +			gpios = <0 GPIO_ACTIVE_LOW>;
> +			output-high;
> +			line-name = "mcp251xfd-gpio0";
> +		};
> +	};
> +};
> +
>  &swr2 {
>  	status = "okay";
>  
> -- 
> 2.34.1
> 

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v1 1/2] dt-bindings: can: microchip,mcp251xfd: allow gpio-hog child nodes

[Krzysztof Kozlowski]

On Thu, Jan 08, 2026 at 06:21:59PM +0530, Viken Dadhaniya wrote:
> The MCP251XFD can expose two pins as GPIOs. The binding already declares
> gpio-controller and #gpio-cells for the device. Whitelist GPIO hog child
> nodes using patternProperties so boards can set default GPIO states at
> boot via DT, consistent with other GPIO controllers
> (e.g. microchip,mpfs-gpio).
> 
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
>  .../devicetree/bindings/net/can/microchip,mcp251xfd.yaml    | 6 ++++++
>  1 file changed, 6 insertions(+)

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

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

[Marc Kleine-Budde]

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

On 08.01.2026 18:22:00, 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.
> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
> Normal mode during boot.
>
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 30 ++++++++++++++++++++
>  1 file changed, 30 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index e3d2f01881ae..f2f2925e645a 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>;

Is the #clock-cells property needed?

> +		};
> +	};
> +
>  	dp-connector {
>  		compatible = "dp-connector";
>  		label = "DP";
> @@ -1151,6 +1159,28 @@ 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>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +
> +		gpio0-hog {
> +			gpio-hog;
> +			gpios = <0 GPIO_ACTIVE_LOW>;
> +			output-high;
> +			line-name = "mcp251xfd-gpio0";

If the CAN transceiver is connected to GPIO0, why not reflect that in
the name of the line?

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: 488 bytes --]

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

[Viken Dadhaniya]

On 1/8/2026 7:33 PM, Dmitry Baryshkov wrote:
> On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
>> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
>> Normal mode during boot.
> 
> The main question is: what is so different between RB3 Gen2 and previous
> RB boards which also incorporated this CAN controller? Are there any
> board differences or is it that nobody tested the CAN beforehand?
> 

The behavior is consistent across platforms, but I do not have details on
how other platforms were tested.

On the RB3Gen2 board, communication with the PCAN interface requires the
CAN transceiver to be in normal mode. Since the GPIO-controller support
was recently integrated into the driver, I configured the transceiver using a
GPIO hog property. Without this configuration, the transceiver is not set
to normal mode, and CAN communication does not work.

>>
>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
>> ---
>>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 30 ++++++++++++++++++++
>>  1 file changed, 30 insertions(+)
>>
> 

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

[Viken Dadhaniya]

On 1/8/2026 10:16 PM, Manivannan Sadhasivam wrote:
> On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
>> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
>> Normal mode during boot.
>>
> 
> It'd be worth mentioning how you tested the controller.

Sure, I will include the testing details in v2. Thanks for the suggestion.

> 
> - Mani
> 
>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
>> ---
>>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 30 ++++++++++++++++++++
>>  1 file changed, 30 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> index e3d2f01881ae..f2f2925e645a 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,28 @@ 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>;
>> +		gpio-controller;
>> +		#gpio-cells = <2>;
>> +
>> +		gpio0-hog {
>> +			gpio-hog;
>> +			gpios = <0 GPIO_ACTIVE_LOW>;
>> +			output-high;
>> +			line-name = "mcp251xfd-gpio0";
>> +		};
>> +	};
>> +};
>> +
>>  &swr2 {
>>  	status = "okay";
>>  
>> -- 
>> 2.34.1
>>
> 

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

[Viken Dadhaniya]

On 1/9/2026 2:22 PM, Marc Kleine-Budde wrote:
> On 08.01.2026 18:22:00, 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.
>> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
>> Normal mode during boot.
>>
>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
>> ---
>>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 30 ++++++++++++++++++++
>>  1 file changed, 30 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> index e3d2f01881ae..f2f2925e645a 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>;
> 
> Is the #clock-cells property needed?

Yes, #clock-cells is required for all clock providers, including
fixed-clock. For fixed-clock, it must be <0> since there are no arguments.
Omitting it will lead to schema validation errors and may break consumers
expecting a proper clock provider node.

> 
>> +		};
>> +	};
>> +
>>  	dp-connector {
>>  		compatible = "dp-connector";
>>  		label = "DP";
>> @@ -1151,6 +1159,28 @@ 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>;
>> +		gpio-controller;
>> +		#gpio-cells = <2>;
>> +
>> +		gpio0-hog {
>> +			gpio-hog;
>> +			gpios = <0 GPIO_ACTIVE_LOW>;
>> +			output-high;
>> +			line-name = "mcp251xfd-gpio0";
> 
> If the CAN transceiver is connected to GPIO0, why not reflect that in
> the name of the line?

Ack, will update the GPIO line name in v2 to reflect the CAN transceiver
connection.

> 
> Marc
> 

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

[Dmitry Baryshkov]

On Fri, Jan 09, 2026 at 06:23:39PM +0530, Viken Dadhaniya wrote:
> 
> 
> On 1/8/2026 7:33 PM, Dmitry Baryshkov wrote:
> > On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
> >> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
> >> Normal mode during boot.
> > 
> > The main question is: what is so different between RB3 Gen2 and previous
> > RB boards which also incorporated this CAN controller? Are there any
> > board differences or is it that nobody tested the CAN beforehand?
> > 
> 
> The behavior is consistent across platforms, but I do not have details on
> how other platforms were tested.
> 
> On the RB3Gen2 board, communication with the PCAN interface requires the
> CAN transceiver to be in normal mode. Since the GPIO-controller support
> was recently integrated into the driver, I configured the transceiver using a
> GPIO hog property. Without this configuration, the transceiver is not set
> to normal mode, and CAN communication does not work.

How do we verify the mode on a running system? I have the boards, but I
don't have anything connected to them over the CAN bus.

BTW: can you recommend any simple setup to actually test the CAN bus on
those devices?

-- 
With best wishes
Dmitry

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

[Konrad Dybcio]

On 1/9/26 3:05 PM, Dmitry Baryshkov wrote:
> On Fri, Jan 09, 2026 at 06:23:39PM +0530, Viken Dadhaniya wrote:
>>
>>
>> On 1/8/2026 7:33 PM, Dmitry Baryshkov wrote:
>>> On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
>>>> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
>>>> Normal mode during boot.
>>>
>>> The main question is: what is so different between RB3 Gen2 and previous
>>> RB boards which also incorporated this CAN controller? Are there any
>>> board differences or is it that nobody tested the CAN beforehand?
>>>
>>
>> The behavior is consistent across platforms, but I do not have details on
>> how other platforms were tested.
>>
>> On the RB3Gen2 board, communication with the PCAN interface requires the
>> CAN transceiver to be in normal mode. Since the GPIO-controller support
>> was recently integrated into the driver, I configured the transceiver using a
>> GPIO hog property. Without this configuration, the transceiver is not set
>> to normal mode, and CAN communication does not work.
> 
> How do we verify the mode on a running system? I have the boards, but I
> don't have anything connected to them over the CAN bus.
> 
> BTW: can you recommend any simple setup to actually test the CAN bus on
> those devices?

(please document the reply to this somewhere internally)

Konrad

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

[Viken Dadhaniya]

On 1/9/2026 7:35 PM, Dmitry Baryshkov wrote:
> On Fri, Jan 09, 2026 at 06:23:39PM +0530, Viken Dadhaniya wrote:
>>
>>
>> On 1/8/2026 7:33 PM, Dmitry Baryshkov wrote:
>>> On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
>>>> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
>>>> Normal mode during boot.
>>>
>>> The main question is: what is so different between RB3 Gen2 and previous
>>> RB boards which also incorporated this CAN controller? Are there any
>>> board differences or is it that nobody tested the CAN beforehand?
>>>
>>
>> The behavior is consistent across platforms, but I do not have details on
>> how other platforms were tested.
>>
>> On the RB3Gen2 board, communication with the PCAN interface requires the
>> CAN transceiver to be in normal mode. Since the GPIO-controller support
>> was recently integrated into the driver, I configured the transceiver using a
>> GPIO hog property. Without this configuration, the transceiver is not set
>> to normal mode, and CAN communication does not work.
> 
> How do we verify the mode on a running system? I have the boards, but I
> don't have anything connected to them over the CAN bus.
> 
> BTW: can you recommend any simple setup to actually test the CAN bus on
> those devices?
> 

I tested the CAN controller using the following commands:

1. Loopback Mode Testing (GPIO hog not required)

ip link set can0 down
ip link set can0 type can bitrate 500000 loopback on
ip link set can0 up
cansend can0 12345678#1122334455667788_B
candump can0

2. Testing with External CAN FD Adapter (PCAN-USB FD)
A GPIO hog was required to configure the transceiver in normal mode.

1. Probed and verified CAN transceiver pins and connected them to the
   PCAN-USB FD hardware.
2. Configured the CAN interface:
	
	ip link set can0 down
	ip link set can0 type can bitrate 500000
	ip link set can0 up

3. Configured the PCAN-USB FD software for 500 kbps arbitration bitrate.

4.Sent a CAN FD frame from Linux
	cansend can0 12345678#1122334455667788_B
	
5. Verified reception in the PCAN software.

6. Transmitted frames from the PCAN software and validated them on Linux
	candump can0

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

[Dmitry Baryshkov]

On Mon, Jan 19, 2026 at 10:21:37AM +0530, Viken Dadhaniya wrote:
> 
> 
> On 1/9/2026 7:35 PM, Dmitry Baryshkov wrote:
> > On Fri, Jan 09, 2026 at 06:23:39PM +0530, Viken Dadhaniya wrote:
> >>
> >>
> >> On 1/8/2026 7:33 PM, Dmitry Baryshkov wrote:
> >>> On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
> >>>> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
> >>>> Normal mode during boot.
> >>>
> >>> The main question is: what is so different between RB3 Gen2 and previous
> >>> RB boards which also incorporated this CAN controller? Are there any
> >>> board differences or is it that nobody tested the CAN beforehand?
> >>>
> >>
> >> The behavior is consistent across platforms, but I do not have details on
> >> how other platforms were tested.
> >>
> >> On the RB3Gen2 board, communication with the PCAN interface requires the
> >> CAN transceiver to be in normal mode. Since the GPIO-controller support
> >> was recently integrated into the driver, I configured the transceiver using a
> >> GPIO hog property. Without this configuration, the transceiver is not set
> >> to normal mode, and CAN communication does not work.
> > 
> > How do we verify the mode on a running system? I have the boards, but I
> > don't have anything connected to them over the CAN bus.
> > 
> > BTW: can you recommend any simple setup to actually test the CAN bus on
> > those devices?
> > 
> 
> I tested the CAN controller using the following commands:
> 
> 1. Loopback Mode Testing (GPIO hog not required)
> 
> ip link set can0 down
> ip link set can0 type can bitrate 500000 loopback on
> ip link set can0 up
> cansend can0 12345678#1122334455667788_B
> candump can0
> 
> 2. Testing with External CAN FD Adapter (PCAN-USB FD)

Thanks! It's price doesn't make it esily available, but it answers the
most imporant question: by the USB CAN adapter.

Did you add

> A GPIO hog was required to configure the transceiver in normal mode.

I'd phrase it differently: to pull the transceiver out of standby mode.
By using the GPIO pin you make it always stay in the normal mode. It is
fine, but it is not optimal. Instead a proper solution would be to use
the MCP251XFD_REG_IOCON_XSTBYEN bit. Could you please instead implement
support for setting that bit, based on the DT property.

> 
> 1. Probed and verified CAN transceiver pins and connected them to the
>    PCAN-USB FD hardware.
> 2. Configured the CAN interface:
> 	
> 	ip link set can0 down
> 	ip link set can0 type can bitrate 500000
> 	ip link set can0 up
> 
> 3. Configured the PCAN-USB FD software for 500 kbps arbitration bitrate.
> 
> 4.Sent a CAN FD frame from Linux
> 	cansend can0 12345678#1122334455667788_B
> 	
> 5. Verified reception in the PCAN software.
> 
> 6. Transmitted frames from the PCAN software and validated them on Linux
> 	candump can0
> 

-- 
With best wishes
Dmitry

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

[Viken Dadhaniya]

On 1/19/2026 11:59 AM, Dmitry Baryshkov wrote:
> On Mon, Jan 19, 2026 at 10:21:37AM +0530, Viken Dadhaniya wrote:
>>
>>
>> On 1/9/2026 7:35 PM, Dmitry Baryshkov wrote:
>>> On Fri, Jan 09, 2026 at 06:23:39PM +0530, Viken Dadhaniya wrote:
>>>>
>>>>
>>>> On 1/8/2026 7:33 PM, Dmitry Baryshkov wrote:
>>>>> On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
>>>>>> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
>>>>>> Normal mode during boot.
>>>>>
>>>>> The main question is: what is so different between RB3 Gen2 and previous
>>>>> RB boards which also incorporated this CAN controller? Are there any
>>>>> board differences or is it that nobody tested the CAN beforehand?
>>>>>
>>>>
>>>> The behavior is consistent across platforms, but I do not have details on
>>>> how other platforms were tested.
>>>>
>>>> On the RB3Gen2 board, communication with the PCAN interface requires the
>>>> CAN transceiver to be in normal mode. Since the GPIO-controller support
>>>> was recently integrated into the driver, I configured the transceiver using a
>>>> GPIO hog property. Without this configuration, the transceiver is not set
>>>> to normal mode, and CAN communication does not work.
>>>
>>> How do we verify the mode on a running system? I have the boards, but I
>>> don't have anything connected to them over the CAN bus.
>>>
>>> BTW: can you recommend any simple setup to actually test the CAN bus on
>>> those devices?
>>>
>>
>> I tested the CAN controller using the following commands:
>>
>> 1. Loopback Mode Testing (GPIO hog not required)
>>
>> ip link set can0 down
>> ip link set can0 type can bitrate 500000 loopback on
>> ip link set can0 up
>> cansend can0 12345678#1122334455667788_B
>> candump can0
>>
>> 2. Testing with External CAN FD Adapter (PCAN-USB FD)
> 
> Thanks! It's price doesn't make it esily available, but it answers the
> most imporant question: by the USB CAN adapter.
> 
> Did you add
> 
>> A GPIO hog was required to configure the transceiver in normal mode.
> 
> I'd phrase it differently: to pull the transceiver out of standby mode.
> By using the GPIO pin you make it always stay in the normal mode. It is
> fine, but it is not optimal. Instead a proper solution would be to use
> the MCP251XFD_REG_IOCON_XSTBYEN bit. Could you please instead implement
> support for setting that bit, based on the DT property.

Thanks for the suggestion.

I tested enabling IOCON.XSTBYEN, but on this hardware it doesn’t bring
the transceiver out of standby by itself. With only XSTBYEN set, the bus
remains inactive and no frames reach the CAN adapter. Clearing LAT0
(driving GPIO0 low) is required to put the transceiver into normal mode;
data transfer works only after LAT0 is cleared.

Given this, a practical approach on this board is:

drive LAT0 = 0 when the controller is started to take the transceiver
out of standby, and

restore LAT0 = 1 when the controller is stopped/suspended to return it
to standby.

If you prefer, I can make this conditional on a DT property (e.g. using
an existing standby-gpios or a new property indicating that the
transceiver’s standby is wired to GPIO0).

> 
>>
>> 1. Probed and verified CAN transceiver pins and connected them to the
>>    PCAN-USB FD hardware.
>> 2. Configured the CAN interface:
>> 	
>> 	ip link set can0 down
>> 	ip link set can0 type can bitrate 500000
>> 	ip link set can0 up
>>
>> 3. Configured the PCAN-USB FD software for 500 kbps arbitration bitrate.
>>
>> 4.Sent a CAN FD frame from Linux
>> 	cansend can0 12345678#1122334455667788_B
>> 	
>> 5. Verified reception in the PCAN software.
>>
>> 6. Transmitted frames from the PCAN software and validated them on Linux
>> 	candump can0
>>
> 

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

[Dmitry Baryshkov]

On Tue, Feb 03, 2026 at 05:07:11PM +0530, Viken Dadhaniya wrote:
> 
> 
> On 1/19/2026 11:59 AM, Dmitry Baryshkov wrote:
> > On Mon, Jan 19, 2026 at 10:21:37AM +0530, Viken Dadhaniya wrote:
> >>
> >>
> >> On 1/9/2026 7:35 PM, Dmitry Baryshkov wrote:
> >>> On Fri, Jan 09, 2026 at 06:23:39PM +0530, Viken Dadhaniya wrote:
> >>>>
> >>>>
> >>>> On 1/8/2026 7:33 PM, Dmitry Baryshkov wrote:
> >>>>> On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
> >>>>>> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
> >>>>>> Normal mode during boot.
> >>>>>
> >>>>> The main question is: what is so different between RB3 Gen2 and previous
> >>>>> RB boards which also incorporated this CAN controller? Are there any
> >>>>> board differences or is it that nobody tested the CAN beforehand?
> >>>>>
> >>>>
> >>>> The behavior is consistent across platforms, but I do not have details on
> >>>> how other platforms were tested.
> >>>>
> >>>> On the RB3Gen2 board, communication with the PCAN interface requires the
> >>>> CAN transceiver to be in normal mode. Since the GPIO-controller support
> >>>> was recently integrated into the driver, I configured the transceiver using a
> >>>> GPIO hog property. Without this configuration, the transceiver is not set
> >>>> to normal mode, and CAN communication does not work.
> >>>
> >>> How do we verify the mode on a running system? I have the boards, but I
> >>> don't have anything connected to them over the CAN bus.
> >>>
> >>> BTW: can you recommend any simple setup to actually test the CAN bus on
> >>> those devices?
> >>>
> >>
> >> I tested the CAN controller using the following commands:
> >>
> >> 1. Loopback Mode Testing (GPIO hog not required)
> >>
> >> ip link set can0 down
> >> ip link set can0 type can bitrate 500000 loopback on
> >> ip link set can0 up
> >> cansend can0 12345678#1122334455667788_B
> >> candump can0
> >>
> >> 2. Testing with External CAN FD Adapter (PCAN-USB FD)
> > 
> > Thanks! It's price doesn't make it esily available, but it answers the
> > most imporant question: by the USB CAN adapter.
> > 
> > Did you add
> > 
> >> A GPIO hog was required to configure the transceiver in normal mode.
> > 
> > I'd phrase it differently: to pull the transceiver out of standby mode.
> > By using the GPIO pin you make it always stay in the normal mode. It is
> > fine, but it is not optimal. Instead a proper solution would be to use
> > the MCP251XFD_REG_IOCON_XSTBYEN bit. Could you please instead implement
> > support for setting that bit, based on the DT property.
> 
> Thanks for the suggestion.
> 
> I tested enabling IOCON.XSTBYEN, but on this hardware it doesn’t bring
> the transceiver out of standby by itself. With only XSTBYEN set, the bus
> remains inactive and no frames reach the CAN adapter. Clearing LAT0
> (driving GPIO0 low) is required to put the transceiver into normal mode;
> data transfer works only after LAT0 is cleared.

Why? It should be doing exactly what is required. Could you please check
the voltage on the pin with the XSTBYEN bit set?

> 
> Given this, a practical approach on this board is:
> 
> drive LAT0 = 0 when the controller is started to take the transceiver
> out of standby, and
> 
> restore LAT0 = 1 when the controller is stopped/suspended to return it
> to standby.
> 
> If you prefer, I can make this conditional on a DT property (e.g. using
> an existing standby-gpios or a new property indicating that the
> transceiver’s standby is wired to GPIO0).

-- 
With best wishes
Dmitry

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

[Konrad Dybcio]

On 2/4/26 2:09 AM, Dmitry Baryshkov wrote:
> On Tue, Feb 03, 2026 at 05:07:11PM +0530, Viken Dadhaniya wrote:
>>
>>
>> On 1/19/2026 11:59 AM, Dmitry Baryshkov wrote:
>>> On Mon, Jan 19, 2026 at 10:21:37AM +0530, Viken Dadhaniya wrote:
>>>>
>>>>
>>>> On 1/9/2026 7:35 PM, Dmitry Baryshkov wrote:
>>>>> On Fri, Jan 09, 2026 at 06:23:39PM +0530, Viken Dadhaniya wrote:
>>>>>>
>>>>>>
>>>>>> On 1/8/2026 7:33 PM, Dmitry Baryshkov wrote:
>>>>>>> On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
>>>>>>>> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
>>>>>>>> Normal mode during boot.
>>>>>>>
>>>>>>> The main question is: what is so different between RB3 Gen2 and previous
>>>>>>> RB boards which also incorporated this CAN controller? Are there any
>>>>>>> board differences or is it that nobody tested the CAN beforehand?
>>>>>>>
>>>>>>
>>>>>> The behavior is consistent across platforms, but I do not have details on
>>>>>> how other platforms were tested.
>>>>>>
>>>>>> On the RB3Gen2 board, communication with the PCAN interface requires the
>>>>>> CAN transceiver to be in normal mode. Since the GPIO-controller support
>>>>>> was recently integrated into the driver, I configured the transceiver using a
>>>>>> GPIO hog property. Without this configuration, the transceiver is not set
>>>>>> to normal mode, and CAN communication does not work.
>>>>>
>>>>> How do we verify the mode on a running system? I have the boards, but I
>>>>> don't have anything connected to them over the CAN bus.
>>>>>
>>>>> BTW: can you recommend any simple setup to actually test the CAN bus on
>>>>> those devices?
>>>>>
>>>>
>>>> I tested the CAN controller using the following commands:
>>>>
>>>> 1. Loopback Mode Testing (GPIO hog not required)
>>>>
>>>> ip link set can0 down
>>>> ip link set can0 type can bitrate 500000 loopback on
>>>> ip link set can0 up
>>>> cansend can0 12345678#1122334455667788_B
>>>> candump can0
>>>>
>>>> 2. Testing with External CAN FD Adapter (PCAN-USB FD)
>>>
>>> Thanks! It's price doesn't make it esily available, but it answers the
>>> most imporant question: by the USB CAN adapter.
>>>
>>> Did you add
>>>
>>>> A GPIO hog was required to configure the transceiver in normal mode.
>>>
>>> I'd phrase it differently: to pull the transceiver out of standby mode.
>>> By using the GPIO pin you make it always stay in the normal mode. It is
>>> fine, but it is not optimal. Instead a proper solution would be to use
>>> the MCP251XFD_REG_IOCON_XSTBYEN bit. Could you please instead implement
>>> support for setting that bit, based on the DT property.
>>
>> Thanks for the suggestion.
>>
>> I tested enabling IOCON.XSTBYEN, but on this hardware it doesn’t bring
>> the transceiver out of standby by itself. With only XSTBYEN set, the bus
>> remains inactive and no frames reach the CAN adapter. Clearing LAT0
>> (driving GPIO0 low) is required to put the transceiver into normal mode;
>> data transfer works only after LAT0 is cleared.
> 
> Why? It should be doing exactly what is required. Could you please check
> the voltage on the pin with the XSTBYEN bit set?

If I'm interpreting the datasheet correctly, XSTBYEN only muxes the pin
into its function and does *not* actually impact the operating mode,
which would match what Viken is observing

Konrad

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

[Dmitry Baryshkov]

On Tue, Feb 17, 2026 at 12:15:12PM +0100, Konrad Dybcio wrote:
> On 2/4/26 2:09 AM, Dmitry Baryshkov wrote:
> > On Tue, Feb 03, 2026 at 05:07:11PM +0530, Viken Dadhaniya wrote:
> >>
> >>
> >> On 1/19/2026 11:59 AM, Dmitry Baryshkov wrote:
> >>> On Mon, Jan 19, 2026 at 10:21:37AM +0530, Viken Dadhaniya wrote:
> >>>>
> >>>>
> >>>> On 1/9/2026 7:35 PM, Dmitry Baryshkov wrote:
> >>>>> On Fri, Jan 09, 2026 at 06:23:39PM +0530, Viken Dadhaniya wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 1/8/2026 7:33 PM, Dmitry Baryshkov wrote:
> >>>>>>> On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
> >>>>>>>> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
> >>>>>>>> Normal mode during boot.
> >>>>>>>
> >>>>>>> The main question is: what is so different between RB3 Gen2 and previous
> >>>>>>> RB boards which also incorporated this CAN controller? Are there any
> >>>>>>> board differences or is it that nobody tested the CAN beforehand?
> >>>>>>>
> >>>>>>
> >>>>>> The behavior is consistent across platforms, but I do not have details on
> >>>>>> how other platforms were tested.
> >>>>>>
> >>>>>> On the RB3Gen2 board, communication with the PCAN interface requires the
> >>>>>> CAN transceiver to be in normal mode. Since the GPIO-controller support
> >>>>>> was recently integrated into the driver, I configured the transceiver using a
> >>>>>> GPIO hog property. Without this configuration, the transceiver is not set
> >>>>>> to normal mode, and CAN communication does not work.
> >>>>>
> >>>>> How do we verify the mode on a running system? I have the boards, but I
> >>>>> don't have anything connected to them over the CAN bus.
> >>>>>
> >>>>> BTW: can you recommend any simple setup to actually test the CAN bus on
> >>>>> those devices?
> >>>>>
> >>>>
> >>>> I tested the CAN controller using the following commands:
> >>>>
> >>>> 1. Loopback Mode Testing (GPIO hog not required)
> >>>>
> >>>> ip link set can0 down
> >>>> ip link set can0 type can bitrate 500000 loopback on
> >>>> ip link set can0 up
> >>>> cansend can0 12345678#1122334455667788_B
> >>>> candump can0
> >>>>
> >>>> 2. Testing with External CAN FD Adapter (PCAN-USB FD)
> >>>
> >>> Thanks! It's price doesn't make it esily available, but it answers the
> >>> most imporant question: by the USB CAN adapter.
> >>>
> >>> Did you add
> >>>
> >>>> A GPIO hog was required to configure the transceiver in normal mode.
> >>>
> >>> I'd phrase it differently: to pull the transceiver out of standby mode.
> >>> By using the GPIO pin you make it always stay in the normal mode. It is
> >>> fine, but it is not optimal. Instead a proper solution would be to use
> >>> the MCP251XFD_REG_IOCON_XSTBYEN bit. Could you please instead implement
> >>> support for setting that bit, based on the DT property.
> >>
> >> Thanks for the suggestion.
> >>
> >> I tested enabling IOCON.XSTBYEN, but on this hardware it doesn’t bring
> >> the transceiver out of standby by itself. With only XSTBYEN set, the bus
> >> remains inactive and no frames reach the CAN adapter. Clearing LAT0
> >> (driving GPIO0 low) is required to put the transceiver into normal mode;
> >> data transfer works only after LAT0 is cleared.
> > 
> > Why? It should be doing exactly what is required. Could you please check
> > the voltage on the pin with the XSTBYEN bit set?
> 
> If I'm interpreting the datasheet correctly, XSTBYEN only muxes the pin
> into its function and does *not* actually impact the operating mode,
> which would match what Viken is observing

See the "Family Reference Manual":

Setting the XSTBYEN bit configures the INT0/GPIO0/XSTBY pin to
automatically control the standby pin of an external CAN transceiver.
The pin is driven high when the MCP25XXFD enters Sleep mode and driven
low when it exits Sleep mode. Standby pin control is not available in
LPM.  IOCON is reset in LPM and GPIO0 will be configured as an input.

> 
> Konrad

-- 
With best wishes
Dmitry

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

[Viken Dadhaniya]

On 2/18/2026 5:49 AM, Dmitry Baryshkov wrote:
> On Tue, Feb 17, 2026 at 12:15:12PM +0100, Konrad Dybcio wrote:
>> On 2/4/26 2:09 AM, Dmitry Baryshkov wrote:
>>> On Tue, Feb 03, 2026 at 05:07:11PM +0530, Viken Dadhaniya wrote:
>>>>
>>>>
>>>> On 1/19/2026 11:59 AM, Dmitry Baryshkov wrote:
>>>>> On Mon, Jan 19, 2026 at 10:21:37AM +0530, Viken Dadhaniya wrote:
>>>>>>
>>>>>>
>>>>>> On 1/9/2026 7:35 PM, Dmitry Baryshkov wrote:
>>>>>>> On Fri, Jan 09, 2026 at 06:23:39PM +0530, Viken Dadhaniya wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/8/2026 7:33 PM, Dmitry Baryshkov wrote:
>>>>>>>>> On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
>>>>>>>>>> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
>>>>>>>>>> Normal mode during boot.
>>>>>>>>>
>>>>>>>>> The main question is: what is so different between RB3 Gen2 and previous
>>>>>>>>> RB boards which also incorporated this CAN controller? Are there any
>>>>>>>>> board differences or is it that nobody tested the CAN beforehand?
>>>>>>>>>
>>>>>>>>
>>>>>>>> The behavior is consistent across platforms, but I do not have details on
>>>>>>>> how other platforms were tested.
>>>>>>>>
>>>>>>>> On the RB3Gen2 board, communication with the PCAN interface requires the
>>>>>>>> CAN transceiver to be in normal mode. Since the GPIO-controller support
>>>>>>>> was recently integrated into the driver, I configured the transceiver using a
>>>>>>>> GPIO hog property. Without this configuration, the transceiver is not set
>>>>>>>> to normal mode, and CAN communication does not work.
>>>>>>>
>>>>>>> How do we verify the mode on a running system? I have the boards, but I
>>>>>>> don't have anything connected to them over the CAN bus.
>>>>>>>
>>>>>>> BTW: can you recommend any simple setup to actually test the CAN bus on
>>>>>>> those devices?
>>>>>>>
>>>>>>
>>>>>> I tested the CAN controller using the following commands:
>>>>>>
>>>>>> 1. Loopback Mode Testing (GPIO hog not required)
>>>>>>
>>>>>> ip link set can0 down
>>>>>> ip link set can0 type can bitrate 500000 loopback on
>>>>>> ip link set can0 up
>>>>>> cansend can0 12345678#1122334455667788_B
>>>>>> candump can0
>>>>>>
>>>>>> 2. Testing with External CAN FD Adapter (PCAN-USB FD)
>>>>>
>>>>> Thanks! It's price doesn't make it esily available, but it answers the
>>>>> most imporant question: by the USB CAN adapter.
>>>>>
>>>>> Did you add
>>>>>
>>>>>> A GPIO hog was required to configure the transceiver in normal mode.
>>>>>
>>>>> I'd phrase it differently: to pull the transceiver out of standby mode.
>>>>> By using the GPIO pin you make it always stay in the normal mode. It is
>>>>> fine, but it is not optimal. Instead a proper solution would be to use
>>>>> the MCP251XFD_REG_IOCON_XSTBYEN bit. Could you please instead implement
>>>>> support for setting that bit, based on the DT property.
>>>>
>>>> Thanks for the suggestion.
>>>>
>>>> I tested enabling IOCON.XSTBYEN, but on this hardware it doesn’t bring
>>>> the transceiver out of standby by itself. With only XSTBYEN set, the bus
>>>> remains inactive and no frames reach the CAN adapter. Clearing LAT0
>>>> (driving GPIO0 low) is required to put the transceiver into normal mode;
>>>> data transfer works only after LAT0 is cleared.
>>>
>>> Why? It should be doing exactly what is required. Could you please check
>>> the voltage on the pin with the XSTBYEN bit set?
>>
>> If I'm interpreting the datasheet correctly, XSTBYEN only muxes the pin
>> into its function and does *not* actually impact the operating mode,
>> which would match what Viken is observing
> 
> See the "Family Reference Manual":
> 
> Setting the XSTBYEN bit configures the INT0/GPIO0/XSTBY pin to
> automatically control the standby pin of an external CAN transceiver.
> The pin is driven high when the MCP25XXFD enters Sleep mode and driven
> low when it exits Sleep mode. Standby pin control is not available in
> LPM.  IOCON is reset in LPM and GPIO0 will be configured as an input.

I measured the standby pin voltage with only XSTBYEN=1 set
(TRIS0 left at reset default of 1 = input): the pin is HIGH
(~3.3V), meaning the transceiver remains in standby.

The root cause is that after reset TRIS0=1 (input direction),
so the pin is not driven. XSTBYEN=1 alone has no effect while
the pin is configured as input.

Clearing TRIS0=0 (output) atomically with XSTBYEN=1 fixes this:

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

After the above change: pin is LOW (~0V), IOCON = 0x03020042,
transceiver active, CAN communication works. Verified on RB3
Gen2 with PCAN-USB FD.

Should I send a patch implementing this, gated on a DT property
such as "microchip,xstbyen"?

> 
>>
>> Konrad
> 

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

[Marc Kleine-Budde]

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

On 12.03.2026 12:04:47, Viken Dadhaniya wrote:
> I measured the standby pin voltage with only XSTBYEN=1 set
> (TRIS0 left at reset default of 1 = input): the pin is HIGH
> (~3.3V), meaning the transceiver remains in standby.
>
> The root cause is that after reset TRIS0=1 (input direction),
> so the pin is not driven. XSTBYEN=1 alone has no effect while
> the pin is configured as input.
>
> Clearing TRIS0=0 (output) atomically with XSTBYEN=1 fixes this:
>
>   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);
>
> After the above change: pin is LOW (~0V), IOCON = 0x03020042,
> transceiver active, CAN communication works. Verified on RB3
> Gen2 with PCAN-USB FD.
>
> Should I send a patch implementing this, gated on a DT property
> such as "microchip,xstbyen"?

Sounds good, make it so.

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 v1 2/2] arm64: dts: qcom: qcs6490-rb3gen2: Enable CAN bus controller

[Dmitry Baryshkov]

On Thu, Mar 12, 2026 at 12:04:47PM +0530, Viken Dadhaniya wrote:
> 
> 
> On 2/18/2026 5:49 AM, Dmitry Baryshkov wrote:
> > On Tue, Feb 17, 2026 at 12:15:12PM +0100, Konrad Dybcio wrote:
> >> On 2/4/26 2:09 AM, Dmitry Baryshkov wrote:
> >>> On Tue, Feb 03, 2026 at 05:07:11PM +0530, Viken Dadhaniya wrote:
> >>>>
> >>>>
> >>>> On 1/19/2026 11:59 AM, Dmitry Baryshkov wrote:
> >>>>> On Mon, Jan 19, 2026 at 10:21:37AM +0530, Viken Dadhaniya wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 1/9/2026 7:35 PM, Dmitry Baryshkov wrote:
> >>>>>>> On Fri, Jan 09, 2026 at 06:23:39PM +0530, Viken Dadhaniya wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 1/8/2026 7:33 PM, Dmitry Baryshkov wrote:
> >>>>>>>>> On Thu, Jan 08, 2026 at 06:22:00PM +0530, 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.
> >>>>>>>>>> A GPIO hog for GPIO0 is included to configure the CAN transceiver in
> >>>>>>>>>> Normal mode during boot.
> >>>>>>>>>
> >>>>>>>>> The main question is: what is so different between RB3 Gen2 and previous
> >>>>>>>>> RB boards which also incorporated this CAN controller? Are there any
> >>>>>>>>> board differences or is it that nobody tested the CAN beforehand?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> The behavior is consistent across platforms, but I do not have details on
> >>>>>>>> how other platforms were tested.
> >>>>>>>>
> >>>>>>>> On the RB3Gen2 board, communication with the PCAN interface requires the
> >>>>>>>> CAN transceiver to be in normal mode. Since the GPIO-controller support
> >>>>>>>> was recently integrated into the driver, I configured the transceiver using a
> >>>>>>>> GPIO hog property. Without this configuration, the transceiver is not set
> >>>>>>>> to normal mode, and CAN communication does not work.
> >>>>>>>
> >>>>>>> How do we verify the mode on a running system? I have the boards, but I
> >>>>>>> don't have anything connected to them over the CAN bus.
> >>>>>>>
> >>>>>>> BTW: can you recommend any simple setup to actually test the CAN bus on
> >>>>>>> those devices?
> >>>>>>>
> >>>>>>
> >>>>>> I tested the CAN controller using the following commands:
> >>>>>>
> >>>>>> 1. Loopback Mode Testing (GPIO hog not required)
> >>>>>>
> >>>>>> ip link set can0 down
> >>>>>> ip link set can0 type can bitrate 500000 loopback on
> >>>>>> ip link set can0 up
> >>>>>> cansend can0 12345678#1122334455667788_B
> >>>>>> candump can0
> >>>>>>
> >>>>>> 2. Testing with External CAN FD Adapter (PCAN-USB FD)
> >>>>>
> >>>>> Thanks! It's price doesn't make it esily available, but it answers the
> >>>>> most imporant question: by the USB CAN adapter.
> >>>>>
> >>>>> Did you add
> >>>>>
> >>>>>> A GPIO hog was required to configure the transceiver in normal mode.
> >>>>>
> >>>>> I'd phrase it differently: to pull the transceiver out of standby mode.
> >>>>> By using the GPIO pin you make it always stay in the normal mode. It is
> >>>>> fine, but it is not optimal. Instead a proper solution would be to use
> >>>>> the MCP251XFD_REG_IOCON_XSTBYEN bit. Could you please instead implement
> >>>>> support for setting that bit, based on the DT property.
> >>>>
> >>>> Thanks for the suggestion.
> >>>>
> >>>> I tested enabling IOCON.XSTBYEN, but on this hardware it doesn’t bring
> >>>> the transceiver out of standby by itself. With only XSTBYEN set, the bus
> >>>> remains inactive and no frames reach the CAN adapter. Clearing LAT0
> >>>> (driving GPIO0 low) is required to put the transceiver into normal mode;
> >>>> data transfer works only after LAT0 is cleared.
> >>>
> >>> Why? It should be doing exactly what is required. Could you please check
> >>> the voltage on the pin with the XSTBYEN bit set?
> >>
> >> If I'm interpreting the datasheet correctly, XSTBYEN only muxes the pin
> >> into its function and does *not* actually impact the operating mode,
> >> which would match what Viken is observing
> > 
> > See the "Family Reference Manual":
> > 
> > Setting the XSTBYEN bit configures the INT0/GPIO0/XSTBY pin to
> > automatically control the standby pin of an external CAN transceiver.
> > The pin is driven high when the MCP25XXFD enters Sleep mode and driven
> > low when it exits Sleep mode. Standby pin control is not available in
> > LPM.  IOCON is reset in LPM and GPIO0 will be configured as an input.
> 
> I measured the standby pin voltage with only XSTBYEN=1 set
> (TRIS0 left at reset default of 1 = input): the pin is HIGH
> (~3.3V), meaning the transceiver remains in standby.
> 
> The root cause is that after reset TRIS0=1 (input direction),
> so the pin is not driven. XSTBYEN=1 alone has no effect while
> the pin is configured as input.
> 
> Clearing TRIS0=0 (output) atomically with XSTBYEN=1 fixes this:
> 
>   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);
> 
> After the above change: pin is LOW (~0V), IOCON = 0x03020042,
> transceiver active, CAN communication works. Verified on RB3
> Gen2 with PCAN-USB FD.
> 
> Should I send a patch implementing this, gated on a DT property
> such as "microchip,xstbyen"?

Sounds good to me.

-- 
With best wishes
Dmitry