Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754248AbbKCLPS (ORCPT ); Tue, 3 Nov 2015 06:15:18 -0500 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:56437 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753284AbbKCLPL (ORCPT ); Tue, 3 Nov 2015 06:15:11 -0500 Date: Tue, 3 Nov 2015 11:14:37 +0000 From: Russell King - ARM Linux To: Caesar Wang Cc: Heiko Stuebner , hl@rock-chips.com, sjg@chromium.org, Jonathan Stone , dianders@chromium.org, linux-rockchip@lists.infradead.org, cwz@rock-chips.com, Ard Biesheuvel , Gregory CLEMENT , Stephen Boyd , linux-kernel@vger.kernel.org, Huang Tao , Thomas Petazzoni , Nadav Haklai , linux-arm-kernel@lists.infradead.org Subject: Re: [RESEND PATCH 0/1] Fix the "hard LOCKUP" when running a heavy loading Message-ID: <20151103111437.GU8644@n2100.arm.linux.org.uk> References: <1446538209-13490-1-git-send-email-wxt@rock-chips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1446538209-13490-1-git-send-email-wxt@rock-chips.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: 1433 Lines: 33 On Tue, Nov 03, 2015 at 04:10:08PM +0800, Caesar Wang wrote: > As the Russell said: > "in other words, which can be handled by updating a control register in > the firmware or boot loader" > Maybe the better solution is in firmware. The full quote is: "I think we're at the point where we start insisting that workarounds which are simple enable/disable feature bit operations (in other words, which can be handled by updating a control register in the firmware or boot loader) must be done that way, and we are not going to add such workarounds to the kernel anymore." The position hasn't changed. Workarounds such as this should be handled in the firmware/boot loader before control is passed to the kernel. The reason is very simple: if the C compiler can generate code which triggers the bug, it can generate code which triggers the bug in the boot loader. So, the only place such workarounds can be done is before any C code gets executed. Putting such workarounds in the kernel is completely inappropriate. Sorry, I'm not going to accept this workaround into the kernel. -- 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/