linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2017-06-13 18:42 UTC|newest]

Thread overview: 24+ 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-16 16:33             ` Mario.Limonciello
2017-06-17 16:34               ` Pali Rohár
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).