From: Frank Rowand <frowand.list@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>,
Rob Herring <robh+dt@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Russell King <linux@armlinux.org.uk>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/22] of: Introduce of_match_device()
Date: Mon, 6 Jun 2016 11:50:47 -0700 [thread overview]
Message-ID: <5755C607.8050602@gmail.com> (raw)
In-Reply-To: <20160606083204.19760-1-thierry.reding@gmail.com>
On 06/06/16 01:31, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> This series of patches introduces a common implementation of a function
> that can be used in iterators (such as the bus_for_each_dev() or the
> driver_for_each_device() functions) and that compare's a device's device
> tree node with the passed in data. Numerous drivers and subsystems have
> their own variant of this function, so a lot of duplication can be
> removed by making use of the common implementation.
>
> One thing that slightly bugs me about this is that it can't be used with
> users of class_for_each_device() or class_find_device() because they get
> passed a callback that takes a const void * rather than a void * for the
> device tree node. I had at some point investigated to turn the remainder
> of the iterators into taking const void *, but there are some drivers in
> the kernel that want to modify the data passed to them, so it isn't easy
> to switch.
>
> An alternative would be to turn the const void * into void * for all the
> callbacks of this sort, so that we can use a single set throughout the
> tree, but I'm not sure how welcome that would be. I can give that a shot
> if people think it worth, though.
>
> Greg, any thoughts on this?
>
> I've also kept the list of recipients very short, to get early feedback
> and buy-in from Rob and Frank on the common implementation. I expect the
> naming to allow for some good bike-shedding.
Common implementation looks fine to me.
My shot at bike-shedding is to make the function name reflect the argument
names of bus_find_device() and driver_find_device(). That would suggest
of_node_match_data(). Or if one wanted to be more concise, of_node_match()
or of_match_node().
But of_match_node() is already in wide use (for something else entirely).
And drivers/regulator/core.c is the one existing version of of_node_match():
static int of_node_match(struct device *dev, const void *data)
{
return dev->of_node == data;
}
This is an example of the 'const void *data' vs 'void *data' that you
mentioned, because this of_node_match() is used for class_find_device().
of_node_match() could be used since only one current usage of the
name would have to be changed to some other name.
So that brings me back to of_node_match_data() being my preference
because of_node_match() is entirely too similar to of_match_node(),
which seems like it would lead to confusion when I am reading code.
Then maybe a variant on that name with a 'const void *data' argument.
Like the longer than I would like of_node_match_const_data().
< snip >
-Frank
prev parent reply other threads:[~2016-06-06 18:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-06 8:31 [PATCH 00/22] of: Introduce of_match_device() Thierry Reding
2016-06-06 8:31 ` [PATCH 02/22] amba: tegra-ahb: Use of_device_match() Thierry Reding
2016-06-06 18:51 ` Frank Rowand
2016-06-06 8:31 ` [PATCH 03/22] coresight: " Thierry Reding
2016-06-06 8:31 ` [PATCH 04/22] i2c: core: " Thierry Reding
2016-06-06 8:31 ` [PATCH 05/22] net: cpsw-phy-sel: " Thierry Reding
[not found] ` <20160606083204.19760-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-06 8:31 ` [PATCH 01/22] of: Implement of_match_device() Thierry Reding
2016-06-06 8:31 ` [PATCH 06/22] nvmem: core: Use of_device_match() Thierry Reding
2016-06-06 8:31 ` [PATCH 10/22] usb: phy: am335x-control: " Thierry Reding
2016-06-06 8:31 ` [PATCH 13/22] drm/armada: " Thierry Reding
2016-06-06 8:31 ` [PATCH 07/22] of/platform: " Thierry Reding
2016-06-06 8:31 ` [PATCH 08/22] spi: " Thierry Reding
2016-06-06 8:31 ` [PATCH 09/22] of: mdio: " Thierry Reding
2016-06-06 8:31 ` [PATCH 11/22] usb: phy: isp1301: " Thierry Reding
2016-06-06 8:31 ` [PATCH 12/22] drm/hdlcd: " Thierry Reding
2016-06-06 8:31 ` [PATCH 14/22] drm/etnaviv: " Thierry Reding
2016-06-06 8:31 ` [PATCH 15/22] drm/hisilicon: " Thierry Reding
2016-06-06 8:31 ` [PATCH 16/22] drm/mediatek: " Thierry Reding
2016-06-06 8:31 ` [PATCH 17/22] drm/msm: " Thierry Reding
2016-06-06 8:32 ` [PATCH 18/22] drm/rockchip: " Thierry Reding
2016-06-06 8:32 ` [PATCH 19/22] drm/sti: " Thierry Reding
2016-06-06 8:32 ` [PATCH 20/22] drm/sun4i: " Thierry Reding
2016-06-06 8:32 ` [PATCH 21/22] drm/tilcdc: " Thierry Reding
2016-06-06 8:32 ` [PATCH 22/22] iommu/mediatek: " Thierry Reding
2016-06-06 18:50 ` Frank Rowand [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=5755C607.8050602@gmail.com \
--to=frowand.list@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=robh+dt@kernel.org \
--cc=thierry.reding@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;
as well as URLs for NNTP newsgroup(s).