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] [thread-next>] [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
 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ