[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZZbrMsI6m6RrltXQ@mail.minyard.net>
Date: Thu, 4 Jan 2024 11:30:26 -0600
From: Corey Minyard <minyard@....org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Kai-Heng Feng <kai.heng.feng@...onical.com>, jdelvare@...e.com,
linux@...ck-us.net, Len Brown <lenb@...nel.org>,
Robert Moore <robert.moore@...el.com>, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org, acpica-devel@...ts.linux.dev
Subject: Re: [PATCH v3 1/2] ACPI: IPMI: Add helper to wait for when SMI is
selected
On Thu, Jan 04, 2024 at 06:11:29PM +0100, Rafael J. Wysocki wrote:
> On Thu, Jan 4, 2024 at 4:42 PM Corey Minyard <minyard@....org> wrote:
> >
> > On Thu, Jan 04, 2024 at 02:34:52PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Jan 4, 2024 at 3:48 AM Kai-Heng Feng
> > > <kai.heng.feng@...onical.com> wrote:
> > > >
> > > > The function of acpi_power_meter module on Dell system requires IPMI
> > > > handler is installed and SMI is selected.
> > >
> > > Does the firmware use _DEP to let the OS know about this dependency?
> > >
> > > > So add a helper to let acpi_power_meter know when IPMI handler and SMI
> > > > are ready.
> > > >
> > > > Signed-off-by: Kai-Heng Feng <kai.heng.feng@...onical.com>
> > > > ---
> > > > v3:
> > > > - New patch.
> > > >
> > > > drivers/acpi/acpi_ipmi.c | 17 ++++++++++++++++-
> > > > include/acpi/acpi_bus.h | 5 +++++
> > > > 2 files changed, 21 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
> > > > index 0555f68c2dfd..54862cab7171 100644
> > > > --- a/drivers/acpi/acpi_ipmi.c
> > > > +++ b/drivers/acpi/acpi_ipmi.c
> > > > @@ -23,6 +23,8 @@ MODULE_LICENSE("GPL");
> > > > #define IPMI_TIMEOUT (5000)
> > > > #define ACPI_IPMI_MAX_MSG_LENGTH 64
> > > >
> > > > +static struct completion smi_selected;
> > > > +
> > > > struct acpi_ipmi_device {
> > > > /* the device list attached to driver_data.ipmi_devices */
> > > > struct list_head head;
> > > > @@ -463,8 +465,10 @@ static void ipmi_register_bmc(int iface, struct device *dev)
> > > > if (temp->handle == handle)
> > > > goto err_lock;
> > > > }
> > > > - if (!driver_data.selected_smi)
> > > > + if (!driver_data.selected_smi) {
> > > > driver_data.selected_smi = ipmi_device;
> > > > + complete(&smi_selected);
> > > > + }
> > > > list_add_tail(&ipmi_device->head, &driver_data.ipmi_devices);
> > > > mutex_unlock(&driver_data.ipmi_lock);
> > > >
> > > > @@ -578,10 +582,21 @@ acpi_ipmi_space_handler(u32 function, acpi_physical_address address,
> > > > return status;
> > > > }
> > > >
> > > > +int acpi_wait_for_acpi_ipmi(void)
> > > > +{
> > > > + long ret;
> > > > +
> > > > + ret = wait_for_completion_interruptible_timeout(&smi_selected, 2 * HZ);
> > > > +
> > > > + return ret > 0 ? 0 : -ETIMEDOUT;
> > >
> > > What will happen if the IPMI driver is unloaded after this has returned 0?
> >
> > The IPMI driver can't be unloaded if it has a user.
>
> Because of the use of the exported symbol, right?
I wasn't thinking that, but yes, that would do it. It also keep track
of users and doesn't allow the driver to be unloaded if anything has
registered as a user, either.
-corey
>
> > I've been following this, but I know little about ACPI. Beyond this
> > solution, the only other solution I could come up with was to start the
> > IPMI driver earlier. But then you are in a chicken-and-egg situation
> > (https://dictionary.cambridge.org/dictionary/english/chicken-and-egg-situation).
> > Which was the reason for the SPMI table, but that's really kind of
> > useless for this, even if the SPMI table existed.
>
> Fine.
>
> Let me reply to the patch with some more comments then.
Powered by blists - more mailing lists