From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756936AbcIGO1T (ORCPT ); Wed, 7 Sep 2016 10:27:19 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:39904 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751810AbcIGO1R (ORCPT ); Wed, 7 Sep 2016 10:27:17 -0400 Date: Wed, 7 Sep 2016 16:27:12 +0200 From: Sebastian Andrzej Siewior To: Matt Redfearn Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , rt@linutronix.de, tglx@linutronix.de, Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH 15/21] mips: octeon: smp: Convert to hotplug state machine Message-ID: <20160907142712.rr34s2c6xiwcrjaz@linutronix.de> References: <20160906170457.32393-1-bigeasy@linutronix.de> <20160906170457.32393-16-bigeasy@linutronix.de> <6ef2674b-aca6-f45f-03b2-ec9aa9a5bf91@imgtec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6ef2674b-aca6-f45f-03b2-ec9aa9a5bf91@imgtec.com> User-Agent: NeoMutt/ (1.7.0) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-09-07 09:24:57 [+0100], Matt Redfearn wrote: > HI Sebastian, Hi Matt, > > --- a/include/linux/cpuhotplug.h > > +++ b/include/linux/cpuhotplug.h > > @@ -44,6 +44,7 @@ enum cpuhp_state { > > CPUHP_SH_SH3X_PREPARE, > > CPUHP_X86_MICRCODE_PREPARE, > > CPUHP_NOTF_ERR_INJ_PREPARE, > > + CPUHP_MIPS_CAVIUM_PREPARE, > > But I'm curious why we have to create a new state here - this is going to > get very unwieldy if every variant of every architecture has to have it's > own state values in that enumeration. Can this use, what I assume is (and > perhaps could be documented better in include/linux/cpuhotplug.h), the > generic prepare state CPUHP_NOTIFY_PREPARE? We can't share the states - one state is for one callback and one callback only. If you want CPUHP_MIPS_PREPARE and you ensure that this used only _once_ then this can be arranged. For online states we have dynamic allocation of ids (which is what most drivers should use). We don't have this of STARTING + PREPARE callbacks. > Thanks, > Matt > Sebastian