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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

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