netdev - Re: [RFC PATCH v4 4/4] ptp_ocp: implement DPLL ops

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, 7 Dec 2022 14:19:22 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kuba@...nel.org>
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>,
        Vadim Fedorenko <vadfed@...com>,
        "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 4/4] ptp_ocp: implement DPLL ops

Wed, Dec 07, 2022 at 03:33:13AM CET, kuba@...nel.org wrote:
>On Fri, 2 Dec 2022 14:39:17 +0000 Kubalewski, Arkadiusz wrote:
>> >>>Btw, did you consider having dpll instance here as and auxdev? It
>> >>>would be suitable I believe. It is quite simple to do it. See
>> >>>following patch as an example:  
>> >>
>> >>I haven't think about it, definetly gonna take a look to see if there
>> >>any benefits in ice.  
>> >
>> >Please do. The proper separation and bus/device modelling is at least one
>> >of the benefits. The other one is that all dpll drivers would happily live
>> >in drivers/dpll/ side by side.
>> 
>> Well, makes sense, but still need to take a closer look on that.
>> I could do that on ice-driver part, don't feel strong enough yet to introduce
>> Changes here in ptp_ocp.
>
>FWIW auxdev makes absolutely no sense to me for DPLL :/
>So Jiri, please say why.

Why not? It's a subdev of a device. In mlx5, we have separate auxdevs
for eth, rdma, vnet, representors. DPLL is also a separate entity which
could be instantiated independently (as it is not really dependent on
eth/rdma/etc)). Auxdev looks like an awesome fit. Why do you think it is
not?

Also, what's good about auxdev is that you can maintain them quite
independetly. So there is going to be driver/dpll/ directory which would
contain all dpll drivers.