From: Grant Likely <grant.likely@linaro.org>
To: Rob Herring <robherring2@gmail.com>, Arnd Bergmann <arnd@arndb.de>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
patches@lists.linaro.org, Rob Herring <rob.herring@calxeda.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH 15/15] OF: remove #ifdef from linux/of_platform.h
Date: Wed, 05 Jun 2013 22:48:17 +0100 [thread overview]
Message-ID: <20130605214817.A46223E10E4@localhost> (raw)
In-Reply-To: <CAL_JsqLRJ1cEWBfAdHEyngJHQKauJ6XzWH2JwXh1qDusMkzUGA@mail.gmail.com>
On Tue, 4 Jun 2013 17:24:51 -0500, Rob Herring <robherring2@gmail.com> wrote:
> On Tue, Jun 4, 2013 at 12:51 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 04 June 2013, Rob Herring wrote:
> >> On Sat, Jun 1, 2013 at 3:57 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Saturday 01 June 2013, Rob Herring wrote:
> >> >> No, we still need empty functions. Here is what of_device.h looks like:
> >> >>
> >> >> http://tinyurl.com/l2azz5m
> >> >>
> >> >> BTW, it has your ack.
> >> >>
> >> >
> >> > Could you add a patch on top that only puts the function declarations
> >> > inside of #ifdef that don't have an inline wrapper?
> >>
> >> I'm confused. You mean that DO have an inline? Like this:
> >>
> >> void foo(void);
> >>
> >> #ifdef CONFIG_OF
> >> void bar(void);
> >> #else
> >> static inline void bar(void) {}
> >> #endif
> >
> > Yes, sorry. That's what I meant.
> >
> >> > It's really annoying to have to change the header file every time one
> >> > needs to call a function from a driver in the DT-only case.
> >>
> >> The functions without inlines are ones that drivers should not call
> >> and should only be called from OF enabled code. That's why we have not
> >> done a complete pass of adding inlines for everything.
> >
> > The problem is that it's a bad default. The convention in kernel code
> > is not to hide declarations in #ifdef, for multiple reasons:
> >
> > * It avoids unnecessary code rebuilds when the symbol changes between
> > two 'make' runs.
> >
> > * It lets drivers and platform code call the function from dead code
> > without causing a build error, thus improving compile coverage.
> >
> > * It's much nicer to read when can write your code like
> >
> > void __init exynos_init_io(struct map_desc *mach_desc, int size)
> > {
> > if (IS_ENABLED_(CONFIG_OF) && initial_boot_params)
> > of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
> > else
> > iotable_init(exynos_iodesc, ARRAY_SIZE(exynos_iodesc));
> > ...
> > }
> >
> > instead of
> >
> > void __init exynos_init_io(struct map_desc *mach_desc, int size)
> > {
> > #ifdef CONFIG_OF
> > if (initial_boot_params)
> > of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
> > else
> > #endif
> > iotable_init(exynos_iodesc, ARRAY_SIZE(exynos_iodesc));
> > ...
> > }
A big part of the reason for not having the headers was to discourage
code like the above; so instead of having a whole bunch of DT functions
inline in a drivers probe hook, they would be collected off in a DT
parse function that can all get compiled away as a block.
However, that's the first time I've thought about the code coverage
issue and it is a good point.
> >
> > The first one looks like actual C code, the second is really ugly,
> > and an inline wrapper wouldn't even do the right thing here.
>
> Right. I get all that. You still have to go add inlines if you want to make:
>
> if (IS_ENABLED(CONFIG_OF))
> of_foo();
>
> just be:
>
> of_foo();
>
> There are situations for both and only inlines cover both cases. I
> don't see a reason we would want to allow the first case and not allow
> the second case. I am tired of taking patches adding the inlines 1 by
> 1, so perhaps we need to refactor the OF headers to better separate
> core infrastructure includes vs. driver only includes if that is
> really a concern.
I'm fine with that. Attitudes have changed quite a bit in the last few
years about DT code in device drivers so it isn't as important to make a
hard distinction about when DT functions can be called.
g.
prev parent reply other threads:[~2013-06-05 21:48 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-31 22:22 [PATCH 00/15] Linux-3.10 ARM randconfig fixes Arnd Bergmann
2013-05-31 22:22 ` [PATCH 01/15] irqdomain: export irq_domain_add_simple Arnd Bergmann
2013-05-31 22:22 ` [PATCH 02/15] mtd: omap2: allow bulding as a module Arnd Bergmann
2013-05-31 22:22 ` [PATCH 03/15] drm/nouveau: use mdelay instead of large udelay constants Arnd Bergmann
2013-05-31 23:34 ` Aaro Koskinen
2013-05-31 22:22 ` [PATCH 04/15] [SCSI] nsp32: " Arnd Bergmann
2013-05-31 22:22 ` [PATCH 05/15] hwrng: bcm2835: fix MODULE_LICENSE tag Arnd Bergmann
2013-06-21 7:16 ` Herbert Xu
2013-05-31 22:22 ` [PATCH 06/15] cpuidle: calxeda: select ARM_CPU_SUSPEND Arnd Bergmann
2013-05-31 22:22 ` [PATCH 07/15] cpufreq: spear needs cpufreq table Arnd Bergmann
2013-06-01 1:58 ` Viresh Kumar
2013-06-01 9:03 ` Arnd Bergmann
2013-06-01 9:45 ` Viresh Kumar
2013-05-31 22:22 ` [PATCH 08/15] thermal: cpu_cooling: fix stub function Arnd Bergmann
2013-06-19 17:25 ` Eduardo Valentin
2013-06-19 18:18 ` Arnd Bergmann
2013-05-31 22:22 ` [PATCH 09/15] drm: always provide debugfs function prototypes Arnd Bergmann
2013-05-31 22:22 ` [PATCH 10/15] drm/tilcd: select BACKLIGHT_LCD_SUPPORT Arnd Bergmann
2013-05-31 22:22 ` [PATCH 11/15] iwlegacy: il_pm_ops is only provided for PM_SLEEP Arnd Bergmann
2013-06-01 5:43 ` Brian Norris
2013-06-01 9:03 ` Arnd Bergmann
2013-06-01 9:12 ` [PATCH v2] " Arnd Bergmann
2013-05-31 22:22 ` [PATCH 12/15] [media] davinci: vpfe_capture needs i2c Arnd Bergmann
2013-05-31 22:22 ` [PATCH 13/15] [media] omap3isp: include linux/mm_types.h Arnd Bergmann
2013-06-01 15:30 ` Laurent Pinchart
2013-06-01 20:04 ` Arnd Bergmann
2013-05-31 22:22 ` [PATCH 14/15] clk: tegra: provide tegra_periph_reset_assert alternative Arnd Bergmann
2013-05-31 22:22 ` [PATCH 15/15] OF: remove #ifdef from linux/of_platform.h Arnd Bergmann
2013-06-01 14:01 ` Rob Herring
2013-06-01 20:03 ` Arnd Bergmann
2013-06-01 20:30 ` Rob Herring
2013-06-01 20:57 ` Arnd Bergmann
2013-06-04 13:01 ` Rob Herring
2013-06-04 17:51 ` Arnd Bergmann
2013-06-04 22:24 ` Rob Herring
2013-06-05 12:13 ` Arnd Bergmann
2013-06-05 21:48 ` Grant Likely [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=20130605214817.A46223E10E4@localhost \
--to=grant.likely@linaro.org \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@lists.linaro.org \
--cc=rob.herring@calxeda.com \
--cc=robherring2@gmail.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