From: "Arnd Bergmann" <arnd@arndb.de> To: "Yann Sionneau" <ysionneau@kalrayinc.com>, "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>, "Yann Sionneau" <ysionneau@kalray.eu>, "Jonathan Corbet" <corbet@lwn.net>, "Thomas Gleixner" <tglx@linutronix.de>, "Marc Zyngier" <maz@kernel.org>, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Will Deacon" <will@kernel.org>, "Peter Zijlstra" <peterz@infradead.org>, "Boqun Feng" <boqun.feng@gmail.com>, "Mark Rutland" <mark.rutland@arm.com>, "Eric W. Biederman" <ebiederm@xmission.com>, "Kees Cook" <keescook@chromium.org>, "Oleg Nesterov" <oleg@redhat.com>, "Ingo Molnar" <mingo@redhat.com>, "Waiman Long" <longman@redhat.com>, "Aneesh Kumar" <aneesh.kumar@linux.ibm.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Nicholas Piggin" <npiggin@gmail.com>, "Paul Moore" <paul@paul-moore.com>, "Eric Paris" <eparis@redhat.com>, "Christian Brauner" <brauner@kernel.org>, "Paul Walmsley" <paul.walmsley@sifive.com>, "Palmer Dabbelt" <palmer@dabbelt.com>, "Albert Ou" <aou@eecs.berkeley.edu>, "Jules Maselbas" <jmaselbas@kalray.eu>, "Guillaume Thouvenin" <gthouvenin@kalray.eu>, "Clement Leger" <clement@clement-leger.fr>, "Vincent Chardon" <vincent.chardon@elsys-design.com>, "Marc Poulhiès" <dkm@kataplop.net>, "Julian Vetter" <jvetter@kalray.eu>, "Samuel Jones" <sjones@kalray.eu>, "Ashley Lesdalons" <alesdalons@kalray.eu>, "Thomas Costis" <tcostis@kalray.eu>, "Marius Gligor" <mgligor@kalray.eu>, "Jonathan Borne" <jborne@kalray.eu>, "Julien Villette" <jvillette@kalray.eu>, "Luc Michel" <lmichel@kalray.eu>, "Louis Morhet" <lmorhet@kalray.eu>, "Julien Hascoet" <jhascoet@kalray.eu>, "Jean-Christophe Pince" <jcpince@gmail.com>, "Guillaume Missonnier" <gmissonnier@kalray.eu>, "Alex Michon" <amichon@kalray.eu>, "Huacai Chen" <chenhuacai@kernel.org>, "WANG Xuerui" <git@xen0n.name>, "Shaokun Zhang" <zhangshaokun@hisilicon.com>, "John Garry" <john.garry@huawei.com>, "Guangbin Huang" <huangguangbin2@huawei.com>, "Bharat Bhushan" <bbhushan2@marvell.com>, "Bibo Mao" <maobibo@loongson.cn>, "Atish Patra" <atishp@atishpatra.org>, "Jason A . Donenfeld" <Jason@zx2c4.com>, "Qi Liu" <liuqi115@huawei.com>, "Jiaxun Yang" <jiaxun.yang@flygoat.com>, "Catalin Marinas" <catalin.marinas@arm.com>, "Mark Brown" <broonie@kernel.org>, "Janosch Frank" <frankja@linux.ibm.com>, "Alexey Dobriyan" <adobriyan@gmail.com> Cc: "Benjamin Mugnier" <mugnier.benjamin@gmail.com>, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-mm@kvack.org, Linux-Arch <linux-arch@vger.kernel.org>, linux-audit@redhat.com, linux-riscv@lists.infradead.org, bpf@vger.kernel.org Subject: Re: [RFC PATCH v2 30/31] kvx: Add power controller driver Date: Mon, 15 Apr 2024 17:30:31 +0200 [thread overview] Message-ID: <61d0584f-dfe4-4d8c-a178-78f000d477d4@app.fastmail.com> (raw) In-Reply-To: <c20b433f-97ef-7faa-5122-9949af41f2fb@kalrayinc.com> 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@kalray.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
WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de> To: "Yann Sionneau" <ysionneau@kalrayinc.com>, "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>, "Yann Sionneau" <ysionneau@kalray.eu>, "Jonathan Corbet" <corbet@lwn.net>, "Thomas Gleixner" <tglx@linutronix.de>, "Marc Zyngier" <maz@kernel.org>, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Will Deacon" <will@kernel.org>, "Peter Zijlstra" <peterz@infradead.org>, "Boqun Feng" <boqun.feng@gmail.com>, "Mark Rutland" <mark.rutland@arm.com>, "Eric W. Biederman" <ebiederm@xmission.com>, "Kees Cook" <keescook@chromium.org>, "Oleg Nesterov" <oleg@redhat.com>, "Ingo Molnar" <mingo@redhat.com>, "Waiman Long" <longman@redhat.com>, "Aneesh Kumar" <aneesh.kumar@linux.ibm.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Nicholas Piggin" <npiggin@gmail.com>, "Paul Moore" <paul@paul-moore.com>, "Eric Paris" <eparis@redhat.com>, "Christian Brauner" <brauner@kernel.org>, "Paul Walmsley" <paul.walmsley@sifive.com>, "Palmer Dabbelt" <palmer@dabbelt.com>, "Albert Ou" <aou@eecs.berkeley.edu>, "Jules Maselbas" <jmaselbas@kalray.eu>, "Guillaume Thouvenin" <gthouvenin@kalray.eu>, "Clement Leger" <clement@clement-leger.fr>, "Vincent Chardon" <vincent.chardon@elsys-design.com>, "Marc Poulhiès" <dkm@kataplop.net>, "Julian Vetter" <jvetter@kalray.eu>, "Samuel Jones" <sjones@kalray.eu>, "Ashley Lesdalons" <alesdalons@kalray.eu>, "Thomas Costis" <tcostis@kalray.eu>, "Marius Gligor" <mgligor@kalray.eu>, "Jonathan Borne" <jborne@kalray.eu>, "Julien Villette" <jvillette@kalray.eu>, "Luc Michel" <lmichel@kalray.eu>, "Louis Morhet" <lmorhet@kalray.eu>, "Julien Hascoet" <jhascoet@kalray.eu>, "Jean-Christophe Pince" <jcpince@gmail.com>, "Guillaume Missonnier" <gmissonnier@kalray.eu>, "Alex Michon" <amichon@kalray.eu>, "Huacai Chen" <chenhuacai@kernel.org>, "WANG Xuerui" <git@xen0n.name>, "Shaokun Zhang" <zhangshaokun@hisilicon.com>, "John Garry" <john.garry@huawei.com>, "Guangbin Huang" <huangguangbin2@huawei.com>, "Bharat Bhushan" <bbhushan2@marvell.com>, "Bibo Mao" <maobibo@loongson.cn>, "Atish Patra" <atishp@atishpatra.org>, "Jason A . Donenfeld" <Jason@zx2c4.com>, "Qi Liu" <liuqi115@huawei.com>, "Jiaxun Yang" <jiaxun.yang@flygoat.com>, "Catalin Marinas" <catalin.marinas@arm.com>, "Mark Brown" <broonie@kernel.org>, "Janosch Frank" <frankja@linux.ibm.com>, "Alexey Dobriyan" <adobriyan@gmail.com> Cc: "Benjamin Mugnier" <mugnier.benjamin@gmail.com>, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-mm@kvack.org, Linux-Arch <linux-arch@vger.kernel.org>, linux-audit@redhat.com, linux-riscv@lists.infradead.org, bpf@vger.kernel.org Subject: Re: [RFC PATCH v2 30/31] kvx: Add power controller driver Date: Mon, 15 Apr 2024 17:30:31 +0200 [thread overview] Message-ID: <61d0584f-dfe4-4d8c-a178-78f000d477d4@app.fastmail.com> (raw) In-Reply-To: <c20b433f-97ef-7faa-5122-9949af41f2fb@kalrayinc.com> 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@kalray.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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-04-15 15:30 UTC|newest] Thread overview: 201+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-20 14:09 [RFC PATCH v2 00/31] Upstream kvx Linux port Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 01/31] Documentation: kvx: Add basic documentation Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-22 9:02 ` Bagas Sanjaya 2023-01-22 9:02 ` Bagas Sanjaya 2023-01-22 9:02 ` Bagas Sanjaya 2023-01-25 18:28 ` Jules Maselbas 2023-01-25 18:28 ` Jules Maselbas 2023-01-25 18:28 ` Jules Maselbas 2023-01-26 2:23 ` Bagas Sanjaya 2023-01-26 2:23 ` Bagas Sanjaya 2023-01-26 2:23 ` Bagas Sanjaya 2023-01-22 15:02 ` Mike Rapoport 2023-01-22 15:02 ` Mike Rapoport 2023-01-22 15:02 ` Mike Rapoport 2023-01-20 14:09 ` [RFC PATCH v2 02/31] Documentation: Add binding for kalray,kv3-1-core-intc Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 17:28 ` Rob Herring 2023-01-20 17:28 ` Rob Herring 2023-01-20 17:28 ` Rob Herring 2023-01-22 11:44 ` Krzysztof Kozlowski 2023-01-22 11:44 ` Krzysztof Kozlowski 2023-01-22 11:44 ` Krzysztof Kozlowski 2023-01-26 16:10 ` Jules Maselbas 2023-01-26 16:10 ` Jules Maselbas 2023-01-26 16:10 ` Jules Maselbas 2023-01-27 8:32 ` Krzysztof Kozlowski 2023-01-27 8:32 ` Krzysztof Kozlowski 2023-01-27 8:32 ` Krzysztof Kozlowski 2023-01-20 14:09 ` [RFC PATCH v2 03/31] Documentation: Add binding for kalray,kv3-1-apic-gic Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-22 11:47 ` Krzysztof Kozlowski 2023-01-22 11:47 ` Krzysztof Kozlowski 2023-01-22 11:47 ` Krzysztof Kozlowski 2023-01-20 14:09 ` [RFC PATCH v2 04/31] Documentation: Add binding for kalray,kv3-1-apic-mailbox Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 17:28 ` Rob Herring 2023-01-20 17:28 ` Rob Herring 2023-01-20 17:28 ` Rob Herring 2023-01-20 14:09 ` [RFC PATCH v2 05/31] Documentation: Add binding for kalray,coolidge-itgen Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-22 11:49 ` Krzysztof Kozlowski 2023-01-22 11:49 ` Krzysztof Kozlowski 2023-01-22 11:49 ` Krzysztof Kozlowski 2023-01-20 14:09 ` [RFC PATCH v2 06/31] Documentation: Add binding for kalray,kv3-1-ipi-ctrl Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 17:28 ` Rob Herring 2023-01-20 17:28 ` [RFC PATCH v2 06/31] Documentation: Add binding for kalray, kv3-1-ipi-ctrl Rob Herring 2023-01-20 17:28 ` [RFC PATCH v2 06/31] Documentation: Add binding for kalray,kv3-1-ipi-ctrl Rob Herring 2023-01-22 11:50 ` Krzysztof Kozlowski 2023-01-22 11:50 ` Krzysztof Kozlowski 2023-01-22 11:50 ` Krzysztof Kozlowski 2023-01-20 14:09 ` [RFC PATCH v2 07/31] Documentation: Add binding for kalray,kv3-1-pwr-ctrl Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 17:28 ` Rob Herring 2023-01-20 17:28 ` [RFC PATCH v2 07/31] Documentation: Add binding for kalray, kv3-1-pwr-ctrl Rob Herring 2023-01-20 17:28 ` [RFC PATCH v2 07/31] Documentation: Add binding for kalray,kv3-1-pwr-ctrl Rob Herring 2023-01-22 11:51 ` Krzysztof Kozlowski 2023-01-22 11:51 ` Krzysztof Kozlowski 2023-01-22 11:51 ` Krzysztof Kozlowski 2023-01-20 14:09 ` [RFC PATCH v2 08/31] kvx: Add ELF-related definitions Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 09/31] kvx: Add build infrastructure Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:39 ` Arnd Bergmann 2023-01-20 14:39 ` Arnd Bergmann 2023-01-20 14:39 ` Arnd Bergmann 2023-01-20 14:53 ` Jules Maselbas 2023-01-20 14:53 ` Jules Maselbas 2023-01-20 14:53 ` Jules Maselbas 2023-01-20 15:01 ` Arnd Bergmann 2023-01-20 15:01 ` Arnd Bergmann 2023-01-20 15:01 ` Arnd Bergmann 2023-01-20 15:03 ` Jules Maselbas 2023-01-20 15:03 ` Jules Maselbas 2023-01-20 15:03 ` Jules Maselbas 2023-01-20 14:09 ` [RFC PATCH v2 10/31] kvx: Add CPU definition headers Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 11/31] kvx: Add atomic/locking headers Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 15:18 ` Mark Rutland 2023-01-20 15:18 ` Mark Rutland 2023-01-20 15:18 ` Mark Rutland 2023-01-26 9:57 ` Jules Maselbas 2023-01-26 9:57 ` Jules Maselbas 2023-01-26 9:57 ` Jules Maselbas 2023-01-26 11:15 ` Mark Rutland 2023-01-26 11:15 ` Mark Rutland 2023-01-26 11:15 ` Mark Rutland 2023-01-26 11:19 ` Jules Maselbas 2023-01-26 11:19 ` Jules Maselbas 2023-01-26 11:19 ` Jules Maselbas 2023-01-29 11:50 ` Guo Ren 2023-01-29 11:50 ` Guo Ren 2023-01-29 11:50 ` Guo Ren 2023-01-20 14:09 ` [RFC PATCH v2 12/31] kvx: Add other common headers Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:29 ` Jason A. Donenfeld 2023-01-20 14:29 ` Jason A. Donenfeld 2023-01-20 14:29 ` Jason A. Donenfeld 2023-01-25 21:55 ` Jules Maselbas 2023-01-25 21:55 ` Jules Maselbas 2023-01-25 21:55 ` Jules Maselbas 2023-01-20 14:09 ` [RFC PATCH v2 13/31] kvx: Add boot and setup routines Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 14/31] kvx: Add exception/interrupt handling Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 15/31] irqchip: Add irq-kvx-apic-gic driver Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 16/31] irqchip: Add irq-kvx-itgen driver Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 17/31] irqchip: Add irq-kvx-apic-mailbox driver Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 18/31] irqchip: Add kvx-core-intc core interupt controller driver Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 19/31] kvx: Add process management Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 20/31] kvx: Add memory management Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-22 16:09 ` Mike Rapoport 2023-01-22 16:09 ` Mike Rapoport 2023-01-22 16:09 ` Mike Rapoport 2023-01-20 14:09 ` [RFC PATCH v2 21/31] kvx: Add system call support Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 22/31] kvx: Add signal handling support Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 23/31] kvx: Add ELF relocations and module support Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 24/31] kvx: Add misc common routines Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 25/31] kvx: Add some library functions Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 26/31] kvx: Add multi-processor (SMP) support Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` [RFC PATCH v2 27/31] kvx: Add kvx default config file Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-22 11:58 ` Krzysztof Kozlowski 2023-01-22 11:58 ` Krzysztof Kozlowski 2023-01-22 11:58 ` Krzysztof Kozlowski 2023-01-20 14:09 ` [RFC PATCH v2 28/31] kvx: Add debugging related support Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:09 ` Yann Sionneau 2023-01-20 14:10 ` [RFC PATCH v2 29/31] kvx: Add support for cpuinfo Yann Sionneau 2023-01-20 14:10 ` Yann Sionneau 2023-01-20 14:10 ` Yann Sionneau 2023-01-22 11:57 ` Krzysztof Kozlowski 2023-01-22 11:57 ` Krzysztof Kozlowski 2023-01-22 11:57 ` Krzysztof Kozlowski 2023-01-20 14:10 ` [RFC PATCH v2 30/31] kvx: Add power controller driver Yann Sionneau 2023-01-20 14:10 ` Yann Sionneau 2023-01-20 14:10 ` Yann Sionneau 2023-01-22 11:54 ` Krzysztof Kozlowski 2023-01-22 11:54 ` Krzysztof Kozlowski 2023-01-22 11:54 ` Krzysztof Kozlowski 2024-04-15 14:08 ` Yann Sionneau 2024-04-15 14:08 ` Yann Sionneau 2024-04-15 15:30 ` Arnd Bergmann [this message] 2024-04-15 15:30 ` Arnd Bergmann 2024-04-17 19:20 ` Krzysztof Kozlowski 2024-04-17 19:20 ` Krzysztof Kozlowski 2023-01-20 14:10 ` [RFC PATCH v2 31/31] kvx: Add IPI driver Yann Sionneau 2023-01-20 14:10 ` Yann Sionneau 2023-01-20 14:10 ` Yann Sionneau 2023-01-22 11:54 ` Krzysztof Kozlowski 2023-01-22 11:54 ` Krzysztof Kozlowski 2023-01-22 11:54 ` Krzysztof Kozlowski 2024-01-31 9:52 ` Yann Sionneau 2024-01-31 9:52 ` Yann Sionneau 2024-01-31 10:12 ` Krzysztof Kozlowski 2024-01-31 10:12 ` Krzysztof Kozlowski 2024-01-31 10:28 ` Arnd Bergmann 2024-01-31 10:28 ` Arnd Bergmann
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=61d0584f-dfe4-4d8c-a178-78f000d477d4@app.fastmail.com \ --to=arnd@arndb.de \ --cc=Jason@zx2c4.com \ --cc=adobriyan@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=alesdalons@kalray.eu \ --cc=amichon@kalray.eu \ --cc=aneesh.kumar@linux.ibm.com \ --cc=aou@eecs.berkeley.edu \ --cc=atishp@atishpatra.org \ --cc=bbhushan2@marvell.com \ --cc=boqun.feng@gmail.com \ --cc=bpf@vger.kernel.org \ --cc=brauner@kernel.org \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=chenhuacai@kernel.org \ --cc=clement@clement-leger.fr \ --cc=corbet@lwn.net \ --cc=devicetree@vger.kernel.org \ --cc=dkm@kataplop.net \ --cc=ebiederm@xmission.com \ --cc=eparis@redhat.com \ --cc=frankja@linux.ibm.com \ --cc=git@xen0n.name \ --cc=gmissonnier@kalray.eu \ --cc=gthouvenin@kalray.eu \ --cc=huangguangbin2@huawei.com \ --cc=jborne@kalray.eu \ --cc=jcpince@gmail.com \ --cc=jhascoet@kalray.eu \ --cc=jiaxun.yang@flygoat.com \ --cc=jmaselbas@kalray.eu \ --cc=john.garry@huawei.com \ --cc=jvetter@kalray.eu \ --cc=jvillette@kalray.eu \ --cc=keescook@chromium.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=krzysztof.kozlowski@linaro.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-audit@redhat.com \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-riscv@lists.infradead.org \ --cc=liuqi115@huawei.com \ --cc=lmichel@kalray.eu \ --cc=lmorhet@kalray.eu \ --cc=longman@redhat.com \ --cc=maobibo@loongson.cn \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=mgligor@kalray.eu \ --cc=mingo@redhat.com \ --cc=mugnier.benjamin@gmail.com \ --cc=npiggin@gmail.com \ --cc=oleg@redhat.com \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=paul@paul-moore.com \ --cc=peterz@infradead.org \ --cc=robh+dt@kernel.org \ --cc=sjones@kalray.eu \ --cc=tcostis@kalray.eu \ --cc=tglx@linutronix.de \ --cc=vincent.chardon@elsys-design.com \ --cc=will@kernel.org \ --cc=ysionneau@kalray.eu \ --cc=ysionneau@kalrayinc.com \ --cc=zhangshaokun@hisilicon.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.