linux-kernel - Re: [PATCH 8/8] eeepc-laptop: don't assume get

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH6sp9PUSbSj0jWNNv6q=rwqUnpkCoiUBxCUAHSVjP+qrUEa9g@mail.gmail.com>
Date:	Tue, 28 Oct 2014 09:09:03 +0100
From:	Frans Klaver <fransklaver@...il.com>
To:	Darren Hart <dvhart@...radead.org>
Cc:	Corentin Chary <corentin.chary@...il.com>,
	acpi4asus-user <acpi4asus-user@...ts.sourceforge.net>,
	platform-driver-x86 <platform-driver-x86@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 8/8] eeepc-laptop: don't assume get_acpi succeeds

On Tue, Oct 28, 2014 at 6:34 AM, Darren Hart <dvhart@...radead.org> wrote:
> On Wed, Oct 22, 2014 at 09:12:43PM +0200, Frans Klaver wrote:
>> In eeepc_hotk_thaw, we assume that get_acpi() will effectively return a
>> bool. However, it is possible that get_acpi() returns an error instead.
>> We should not be writing error values to the ACPI device, even though
>> it's quite possible that we couldn't contact the ACPI device in the
>> first place.
>>
>> Signed-off-by: Frans Klaver <fransklaver@...il.com>
>> ---
>>  drivers/platform/x86/eeepc-laptop.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
>> index 275a239..14f79ef 100644
>> --- a/drivers/platform/x86/eeepc-laptop.c
>> +++ b/drivers/platform/x86/eeepc-laptop.c
>> @@ -911,7 +911,7 @@ static int eeepc_hotk_thaw(struct device *device)
>>       struct eeepc_laptop *eeepc = dev_get_drvdata(device);
>>
>>       if (eeepc->wlan_rfkill) {
>> -             bool wlan;
>> +             int wlan;
>>
>>               /*
>>                * Work around bios bug - acpi _PTS turns off the wireless led
>> @@ -919,7 +919,8 @@ static int eeepc_hotk_thaw(struct device *device)
>>                * we should kick it ourselves in case hibernation is aborted.
>>                */
>>               wlan = get_acpi(eeepc, CM_ASL_WLAN);
>> -             set_acpi(eeepc, CM_ASL_WLAN, wlan);
>> +             if (wlan >= 0)
>> +                     set_acpi(eeepc, CM_ASL_WLAN, wlan);
>
> And if not? Seems like we should be passing the error code along.

Wouldn't that mean that you cannot thaw the system if the wlan acpi call fails?

I'd rather have my system up and running without wlan, than I'd have
my system down because we couldn't start wlan. This is of course
assuming that returning an error from eeepc_hotk_thaw means the
thawing stops.

Thanks,
Frans
--
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/