[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <525EBB30.5030602@nvidia.com>
Date: Wed, 16 Oct 2013 12:13:36 -0400
From: Rhyland Klein <rklein@...dia.com>
To: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
CC: "John W. Linville" <linville@...driver.com>,
Johannes Berg <johannes@...solutions.net>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 0/5] rfkill-gpio: ACPI support
On 10/16/2013 6:53 AM, Heikki Krogerus wrote:
> Hi,
>
> The first patches prepare the driver for the support. The last patch
> can then add the support quite easily. With these patches, adding DT
> support later will be quite straight forward if someone needs it.
>
>
> Heikki Krogerus (5):
> net: rfkill: gpio: convert to resource managed allocation
> net: rfkill: gpio: clean up clock handling
> net: rfkill: gpio: spinlock-safe GPIO access
> net: rfkill: gpio: prepare for DT and ACPI support
> net: rfkill: gpio: add ACPI support
>
> net/rfkill/Kconfig | 2 +-
> net/rfkill/rfkill-gpio.c | 211 ++++++++++++++++++++++-------------------------
> 2 files changed, 99 insertions(+), 114 deletions(-)
>
Strictly speaking, duplicating the pdata fields into the
rfkill_gpio_data structure isn't really necessary. Many drivers simply
have the dt parsing or in this case ACPI parsing generate a
platform_data structure which would then be saved in the
rfkill_gpio_data structure.
In this case, since it is only a few fields, I am not too worried and I
am fine either way.
Acked-by: Rhyland Klein <rklein@...dia.com>
--
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists