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] [thread-next>] [day] [month] [year] [list]

Message-ID: <5486697e-d02e-4b12-9a60-99d0de343515@oss.qualcomm.com>
Date: Tue, 3 Feb 2026 17:07:11 +0530
From: Viken Dadhaniya <viken.dadhaniya@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....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 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
>>
>