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

[Dmitry Baryshkov]

On Thu, Mar 12, 2026 at 12:04:47PM +0530, Viken Dadhaniya wrote:
> 
> 
> 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"?

Sounds good to me.

-- 
With best wishes
Dmitry