On Wed, 28 Nov 2018 01:49:48 +0100,
ayman.bagabas@xxxxxxxxx wrote:
>
> On Tue, 2018-11-27 at 17:52 +0200, Andy Shevchenko wrote:
> > On Tue, Nov 27, 2018 at 1:02 PM Takashi Iwai <tiwai@xxxxxxx> wrote:
> > > On Tue, 27 Nov 2018 03:57:48 +0100,
> > > Ayman Bagabas wrote:
> > > > + handle = ACPI_HANDLE(&inputdev->dev);
> > > > + args[0].type = args[1].type = args[2].type =
> > > > ACPI_TYPE_INTEGER;
> > > > + args[1].integer.value = 0x04;
> > > > +
> > > > + if (acpi_has_method(handle, method =
> > > > "\\_SB.PCI0.LPCB.EC0.SPIN")) {
> > >
> > > This looks ugly... And checkpatch also complains.
> >
> > Good point.
> > Actually another question is what handle do we get here? Can we check
> > method name by relative path, i.e. "SPIN" / "WPIN" instead?
>
> The handle is a NULL handle at "\". Should I use acpi_get_handle(NULL,
> "\\_SB.PCI0.LPCB.EC0", &handle)? EC0 is a acpi device HID:PNP0C09.
Then passing NULL explicitly avoid confusion, IMO.
> > > > + args[0].integer.value = 0;
> > > > + args[2].integer.value = on ? 1 : 0;
> > > > + } else if (acpi_has_method(handle, method =
> > > > "\\_SB.PCI0.LPCB.EC0.WPIN")) {
> > > > + args[0].integer.value = 1;
> > > > + args[2].integer.value = on ? 0 : 1;
> > > > + } else {
> > > > + dev_err(&inputdev->dev, "Unable to find ACPI
> > > > method\n");
> > > > + return -ENOSYS;
> > > > + }
> > >
> > > Can these checks be done at initialization phase? It doesn't seem
> > > needed to be executed at each call.
> >
> > Agree.
> >
>
> Even if it was done in init phase, we still need to check what acpi
> method should be used and based on that and micmute status we set the
> arguments args[0] and args[2], args[1] is the pin value. We could check
> these using event_guid, but that would assume the methods exist for
> each guid.
> For example, if event_guid == MBX_EVENT_GUID, then method SPIN should
> be used.
Hmm, I can't read it from your patch... Where is event_guid checked
in huawei_wmi_mucmute_led_set()? I thought it checks only
acpi_has_method().
thanks,
Takashi
