All of lore.kernel.org
 help / color / mirror / Atom feed
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

      parent reply	other threads:[~2016-06-06 18:50 UTC|newest]

Thread overview: 30+ 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 ` 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     ` Thierry Reding
2016-06-06  8:31   ` [PATCH 06/22] nvmem: core: Use of_device_match() Thierry Reding
2016-06-06  8:31     ` Thierry Reding
2016-06-06  8:31   ` [PATCH 10/22] usb: phy: am335x-control: " Thierry Reding
2016-06-06  8:31     ` Thierry Reding
2016-06-06  8:31   ` [PATCH 13/22] drm/armada: " Thierry Reding
2016-06-06  8:31     ` Thierry Reding
2016-06-06  8:31 ` [PATCH 02/22] amba: tegra-ahb: " 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
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.