[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAAd53p6POFCNEP4J8U_jTexBkxOn-15ULRqQj+r2GA3q2+1raQ@mail.gmail.com>
Date: Wed, 27 Dec 2023 11:39:46 +0800
From: Kai-Heng Feng <kai.heng.feng@...onical.com>
To: Armin Wolf <W_Armin@....de>
Cc: Guenter Roeck <linux@...ck-us.net>, jdelvare@...e.com, linux-hwmon@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hwmon: (acpi_power_meter) Install IPMI handler for Dell systems
Hi Armin,
On Fri, Dec 22, 2023 at 8:08 PM Armin Wolf <W_Armin@....de> wrote:
>
> Am 22.12.23 um 04:57 schrieb Kai-Heng Feng:
>
> > Hi Guenter,
> >
> > On Thu, Dec 21, 2023 at 7:49 AM Guenter Roeck <linux@...ck-us.net> wrote:
> >> On Wed, Dec 20, 2023 at 01:13:50PM +0800, Kai-Heng Feng wrote:
> >>> The following error can be observed at boot:
> >>> [ 3.717920] ACPI Error: No handler for Region [SYSI] (00000000ab9e62c5) [IPMI] (20230628/evregion-130)
> >>> [ 3.717928] ACPI Error: Region IPMI (ID=7) has no handler (20230628/exfldio-261)
> >>>
> >>> [ 3.717936] No Local Variables are initialized for Method [_GHL]
> >>>
> >>> [ 3.717938] No Arguments are initialized for method [_GHL]
> >>>
> >>> [ 3.717940] ACPI Error: Aborting method \_SB.PMI0._GHL due to previous error (AE_NOT_EXIST) (20230628/psparse-529)
> >>> [ 3.717949] ACPI Error: Aborting method \_SB.PMI0._PMC due to previous error (AE_NOT_EXIST) (20230628/psparse-529)
> >>> [ 3.717957] ACPI: \_SB_.PMI0: _PMC evaluation failed: AE_NOT_EXIST
> >>>
> >>> On Dell systems several methods of acpi_power_meter access variables in
> >>> IPMI region [0], so request module 'ipmi_si' which will load 'acpi_ipmi'
> >>> and install the region handler accordingly.
> >>>
> >>> [0] https://www.dell.com/support/manuals/en-us/redhat-enterprise-linux-v8.0/rhel8_rn_pub/advanced-configuration-and-power-interface-acpi-error-messages-displayed-in-dmesg?guid=guid-0d5ae482-1977-42cf-b417-3ed5c3f5ee62
> >>>
> >>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@...onical.com>
> >>> ---
> >>> drivers/hwmon/acpi_power_meter.c | 2 ++
> >>> 1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/drivers/hwmon/acpi_power_meter.c b/drivers/hwmon/acpi_power_meter.c
> >>> index 703666b95bf4..b9db53166bc9 100644
> >>> --- a/drivers/hwmon/acpi_power_meter.c
> >>> +++ b/drivers/hwmon/acpi_power_meter.c
> >>> @@ -882,6 +882,8 @@ static int acpi_power_meter_add(struct acpi_device *device)
> >>> strcpy(acpi_device_name(device), ACPI_POWER_METER_DEVICE_NAME);
> >>> strcpy(acpi_device_class(device), ACPI_POWER_METER_CLASS);
> >>> device->driver_data = resource;
> >>> + if (dmi_match(DMI_SYS_VENDOR, "Dell Inc."))
> >>> + request_module("ipmi_si");
> >>>
> >> This looks like a terrible hack to me. Is there precedent of similar hacks
> >> elsewhere showing that this is the "way to go" ?
> > Yes it's ugly.
> >
> > The error happens in the ACPI ASL code, so it's not possible to know
> > if any method of apci_power_meter requires IPMI region.
> > I really can't think of any better solution for it.
> >
> > Kai-Heng
>
> Maybe we could use an ACPI scan handler for that?
> Basically we would call request_module() upon discovering an ACPI IPMI device,
> so that the necessary module is available for handling the IPMI opregion.
> This would also prevent any issues should other devices also require IPMI access.
I think the ACPI core already does this. But since the modules are
loading and probing asynchronously, the order needs to be enforced.
I'll send another revision that doesn't use request_module().
Kai-Heng
>
> Armin Wolf
>
> >> Guenter
> >>
> >>> res = read_capabilities(resource);
> >>> if (res)
> >>> --
> >>> 2.34.1
> >>>
Powered by blists - more mailing lists