[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080804212952.GC24927@khazad-dum.debian.net>
Date: Mon, 4 Aug 2008 18:29:52 -0300
From: Henrique de Moraes Holschuh <hmh@....eng.br>
To: Matthew Garrett <mjg59@...f.ucam.org>
Cc: corentincj@...aif.net, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, IvDoorn@...il.com
Subject: Re: [PATCH 2/2] eeepc-laptop: Use standard interfaces
On Mon, 04 Aug 2008, Matthew Garrett wrote:
> +static int eeepc_wlan_rfkill_set(void *data, enum rfkill_state state)
> +{
> + return set_acpi(CM_ASL_WLAN, state);
> +}
> +
> +static int eeepc_wlan_rfkill_state(void *data, enum rfkill_state *state)
> +{
> + *state = get_acpi(CM_ASL_WLAN);
> + return 0;
> +}
This might just be style, but I'd rather you didn't do this unless get_acpi
and set_acpi do take enum rfkill_state... Doing state conversion would be a
lot more future-proof, as well:
Something like:
set_acpi(CM_ASL_WLAN, (state == RFKILL_STATE_UNBLOCKED) ? 0 : 1);
And:
*state = get_acpi(CM_ASL_WLAN) ? RFKILL_STATE_SOFT_BLOCKED :
RFKILL_STATE_UNBLOCKED;
Adjust as needed.
> + ehotk->eeepc_wlan_rfkill->user_claim_unsupported = 0;
This is not needed, and if we get rid of user_claim_unsupported later, your
code wouldn't need changes if you get rid of that line.
I have not paid much attention to it yet, but so far I have failed to
understand what user_claim_unsupported is good for in the new style rfkill
interface.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
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