netdev - Re: [PATCH v2 2/2] can: netlink: add interface for CAN-FD Transmitter Delay Compensation (TDC)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Jun 2021 20:17:51 +0900
From:   Vincent MAILHOL <mailhol.vincent@...adoo.fr>
To:     Marc Kleine-Budde <mkl@...gutronix.de>
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>
Subject: Re: [PATCH v2 2/2] can: netlink: add interface for CAN-FD Transmitter
 Delay Compensation (TDC)

On Fri. 18 Jun 2021 at 19:23, Vincent MAILHOL
<mailhol.vincent@...adoo.fr> wrote:
>
> On Fri. 18 Jun 2021 at 18:34, Marc Kleine-Budde <mkl@...gutronix.de> wrote:
> > On 04.06.2021 00:15:50, Vincent Mailhol wrote:
> > > Add the netlink interface for TDC parameters of struct can_tdc_const
> > > and can_tdc.
> > >
> > > Contrary to the can_bittiming(_const) structures for which there is
> > > just a single IFLA_CAN(_DATA)_BITTMING(_CONST) entry per structure,
> > > here, we create a nested entry IFLA_CAN_TDC. Within this nested entry,
> > > additional IFLA_CAN_TDC_TDC* entries are added for each of the TDC
> > > parameters of the newly introduced struct can_tdc_const and struct
> > > can_tdc.
> > >
> > > For struct can_tdc_const, these are:
> > >         IFLA_CAN_TDC_TDCV_MAX
> > >         IFLA_CAN_TDC_TDCO_MAX
> > >         IFLA_CAN_TDC_TDCF_MAX
> > >
> > > For struct can_tdc, these are:
> > >         IFLA_CAN_TDC_TDCV
> > >         IFLA_CAN_TDC_TDCO
> > >         IFLA_CAN_TDC_TDCF
> >
> > 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.
>
> TDCV indicates the position of the bit start on the RX pin. 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 !?
>
> Maybe I am missing something but I just do not get it.
>
> I believe you started to implement the mcp2518fd. 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.