From: "Arnd Bergmann" <arnd@arndb.de>
To: "Dominik Brodowski" <linux@dominikbrodowski.net>,
"Souptick Joarder" <jrdr.linux@gmail.com>
Cc: "Tony Lindgren" <tony@atomide.com>,
linux-kernel@vger.kernel.org, "kernel test robot" <lkp@intel.com>
Subject: Re: [PATCH] pcmcia: Removed unused variable control.
Date: Fri, 23 Sep 2022 08:58:47 +0200 [thread overview]
Message-ID: <ae8041cd-0f20-47e9-a4be-92159785e8a8@www.fastmail.com> (raw)
In-Reply-To: <YyxzrjA7hW6gdV5e@owl.dominikbrodowski.net>
On Thu, Sep 22, 2022, at 4:39 PM, Dominik Brodowski wrote:
> Am Mon, Jul 25, 2022 at 06:59:55AM +0530 schrieb Souptick Joarder:
>> From: "Souptick Joarder (HPE)" <jrdr.linux@gmail.com>
>>
>> Kernel test robot throws below warning ->
>> drivers/pcmcia/omap_cf.c:127:7: warning: variable 'control'
>> set but not used [-Wunused-but-set-variable]
>>
>> Removed unused variable control.
>
> From a code-generation standpoint, this is obiously correct, and probably
> the compiler removes that omap_readw() already.
omap_readw() is an 'extern' function, so it does not get removed.
Even if it was inline, it's still "and volatile" read that gets
left in because it may (and probably does) have side-effects.
> But, to be honest, I'm not
> perfectly sure on what the device expects -- and whether it's required to
> write back the control register (or parts of it). Does anyone still have the
> hardware (or specs)? If not, I'm tempted to apply this patch on the basis
> that the compiler might remove that omap_readw() anyway.
I think assigning to an unused variable was at some point needed to
avoid a compiler warning because otherwise omap_readw() was just a
pointer dereference. The safe way to transform the code should be to
drop the variable but leave the function call.
Note that the driver is only used on the 'osk' reference board,
not on any devices that were in mass-production.
Arnd
next prev parent reply other threads:[~2022-09-23 6:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-25 1:29 Souptick Joarder
2022-09-22 14:39 ` Dominik Brodowski
2022-09-23 6:58 ` Arnd Bergmann [this message]
2022-09-24 14:06 ` Dominik Brodowski
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=ae8041cd-0f20-47e9-a4be-92159785e8a8@www.fastmail.com \
--to=arnd@arndb.de \
--cc=jrdr.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=lkp@intel.com \
--cc=tony@atomide.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
all inboxes | Powered by JetHome®