linux-kernel - Re: [PATCH] acpi: video: improve quirk check

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] [day] [month] [year] [list]

Date:	Wed, 07 Aug 2013 12:35:06 +0800
From:	Aaron Lu <aaron.lwe@...il.com>
To:	Felipe Contreras <felipe.contreras@...il.com>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>, 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 08/04/2013 10:19 PM, 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

The code is introduced by commit a50188dae3089dcd15a6ae793528c157680891f1
where the broken system will always return a constant value for _BQC,
either 0 or 100. So the commit at that time tries to not test a maximum
value for the quirk.

Then we have the ASUS NV56Z problem and its problem is explained in:
https://github.com/aaronlu/linux/commit/0a3d2c5b59caf80ae5bb1ca1fda0f7bf448b38c9
And due to its reverse order of _BCL, testing the minimum value is not
good either.

So if the two values test is going to be adopted, I would suggest avoid
testing edge values. But then I'm not sure if it is still worth to test
two values instead of one.

> 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).
> 
> 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.

If you think _BCM fails before _DOS and that makes acpi_video_bqc_quirk
not correct, I think you can call acpi_video_bus_start_devices before the
acpi_video_bus_get_devices in acpi_video_bus_add to make _BCM work before
we do the quirk test and then add some debug prints in acpi_video_bqc_quirk
and add some test levels to check it out.

-Aaron

> 
> 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.
--
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/