netdev - Re: [RFC PATCH] net: dsa: mv88e6xxx: correct CC scale factor for 88E6393X

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d6622575-bf1b-445a-b08f-2739e3642aae@lunn.ch>
Date: Sun, 15 Sep 2024 21:14:04 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Shenghao Yang <me@...nghaoyang.info>
Cc: netdev@...r.kernel.org, f.fainelli@...il.com, olteanv@...il.com,
	pavana.sharma@...i.com, ashkan.boldaji@...i.com, kabel@...nel.org
Subject: Re: [RFC PATCH] net: dsa: mv88e6xxx: correct CC scale factor for
 88E6393X

On Sun, Sep 15, 2024 at 07:57:27PM +0800, Shenghao Yang wrote:
> Sending this as an RFC: no datasheet access - this
> scaling factor may not be correct for all boards if this
> 4ns vs 8ns discrepancy is down to physical design.
> 
> If the counter is truly spec'd to always count at
> 250MHz other chips in the same family may need
> correction too.

Hi Shenghao

This sort of text should be placed below the --- marker so it is not
part of the commit message which actually get merged.

What we want above the --- is a description of the problem you see,
and how your patch fixes this problem. It should include an
explanation of what you think the real problem is.

My understanding is that the clock can either be 250MHz or 125MHz like
older generations. If an external clock is used, it should be 125MHz.
The internally generated clock is however 250Mhz.

There is a register MV88E6XXX_TAI_CLOCK_PERIOD which indicates the
period of one clock tick. It probably defaults to 0x0FA0, or 4000
decimal which should be correct for the internal clock. But if an
external clock is being used, it needs to be set to 0x1F40, or 8000
decimal. It would be good if you could read it out and see if it is
correct by default.

This should apply to the 6393X family, so 6191X 6193X 6361 6393X. It
does not appear to apply to older devices.

	Andrew