Message-Id: <61d0584f-dfe4-4d8c-a178-78f000d477d4@app.fastmail.com>
Date: Mon, 15 Apr 2024 17:30:31 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Yann Sionneau" <ysionneau@...rayinc.com>,
 "Krzysztof Kozlowski" <krzysztof.kozlowski@...aro.org>,
 "Yann Sionneau" <ysionneau@...ray.eu>,
 "Jonathan Corbet" <corbet@....net>,
 "Thomas Gleixner" <tglx@...utronix.de>, "Marc Zyngier" <maz@...nel.org>,
 "Rob Herring" <robh+dt@...nel.org>,
 "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
 "Will Deacon" <will@...nel.org>, "Peter Zijlstra" <peterz@...radead.org>,
 "Boqun Feng" <boqun.feng@...il.com>,
 "Mark Rutland" <mark.rutland@....com>,
 "Eric W. Biederman" <ebiederm@...ssion.com>,
 "Kees Cook" <keescook@...omium.org>, "Oleg Nesterov" <oleg@...hat.com>,
 "Ingo Molnar" <mingo@...hat.com>, "Waiman Long" <longman@...hat.com>,
 "Aneesh Kumar" <aneesh.kumar@...ux.ibm.com>,
 "Andrew Morton" <akpm@...ux-foundation.org>,
 "Nicholas Piggin" <npiggin@...il.com>,
 "Paul Moore" <paul@...l-moore.com>, "Eric Paris" <eparis@...hat.com>,
 "Christian Brauner" <brauner@...nel.org>,
 "Paul Walmsley" <paul.walmsley@...ive.com>,
 "Palmer Dabbelt" <palmer@...belt.com>,
 "Albert Ou" <aou@...s.berkeley.edu>,
 "Jules Maselbas" <jmaselbas@...ray.eu>,
 "Guillaume Thouvenin" <gthouvenin@...ray.eu>,
 "Clement Leger" <clement@...ment-leger.fr>,
 "Vincent Chardon" <vincent.chardon@...ys-design.com>,
 Marc Poulhiès <dkm@...aplop.net>,
 "Julian Vetter" <jvetter@...ray.eu>, "Samuel Jones" <sjones@...ray.eu>,
 "Ashley Lesdalons" <alesdalons@...ray.eu>,
 "Thomas Costis" <tcostis@...ray.eu>, "Marius Gligor" <mgligor@...ray.eu>,
 "Jonathan Borne" <jborne@...ray.eu>,
 "Julien Villette" <jvillette@...ray.eu>,
 "Luc Michel" <lmichel@...ray.eu>, "Louis Morhet" <lmorhet@...ray.eu>,
 "Julien Hascoet" <jhascoet@...ray.eu>,
 "Jean-Christophe Pince" <jcpince@...il.com>,
 "Guillaume Missonnier" <gmissonnier@...ray.eu>,
 "Alex Michon" <amichon@...ray.eu>, "Huacai Chen" <chenhuacai@...nel.org>,
 "WANG Xuerui" <git@...0n.name>,
 "Shaokun Zhang" <zhangshaokun@...ilicon.com>,
 "John Garry" <john.garry@...wei.com>,
 "Guangbin Huang" <huangguangbin2@...wei.com>,
 "Bharat Bhushan" <bbhushan2@...vell.com>,
 "Bibo Mao" <maobibo@...ngson.cn>, "Atish Patra" <atishp@...shpatra.org>,
 "Jason A . Donenfeld" <Jason@...c4.com>, "Qi Liu" <liuqi115@...wei.com>,
 "Jiaxun Yang" <jiaxun.yang@...goat.com>,
 "Catalin Marinas" <catalin.marinas@....com>,
 "Mark Brown" <broonie@...nel.org>,
 "Janosch Frank" <frankja@...ux.ibm.com>,
 "Alexey Dobriyan" <adobriyan@...il.com>
Cc: "Benjamin Mugnier" <mugnier.benjamin@...il.com>,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, linux-mm@...ck.org,
 Linux-Arch <linux-arch@...r.kernel.org>, linux-audit@...hat.com,
 linux-riscv@...ts.infradead.org, bpf@...r.kernel.org
Subject: Re: [RFC PATCH v2 30/31] kvx: Add power controller driver

On Mon, Apr 15, 2024, at 16:08, Yann Sionneau wrote:
> On 1/22/23 12:54, Krzysztof Kozlowski wrote:
>> On 20/01/2023 15:10, Yann Sionneau wrote:
>>> From: Jules Maselbas <jmaselbas@...ray.eu>
>>>
>>> The Power Controller (pwr-ctrl) control cores reset and wake-up
>>> procedure.
>>> +
>>> +int __init kvx_pwr_ctrl_probe(void)
>>> +{
>>> +	struct device_node *ctrl;
>>> +
>>> +	ctrl = get_pwr_ctrl_node();
>>> +	if (!ctrl) {
>>> +		pr_err("Failed to get power controller node\n");
>>> +		return -EINVAL;
>>> +	}
>>> +
>>> +	if (!of_device_is_compatible(ctrl, "kalray,kvx-pwr-ctrl")) {
>>> +		pr_err("Failed to get power controller node\n");
>> No. Drivers go to drivers, not to arch directory. This should be a
>> proper driver instead of some fake stub doing its own driver matching.
>> You need to rework this.
>
> I am working on a v3 patchset, therefore I am working on a solution for 
> this "pwr-ctrl" driver that needs to go somewhere else than arch/kvx/.
>
> The purpose of this "driver" is just to expose a void 
> kvx_pwr_ctrl_cpu_poweron(unsigned int cpu) function, used by 
> kernel/smpboot.c function __cpu_up() in order to start secondary CPUs in 
> SMP config.
>
> Doing this, on our SoC, requires writing 3 registers in a memory-mapped 
> device named "power controller".
>
> I made some researches in drivers/ but I am not sure yet what's a good 
> place that fits what our device is doing (booting secondary CPUs).
>
> * drivers/power/reset seems to be for resetting the entire SoC
>
> * drivers/power/supply seems to be to control power supplies ICs/periph.
>
> * drivers/reset seems to be for device reset
>
> * drivers/pmdomain maybe ?

Right, I don't think any of the above are appropriate

> * drivers/soc ?
>
> * drivers/platform ?
>
> * drivers/misc ?

Not drivers/misc, that is mainly for things with a user-space
interface.

drivers/soc is mainly for drivers used by other drivers, but
this would work, especially if you expect to have multiple
SoC variants that all use the same architecture code but
incompatible register layouts

drivers/platform is really for things outside of the SoC
that are used for managing the system, especially across
architectures, so I don't think that is a good fit.

Traditionally we had this code in arch/{arm,mips,powerpc,sh,x86}
and we never created a drier subsystem for it since newer
targets (arm64, riscv, newer arm, most x86) all use a method
that is specified as part of the ISA or firmware interface.

The question what you expect to see with future hardware
iterations: if you think all arch/kvx/ hardware will use the
same code for maybe at least the next five years, I would
suggest you keep it in arch/kvx/kernel/smp.c, but if you
know or expect other implementations to be needed, I can
merge it as a driver through drivers/soc/.

     Arnd

Powered by blists - more mailing lists