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, 29 Apr 2022 23:31:28 +0200
From:   Pavel Pisa <>
To:     "Marc Kleine-Budde" <>
        Oliver Hartkopp <>,
        Wolfgang Grandegger <>,
        David Miller <>,,,
        Marin Jerabek <>,
        Ondrej Ille <>,
        Jiri Novak <>,
        Jaroslav Beran <>,
        Petr Porazil <>, Pavel Machek <>,
        Carsten Emde <>,
        Drew Fustini <>,
        Matej Vasilevski <>,
        Andrew Dennison <>
Subject: Re: [PATCH v1 0/4] can: ctucanfd: clenup acoording to the actual rules and documentation linking

Hello Marc,

On Thursday 28 of April 2022 09:22:39 Marc Kleine-Budde wrote:
> > Jiapeng Chong (2):
> >   can: ctucanfd: Remove unnecessary print function dev_err()
> >   can: ctucanfd: Remove unused including <linux/version.h>
> I had these already applied.
> > Pavel Pisa (2):
> >   can: ctucanfd: remove PCI module debug parameters and core debug
> >     statements.
> >   docs: networking: device drivers: can: add ctucanfd and its author
> >     e-mail update
> Split into separate patches and applied.

Excuse me for late reply and thanks much for split to preferred
form. Matej Vasilevski has tested updated linux-can-next testing
on Xilinx Zynq 7000 based MZ_APO board and used it with his
patches to do proceed next round of testing of Jan Charvat's NuttX
TWAI (CAN) driver on ESP32C3. We plan that CTU CAN FD timestamping
will be send for RFC/discussion soon.

I would like to thank to Andrew Dennison who implemented, tested
and shares integration with LiteX and RISC-V

He uses development version of the CTU CAN FD IP core with configurable
number of Tx buffers (2 to 8) for which will be required
automatic setup logic in the driver.

I need to discuss with Ondrej Ille actual state and his plans.
But basically ntxbufs in the ctucan_probe_common() has to be assigned
from TXTB_INFO TXT_BUFFER_COUNT field. For older core version
the TXT_BUFFER_COUNT field bits should be equal to zero so when
value is zero, the original version with fixed 4 buffers will
be recognized. When value is configurable then for (uncommon) number
of buffers which is not power of two, there will be likely
a problem with way how buffers queue is implemented

  txtb_id = priv->txb_head % priv->ntxbufs;

When I have provided example for this type of queue many years
ago I have probably shown example with power of 2 masking,
but modulo by arbitrary number does not work with sequence
overflow. Which means to add there two "if"s unfortunately

  if (++priv->txb_tail == 2 * priv->ntxbufs)
      priv->txb_tail = 0;

We need 2 * priv->ntxbufs range to distinguish empty and full queue...
But modulo is not nice either so I probably come with some other
solution in a longer term. In the long term, I want to implement
virtual queues to allow multiqueue to use dynamic Tx priority
of up to 8 the buffers...

Best wishes,

                Pavel Pisa
    phone:      +420 603531357
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    CAN related:
    Open Technologies Research Education and Exchange Services

Powered by blists - more mailing lists