linux-kernel - Re: RE: [PATCH] can: length: add definitions for frame lengths in bits

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: <20230509-helmet-oozy-c1136e384d2e-mkl@pengutronix.de>
Date:   Tue, 9 May 2023 08:43:20 +0200
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Vincent MAILHOL <mailhol.vincent@...adoo.fr>
Cc:     Thomas.Kopp@...rochip.com, linux-can@...r.kernel.org,
        marex@...x.de, linux-kernel@...r.kernel.org
Subject: Re: RE: [PATCH] can: length: add definitions for frame lengths in
 bits

On 09.05.2023 13:16:08, Vincent MAILHOL wrote:
> > The diagram in https://www.can-cia.org/can-knowledge/can/can-fd/
> > suggests that IMF is part of the frame.
> 
> ISO 11898-1:2015 section 10.4.6 "Specification of inter-frame space"
> makes it clear that the intermission is not part of the frame but part
> of the "Inter-frame space".

For this reason, it is good to have open standards...oh wait!

> To close the discussion, I would finally argue that the intermission
> occurs after the EOF bit. Something after an "End of Frame" is not
> part of the frame, right?
> 
> I agree with and will follow Thomas's suggestion.

[...]

> > > /*
> > >   * Size of a CAN-FD Standard Frame
> > > @@ -69,17 +87,17 @@
> > >   * Error Status Indicator (ESI)                1
> > >   * Data length code (DLC)              4
> > >   * Data field                          0...512
> > > - * Stuff Bit Count (SBC)               0...16: 4 20...64:5
> > > + * Stuff Bit Count (SBC)               4
> >
> > ACK
> >
> > >   * CRC                                 0...16: 17 20...64:21
> > >   * CRC delimiter (CD)                  1
> > > + * Fixed Stuff bits (FSB)              0...16: 6 20...64:7
> >
> > As far as I understand
> > https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8338047 the FSB
> > is 5 or 6.
> 
> Reading the ISO, the fixed bit stuff applies to the CRC field (which,
> in the standard nomenclature, includes both the stuff count and the
> CRC sequence).
> The CRC field starts with a fixed stuff bit and then has another fixed
> stuff bit after each fourth bit.
> 
> So the formula would be:
> 
>   FSB count = 1 + round_down(len(CRC field)/4)
>             = 1 + round_down((len(stuff count) + len(CRC sequence))/4)
> 
> In case of CRC_17:
> 
>   FSB count = 1 + round_down((4 + 17)/4)
>             = 6
> 
> This is coherent with the last figure of
> https://www.can-cia.org/can-knowledge/can/can-fd/ which shows 6 FSB
> for CRC_17.
> 
> In case of CRC_21:
> 
>   FSB count = 1 + round_down((4 + 21)/4)
>             = 7
> 
> So, ACK for Thomas, NACK for Marc (sorry :))

It seems that the reviewers of this paper missed some parts :)

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

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