[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230721190834.375dbb79@kernel.org>
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.
Powered by blists - more mailing lists