linux-kernel - Re: [PATCH 2/5] toshiba_acpi: Fix illumination not available on certain models

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

Date:	Fri, 5 Sep 2014 22:49:09 -0600
From:	Azael Avalos <coproscefalo@...il.com>
To:	Darren Hart <dvhart@...radead.org>
Cc:	Matthew Garrett <matthew.garrett@...ula.com>,
	"platform-driver-x86@...r.kernel.org" 
	<platform-driver-x86@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/5] toshiba_acpi: Fix illumination not available on
 certain models

Hi there

2014-09-05 20:35 GMT-06:00 Darren Hart <dvhart@...radead.org>:
> On Fri, Sep 05, 2014 at 11:14:04AM -0600, Azael Avalos wrote:
>> Some Toshiba models with illumination support set a different
>> value on the returned codes, thus not allowing the illumination
>> LED to be registered, where it should be.
>>
>> This patch removes a check from toshiba_illumination_available
>> function to allow such models to register the illumination LED.
>>
>> Signed-off-by: Azael Avalos <coproscefalo@...il.com>
>> ---
>>  drivers/platform/x86/toshiba_acpi.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c
>> index a149bc6..4803e7b 100644
>> --- a/drivers/platform/x86/toshiba_acpi.c
>> +++ b/drivers/platform/x86/toshiba_acpi.c
>> @@ -436,7 +436,7 @@ static int toshiba_illumination_available(struct toshiba_acpi_dev *dev)
>>       if (ACPI_FAILURE(status) || out[0] == HCI_FAILURE) {
>>               pr_err("ACPI call to query Illumination support failed\n");
>>               return 0;
>> -     } else if (out[0] == HCI_NOT_SUPPORTED || out[1] != 1) {
>> +     } else if (out[0] == HCI_NOT_SUPPORTED) {
>
> OK, but by eliminating the check, supposedly certain models which do not support
> illumination but do not report it via out[0], but instead via out[1], will now
> attempt to use illumination - correct?

Oh no, the main check is out[0], which either hold success if the
feature is supported
or an HCI/SCI error otherwise.

>
> The end result being user calls to an ACPI function which at best doesn't exist
> and at worst.... does, but does something entirely different.
>
> I admit the potential for a problem is slight, but is it possible to check
> something explicit for support on the newer models rather than removing an
> existing check?

Our only resource right now is the DSDT and actual hardware to test,
as those calls
are not documented anywhere, and everytime the vendor decides to
change something,
we're on the loose end.

All the DSDTs that I previously had all set out[1] to one, so I was
using that as an
extra check to make sure we had illumination support, but now, recent models
set out[1] to zero, and those models, which do happen to have illumination
support (Qosmio X75 for example) were failing to register the LED.

>
> --
> Darren Hart
> Intel Open Source Technology Center



-- 
-- El mundo apesta y vosotros apestais tambien --
--
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/