netdev - RE: [RFC PATCH v7 1/8] dpll: spec: Add Netlink spec in YAML

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]

Message-ID: <DM6PR11MB4657499C8AA3DDB87AAB16AD9B799@DM6PR11MB4657.namprd11.prod.outlook.com>
Date: Tue, 16 May 2023 12:15:53 +0000
From: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: Vadim Fedorenko <vadfed@...a.com>, Jiri Pirko <jiri@...nulli.us>,
	"Jonathan Lemon" <jonathan.lemon@...il.com>, Paolo Abeni <pabeni@...hat.com>,
	"Olech, Milena" <milena.olech@...el.com>, "Michalik, Michal"
	<michal.michalik@...el.com>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, poros <poros@...hat.com>, mschmidt
	<mschmidt@...hat.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>, Vadim Fedorenko
	<vadim.fedorenko@...ux.dev>
Subject: RE: [RFC PATCH v7 1/8] dpll: spec: Add Netlink spec in YAML

>From: Jakub Kicinski <kuba@...nel.org>
>Sent: Friday, May 12, 2023 1:29 AM
>
>On Thu, 11 May 2023 20:53:40 +0000 Kubalewski, Arkadiusz wrote:
>> >Because I think that'd be done by an NCO, no?
>>
>> From docs I can also see that chip has additional designated dpll for NCO
>>mode,
>> and this statement:
>> "Numerically controlled oscillator (NCO) behavior allows system software
>>to steer
>> DPLL frequency or synthesizer frequency with resolution better than 0.005
>>ppt."
>>
>> I am certainly not an expert on this, but seems like the NCO mode for
>this chip
>> is better than FREERUN, since signal produced on output is somehow higher
>quality.
>
>Herm, this seems complicated. Do you have a use case for this?
>Maybe we can skip it :D
>

True!
Actually yeah, I agree let's skip it, we don't have implemented example and
there is no need for it for now, we will have to discuss it someday if someone
want to give control over it to the user, and as Jiri already pointed, probably
it could be done with using internal oscillator type of pin and just
configurable frequency.

Thus I will remove the NCO from the dpll modes.

>My reading of the quote is that there is an NCO which SW can control
>precisely. But that does not answer the questions:
> - is the NCO driven by system clock 

Yes it is, other part of documentation lead to this conclusion.

> or can it be used in locked mode?

There is also a behavior called "NCO-hybrid", and as I understand works
somehow as you described, dpll can lock to something but additional offset
based on so called "System Clock Input (Jitter Reference)" pin is applied
to the signal (the pin is also used for normal NCO mode).

> - what is the "system software"? FW which based on temperature
>   information, and whatever else compensates drift of system clock?
>   or there are exposed registers to control the NCO?

The synchronizer chip firmware provides the knobs in form of registers to
control frequency offset for all the outputs, as well as for dpll's
frequency offset.

Thank you,
Arkadiusz