[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZFjoWn9+H932DdZ1@nanopsycho>
Date: Mon, 8 May 2023 14:17:30 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
"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
Mon, May 08, 2023 at 08:50:09AM CEST, pabeni@...hat.com wrote:
>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.
Well sure, in case there is no "label" attr for the rest of the types.
Which I believe it is, for the ice implementation in this patchset.
Otherwise, there is no way to distinguish between the pins.
To have multiple attrs for label for multiple pin types does not make
any sense to me, that was my point.
>
>Cheer,
>
>Paolo
>
Powered by blists - more mailing lists