From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54E8FC433DF for ; Thu, 21 May 2020 10:14:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F2284207D3 for ; Thu, 21 May 2020 10:14:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="WABF7N4a" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728218AbgEUKOh (ORCPT ); Thu, 21 May 2020 06:14:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726871AbgEUKOg (ORCPT ); Thu, 21 May 2020 06:14:36 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8695C061A0E for ; Thu, 21 May 2020 03:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nVvJE8f1XxadM3r7X+mk11otqfh8Bv87wWgbGlu9ktw=; b=WABF7N4aMaOXWI7ApaPItftPt wpbZ/eOeCoz0ddFnEoR8gUtBRadfwNGTWP6j8+iMnJvBTs2il5Z6/BiWHF9vjV9IIMyK+yWcC9VpU skNyREoyOT1/by11c05/1EDbfF3foZ8CwpEPS+jbtBlpiI1WWjObUuJGYz9BASIvlZwgXXF3b9AmM gmwojpyL0OMblzBr6UqsgA43PvtfHB0LBqHYTBI2JKVOeQxDuOKHYMfJdn2o4avhfj9kng0fwM4Aa 35sIUimvJyGxeXSfVpNnEEoTqVINeCyAmMhnfTEQzzM8AJ8qHDtKEKjf52UasiS+tGEvxxXvm+EvT p/y9/FZ1w==; Received: from shell.armlinux.org.uk ([2002:4e20:1eda:1:5054:ff:fe00:4ec]:60806) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbiDZ-0002A2-L8; Thu, 21 May 2020 11:14:25 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jbiDW-00006u-Vn; Thu, 21 May 2020 11:14:23 +0100 Date: Thu, 21 May 2020 11:14:22 +0100 From: Russell King - ARM Linux admin To: Arnd Bergmann Cc: Sudeep Holla , Mark Rutland , Lorenzo Pieralisi , Catalin Marinas , "linux-kernel@vger.kernel.org" , Steven Price , harb@amperecomputing.com, Will Deacon , Linux ARM Subject: Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support Message-ID: <20200521101422.GO1551@shell.armlinux.org.uk> References: <20200518091222.27467-1-sudeep.holla@arm.com> <158999823818.135150.13263761266508812198.b4-ty@kernel.org> <20200521070629.GB1131@bogus> <20200521075755.GA4668@willie-the-truck> <20200521081055.GD1131@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote: > Note that the warning should come up for either W=1 or C=1, and I also > think that > new code should generally be written sparse-clean and have no warnings with > 'make C=1' as a rule. No, absolutely not, that's a stupid idea, there are corner cases where hiding a sparse warning is the wrong thing to do. Look at many of the cases in fs/ for example. See https://lkml.org/lkml/2004/9/12/249 which should make anyone who sees a use of __force in some random code stop and question why it is there, and whether it is actually correct, or just there to hide a sparse warning. Remember, sparse is there to warn that something isn't quite right, and the view taken is, if it isn't right, then we don't "cast the warning away" with __force, even if we intend not to fix the code immediately. So, going for "sparse-clean" is actually not correct. Going for "no unnecessary warnings" is. And don't think what I've said above doesn't happen; I've rejected patches from people who've gone around trying to fix every sparse warning that they see by throwing __force incorrectly at it. The thing is, if you hide all the warnings, even for incorrect code, then sparse becomes completely useless to identify where things in the code are not quite correct. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C612EC433E0 for ; Thu, 21 May 2020 10:15:04 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 77BF92072C for ; Thu, 21 May 2020 10:15:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="YBIsofJn"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="WABF7N4a" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 77BF92072C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XmcWX2iIwrYS+QuE4A4IF1K9T5dFIMQHqaqgivfrsFo=; b=YBIsofJnzYAkUf SBqVHe9ePBKdICdJXPFpdbnnAGTJJlBR4Qj+T4kfdW2tWXUNjGiMorO4nkuNSLCBYAqJ3buSTeSt4 OMHsjrYIT/IP5WcxHKqQlZAoz1ECJBwIJBkBgGySQjsym9s9WBjXywdrWrGFXCcZxFiyyygm1pPam 75HEY5sVD29hHop+nLyVzJP+lHwny/tcOexjzm7fWh7OlFhfYZuEaQPLDLqqRCFNQJo/8QXRWg922 0lHIvvymIrtRbXc2jQpWFDV4t/pPLknzFIWVmRjAaodTSqD+3XyLd9EL1TcXGVqsynaDbOcAQfy1m hV+xL41OyPI2qTCJ+LiA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jbiEB-0000FR-PD; Thu, 21 May 2020 10:15:03 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jbiE6-0008Qn-0R for linux-arm-kernel@lists.infradead.org; Thu, 21 May 2020 10:14:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nVvJE8f1XxadM3r7X+mk11otqfh8Bv87wWgbGlu9ktw=; b=WABF7N4aMaOXWI7ApaPItftPt wpbZ/eOeCoz0ddFnEoR8gUtBRadfwNGTWP6j8+iMnJvBTs2il5Z6/BiWHF9vjV9IIMyK+yWcC9VpU skNyREoyOT1/by11c05/1EDbfF3foZ8CwpEPS+jbtBlpiI1WWjObUuJGYz9BASIvlZwgXXF3b9AmM gmwojpyL0OMblzBr6UqsgA43PvtfHB0LBqHYTBI2JKVOeQxDuOKHYMfJdn2o4avhfj9kng0fwM4Aa 35sIUimvJyGxeXSfVpNnEEoTqVINeCyAmMhnfTEQzzM8AJ8qHDtKEKjf52UasiS+tGEvxxXvm+EvT p/y9/FZ1w==; Received: from shell.armlinux.org.uk ([2002:4e20:1eda:1:5054:ff:fe00:4ec]:60806) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbiDZ-0002A2-L8; Thu, 21 May 2020 11:14:25 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jbiDW-00006u-Vn; Thu, 21 May 2020 11:14:23 +0100 Date: Thu, 21 May 2020 11:14:22 +0100 From: Russell King - ARM Linux admin To: Arnd Bergmann Subject: Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support Message-ID: <20200521101422.GO1551@shell.armlinux.org.uk> References: <20200518091222.27467-1-sudeep.holla@arm.com> <158999823818.135150.13263761266508812198.b4-ty@kernel.org> <20200521070629.GB1131@bogus> <20200521075755.GA4668@willie-the-truck> <20200521081055.GD1131@bogus> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200521_031458_058309_1968388A X-CRM114-Status: GOOD ( 12.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Lorenzo Pieralisi , Catalin Marinas , "linux-kernel@vger.kernel.org" , Steven Price , harb@amperecomputing.com, Sudeep Holla , Will Deacon , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote: > Note that the warning should come up for either W=1 or C=1, and I also > think that > new code should generally be written sparse-clean and have no warnings with > 'make C=1' as a rule. No, absolutely not, that's a stupid idea, there are corner cases where hiding a sparse warning is the wrong thing to do. Look at many of the cases in fs/ for example. See https://lkml.org/lkml/2004/9/12/249 which should make anyone who sees a use of __force in some random code stop and question why it is there, and whether it is actually correct, or just there to hide a sparse warning. Remember, sparse is there to warn that something isn't quite right, and the view taken is, if it isn't right, then we don't "cast the warning away" with __force, even if we intend not to fix the code immediately. So, going for "sparse-clean" is actually not correct. Going for "no unnecessary warnings" is. And don't think what I've said above doesn't happen; I've rejected patches from people who've gone around trying to fix every sparse warning that they see by throwing __force incorrectly at it. The thing is, if you hide all the warnings, even for incorrect code, then sparse becomes completely useless to identify where things in the code are not quite correct. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel