linux-kernel - Re: [PATCH v7 2/2] cpufreq: airoha: Add EN7581 CPUFreq SMCCC driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPDyKFq7c607_NtiEF=4HinL5HABv7+fW9EGi1xfwpOpUPO6Bg@mail.gmail.com>
Date: Thu, 19 Dec 2024 16:23:52 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Viresh Kumar <viresh.kumar@...aro.org>, Christian Marangi <ansuelsmth@...il.com>
Cc: "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, 13 Dec 2024 at 23:35, Christian Marangi <ansuelsmth@...il.com> wrote:
>
> 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?

The power-domain provider driver should use the compatible
"airoha,en7581-cpufreq". This driver should be responsible for
registering the genpd and the clock.

Potentially, the power-domain provider driver could also register the
"cpufreq-dt" platform-device. To make this work, we also need to
extend the cpufreq-dt driver (maybe extend its platform-data too?) to
be capable of attaching the corresponding cpu-devices to their
power(perf)-domains. For the moment, this isn't supported, but I think
it would be nice if it could. Another option, would be to use an
additional separate name-based cpufreq-driver, as in the
qcom-cpufreq-nvmem.c, that then becomes responsible for registering
the cpufreq-dt device.

Viresh, do you have a better approach in mind?

Kind regards
Uffe