From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Helge Deller <deller@gmx.de>
Cc: Jason Yan <yanaijie@huawei.com>, Sam Ravnborg <sam@ravnborg.org>,
linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
b.zolnierkie@samsung.com
Subject: Re: [PATCH] video: fbdev: matroxfb: remove dead code and set but not used variable
Date: Fri, 20 Mar 2026 16:37:33 +0200 [thread overview]
Message-ID: <ab1brTQUiEJFkL-D@ashevche-desk.local> (raw)
In-Reply-To: <f13eab5d-bcf0-49ba-91ac-0903040438be@gmx.de>
On Thu, Mar 19, 2026 at 01:44:28PM +0100, Helge Deller wrote:
> On 3/19/26 10:08, Andy Shevchenko wrote:
> > On Thu, Mar 19, 2026 at 09:35:33AM +0100, Helge Deller wrote:
> > > On 3/19/26 09:21, Andy Shevchenko wrote:
> > > > On Thu, Mar 19, 2026 at 04:06:44PM +0800, Jason Yan wrote:
> > > > > 在 2026/3/19 15:38, Andy Shevchenko 写道:
> > > > > > On Thu, Mar 19, 2026 at 10:22:08AM +0800, Jason Yan wrote:
...
> > > > > > Helge, can we revert this change and start over, please? (I can also send
> > > > > > revert if you think it's a better way)
> > >
> > > Andy, all points you make against removing relevant code is absolutely right.
> > >
> > > But for this specific commit 7b987887f97b ("video: fbdev: matroxfb: remove dead code and
> > > set but not used variable") I have to agree with Jason, that the patch is ok.
> > > I don't see any build errors either.
> >
> > Just run on today's Linux Next (since the driver has not been changed in that
> > sense for a few years, the very same issue is present for a long time):
> >
> > 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.
>
> Ok.
>
> > > Are we mixing up things here maybe?
> >
> > ...
> >
> > FWIW, I dove to the history of the driver.
> >
> > So, the code, that was guarded by #if 0 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.").
> >
> > 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.
> >
> > So, 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.
>
> Yes, I think that's what I'd prefer.
> Do you mind sending a patch?
I have just sent 20260320143646.3218199-1-andriy.shevchenko@linux.intel.com.
--
With Best Regards,
Andy Shevchenko
prev parent reply other threads:[~2026-03-20 14:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-03 2:16 [PATCH] video: fbdev: matroxfb: remove dead code and set but not used variable Jason Yan
2020-04-08 10:18 ` Sam Ravnborg
2026-03-18 7:45 ` Andy Shevchenko
2026-03-19 2:22 ` Jason Yan
2026-03-19 7:38 ` Andy Shevchenko
2026-03-19 8:06 ` Jason Yan
2026-03-19 8:21 ` Andy Shevchenko
2026-03-19 8:35 ` Helge Deller
2026-03-19 9:08 ` Andy Shevchenko
2026-03-19 12:44 ` Helge Deller
2026-03-20 14:37 ` Andy Shevchenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ab1brTQUiEJFkL-D@ashevche-desk.local \
--to=andriy.shevchenko@intel.com \
--cc=b.zolnierkie@samsung.com \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=yanaijie@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox