From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752774AbcGOOLX (ORCPT ); Fri, 15 Jul 2016 10:11:23 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:47232 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752470AbcGOOLH (ORCPT ); Fri, 15 Jul 2016 10:11:07 -0400 Date: Fri, 15 Jul 2016 16:10:26 +0200 From: Sebastian Andrzej Siewior To: Jacek Anaszewski Cc: Thomas Gleixner , Peter Zijlstra , Ingo Molnar , Anna-Maria Gleixner , LKML , rt@linutronix.de, Richard Cochran , Linus Torvalds , Linus Walleij , Paul Gortmaker , Richard Purdie , linux-leds@vger.kernel.org, Pawel Moll Subject: Re: [patch V2 43/67] leds/trigger/cpu: Convert to hotplug state machine Message-ID: <20160715141026.GA16938@linutronix.de> References: <20160713153219.128052238@linutronix.de> <20160713153336.465496902@linutronix.de> <57873CFF.1010803@samsung.com> <20160714074713.GA17287@gmail.com> <5787490F.5000105@samsung.com> <20160714094154.GY30154@twins.programming.kicks-ass.net> <57877640.4020004@samsung.com> <57877DAE.8080401@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <57877DAE.8080401@samsung.com> X-Key-Id: 2A8CF5D1 X-Key-Fingerprint: 6425 4695 FFF0 AA44 66CC 19E6 7B96 E816 2A8C F5D1 User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Jacek Anaszewski | 2016-07-14 13:55:26 [+0200]: >On 07/14/2016 01:33 PM, Thomas Gleixner wrote: >>That does not explain WHY this needs to happen in the low level bringup phase >>of the CPU with interrupts disabled and can't be done from the normal ONLINE >>callbacks in thread context. > >It was before my time in kernel, so I can only suppose that it was >the easiest way. Does it introduce some problems? It was introduced by Pawel Moll in fba14ae8e924 ("ledtrig-cpu: Handle CPU hot(un)plugging"). It does not introduce any problems but those bring up / bring down levels are usually used by the core code. This does not look like it needs to be done _that_ early or late during the removal / addition of a CPU to the system. Which means this looks like it could be moved to CPU_ONLINE / CPU_DOWN_PREPARE which in turns means we could use dynamic IDs instead of those hardcoded ones since the LED subsystem does not depend on other components. Sebastian