Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754461AbbKJQ0b (ORCPT ); Tue, 10 Nov 2015 11:26:31 -0500 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:46148 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754456AbbKJQ02 (ORCPT ); Tue, 10 Nov 2015 11:26:28 -0500 Date: Tue, 10 Nov 2015 16:25:53 +0000 From: Russell King - ARM Linux To: Kapil Hali Cc: Florian Fainelli , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Ray Jui , Scott Branden , Jon Mason , Gregory Fong , Lee Jones , Hauke Mehrtens , Kever Yang , Maxime Ripard , Olof Johansson , Paul Walmsley , Linus Walleij , Chen-Yu Tsai , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com Subject: Re: [PATCH v3 1/4] dt-bindings: add SMP enable-method for Broadcom NSP Message-ID: <20151110162553.GH8644@n2100.arm.linux.org.uk> References: <1446844273-6460-1-git-send-email-kapilh@broadcom.com> <1446844273-6460-2-git-send-email-kapilh@broadcom.com> <563E6FC7.6070700@gmail.com> <20151108173116.GV8644@n2100.arm.linux.org.uk> <56421540.1020303@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56421540.1020303@broadcom.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3216 Lines: 65 On Tue, Nov 10, 2015 at 09:33:12PM +0530, Kapil Hali wrote: > Hi Russel, Wrong. Look at my name as sent in the From: and as quoted in the very next line. As far as I'm concerned (and I don't care what other people say) it's disrespectful to spell people's names incorrectly. > It was clear the very first time itself as pointed out by you and the > lead developers and hence the change was readily sent in the very next > patch set. I didn't change a comment in this patch, which is misleading > about the SMP enable-method used in the patch set, it is my mistake and > I apologies for the same. I will change it and send the next patch set. Thanks. > Also, before sending out the patch set, I had asked for a clarification > about the method: https://lkml.org/lkml/2015/11/6/234 Sorry, I don't read every single email irrespective of how it's marked. There's way too much email, and way too much mail with improperly classified recipient lists to be able to usefully sort this mail. (If you do the math, the email rate during a 12 hour working day from just linux-arm-kernel is one email every 2.5 minutes, assuming 300 emails a day. It takes way longer than that to compose a proper reply to an email - I've spent around 15 minutes on this one alone. Hence, if I'm busy, I more or less totally ignore email now, and rarely bother to "catch up" with missed emails.) > For my understanding, I am repeating my query- In case of simple method of > waking up secondary core, smp_boot_secondary() will always return success > indicating secondary core successfully started. I understand that in > __cpu_up(), primary core waits for completion till secondary core comes > online or time outs. However, is it appropriate to return successful start > of secondary core without knowing if it really did? Yes, because all that your smp_boot_secondary() should be doing is trying to start the core. If you encounter an error trying to do so, that's what the error return is for. If you just set a bit somewhere to tell the hardware to release the secondary core's reset, then if you set the bit and return success, that's prefectly acceptable. The core ARM SMP code will then wait up to one second for the secondary core to become known to the kernel before declaring that the CPU failed to come online. If it fails to appear, we assume that it will never appear - and actually at that point the system is in an unknown state: if the secondary CPU crashed during its boot, it could start scribbling into memory or touching devices in an unpredictable way: the only sane answer is to reboot the whole system to ensure that it's back to a known good state. Hence why we don't provide any cleanup at the point of a failed secondary CPU (I've been debating about tainting the kernel at that point, so we know when things have gone bad.) Hope this helps. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/