From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout06.his.huawei.com (canpmsgout06.his.huawei.com [113.46.200.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 13A4F286415; Sat, 21 Mar 2026 02:20:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.221 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774059637; cv=none; b=E2vDZRU5Qy+GrcnyYWMB/sAKkZWiobApKSBWYPix9ofa9vq46YDo5xgYt86hJ14NXm9JEWJQA4sDg//0wp/PF2ABK5Vqa1paNBBlu360Bm3TjWkmNQz2NmqNANDWAKq+VfbhpAOfjPE6nJOb9PrWNzEZlw32SewteJw6uX4tp+o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774059637; c=relaxed/simple; bh=Qer7XtUdn/hgWhPuvUq0nksSyHMOsuBlGMrQi8nOfj8=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=V8420cD6sHBllowQCvopP6VuhsSMUV4LNzIJ51DqxooKXPD9a5w83SPrtmf71XtcNvDhuoRfuv0I9ilxPewAxaAmYwLuS/Xs0KmQaYXyzqEsqB1TxZn3fdJyiouIJ7XJEBIvQGL0uAILEkFguPxiuwSyQQu6iCd2jPI9DA9+pgc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=K1Az0G+I; arc=none smtp.client-ip=113.46.200.221 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="K1Az0G+I" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=G1QUG9uubtkZKNrUSnV+qD2JajwUNppKtuRnRb8xPNk=; b=K1Az0G+IgOYrtU30nfOTWUkGDWXkpj9pDzK4YhV3vJuHVCUyldqiUVgWIb5tlqvpWs8PRxvV9 M8GsIlbYTDNAO2XhEpyCXEwKxR8krFwI6C2q72udF1VSOErZvxN/HmRwodkDIRyhSQhdlkEWXfE csez44twmzDIrzSWnFKruTQ= Received: from mail.maildlp.com (unknown [172.19.162.223]) by canpmsgout06.his.huawei.com (SkyGuard) with ESMTPS id 4fd30M1db2zRhQf; Sat, 21 Mar 2026 10:14:27 +0800 (CST) Received: from dggpemf500002.china.huawei.com (unknown [7.185.36.57]) by mail.maildlp.com (Postfix) with ESMTPS id 35EA240569; Sat, 21 Mar 2026 10:20:30 +0800 (CST) Received: from [10.174.179.11] (10.174.179.11) by dggpemf500002.china.huawei.com (7.185.36.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sat, 21 Mar 2026 10:20:29 +0800 Message-ID: <530b1334-302d-44fb-b180-ddb52cd52115@huawei.com> Date: Sat, 21 Mar 2026 10:20:28 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/1] video: fbdev: matroxfb: Mark variable with __maybe_unused to avoid W=1 build break To: Andy Shevchenko , Thomas Zimmermann , , , , CC: Helge Deller , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt References: <20260320143646.3218199-1-andriy.shevchenko@linux.intel.com> From: Jason Yan In-Reply-To: <20260320143646.3218199-1-andriy.shevchenko@linux.intel.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To dggpemf500002.china.huawei.com (7.185.36.57) 在 2026/3/20 22:36, Andy Shevchenko 写道: > Clang is not happy about set but unused variable: > > drivers/video/fbdev/matrox/g450_pll.c:412:18: error: variable 'mnp' set but not used [-Werror,-Wunused-but-set-variable] > 412 | unsigned int mnp; > | ^ > 1 error generated. > > Since the commit 7b987887f97b ("video: fbdev: matroxfb: remove dead code > and set but not used variable") the 'mnp' became unused, but eliminating > that code might have side-effects. The question here is what should we do > with 'mnp'? The easiest way out is just mark it with __maybe_unused which > will shut the compiler up and won't change any possible IO flow. So does > this change. > > Fixes: 7b987887f97b ("video: fbdev: matroxfb: remove dead code and set but not used variable") > Signed-off-by: Andy Shevchenko > > --- > Cc: Jason Yan > --- > > Below is a dive into the history of the driver. > > The problem was revealed when the #if 0 guarded code along with unused > pixel_vco variable was removed. That code was introduced in the original > commit 213d22146d1f ("[PATCH] (1/3) matroxfb for 2.5.3"). And then guarded > in the commit 705e41f82988 ("matroxfb DVI updates: Handle DVI output on > G450/G550. Powerdown unused portions of G450/G550 DAC. Split G450/G550 DAC > from older DAC1064 handling. Modify PLL setting when both CRTCs use same > pixel clocks."). > > NOTE: The two commits mentioned above pre-date Git era and available in > history.git repository for archaeological purposes. > > Even without that guard the modern compilers may see that the pixel_vco > wasn't ever used and seems a leftover after some debug or review made > 25 years ago. > > The g450_mnp2vco() doesn't have any IO and as Jason said doesn't seem > to have any side effects either than some unneeded CPU processing during > runtime. I agree that's unlikely that timeout (or heating up the CPU) has > any effect on the HW (GPU/display) functionality. > --- > drivers/video/fbdev/matrox/g450_pll.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/video/fbdev/matrox/g450_pll.c b/drivers/video/fbdev/matrox/g450_pll.c > index e2c1478aa47f..6a08f78cd1ac 100644 > --- a/drivers/video/fbdev/matrox/g450_pll.c > +++ b/drivers/video/fbdev/matrox/g450_pll.c > @@ -409,7 +409,7 @@ static int __g450_setclk(struct matrox_fb_info *minfo, unsigned int fout, > case M_VIDEO_PLL: > { > u_int8_t tmp; > - unsigned int mnp; > + unsigned int mnp __maybe_unused; > unsigned long flags; > > matroxfb_DAC_lock_irqsave(flags); Reviewed-by: Jason Yan