linux-kernel - Re: [PATCH v11 02/14] HP BIOSCFG driver

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: <b4b9fb11-d6d0-42e6-9193-ba3c2c846071@t-8ch.de>
Date:   Tue, 25 Apr 2023 07:28:00 +0200
From:   Thomas Weißschuh <thomas@...ch.de>
To:     Jorge Lopez <jorgealtxwork@...il.com>
Cc:     hdegoede@...hat.com, platform-driver-x86@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v11 02/14] HP BIOSCFG driver - biosattr-interface

On 2023-04-24 17:14:57-0500, Jorge Lopez wrote:
> Sorry for asking again.  I just want to be understand exactly what I must do.

No problem!

> > > > >
> > > > > > +     args->command = command;
> > > > > > +     args->commandtype = query;
> > > > > > +     args->datasize = insize;
> > > > > > +     memcpy(args->data, buffer, flex_array_size(args, data, insize));
> > > > > > +
> > > > > > +     ret = wmi_evaluate_method(HP_WMI_BIOS_GUID, 0, mid, &input, &output);
> > > > >
> > > > > The driver is mixing calls to the UUID based APIs and the wmi_device
> > > > > ones.
> > > > > wmi_devices is newer and preferred.
> > > >
> > > > The driver  calls wmi_evaluate_method when initiating an WMI call.
> > > > Where is the driver mixing calls to the UUID based APIs and the
> > > > wmi_device one?
> > > > WMI calls are made by calling hp_wmi_perform_query() which invokes
> > > > wmi_evaluate_method().
> > > > Did I miss something?
> > >
> > > wmi_evaluate_method() is UUID-based.
> > > struct wmi_driver is wmi_device based.
> > >
> > > The wmi_driver/wmi_device code essentially does nothing and is only used
> > > to validate that a device is present.
> > > The same can be done more easily wmi_has_guid().
> > >
> >
> 
> Are you asking to replace all calls to wmi_evaluate_method() which is
> UUID based API with calls to  wmidev_evaluate_method() which is
> wmi_device based?  Correct?

To be honest I'm not 100% sure.

wmi_device is great and perferct for simple drivers binding to a single
UUID.

But it does not handle multi-UUID logic as your driver needs very well.

I would argue to stick to the legacy calls as it allows you to drop a
bunch of code and makes the initialization flow more straightforward.

But I don't know if somebody else won't ask for wmi_device later.