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

Date:   Thu, 8 Dec 2022 16:54:15 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>,
        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-clk@...r.kernel.org" <linux-clk@...r.kernel.org>
Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API

On Thu, 8 Dec 2022 13:02:09 +0100 Jiri Pirko wrote:
> Wed, Dec 07, 2022 at 06:19:46PM CET, kuba@...nel.org wrote:
> >On Wed, 7 Dec 2022 15:51:42 +0100 Jiri Pirko wrote:  
> >> Really, even in case only one driver actually consumes the complexicity?
> >> I understand having a "libs" to do common functionality for drivers,
> >> even in case there is one. But this case, I don't see any benefit.  
> >
> >In the same email thread you admit that mlx5 has multiple devlink
> >instances for the same ASIC and refuse to try to prevent similar
> >situation happening in the new subsystem.  
> 
> I don't understand your point. In CX there is 1 clock for 2 pci PFs. I
> plan to have 1 dpll instance for the clock shared.
> 
> But how is what you write relevant to the discussion? We are talking
> about:
> a) 1 pin in 2 dpll instances
> what I undestand you say here is to prevent:
> b) 2 dpll instances for 1 clock
> apples and oranges. Am I missing something?
> 
> I'm totally against b) but that is not what we discuss here, correct?

Correct, neither (a), nor (b), and as much code for "find other PFs
referring to this device on the board" moved into the core as possible.

AFAIU (and if I'm reading the docs Maciek linked) in case of Intel
there are actually multiple DPLL instances in a single package / Si die.
I presume we want those to be a separate DPLL instance each?
But being part of a single die they share pins..