From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751914AbcGRI0n (ORCPT ); Mon, 18 Jul 2016 04:26:43 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:61415 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751437AbcGRI0l (ORCPT ); Mon, 18 Jul 2016 04:26:41 -0400 X-AuditID: cbfec7f5-f792a6d000001302-55-578c92beaf52 Message-id: <578C92BC.2070603@samsung.com> Date: Mon, 18 Jul 2016 10:26:36 +0200 From: Jacek Anaszewski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-version: 1.0 To: Sebastian Andrzej Siewior 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 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> <20160715141026.GA16938@linutronix.de> In-reply-to: <20160715141026.GA16938@linutronix.de> Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsVy+t/xq7r7JvWEG7Qf4bF4d2E5m8W0i5OY Lab8Wc5kcXnXHDaLrW/WMVqs/neK0eLa3uPMFhOmr2WxON57gMmit2snk8XuXU9ZLa7eOcho sXnTVGaLR31v2R34PNbMW8PosXmFlsemVZ1sHneu7WHzeHfuHLvHiRm/WTz2zP/B6vF5k5zH +i1bmQI4o7hsUlJzMstSi/TtErgyPk2VL3jLWfHgcTNTA+Nb9i5GTg4JAROJzonTGSFsMYkL 99azdTFycQgJLGWUeLVhOQuE84xRouH0XbAOXgEtiTUXb7CA2CwCqhJ939eA2WwChhI/X7xm ArFFBSIk/pzexwpRLyjxY/I9sBoRAVOJxouHwIYyC/xhlnh/9AZYg7BAgMS0Wx+gtk1ilvi5 cgXQHRwcnALGEqsvJoPUMAuYSTxqWccMYctLbF7zlnkCo8AsJDtmISmbhaRsASPzKkbR1NLk guKk9FwjveLE3OLSvHS95PzcTYyQmPq6g3HpMatDjAIcjEo8vDfWdocLsSaWFVfmHmKU4GBW EuFtaegJF+JNSaysSi3Kjy8qzUktPsQozcGiJM47c9f7ECGB9MSS1OzU1ILUIpgsEwenVANj CM83169/T/E1W/LM4q1czbt0hWLu/RLLuV1urIW9Pv8WOr6aFLw03cBo3oLCpLfCLWpGsptT p+5bprHBn9ujj7P588dAfuGdXqv5wi6qf161vmTmF4vNrE9jheMDFbda7te5zcy1gu2A507n xl3P4x5c8vs15Z+JzkL3d1stGpK/x7NMOWKmxFKckWioxVxUnAgAQidDwqUCAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sebastian, On 07/15/2016 04:10 PM, Sebastian Andrzej Siewior wrote: > * 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. From the LED subsystem perspective I don't see any particular reason for which it couldn't be accomplished from the ONLINE callbacks. -- Best regards, Jacek Anaszewski