linux-kernel - Re: [PATCH v2 3/6] ACPI: AC: Replace acpi_driver with platform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0g=MkRwFQ88SQfRcvwnii5VnXujC7ZUaDsncodNkzdNdQ@mail.gmail.com>
Date:   Mon, 9 Oct 2023 19:51:25 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     "Wilczynski, Michal" <michal.wilczynski@...el.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...el.com>,
        linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
        nvdimm@...ts.linux.dev, rafael.j.wysocki@...el.com,
        lenb@...nel.org, dan.j.williams@...el.com,
        vishal.l.verma@...el.com, ira.weiny@...el.com
Subject: Re: [PATCH v2 3/6] ACPI: AC: Replace acpi_driver with platform_driver

On Mon, Oct 9, 2023 at 3:04 PM Wilczynski, Michal
<michal.wilczynski@...el.com> wrote:
>
>
>
> On 10/9/2023 2:27 PM, Rafael J. Wysocki wrote:
> > On Mon, Oct 9, 2023 at 10:40 AM Wilczynski, Michal
> > <michal.wilczynski@...el.com> wrote:
> >>

[cut]

> >> Yeah we could add platform device without removing acpi device, and
> >> yes that would introduce data duplication, like Andy noticed.
> > But he hasn't answered my question regarding what data duplication he
> > meant, exactly.
> >
> > So what data duplication do you mean?
>
> So what I meant was that many drivers would find it useful to have
> a struct device embedded in their 'private structure', and in that case
> there would be a duplication of platform_device and acpi_device as
> both pointers would be needed.

It all depends on how often each of them is going to be used in the
given driver.

This particular driver only needs a struct acpi_device pointer if I'm
not mistaken.

> Mind this if you only have struct device
> it's easy to get acpi device, but it's not the case the other way around.
>
> So for this driver it's just a matter of sticking to convention,

There is no convention in this respect and there is always a tradeoff
between using more memory and using more CPU time in computing in
general, but none of them should be wasted just for the sake of
following a convention.

> for the others like it would be duplication.

So I'm only talking about the driver modified by the patch at hand.

> In my version of this patch we managed to avoid this duplication, thanks
> to the contextual argument introduced before, but look at this patch:
> https://github.com/mwilczy/linux-pm/commit/cc8ef52707341e67a12067d6ead991d56ea017ca
>
> Author of this patch had to introduce platform_device and acpi_device to the struct ac, so
> there was some duplication. That is the case for many drivers to come, so I decided it's better
> to change this and have a pattern with keeping only 'struct device'.

Well, if the only thing you need from a struct device is its
ACPI_COMPANION(), it is better to store a pointer to the latter.