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.1On 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 |
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
>
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
>
--
மணிவண்ணன் சதாசிவம்
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
>>
>
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
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(+) >> >
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
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
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
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 >> >
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
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
© 2016 - 2026 Red Hat, Inc.