[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0gS1yvORG_+Z80y6McBhu_QLNfY7-RqJKZ1HjGevzGJFQ@mail.gmail.com>
Date: Fri, 19 Dec 2025 18:22:24 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Jonathan Cameron <jonathan.cameron@...wei.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Linux ACPI <linux-acpi@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, Linux PCI <linux-pci@...r.kernel.org>,
Bjorn Helgaas <helgaas@...nel.org>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>, Hans de Goede <hansg@...nel.org>,
Mario Limonciello <mario.limonciello@....com>
Subject: Re: [PATCH v1 3/8] ACPI: bus: Split _OSC evaluation out of acpi_run_osc()
On Fri, Dec 19, 2025 at 1:44 PM Jonathan Cameron
<jonathan.cameron@...wei.com> wrote:
>
> On Thu, 18 Dec 2025 21:36:08 +0100
> "Rafael J. Wysocki" <rafael@...nel.org> wrote:
>
> > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >
> > Split a function for evaluating _OSL called acpi_eval_osc() out of
>
> _OSC
Yup, thanks!
> > acpi_run_osc() to facilitate subsequent changes and add some more
> > parameters sanity checks to the latter.
> >
> > No intentional functional impact.
> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> One comment on the fun static keyword usage. Next time I have
> to ask/answer some silly C questions in an interview that one is definitely going
> in :)
> > ---
> > drivers/acpi/bus.c | 89 ++++++++++++++++++++++++++++++-----------------------
> > 1 file changed, 52 insertions(+), 37 deletions(-)
> >
> > --- a/drivers/acpi/bus.c
> > +++ b/drivers/acpi/bus.c
> > @@ -195,52 +195,67 @@ static void acpi_dump_osc_data(acpi_hand
> > OSC_INVALID_REVISION_ERROR | \
> > OSC_CAPABILITIES_MASK_ERROR)
> >
> > -acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context)
> > +static int acpi_eval_osc(acpi_handle handle, guid_t *guid, int rev,
> > + struct acpi_buffer *cap,
> > + union acpi_object in_params[static 4],
>
> This static usage has such non intuitive behavior maybe use
> the new at_least marking in compiler_types.h to indicate
> what protection against wrong sizes it can offer.
I'll have a look at that, thanks!
Powered by blists - more mailing lists