[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <e4e4046d53ce61ac0f7db882fa31556e8a9db94b.camel@redhat.com>
Date: Thu, 27 Apr 2023 10:05:11 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...nulli.us>
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
Subject: Re: [PATCH RFC v6 2/6] dpll: Add DPLL framework base functions
Hi,
On Mon, 2023-04-17 at 12:49 -0700, Jakub Kicinski wrote:
> [resend with fixed CC list]
>
> On Sun, 16 Apr 2023 18:23:15 +0200 Jiri Pirko wrote:
> > > What is index? I thought you don't want an index and yet there is one,
> > > just scoped by random attributes :(
> >
> > Index internal within a single instance. Like Intel guys, they have 1
> > clock wired up with multiple DPLLs. The driver gives every DPLL index.
> > This is internal, totally up to the driver decision. Similar concept to
> > devlink port index.
>
> devlink port index ended up as a pretty odd beast with drivers encoding
> various information into it, using locally grown schemes.
>
> Hard no on doing that in dpll, it should not be exposed to the user.
I'm replying here just in case the even the above reply was lost.
I guess the last remark resolved this specific discussion.
@Vadim, @Arkadiusz, even if net-next is currently closed, there are no
restrictions for RFC patches: feel free to share v7 when it fits you
better!
Thanks,
Paolo
Powered by blists - more mailing lists