From: Darren Hart <dvhart@infradead.org>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Andy Shevchenko <andy@infradead.org>,
Andy Lutomirski <luto@kernel.org>,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RFC: platform/x86: wmi: Fix check for method instance number
Date: Tue, 13 Jun 2017 11:42:28 -0700 [thread overview]
Message-ID: <20170613184228.GC22450@fury> (raw)
In-Reply-To: <201706132004.58051@pali>
On Tue, Jun 13, 2017 at 08:04:57PM +0200, Pali Rohár wrote:
> On Tuesday 13 June 2017 18:49:51 Darren Hart wrote:
> > On Sat, Jun 10, 2017 at 09:15:57PM +0200, Pali Rohár wrote:
> > > On Saturday 27 May 2017 13:55:34 Pali Rohár wrote:
> > > > instance_count defines number of instances of data block and
> > > > instance itself is indexed from zero, which means first instance
> > > > has number 0. Therefore check for invalid instance should be
> > > > non-strict inequality.
> > > >
> > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > ---
> > > > I'm marking this patch as RFC because it is not tested at all and
> > > > probably could break existing WMI drivers. Some WMI drivers pass
> > > > instance number 1 and I'm not sure if ACPI-WMI bytecode for those
> > > > machines has really two instances. In more cases ACPI-WMI
> > > > bytecode does not check instance number if supports only one
> > > > instance. So then any instance id can be used for correct
> > > > execution of ACPI-WMI method.
> > > >
> > > > So this patch is open for discussion.
> > >
> > > Hi! Any comments?
> >
> > Hi Pali,
> >
> > This change appears correct to me, but your comment about this
> > parameter being ignored by ACPI-WMI is definitely concerning. Since
> > this doesn't address a specific failure report, and it has the
> > potential to break functional drivers, I wouldn't want to merge it
> > without some evidence that those drivers still work.
>
> I agree that it should not be merged without any other testing or
> discussion. Reason why I marked it as RFC.
>
> ACPI bytecode (which implements WMI functions) is often ignoring
> instance method if there is only one instance. So it does not have to
> decide which instance to call based on parameter.
>
> IIRC it is also stated in that MSDN documentation.
That is my reading of it as well:
"One parameter is passed to the method--the index of the instance, which
is of type ULONG. Data blocks registered with only a single instance can
ignore the parameter."
https://msdn.microsoft.com/en-us/library/windows/hardware/dn614028(v=vs.85).aspx
The "can" instead of "shall" makes our job harder. We could special case
the instance_count == 1 case and either skip the test (relying on the
WMI code to ignore or return an appropriate error - risky) or we could
force it to 0, which should always work per the specification, but it's
possible some firmware out there is just broken and misuses this
input... oh man... I bet that exists somewhere... "we can ignore
instance_count, so let's use it as a simple integer input for FOO....
ugh.
>
> > I'd suggest reaching out to the maintainers and contributors to the
> > drivers you mention to request some help in testing.
>
> Seems sane. Grep for all methods with instance number different as zero
> (or just number one -- which can be suspicious as somebody could thought
> that indexing is from one, not zer) and try to receive ACPI/BMOF data
> and verify it.
This would still be the ideal solution, verify we can do the right thing
without breaking existing drivers. Agreed.
--
Darren Hart
VMware Open Source Technology Center
next prev parent reply other threads:[~2017-06-13 18:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-27 11:55 [PATCH] RFC: platform/x86: wmi: Fix check for method instance number Pali Rohár
2017-06-10 19:15 ` Pali Rohár
2017-06-13 16:49 ` Darren Hart
2017-06-13 18:04 ` Pali Rohár
2017-06-13 18:42 ` Darren Hart [this message]
2017-06-14 15:46 ` Pali Rohár
2017-06-14 20:39 ` Darren Hart
2017-06-15 13:59 ` Pali Rohár
2017-06-15 15:16 ` Mario.Limonciello
2017-06-15 15:16 ` Mario.Limonciello
2017-06-16 16:33 ` Mario.Limonciello
2017-06-16 16:33 ` Mario.Limonciello
2017-06-17 16:34 ` Pali Rohár
2017-06-21 21:52 ` Mario.Limonciello
2017-06-21 21:52 ` Mario.Limonciello
2017-06-22 7:33 ` Pali Rohár
2017-06-17 16:47 ` Pali Rohár
2017-06-19 15:02 ` joeyli
2017-07-05 9:51 ` Pali Rohár
2017-07-05 19:30 ` David Airlie
2017-07-05 20:24 ` Pali Rohár
2017-08-06 15:35 ` Pali Rohár
2017-08-06 16:10 ` Andy Shevchenko
2017-08-06 20:21 ` Pali Rohár
2017-08-06 15:42 ` Pali Rohár
2017-08-06 16:18 ` Hans de Goede
2017-08-06 20:16 ` Pali Rohár
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170613184228.GC22450@fury \
--to=dvhart@infradead.org \
--cc=andy@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=pali.rohar@gmail.com \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.