mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Len Brown <lenb@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"ACPI Devel Maling List" <linux-acpi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linuxarm <linuxarm@huawei.com>
Subject: Re: [PATCH PoC 2/3] ACPI: platform: Refactor acpi_create_platform_device()
Date: Fri, 19 Aug 2022 09:10:03 +0100	[thread overview]
Message-ID: <dd41c5c3-ee16-821c-afd4-ddda4443bc78@huawei.com> (raw)
In-Reply-To: <CAHp75VdhCovo1uT3oxQAymEO9X+29oDet7LjYkLvpmj+r15Tfg@mail.gmail.com>

On 18/08/2022 20:41, Andy Shevchenko wrote:
> On Tue, Aug 16, 2022 at 2:33 PM John Garry <john.garry@huawei.com> wrote:
>>
>> There is commonality between acpi_create_platform_device() and
>> hisi_lpc_acpi_add_child(), in that it covers 2x main steps:
>> - Read resources for the acpi_device
>> - Create platform device
>>
>> Refactor acpi_create_platform_device() so that it may be reused by
>> hisi_lpc_acpi_add_child() to reduce duplication.
> 
> ...
> 
>> + * acpi_create_platform_device_ops - Create platform device for ACPI device node
> 
> Not sure I understand why _ops is a suffix for the function. I would
> expect _ops to be a data struct where the ->xlate() and perhaps other
> callbacks may be collected. It may be that I have missed that portion
> in the previous discussion.

ok, maybe I can put all the members into a struct, but I don't think 
that it improves the overall code too much.

> 
> ...
> 
>> +       if (name)
>> +               pdevinfo.name = name;
>> +       else
>> +               pdevinfo.name = dev_name(&adev->dev);
> 
>> +       pdevinfo.data = data;
>> +       pdevinfo.size_data = size_data;
> 
> It rather reminds me of platform device registration full with this
> device info. May be what you need is
> struct acpi_platfrom_device_info {
>    properties;
>    name;
>    id;
>    ->xlate();
>    ...
> };
> 
> ?
> 
> ...
> 
>> +struct platform_device *acpi_create_platform_device_ops(
>> +                               struct acpi_device *adev,
>> +                               const char *name,
>> +                               const struct property_entry *properties,
>> +                               void *data, size_t size_data,
>> +                               int (*xlat)(struct acpi_device *adev,
>> +                                           struct resource *res,
>> +                                           void *data, size_t size_data),
>> +                               int id);
> 
> ...because this looks  a bit too much from the amount of parameters
> point of view.
> 

ok, agreed.

But even if we improve this code, the hisi_lpc changes are quite large 
and unwieldly.

Thanks,
John

  reply	other threads:[~2022-08-19  8:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-16 11:27 [PATCH PoC 0/3] ACPI/PNP/HISI_LPC: Refactor ACPI platform code for reuse John Garry
2022-08-16 11:27 ` [PATCH PoC 1/3] ACPI / PNP: Don't add enumeration_by_parent devices John Garry
2022-08-18 19:31   ` Andy Shevchenko
2022-08-19  8:05     ` John Garry
2022-08-19  9:59       ` Andy Shevchenko
2022-08-19 10:20         ` John Garry
2022-08-19 10:41           ` Andy Shevchenko
2022-08-16 11:27 ` [PATCH PoC 2/3] ACPI: platform: Refactor acpi_create_platform_device() John Garry
2022-08-18 19:41   ` Andy Shevchenko
2022-08-19  8:10     ` John Garry [this message]
2022-08-23 16:42       ` Rafael J. Wysocki
2022-09-01 10:52         ` John Garry
2022-08-16 11:27 ` [PATCH PoC 3/3] bus: hisi_lpc: Use acpi_create_platform_device_ops() John Garry

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=dd41c5c3-ee16-821c-afd4-ddda4443bc78@huawei.com \
    --to=john.garry@huawei.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.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®