linux-kernel - Re: [PATCH net] net: lan966x: Fix the initialization of taprio

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

Message-ID: <4f8b0e67-1cc4-4387-bad3-0c5ae2092f52@lunn.ch>
Date: Wed, 19 Nov 2025 15:26:41 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Horatiu Vultur <horatiu.vultur@...rochip.com>
Cc: UNGLinuxDriver@...rochip.com, andrew+netdev@...n.ch,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, richardcochran@...il.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] net: lan966x: Fix the initialization of taprio

On Wed, Nov 19, 2025 at 09:26:46AM +0100, Horatiu Vultur wrote:
> The 11/18/2025 20:20, Andrew Lunn wrote:
> 
> Hi Andrew,
> 
> > 
> > On Mon, Nov 17, 2025 at 03:43:09PM +0100, Horatiu Vultur wrote:
> > > To initialize the taprio block in lan966x, it is required to configure
> > > the register REVISIT_DLY. The purpose of this register is to set the
> > > delay before revisit the next gate and the value of this register depends
> > > on the system clock. The problem is that the we calculated wrong the value
> > > of the system clock period in picoseconds. The actual system clock is
> > > ~165.617754MHZ and this correspond to a period of 6038 pico seconds and
> > > not 15125 as currently set.
> > 
> > Is the system clock available as a linux clock? Can you do a
> > clk_get_rate() on it?
> 
> Unfortunetly, I can not do clk_get_rate because in the device tree for the
> switch node I don't have any clocks property. And maybe that is the
> problem because I have the system clock (sys_clk) in the lan966x.dtsi
> file. But if I go this way then I need add a bigger changeset and add
> it to multiple kernel trees which complicate the things.
> So maybe I should not change this patch and then create another one
> targeting net-next where I can start using clk_get_rate()

This is fine as is. But maybe rather than use the magic number, add a
#defines for the system clock rate, and convert to pico seconds in the
code, and let the compiler do it at compile time. The code then
documents what is going on.

	Andrew