[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20131121125007.17A8FC40A2C@trevor.secretlab.ca>
Date: Thu, 21 Nov 2013 12:50:07 +0000
From: Grant Likely <grant.likely@...aro.org>
To: Rob Herring <robherring2@...il.com>, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rob Herring <rob.herring@...xeda.com>
Subject: Re: [RFC PATCH 2/2] of: add initcall with match boilerplate helpers
On Wed, 30 Oct 2013 01:12:51 -0500, Rob Herring <robherring2@...il.com> wrote:
> From: Rob Herring <rob.herring@...xeda.com>
>
> Add boilerplate helpers to create initcalls which are conditional on
> matching on devicetree properties.
>
> Cc: Grant Likely <grant.likely@...aro.org>
> Signed-off-by: Rob Herring <rob.herring@...xeda.com>
> ---
> include/linux/of.h | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index f95aee3..a1327c9 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -592,6 +592,18 @@ static inline int of_property_read_u32(const struct device_node *np,
> s; \
> s = of_prop_next_string(prop, s))
>
> +#define of_initcall_match(__func, __lvl, __match) \
> +static int __init __func##_init(void) \
> +{ \
> + if (of_find_matching_node(NULL, __match)) \
> + return __func(); \
> + else \
> + return -ENODEV; \
> +} \
> +__lvl(__func##_init);
> +
> +#define of_module_init_match(__func, __match) of_initcall_match(__func, module_init, __match)
> +
I'm not sure why this is necessary. I don't particularly have a problem
with it, but I wouldn't normally try to filter out device drivers when
the probe code simply won't get called.
Considering it's paired with the previous patch that creates devices in
the module init call, I'm assuming it is to support that use case. If so
then I don't think it is a good idea. If there is another use case then
maybe.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists