Thread (30 messages) 30 messages, 6 authors, 2024-12-08

Re: [PATCH v3 04/11] driver core: Constify API device_find_child() then adapt for various usages

From: Zijun Hu <hidden>
Date: 2024-12-06 11:08:51
Also in: arm-scmi, linux-block, linux-cxl, linux-efi, linux-gpio, linux-hwmon, linux-media, linux-mediatek, linux-pwm, linux-remoteproc, linux-scsi, linux-serial, linux-sound, linux-usb, lkml, nvdimm, sparclinux

On 2024/12/6 15:21, Uwe Kleine-König wrote:
Hello,

On Thu, Dec 05, 2024 at 08:10:13AM +0800, Zijun Hu wrote:
quoted
From: Zijun Hu <redacted>

Constify the following API:
struct device *device_find_child(struct device *dev, void *data,
		int (*match)(struct device *dev, void *data));
To :
struct device *device_find_child(struct device *dev, const void *data,
                                 device_match_t match);
typedef int (*device_match_t)(struct device *dev, const void *data);
with the following reasons:

- Protect caller's match data @*data which is for comparison and lookup
  and the API does not actually need to modify @*data.

- Make the API's parameters (@match)() and @data have the same type as
  all of other device finding APIs (bus|class|driver)_find_device().

- All kinds of existing device match functions can be directly taken
  as the API's argument, they were exported by driver core.

Constify the API and adapt for various existing usages by simply making
various match functions take 'const void *' as type of match data @data.
With the discussion that a new name would ease the conversion, maybe
consider device_find_child_device() to also align the name (somewhat) to
the above mentioned (bus|class|driver)_find_device()?
i finally select this squashing method after considerations as shown by
link below:
https://lore.kernel.org/all/3a4de1bb-3eb2-469a-8ff7-ff706804f5bb@icloud.com (local)

device_find_child() is consist with existing device_find_child_by_name()
and device_find_any_child, device's child is also a device, so we may
not need the tail _device().
Do you have a merge plan already? I guess this patch will go through
Greg's driver core tree?
this patch series is already squashing solution.

yes. hope it move toward mainline by Greg's driver core tree.

(^^)(^^)
Best regards
Uwe
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help