netdev - [RFC] can: ctucanfd: RX timestamping implementation

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-next>] [day] [month] [year] [list]

Message-Id: <20220512232706.24575-1-matej.vasilevski@seznam.cz>
Date:   Fri, 13 May 2022 01:27:04 +0200
From:   Matej Vasilevski <matej.vasilevski@...nam.cz>
To:     linux-can@...r.kernel.org, mkl@...gutronix.de,
        pisa@....felk.cvut.cz
Cc:     devicetree@...r.kernel.org, netdev@...r.kernel.org,
        ondrej.ille@...il.com, martin.jerabek01@...il.com,
        matej.vasilevski@...nam.cz
Subject: [RFC] can: ctucanfd: RX timestamping implementation

Hello,

I would like to upstream my timestamping patch for CTU CAN FD IP core,
but I guess it won't be that easy, so this is only an RFC.

I'm using the timecounter/cyclecounter structures as has been recommended
(basically copied from the mcp251xfd). But the hard part here is passing
information to the driver, because the timestaping counter width and
frequency isn't defined in the IP core specs.

So currently I take both the counter width and frequency from Device Tree.
The frequency can be specified in the form of second clock in "clocks"
property (which seems good to me, because then the timestamping clock
would be initialized and managed automatically, in case the clock isn't
the same as the main clock). Or directly in "ts-frequency" property.
Counter bit width is specified in the "ts-bit-width" property.
This means that PCI devices currently can't report timestamps (because
Device Tree isn't used for PCI devices).
Alternatively, I could use module parameters, but those are frowned
upon. Module_param also uses static variables, which means one parameter
would be shared across multiple ctucanfd devices, which isn't great
either.

This patch also introduces another Kconfig option:
CAN_CTUCANFD_PLATFORM_ENABLE_HW_TIMESTAMPS to control whether timestamps
are enabled by default. I've done this for cases when somebody would
like to disable timestamping (be it for performance reasons or
whatever). Seems to me better than having to run some script after
startup which would disable timestamping. I don't know which tool does
can do this (ethtool/ip-link?), but I guess it would require the
.ndo_eth_ioctl callback in the driver.

Looking forward to some comments/feedback.

Thank you, yours sincerely,
Matej Vasilevski