linux-kernel - Re: [PATCH v5 2/7] can: bittiming: allow TDC{V,O} to be zero and add can_tdc_const::tdc{v,o,f}

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]

Date:   Mon, 16 Aug 2021 16:30:52 +0200
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Vincent MAILHOL <mailhol.vincent@...adoo.fr>
Cc:     linux-can <linux-can@...r.kernel.org>,
        Stefan Mätje <Stefan.Maetje@....eu>,
        netdev <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 2/7] can: bittiming: allow TDC{V,O} to be zero and add
 can_tdc_const::tdc{v,o,f}_min

On 16.08.2021 23:10:29, Vincent MAILHOL wrote:
[...]
> After the discussion I had with Stefan, I assumed mcp251xxfd also
> used relative TDCO.  However, in the mcp15xxfd family manual,
> Equation 3-10: "Secondary Sample Point" on page 18 states that:
> 
> | SSP = TDCV + TDCO
> 
> As I commented above, this is the formula of the absolute
> TDCO. Furthermore, in the example you shared, TDCO is
> 16 (absolute), not 0 (relative).

ACK

> *BUT*, if this is the absolute TDCO, I just do not get how it can
> be negative (I already elaborated on this in the past: if you
> subtract from TDCV, you are measuring the previous bit...)
> 
> Another thing which is misleading to me is that the mcp15xxfd
> family manual lists the min and max values for most of the
> bittiming parameters but not for TDCO.
> 
> Finally, I did a bit of research and found that:
> http://ww1.microchip.com/downloads/en/DeviceDoc/Section_56_Controller_Area_Network_with_Flexible_Data_rate_DS60001549A.pdf

Interesting. This data sheet is older than the one of the mcp2518fd.

> This is *not* the mcp25xxfd datasheet but it is still from
> Microship and as you will see, it is mostly similar to the
> mcp25xxfd except for, you guessed it, the TDCO.
> 
> It reads:
> | TDCMOD<1:0>: Transmitter Delay Compensation Mode bits
> | Secondary Sample Point (SSP).
> | 10 = Auto; measure delay and add CFDxDBTCFG.TSEG1; add TDCO
> | 11 = Auto; measure delay and add CFDxDBTCFG.TSEG1; add TDCO
> | 01 = Manual; Do not measure, use TDCV plus TDCO from the register
> | 00 = Disable
> 
> | TDCO<6:0>: Transmitter Delay Compensation Offset bits
> | Secondary Sample Point (SSP). Two's complement; offset can be
> positive, zero, or negative.
> | 1111111 = -64 x SYSCLK
> | .
> | .
> | .
> | 0111111 = 63 x SYSCLK
> | .
> | .
> | .
> | 0000000 = 0 x SYSCLK
> 
> Here, you can clearly see that the TDCO has the exact same range
> as the one of the mcp25xxfd but the description of TDCMOD
> changes, telling us that:
> 
> | SSP = TDCV (measured delay) + CFDxDBTCFG.TSEG1 (sample point) + TDCO
> 
> Which means this is a relative TDCO.
> 
> I just do not get how two documents from Microchip can have the
> TDCO relative range of -64..63 but use a different formula. I am
> sorry but at that point, I just do not understand what is going
> on with your controller...

Me neither. I'll ask my microchip contact.

regards,
Marc

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

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