From: Russell King - ARM Linux <linux@arm.linux.org.uk> To: Kapil Hali <kapilh@broadcom.com> Cc: Florian Fainelli <f.fainelli@gmail.com>, Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>, Mark Rutland <mark.rutland@arm.com>, Ian Campbell <ijc+devicetree@hellion.org.uk>, Kumar Gala <galak@codeaurora.org>, Ray Jui <rjui@broadcom.com>, Scott Branden <sbranden@broadcom.com>, Jon Mason <jonmason@broadcom.com>, Gregory Fong <gregory.0xf0@gmail.com>, Lee Jones <lee@kernel.org>, Hauke Mehrtens <hauke@hauke-m.de>, Kever Yang <kever.yang@rock-chips.com>, Maxime Ripard <maxime.ripard@free-electrons.com>, Olof Johansson <olof@lixom.net>, Paul Walmsley <paul@pwsan.com>, Linus Walleij <linus.walleij@linaro.org>, Chen-Yu Tsai <wens@csie.org>, 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 Date: Tue, 10 Nov 2015 16:25:53 +0000 [thread overview] Message-ID: <20151110162553.GH8644@n2100.arm.linux.org.uk> (raw) In-Reply-To: <56421540.1020303@broadcom.com> 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.
WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v3 1/4] dt-bindings: add SMP enable-method for Broadcom NSP Date: Tue, 10 Nov 2015 16:25:53 +0000 [thread overview] Message-ID: <20151110162553.GH8644@n2100.arm.linux.org.uk> (raw) In-Reply-To: <56421540.1020303@broadcom.com> 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.
next prev parent reply other threads:[~2015-11-10 16:26 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-11-06 21:11 [PATCH v3 0/4] SMP support for Broadcom NSP Kapil Hali 2015-11-06 21:11 ` Kapil Hali 2015-11-06 21:11 ` Kapil Hali 2015-11-06 21:11 ` [PATCH v3 1/4] dt-bindings: add SMP enable-method " Kapil Hali 2015-11-06 21:11 ` Kapil Hali 2015-11-06 21:11 ` Kapil Hali 2015-11-07 18:03 ` Rob Herring 2015-11-07 18:03 ` Rob Herring 2015-11-07 18:03 ` Rob Herring 2015-11-10 16:26 ` Kapil Hali 2015-11-10 16:26 ` Kapil Hali 2015-11-10 16:26 ` Kapil Hali 2015-11-07 21:40 ` Florian Fainelli 2015-11-07 21:40 ` Florian Fainelli 2015-11-08 17:31 ` Russell King - ARM Linux 2015-11-08 17:31 ` Russell King - ARM Linux 2015-11-08 19:36 ` Florian Fainelli 2015-11-08 19:36 ` Florian Fainelli 2015-11-08 19:36 ` Florian Fainelli 2015-11-10 16:03 ` Kapil Hali 2015-11-10 16:03 ` Kapil Hali 2015-11-10 16:03 ` Kapil Hali 2015-11-10 16:25 ` Russell King - ARM Linux [this message] 2015-11-10 16:25 ` Russell King - ARM Linux 2015-11-12 12:37 ` Kapil Hali 2015-11-12 12:37 ` Kapil Hali 2015-11-12 12:37 ` Kapil Hali 2015-11-10 16:07 ` Kapil Hali 2015-11-10 16:07 ` Kapil Hali 2015-11-10 16:07 ` Kapil Hali 2015-11-06 21:11 ` [PATCH v3 2/4] ARM: dts: add SMP support " Kapil Hali 2015-11-06 21:11 ` Kapil Hali 2015-11-06 21:11 ` Kapil Hali 2015-11-06 21:11 ` [PATCH v3 3/4] ARM: BCM: Add " Kapil Hali 2015-11-06 21:11 ` Kapil Hali 2015-11-06 21:11 ` Kapil Hali 2015-11-06 21:11 ` [PATCH v3 4/4] ARM: BCM: Add SMP support for Broadcom 4708 Kapil Hali 2015-11-06 21:11 ` Kapil Hali 2015-11-06 21:11 ` Kapil Hali 2015-11-06 21:42 ` Hauke Mehrtens 2015-11-06 21:42 ` Hauke Mehrtens 2015-11-06 21:42 ` Hauke Mehrtens 2015-11-06 22:54 ` Jon Mason 2015-11-06 22:54 ` Jon Mason 2015-11-06 22:54 ` Jon Mason 2015-11-06 23:27 ` Hauke Mehrtens 2015-11-06 23:27 ` Hauke Mehrtens 2015-11-06 23:27 ` Hauke Mehrtens 2015-11-06 23:41 ` Hauke Mehrtens 2015-11-06 23:41 ` Hauke Mehrtens 2015-11-09 15:29 ` Jon Mason 2015-11-09 15:29 ` Jon Mason 2015-11-09 15:29 ` Jon Mason 2015-11-06 23:16 ` Scott Branden 2015-11-06 23:16 ` Scott Branden 2015-11-06 23:16 ` Scott Branden 2015-11-06 21:26 ` [PATCH v3 0/4] SMP support for Broadcom NSP Heiko Stuebner 2015-11-06 21:26 ` Heiko Stuebner
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=20151110162553.GH8644@n2100.arm.linux.org.uk \ --to=linux@arm.linux.org.uk \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=devicetree@vger.kernel.org \ --cc=f.fainelli@gmail.com \ --cc=galak@codeaurora.org \ --cc=gregory.0xf0@gmail.com \ --cc=hauke@hauke-m.de \ --cc=ijc+devicetree@hellion.org.uk \ --cc=jonmason@broadcom.com \ --cc=kapilh@broadcom.com \ --cc=kever.yang@rock-chips.com \ --cc=lee@kernel.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maxime.ripard@free-electrons.com \ --cc=olof@lixom.net \ --cc=paul@pwsan.com \ --cc=pawel.moll@arm.com \ --cc=rjui@broadcom.com \ --cc=robh+dt@kernel.org \ --cc=sbranden@broadcom.com \ --cc=wens@csie.org \ /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.