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:   Thu, 4 Aug 2022 10:08:25 +0200
From:   Pavel Pisa <pisa@....felk.cvut.cz>
To:     "Marc Kleine-Budde" <mkl@...gutronix.de>,
        Matej Vasilevski <matej.vasilevski@...nam.cz>,
        Ondrej Ille <ondrej.ille@...il.com>
Cc:     Vincent Mailhol <vincent.mailhol@...il.com>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-can@...r.kernel.org, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, Jiri Novak <jnovak@....cvut.cz>,
        Oliver Hartkopp <socketcan@...tkopp.net>
Subject: Re: [PATCH v2 1/3] can: ctucanfd: add HW timestamps to RX and error CAN frames

Hello Marc,

On Wednesday 03 of August 2022 11:04:36 Marc Kleine-Budde wrote:
> On 02.08.2022 09:37:54, Pavel Pisa wrote:
> > See 2.14.1 Loopback mode
> > SETTINGS[ILBP]=1.
> >
> > in the datasheet
> >
> >   http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/doc/Datasheet.pdf
>
> BTW: the datasheet says:
> | 3.1.36 RX_DATA
> |
> | ... this register must be read by 32 bit access.
>
> While there is a section that uses 8-bit accessed on that register:

Congratulation to watchfull reading.

The FPGA design is done so that 32, 16 and 8-bits read writes
are supported. But when you read only part of the RX data
register then you lose rest because FIFO advances to the next
32-bit word. That is reasonable solution for 32-bit systems.

There has been added option in 3.0 version to switch into mode
where FIFO doe not advance when RX_DATA is read, then you can
read it by 8 or 16 bits. If MODES[RXBAM]=0 is set. Then advance
to the next world is requested by COMMAND[RXRPMV] bit.
Ondrej Ille considered that mode for for some embedded
use of the core connected to some small MCU. But this
mode causes great overhead in the driver, multiple reads
of RX_DATA followed by write to to COMMAND. I would consider
only default 32-bit mode for Linux driver.  

In the fact, to connect to 16-bit systems, my preference would
be to add option into design to select if Rx FIFO advances
by read of LSB or MSB of the RX_DATA register.

Anyway, command register needs at least 16-bit accesses
for now to correctly command operation, for 8-bit it would
require catch one written byte into latch and combine
it with another one written to the other part and this
would require locking around each command write...

For priority register we need at least 16-bit single write
cycle access when 4 TX buffers are used in FIFO configuration.

I do not intend to complicate driver for all these edge cases
when our target on regular Linux systems is utilize 32-bit
busses...

Actual driver uses only 32-bit access exclusively...

Thanks for the checks and suggestions,

                Pavel
-- 
                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa@....felk.cvut.cz
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://control.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/
    RISC-V education: https://comparch.edu.cvut.cz/
    Open Technologies Research Education and Exchange Services
    https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

Powered by blists - more mailing lists