All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: quic_zijuhu <quic_zijuhu@quicinc.com>
Cc: Zijun Hu <zijun_hu@icloud.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Takashi Sakamoto <o-takashi@sakamocchi.jp>,
	Timur Tabi <timur@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net, netdev@vger.kernel.org
Subject: Re: [PATCH 2/5] driver core: Introduce an API constify_device_find_child_helper()
Date: Tue, 13 Aug 2024 12:57:43 +0200	[thread overview]
Message-ID: <2024081311-mortality-opal-cf0f@gregkh> (raw)
In-Reply-To: <3f7e9969-5285-4dba-b16e-65c6b10ee89a@quicinc.com>

On Tue, Aug 13, 2024 at 06:50:04PM +0800, quic_zijuhu wrote:
> On 8/13/2024 5:45 PM, Greg Kroah-Hartman wrote:
> > On Sun, Aug 11, 2024 at 08:18:08AM +0800, Zijun Hu wrote:
> >> From: Zijun Hu <quic_zijuhu@quicinc.com>
> >>
> >> Introduce constify_device_find_child_helper() to replace existing
> >> device_find_child()'s usages whose match functions will modify
> >> caller's match data.
> > 
> > Ick, that's not a good name, it should be "noun_verb" with the subsystem being on the prefix always.
> > 
> okay, got it.
> 
> is it okay to use device_find_child_mut() suggested by Przemek Kitszel ?

No, just switch all callers over to be const and keep the same name.

> > But why is this even needed?  Device pointers are NOT const for the
> > obvious reason that they can be changed by loads of different things.
> > Trying to force them to be const is going to be hard, if not impossible.
> > 
> 
> [PATCH 3/5] have more discussion about these questions with below link:
> https://lore.kernel.org/all/8b8ce122-f16b-4207-b03b-f74b15756ae7@icloud.com/
> 
> 
> The ultimate goal is to make device_find_child() have below prototype:
> 
> struct device *device_find_child(struct device *dev, const void *data,
> 		int (*match)(struct device *dev, const void *data));
> 
> Why ?
> 
> (1) It does not make sense, also does not need to, for such device
> finding operation to modify caller's match data which is mainly
> used for comparison.
> 
> (2) It will make the API's match function parameter have the same
> signature as all other APIs (bus|class|driver)_find_device().
> 
> 
> My idea is that:
> use device_find_child() for READ only accessing caller's match data.
> 
> use below API if need to Modify caller's data as
> constify_device_find_child_helper() does.
> int device_for_each_child(struct device *dev, void *data,
>                     int (*fn)(struct device *dev, void *data));
> 
> So the The ultimate goal is to protect caller's *match data* @*data  NOT
> device @*dev.

Ok, sorry, I was confused.

thanks,

greg k-h

  reply	other threads:[~2024-08-13 10:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-11  0:18 [PATCH 0/5] driver core: Prevent device_find_child() from modifying caller's match data Zijun Hu
2024-08-11  0:18 ` [PATCH 1/5] driver core: Add simple parameter checks for APIs device_(for_each|find)_child() Zijun Hu
2024-08-13  9:44   ` Greg Kroah-Hartman
2024-08-13 10:00     ` quic_zijuhu
2024-08-13 10:19       ` Greg Kroah-Hartman
2024-08-11  0:18 ` [PATCH 2/5] driver core: Introduce an API constify_device_find_child_helper() Zijun Hu
2024-08-13  9:45   ` Greg Kroah-Hartman
2024-08-13 10:50     ` quic_zijuhu
2024-08-13 10:57       ` Greg Kroah-Hartman [this message]
2024-08-13 11:15         ` quic_zijuhu
2024-08-11  0:18 ` [PATCH 3/5] cxl/region: Prevent device_find_child() from modifying caller's match data Zijun Hu
2024-08-12 12:54   ` Przemek Kitszel
2024-08-12 15:32     ` Zijun Hu
2024-08-11  0:18 ` [PATCH 4/5] firewire: core: " Zijun Hu
2024-08-11  0:18 ` [PATCH 5/5] net: qcom/emac: " Zijun Hu

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=2024081311-mortality-opal-cf0f@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=alison.schofield@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=ira.weiny@intel.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=kuba@kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    --cc=o-takashi@sakamocchi.jp \
    --cc=pabeni@redhat.com \
    --cc=quic_zijuhu@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=timur@kernel.org \
    --cc=vishal.l.verma@intel.com \
    --cc=zijun_hu@icloud.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.