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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <qvuokwiqllm6zmlzj3pfvziylrr5krjya5rnf3ojeycdoutlro@fl5qukh4vorm>
Date: Mon, 19 Jan 2026 08:29:04 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Viken Dadhaniya <viken.dadhaniya@....qualcomm.com>
Cc: mkl@...gutronix.de, mani@...nel.org, thomas.kopp@...rochip.com,
        mailhol@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
        conor+dt@...nel.org, andersson@...nel.org, konradybcio@...nel.org,
        linux-can@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        mukesh.savaliya@....qualcomm.com, anup.kulkarni@....qualcomm.com
Subject: Re: [PATCH v1 2/2] arm64: dts: qcom: qcs6490-rb3gen2: Enable CAN bus
 controller

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