[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <23723258.099Re4s3PJ@vostro.rjw.lan>
Date: Mon, 05 Aug 2013 16:04:11 +0200
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Felipe Contreras <felipe.contreras@...il.com>
Cc: Aaron Lu <aaron.lwe@...il.com>, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, Len Brown <lenb@...nel.org>,
Zhang Rui <rui.zhang@...el.com>
Subject: Re: [PATCH] acpi: video: improve quirk check
On Sunday, August 04, 2013 09:19:56 AM Felipe Contreras wrote:
> On Sun, Aug 4, 2013 at 9:19 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> > On Sunday, August 04, 2013 01:42:49 AM Felipe Contreras wrote:
>
> >> Personally I think there are better ways to fix the code for the
> >> synthetic case than what you patch does, which will also make _BQC
> >> work. That can be discussed later though, the one-liner is simple, and
> >> it works.
> >
> > So, let's assume that the one-liner goes into 3.11 and work further with that
> > assumption.
> >
> > How would you address the sythetic case (on top of the one-liner)?
>
> I would write and read two values instead of one. The code is trying
> to check if _BQC is always returning the maximum, and if you try with
> two values you can be absolutely certain if that's happening or not;
> it doesn't even matter which values you choose. Even in the synthetic
> case that only has two values the check would work correctly and
> detect that _BQC works correctly (or not).
I like that.
> In my machine I think the issue is slightly different, I think _BCM is
> failing, at least until enabling the _DOS thing, but at the end of the
> day it's the same thing for the check; _BQC is always returning the
> same value, and the code above will find that out, regardless of which
> values are tested.
>
> For my particular machine though, I think it's more interesting to
> find out why _BCM is failing before _DOS, and why efaa14c made it
> work. If that is actually the case.
That depends on how the BIOS+platform is designed and that may change from
one system to another quite a bit.
The only common denominator is what Windows expects (and that unfortunately
depends on the version of Windows too), because that's the functionality
which is likely to have been tested. Anything else is likely to be untested
and therefore most probably buggy.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists