netdev - Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API

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]

Date:   Wed, 11 Jan 2023 09:19:34 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>,
        Maciek Machnikowski <maciek@...hnikowski.net>,
        'Vadim Fedorenko' <vfedorenko@...ek.ru>,
        'Jonathan Lemon' <jonathan.lemon@...il.com>,
        'Paolo Abeni' <pabeni@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>
Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API

Tue, Jan 10, 2023 at 09:05:49PM CET, kuba@...nel.org wrote:
>On Mon, 9 Jan 2023 14:43:01 +0000 Kubalewski, Arkadiusz wrote:
>> This is a simplified network switch board example.
>> It has 2 synchronization channels, where each channel:
>> - provides clk to 8 PHYs driven by separated MAC chips,
>> - controls 2 DPLLs.
>> 
>> Basically only given FW has control over its PHYs, so also a control over it's
>> MUX inputs.
>> All external sources are shared between the channels.
>> 
>> This is why we believe it is not best idea to enclose multiple DPLLs with one
>> object:
>> - sources are shared even if DPLLs are not a single synchronizer chip,
>> - control over specific MUX type input shall be controllable from different
>> driver/firmware instances.
>> 
>> As we know the proposal of having multiple DPLLs in one object was a try to
>> simplify currently implemented shared pins. We fully support idea of having
>> interfaces as simple as possible, but at the same time they shall be flexible
>> enough to serve many use cases.
>
>I must be missing context from other discussions but what is this
>proposal trying to solve? Well implemented shared pins is all we need.

There is an entity containing the pins. The synchronizer chip. One
synchronizer chip contains 1-n DPLLs. The source pins are connected
to each DPLL (usually). What we missed in the original model was the
synchronizer entity. If we have it, we don't need any notion of somehow
floating pins as independent entities being attached to one or many
DPLL refcounted, etc. The synchronizer device holds them in
straightforward way.

Example of a synchronizer chip:
https://www.renesas.com/us/en/products/clocks-timing/jitter-attenuators-frequency-translation/8a34044-multichannel-dpll-dco-four-eight-channels#overview