[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <675cb6b2.050a0220.149877.5bab@mx.google.com>
Date: Fri, 13 Dec 2024 23:35:25 +0100
From: Christian Marangi <ansuelsmth@...il.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Ulf Hansson <ulf.hansson@...aro.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, linux-pm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
upstream@...oha.com
Subject: Re: [PATCH v7 2/2] cpufreq: airoha: Add EN7581 CPUFreq SMCCC driver
On Fri, Dec 13, 2024 at 09:30:01AM +0530, Viresh Kumar wrote:
> On 12-12-24, 13:01, Ulf Hansson wrote:
> > On Fri, 6 Dec 2024 at 22:16, Christian Marangi <ansuelsmth@...il.com> wrote:
> > Hmm, it looks like this needs to be moved and possibly split up.
> >
> > The provider part (for the clock and power-domain) belongs in
> > /drivers/pmdomain/*, along with the other power-domain providers.
> >
> > Other than that, I was really expecting the cpufreq-dt to take care of the rest.
> >
> > To me, the above code belongs in a power-domain provider driver. While
> > the below should be taken care of in cpufreq-dt, except for the device
> > registration of the cpufreq-dt device, I guess.
> >
> > Viresh, what's your view on this?
>
> Sure, no issues.. These are all cpufreq related, but don't necessarily belong in
> the cpufreq directory.
>
Problem is really DT schema... I wonder if it's acceptable to push a
name-only driver in pmdomain just do detach from cpufreq. The cpufreq
driver would manually probe the pmdomain. Is it acceptable?
Or do you have alternative solution for this?
--
Ansuel
Powered by blists - more mailing lists