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:   Fri, 18 Jun 2021 14:44:47 +0200
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Vincent MAILHOL <mailhol.vincent@...adoo.fr>
Cc:     linux-can <linux-can@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        Thomas Kopp <thomas.kopp@...rochip.com>
Subject: CAN-FD Transmitter Delay Compensation (TDC) on mcp2518fd

On 18.06.2021 20:17:51, Vincent MAILHOL wrote:
> > > I just noticed in the mcp2518fd data sheet:
> > >
> > > | bit 14-8 TDCO[6:0]: Transmitter Delay Compensation Offset bits;
> > > | Secondary Sample Point (SSP) Two’s complement; offset can be positive,
> > > | zero, or negative.
> > > |
> > > | 011 1111 = 63 x TSYSCLK
> > > | ...
> > > | 000 0000 = 0 x TSYSCLK
> > > | ...
> > > | 111 1111 = –64 x TSYSCLK
> > >
> > > Have you takes this into account?
> >
> > I have not. And I fail to understand what would be the physical
> > meaning if TDCO is zero or negative.

The mcp25xxfd family data sheet says:

| SSP = TDCV + TDCO

> > TDCV indicates the position of the bit start on the RX pin.

If I understand correctly in automatic mode TDCV is measured by the CAN
controller and reflects the transceiver delay. I don't know why you want
to subtract a time from that....

The rest of the relevant registers:

| TDCMOD[1:0]: Transmitter Delay Compensation Mode bits; Secondary Sample Point (SSP)
| 10-11 = Auto; measure delay and add TDCO.
| 01 = Manual; Do not measure, use TDCV + TDCO from register
| 00 = TDC Disabled
| 
| TDCO[6:0]: Transmitter Delay Compensation Offset bits; Secondary Sample Point (SSP)
| Two’s complement; offset can be positive, zero, or negative.
| 011 1111 = 63 x TSYSCLK
| ...
| 000 0000 = 0 x TSYSCLK
| ...
| 111 1111 = –64 x TSYSCLK
| 
| TDCV[5:0]: Transmitter Delay Compensation Value bits; Secondary Sample Point (SSP)
| 11 1111 = 63 x TSYSCLK
| ...
| 00 0000 = 0 x TSYSCLK

> > If TDCO is zero, the measurement occurs on the bit start when all
> > the ringing occurs. That is a really bad choice to do the
> > measurement. If it is negative, it means that you are measuring the
> > previous bit o_O !?

I don't know...

> > Maybe I am missing something but I just do not get it.
> >
> > I believe you started to implement the mcp2518fd.

No I've just looked into the register description.

> > Can you force a
> > zero and a negative value and tell me if the bus is stable?
> 
> Actually, ISO 11898-1 specifies that the "SSP position should be
> at least 0 to 63 minimum time quanta". This means that we can
> have SSP = TDCV + TDCO = 0. In my implementation, I used 0 as a
> reserved value for TDCV and TDCO. To comply with the standard, I
> now need to allow both TDCV and TDCO to be zero and add a new
> field in struct tdc to manage the automatic/manual options.
> 
> That said, these zero values still make no sense to me. Why would
> someone do the measurement on the bit edge?
> 
> Concerning the negative values, the ISO standard says nothing
> about it.  If you are using the automatic measurement, a negative
> TDCO is impossible to use. TDCV is measured on every bit. When
> the measurement is done, it is too late to subtract from it (or
> maybe the mcp2518fd has a time machine built in?).

:)

> If you are
> using the manual mode for TDCV, just choose two positive values
> so that TDCV + TDCO = SSF.

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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ