Received: by 2002:ac0:a591:0:0:0:0:0 with SMTP id m17-v6csp543075imm; Sat, 7 Jul 2018 03:03:08 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfLoW3wb68Gp/ueJoy2UoegLHIYXImbAvxf/3NFVf5TrOD5JF7OeguAvQbrLSKw9PgkYBM6 X-Received: by 2002:a17:902:8f82:: with SMTP id z2-v6mr13348362plo.203.1530957788350; Sat, 07 Jul 2018 03:03:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530957788; cv=none; d=google.com; s=arc-20160816; b=iqPUmfC5T+7btGW26QIEYIJroxYDempBJGOCjfKrEpuQteUTxwDaEvrJIMda5waBx9 5vL034TUVLHBgMjZjacl1N28MW+LrDPBN5aLnCzYmcIIN2Z2pUrWhVFjzGH9GcZMCmK6 57B3A+v5Vmnf6Pe1dHkNoh6MDeTGDESiwEj1VU/0pCm+CiqYXdV+6B5ptodW5A0wf1gt LKVQMLNDWi+cX0YaeEK1qml6T6emVKqkWfEhrdNf8UGTgfs7mJag3qSu8Si0ERI0pwW0 6B9hIJJ5o2w0/2K48EYnM2ADYZEf76R8dYpc045+9uULZZ42yRKQkfqXlbEHVokOzMW1 CMjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=skEB0NTuceN7yWLfR1eoFmuvfHqBfRX8Wrln361LYMI=; b=CRwzJYC4Ze3FOqvAUcQmpDqpcdorA0UfBfIM4Bv1RCV7vCtLMx2DWVBVDsRJsDPg8E JBNwFA7qkI+D5khWfztW9RiZLuNd6CtV0MAuE0KbkWLIcf2zV6ZcnBNMJ54lWVoN/4kf wAzxptvGm7LFAu15+nxRoXNlBqh/7QHo3jsxgSbn52drzMzYtuUyGeWMUeeZv7cs8bKr 8wTxzLS2YHKcrnqtVWCW19SC4/c7UI3tBijI+xUPCJBXN6EbxXUbtpF6gwWQKSasDZgq brNDOg+/1I/I/mWQIZM5MDeuRWq/KJe+aXJQyB/I+aRO/U8m78BOmsnHIIALDMf5NTP8 1l2w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v6-v6si9939744plp.60.2018.07.07.03.02.54; Sat, 07 Jul 2018 03:03:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753687AbeGGKBy (ORCPT + 99 others); Sat, 7 Jul 2018 06:01:54 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:46010 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753567AbeGGKBx (ORCPT ); Sat, 7 Jul 2018 06:01:53 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E6A5680D; Sat, 7 Jul 2018 03:01:52 -0700 (PDT) Received: from why.wild-wind.fr.eu.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AF5A53F5AD; Sat, 7 Jul 2018 03:01:51 -0700 (PDT) Date: Sat, 7 Jul 2018 11:01:47 +0100 From: Marc Zyngier To: Bo Yan Cc: , , Subject: Re: [PATCH] irqchip/gic: check return value of of_address_to_resource Message-ID: <20180707110147.64905726@why.wild-wind.fr.eu.org> In-Reply-To: References: <1530814859-11610-1-git-send-email-byan@nvidia.com> <20180705201327.4a4dc7dd@why.wild-wind.fr.eu.org> <5548bdf4-4e4f-a2e1-b194-da35da87e3d3@nvidia.com> Organization: ARM Ltd X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 5 Jul 2018 12:32:22 -0700 Bo Yan wrote: > Marc, > > Sorry for the previous reply. My email settings were not correct, so it inserted those confidentiality text, which was not what I intended. > > This is what I think: > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > index ced10c4..0b60bb0 100644 > --- a/drivers/irqchip/irq-gic.c > +++ b/drivers/irqchip/irq-gic.c > @@ -1284,7 +1284,7 @@ static bool gic_check_eoimode(struct device_node *node, void __iomem **base) > { > struct resource cpuif_res; > > - of_address_to_resource(node, 1, &cpuif_res); > + (void)of_address_to_resource(node, 1, &cpuif_res); > > if (!is_hyp_mode_available()) > return false; > > We are 100% sure of_address_to_resource will succeed in this particular case, so "(void)" will help suppress Coverity warning. In all honesty. I don't see the point of patching the kernel to silence a warning when we know that this is a false positive. I'm sure you can flag that one as "false positive" in Coverity. Thanks, M. -- Without deviation from the norm, progress is not possible.