[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d86ff1331a621bf3048123c24c22f49e9ecf0044.camel@redhat.com>
Date: Mon, 08 May 2023 08:50:09 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kuba@...nel.org>
Cc: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>, Vadim
Fedorenko <vadim.fedorenko@...ux.dev>, Vadim Fedorenko <vadfed@...a.com>,
Jonathan Lemon <jonathan.lemon@...il.com>, poros <poros@...hat.com>,
mschmidt <mschmidt@...hat.com>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, linux-arm-kernel@...ts.infradead.org,
"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>, "Olech, Milena"
<milena.olech@...el.com>, "Michalik, Michal" <michal.michalik@...el.com>
Subject: Re: [PATCH RFC v6 2/6] dpll: Add DPLL framework base functions
On Sun, 2023-05-07 at 09:58 +0200, Jiri Pirko wrote:
> Fri, May 05, 2023 at 05:35:31PM CEST, kuba@...nel.org wrote:
> > On Fri, 5 May 2023 12:41:11 +0200 Jiri Pirko wrote:
> > >
> > Sound perfectly fine, if it's a front panel label, let's call
> > the attribute DPLL_A_PIN_FRONT_PANEL_LABEL. If the pin is not
> > brought out to the front panel it will not have this attr.
> > For other type of labels we should have different attributes.
>
> Hmm, that would kind of embed the pin type into attr which feels wrong.
Looking at the above from a different angle, the
DPLL_A_PIN_FRONT_PANEL_LABEL attribute will be available only for
DPLL_PIN_TYPE_EXT type pins, which looks legit to me - possibly
renaming DPLL_A_PIN_FRONT_PANEL_LABEL as DPLL_A_PIN_EXT_LABEL.
Cheer,
Paolo
Powered by blists - more mailing lists