netdev - Re: [PATCH 09/11] ice: implement dpll interface to control cgu

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: Fri, 21 Jul 2023 19:08:34 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>, Vadim
 Fedorenko <vadim.fedorenko@...ux.dev>, 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>, Bart Van Assche
 <bvanassche@....org>
Subject: Re: [PATCH 09/11] ice: implement dpll interface to control cgu

On Fri, 21 Jul 2023 09:33:14 +0200 Jiri Pirko wrote:
> >d) SyncE daemon uses PIN_SET to set state of pin_id:13 to CONNECTED with
> >   parent pin (pin-id:2)  
> 
> For this you need pin_id and pin_parent_id because you set the state on
> a parent pin.
> 
> 
> Yeah, this is exactly why I initially was in favour of hiding all the
> muxes and magic around it hidden from the user. Now every userspace app
> working with this has to implement a logic of tracking pin and the mux
> parents (possibly multiple levels) and configure everything. But it just
> need a simple thing: "select this pin as a source" :/
> 
> 
> Jakub, isn't this sort of unnecessary HW-details complexicity exposure
> in UAPI you were against in the past? Am I missing something?

From just reading what I'm quoting - I don't think so.
Muxes are meaningful because they limit valid configurations.
We can implement "automatic mutex config" in the kernel
if user wants it, centrally in the core, otherwise each
driver will have to do it on its own.