Hi, Guenter, On Wed, 2022-05-11 at 06:12 -0700, Guenter Roeck wrote: > On 5/11/22 00:54, Zhang Rui wrote: > > The acpi_power_meter driver doesn't create any standard hwmon sysfs > > attributes under its hwmon device node, but instead, the driver has > > its > > own code to create the hwmon style sysfs attributes in the ACPI > > device > > node of the ACPI Power Meter device. > > I'm not clear why it was designed in that way. > > > > In order to elimite > > [ 79.960333] power_meter ACPI000D:00: hwmon_device_register() is > > deprecated. Please convert the driver to use > > hwmon_device_register_with_info(). > > convert the driver to use the new API, no chip_info or sysfs_groups > > parameter needed. > > > > The only difference brought by this patch is that the "name" > > attribute > > will be created under the hwmon device node. Not sure if this > > matters or > > not. > > > > Signed-off-by: Zhang Rui <rui.zhang@xxxxxxxxx> > > No, this is not a conversion and not acceptable. Corentin Labbe is > working on the real thing. See > https://patchwork.kernel.org/project/linux-hwmon/patch/20220509063010.3878134-3-clabbe@xxxxxxxxxxxx/ > > Thanks for the pointer. And this was my original intension about how to do the conversion. But then I realized that, just like I described in the changelog, the original sysfs attributes in this driver, although they're hwmon style, but they are actually located under the ACPI device node. And the patch above will move them to the hwmon device node, right? With any patch, this is what I got under the hwmon device node # ls /sys/class/hwmon/hwmon0/ device power subsystem uevent and this is what I got under the ACPI device node # ls /sys/class/hwmon/hwmon0/device/ driver hid hwmon measures modalias name path physical_node powe r power1_model_number power1_oem_info power1_serial_number status subsystem uevent uid Plus, in that patch, I don't see how to handle the power meter capabilities change, i.e. METER_NOTIFY_CONFIG event, in acpi_power_meter_notify(). According to the previous logic, we may need to remove/add different attributes based on the new capabilities. In section 10.4.1 of ACPI Spec 6.4, it says that the _PMC information "remains constant unless either the power meter's firmware or the BMC hardware changes, at which time the platform is required to send Notify(power_meter, 0x80) for the OSPM to re-evaluate _PMC" If this could happen in real life, we cannot rely on a fixed hwmon_chip_info and attribute_groups at driver registration phase. thanks, rui > Guenter > > > --- > > drivers/hwmon/acpi_power_meter.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/hwmon/acpi_power_meter.c > > b/drivers/hwmon/acpi_power_meter.c > > index c405a5869581..81a982dda5af 100644 > > --- a/drivers/hwmon/acpi_power_meter.c > > +++ b/drivers/hwmon/acpi_power_meter.c > > @@ -890,7 +890,8 @@ static int acpi_power_meter_add(struct > > acpi_device *device) > > if (res) > > goto exit_free_capability; > > > > - resource->hwmon_dev = hwmon_device_register(&device->dev); > > + resource->hwmon_dev = hwmon_device_register_with_info(&device- > > >dev, > > + ACPI_POWER_METER_NAME, NULL, NULL, > > NULL); > > if (IS_ERR(resource->hwmon_dev)) { > > res = PTR_ERR(resource->hwmon_dev); > > goto exit_remove; > >
