From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] dmaengine: edma: fix build without CONFIG_OF
Date: Wed, 04 Nov 2015 11:29:01 +0100 [thread overview]
Message-ID: <3771870.4l0jsKt335@wuerfel> (raw)
In-Reply-To: <5639CA72.4050604@ti.com>
On Wednesday 04 November 2015 11:05:54 Peter Ujfalusi wrote:
> >
> > I think that would be less readable, and gives no compile-time coverage
> > to the contents of the edma_tc_set_pm_state function.
>
> Hrm, if the compiler knows that there is no need to compile the code after the:
> if (!IS_ENABLED(CONFIG_OF) || !tc)
> when OF is disabled, then it does not give more compile coverage then have
> empty inline function in case of !OF.
No, the way it works (simplified but close enough here) is that gcc parses
all the source code first and throws warnings or errors for everything that
looks wrong to it, and only later throws out all code that it knows is never
used before emitting the object code.
The difference to the #ifdef is that the preprocessor here throws out all
disabled code before it gets parsed, so we don't get warnings for it.
> Not sure about it, but if we disable all optimization in gcc, then we might
> get the same missing symbol?
It's impossible to build the kernel with inlining disabled, because we
rely on the same kind of optimization in lots of places.
> > The effect is the same, so I'd rather stay with my version.
>
> I'm fine with both. It is up to Vinod to decide which one he prefers (I prefer
> the #if #else #endif version).
>
> Anyways:
> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Thanks!
Arnd
next prev parent reply other threads:[~2015-11-04 10:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-03 14:00 [PATCH] dmaengine: edma: fix build without CONFIG_OF Arnd Bergmann
2015-11-04 7:42 ` Peter Ujfalusi
2015-11-04 8:46 ` Arnd Bergmann
2015-11-04 9:05 ` Peter Ujfalusi
2015-11-04 10:29 ` Arnd Bergmann [this message]
2015-11-16 3:36 ` Vinod Koul
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=3771870.4l0jsKt335@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).