Received: by 2002:ac0:a679:0:0:0:0:0 with SMTP id p54csp37631imp; Wed, 20 Feb 2019 13:44:26 -0800 (PST) X-Google-Smtp-Source: AHgI3IaTepEIK3MlD7plFWN4p+PDelbDIFK6tzTGwmyQ4wo5/eUJp5c/f1p0F+VmtDNCLeqtu7Zf X-Received: by 2002:a65:5c01:: with SMTP id u1mr9343560pgr.197.1550699066193; Wed, 20 Feb 2019 13:44:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550699066; cv=none; d=google.com; s=arc-20160816; b=WHqgYy4ZfPLTx5PALG0z8vMnROl5MSvYCOoxLBps0gFSSfQQ6bjSe80jN8qqshw4vW eKlZ8F/Y4hldGeXSRHuR0K6EsLT8Nf9W8nH71Fzkw+1hl0bvA8+gPnWuVQIRKAN0hB8j 9M7cQrU5o57xUGacekqihL0T5ptTEUDusjd/iEE7y8JXEkEIqAzBaJRhdBH3aA9xSG7K X55AQkbPlaUTX3RvsvdBPkKgrj+EiIn+q8lq6VvcJ0y53tuc7d7gpDXsmfkuxBW99pvi peEvZRJn4rbxk18AFDrYfbOJ0LiHRweL/Mqo0fM+kNeqhXwXoW9T76zF3SMqCxvLmwIY tsCA== 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 :references:in-reply-to:message-id:subject:cc:to:from:date; bh=eiDgdF6G9OHbOEy6iiLGf8I6V8vaNEjYQ8p5TeReIU0=; b=RZTBBXngAeTNGfd1shA5HkkScGMGojQ+8WzoV7q0FlUMJrNQjmYj2jC76oqqh9OOeN ENGxtm7/JTOgJA8u5dEhAZFPmhZp1LRdzl2W1dCNS5V7ucz6097KPqfFLmBW5s6gaPtv BwdQGciRFy8s68ii38O+NcnTpvUeWe6TXsF2XWwdkUGN4k5Is27holb6nsD68DNMZ+H8 cN6p/E8Zl6TChc1J/yUYOZjB7QJqxPiicd3faPa7YG9Og6iTZGLuiSPfK7f2bdUnkTwq lg+oHQheNj2TwgBUkr/3mJ5mC9jZ8qddKhlpO+fdKQQzICN2D4oGJP+Z/rkwMNqJA7Hj NoIQ== 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 m9si6802367pgt.73.2019.02.20.13.44.10; Wed, 20 Feb 2019 13:44:26 -0800 (PST) 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 S1727008AbfBTVnt (ORCPT + 99 others); Wed, 20 Feb 2019 16:43:49 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:46732 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725869AbfBTVns (ORCPT ); Wed, 20 Feb 2019 16:43:48 -0500 Received: from X1 (unknown [104.133.8.102]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 91C742B01; Wed, 20 Feb 2019 21:43:47 +0000 (UTC) Date: Wed, 20 Feb 2019 13:43:45 -0800 From: Andrew Morton To: "Kani, Toshi" Cc: "yuehaibing@huawei.com" , "cpandya@codeaurora.org" , "tglx@linutronix.de" , "will.deacon@arm.com" , "linux-kernel@vger.kernel.org" , "kernel-janitors@vger.kernel.org" Subject: Re: [PATCH -next] mm: fix set but not used warning Message-Id: <20190220134345.e39094996c111be4ffa0c976@linux-foundation.org> In-Reply-To: <7425c8905127ddd078500d4c14a2147bd00422a0.camel@hpe.com> References: <20190218135743.131904-1-yuehaibing@huawei.com> <7425c8905127ddd078500d4c14a2147bd00422a0.camel@hpe.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.32; 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 Tue, 19 Feb 2019 18:28:30 +0000 "Kani, Toshi" wrote: > On Mon, 2019-02-18 at 13:57 +0000, YueHaibing wrote: > > Fixes gcc '-Wunused-but-set-variable' warning: > > > > lib/ioremap.c: In function 'ioremap_page_range': > > lib/ioremap.c:203:16: warning: > > variable 'start' set but not used [-Wunused-but-set-variable] > > > > flush_cache_vmap may no need param, so add __maybe_unused fix this warning. > > I think flush_cache_vmap should have a proper prototype with > __maybe_unused for its args. But, there are so many arch-specific > definitions at glace, and I am not sure how manageable such change is, > though... This is one of the reasons why things like flush_cache_vmap() should be implemented as static inline C functions, not as macros.