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

[Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>]

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
>