From: Zijun Hu <zijun_hu@icloud.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
linux-kernel@vger.kernel.org, Zijun Hu <quic_zijuhu@quicinc.com>
Subject: Re: [PATCH] driver core: Simplify driver API device_find_child_by_name() implementation
Date: Thu, 1 Aug 2024 08:08:30 +0800 [thread overview]
Message-ID: <b6dcf753-c262-46d9-bbf6-53b25d0e2bff@icloud.com> (raw)
In-Reply-To: <2024073119-mortally-ashes-80f0@gregkh>
On 2024/8/1 00:21, Greg Kroah-Hartman wrote:
> On Thu, Aug 01, 2024 at 12:04:40AM +0800, Zijun Hu wrote:
>> On 2024/7/31 20:53, Greg Kroah-Hartman wrote:
>>> On Sat, Jul 20, 2024 at 09:21:50AM +0800, Zijun Hu wrote:
>>>> From: Zijun Hu <quic_zijuhu@quicinc.com>
>>>>
>>>> Simplify device_find_child_by_name() implementation by using present
>>>> driver APIs device_find_child() and device_match_name().
>>>>
>>>> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
>>>> ---
>>>> drivers/base/core.c | 15 +++------------
>>>> include/linux/device.h | 4 ++++
>>>> 2 files changed, 7 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/drivers/base/core.c b/drivers/base/core.c
>>>> index 730cae66607c..22ab4b8a2bcd 100644
>>>> --- a/drivers/base/core.c
>>>> +++ b/drivers/base/core.c
>>>> @@ -4089,18 +4089,9 @@ EXPORT_SYMBOL_GPL(device_find_child);
>>>> struct device *device_find_child_by_name(struct device *parent,
>>>> const char *name)
>>>> {
>>>> - struct klist_iter i;
>>>> - struct device *child;
>>>> -
>>>> - if (!parent)
>>>> - return NULL;
>>>> -
>>>> - klist_iter_init(&parent->p->klist_children, &i);
>>>> - while ((child = next_device(&i)))
>>>> - if (sysfs_streq(dev_name(child), name) && get_device(child))
>>>> - break;
>>>> - klist_iter_exit(&i);
>>>> - return child;
>>>> + /* TODO: remove type cast after const device_find_child() prototype */
>>>
>>> I do not understand the TODO here. Why is it needed? Why not fix it up
>>> now?
>>>
>>
>> i have below findings during trying to simplify this API.
>>
>> there are a type of driver APIs for finding device, for example,
>> (bus|driver|class)_find_device() which all take below type for
>> parameter @match:
>> int (*match)(struct device *, const void *match_data)
>> but device_find_child() take below type with void * for @match_data:
>> int (*match)(struct device *, void *match_data).
>>
>> @match's type of device_find_child() is not good as other finding APIs
>> since nothing will be touched for finding operations normally.
>>
>> i want to introduce a dedicate type for device match.
>> typedef int (*device_match_t)(struct device *dev, const void *data);
>
> Yes, that would be good.
>
>> advantages:
>> 1) device_match_t is simpler for finding APIs declarations and definitions
>> 2) maybe stop further driver APIs from using bad match type as
>> device_find_child()
>>
>> TODO:
>> 1) introduce device_match_t and use it for current present APIs
>> (bus|driver|class)_find_device()
>> 2) change API device_find_child() to take device_match_t, more jobs to
>> do since need to touch many drivers
>> 3) correct this change by by remove all TODO inline comments and force cast.
>>
>> not sure if my ideas is good, what is your opinions?
>
> That's great, but evolve it properly, don't add TODO lines here, there's
> no real need for that. Should end up with a lot of good cleanup
> changes, and might not be all that bad overall.
>
okay, thanks for these good suggestions.
let me mark this patch as abandoned now since i would like to do it by
another better way.
> thanks,
>
> greg k-h
prev parent reply other threads:[~2024-08-01 0:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-20 1:21 Zijun Hu
2024-07-31 12:53 ` Greg Kroah-Hartman
2024-07-31 16:04 ` Zijun Hu
2024-07-31 16:21 ` Greg Kroah-Hartman
2024-08-01 0:08 ` Zijun Hu [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=b6dcf753-c262-46d9-bbf6-53b25d0e2bff@icloud.com \
--to=zijun_hu@icloud.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_zijuhu@quicinc.com \
--cc=rafael@kernel.org \
/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
all inboxes | Powered by JetHome®