linux-kernel - Re: MCP251x SPI CAN controller on Cavium ThunderX

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: <cf336886-a64f-9ff1-2a44-984ff64f8433@pengutronix.de>
Date:   Thu, 16 Nov 2017 13:12:36 +0100
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Tim Harvey <tharvey@...eworks.com>,
        David Daney <ddaney@...iumnetworks.com>,
        Jan Glauber <jan.glauber@...iumnetworks.com>
Cc:     Mark Brown <broonie@...nel.org>, linux-spi@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Wolfgang Grandegger <wg@...ndegger.com>
Subject: Re: MCP251x SPI CAN controller on Cavium ThunderX

On 11/16/2017 12:18 AM, Tim Harvey wrote:
> David / Jan,
> 
> For reference, the HM describes TXNUM/TOTNUM as:
>  TXNUM - Number of bytes to transmit
>  TOTNUM - Total number of bytes to shift (transmit and receive)
> 
> Here are some experiments that show somewhat inconsistent results:
> - full duplex 3byte tx / 3byte rx to MCP251x
> mpi_dat0 => 0x03 // READ
> mpi_dat1 => 0x0e // CANSTAT
> mip_dat2 => 0xa5 // dummy (but making it 0xa5 instead of 0x00 to prove a point)
> mpi_tx => 0x100303 // TXNUM=3 TOTNUM=3; we see 24 clock cycles
> // wait for completion
> mpi_dat0 <= 0xff
> mpi_dat1 <= 0xff

Do you see 0xff 0xff on the MISO wire for byte 1 and 2?

> mpi_dat2 <=0xa5 // this the dummy byte we sent out MOSI not what came
> in on MISO which the scope shows as 0x80

Oh, the device reads what you have shifed out? This is not good.

> if I set TXNUM=3 TOTNUM=4:
> mpi_dat0 => 0x03 // READ
> mpi_dat1 => 0x0e // CANSTAT
> mip_dat2 => 0xa5 // dummy
> mpi_tx => 0x100304 // TXNUM=3 TOTNUM=4; we see 32 clock cycles

What's on MOSI for byte 4?

> // wait for completion
> mpi_dat0 <= 0xff
> mpi_dat1 <= 0xff
> mpi_dat2 <= 0x80 // response for CANSTAT reg 0x0e
> mpi_dat3 <= 0x87 // response for CANCTRL reg 0x0f (because we shifted
> 32 clock cycles)

Looks correct.

> if I set TXNUM=2 TOTNUM=3:
> mpi_dat0 => 0x03 // READ
> mpi_dat1 => 0x0e // CANSTAT
> mpi_tx => 0x100203 // TXNUM=2 TOTNUM=3; we see 24 clock cycles

What's on MOSI for byte 3?

> // wait for completion
> mpi_dat0 <= 0xff
> mpi_dat1 <= 0xff
> mpi_dat2 <= 0x80 // response for CANSTAT reg 0x0e
> 
> if I set TXNUM=1 TOTNUM=1 to send a RESET command:
> mpi_dat0 => 0xc0 // RESET
> mpi_tx => 0x100101 // TXNUM=1 TOTNUM=1; we see 8 clock cycles
> // wait for completion
> mpi_dat0 <= 0xc0
> 
> In all cases above what is seen on MISO in relation to CLK matches the
> expectations of the mcp251x but the CN80xx MPI_DAT registers don't
> return what I see on MISO. Am I missing a consistent pattern of
> MPI_DAT vs TXNUM/TOTNUM here that would allow us to work-around this?
> Is this a CN80xx chip errata? There is no known errata for the CN80XX
> MPI engine.
> 
> I could re-write the mcp251x driver to not use full-duplex but I'm
> assuming most SPI drivers use full-duplex transactions.

ACK.

You don't want to use the mcp251x chip anyways for CAN, the SPI is quite
slow and the load of the CPU is relatively high. Don't expect to get
many messages over CAN and prepare for dropped frames. Better use a
USB-CAN dongle. Or a proper card with some sort of PCI interface.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)