All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] net: rfkill: add generic gpio rfkill driver
@ 2011-05-12  0:21 Rhyland Klein
  2011-05-12  8:31 ` Johannes Berg
  0 siblings, 1 reply; 12+ messages in thread
From: Rhyland Klein @ 2011-05-12  0:21 UTC (permalink / raw)
  To: Johannes Berg; +Cc: olof, linux-wireless, linux-kernel, Rhyland Klein

This adds a new generic gpio rfkill driver to support rfkill switches
which are controlled by gpios. The driver also supports passing in
data about the clock for the radio, so that when rfkill is blocking,
it can disable the clock.

This driver assumes platform data is passed from the board files to
configure it for specific devices.

Change-Id: I10bdce04c9d6e0489ad208ebbc6e78ab4424f4a8
From: Anantha Idapalapati <aidapalapati@nvidia.com>
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
---
v2:
	- Moved to dynamic allocation for gpio names
	- added state of clock enabled to prevent double disabling/enabling
	- fixed Kconfig description
	- removed setting initial state, as rfkill-core will do it
	- enabled using this driver as a module

 include/linux/rfkill-gpio.h |   43 ++++++++
 net/rfkill/Kconfig          |    8 ++
 net/rfkill/Makefile         |    1 +
 net/rfkill/rfkill-gpio.c    |  227 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 279 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/rfkill-gpio.h
 create mode 100644 net/rfkill/rfkill-gpio.c

diff --git a/include/linux/rfkill-gpio.h b/include/linux/rfkill-gpio.h
new file mode 100644
index 0000000..a175d05
--- /dev/null
+++ b/include/linux/rfkill-gpio.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2011, NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ */
+
+
+#ifndef __RFKILL_GPIO_H
+#define __RFKILL_GPIO_H
+
+#include <linux/types.h>
+#include <linux/rfkill.h>
+
+/**
+ * struct rfkill_gpio_platform_data - platform data for rfkill gpio device.
+ * for unused gpio's, the expected value is -1.
+ * @name:		name for the gpio rf kill instance
+ * @reset_gpio:		GPIO which is used for reseting rfkill switch
+ * @shutdown_gpio:	GPIO which is used for shutdown of rfkill switch
+ * @power_clk_name:	[optional] name of clk to turn off while blocked
+ */
+
+struct rfkill_gpio_platform_data {
+	char			*name;
+	int			reset_gpio;
+	int			shutdown_gpio;
+	const char		*power_clk_name;
+	enum rfkill_type	type;
+};
+
+#endif /* __RFKILL_GPIO_H */
diff --git a/net/rfkill/Kconfig b/net/rfkill/Kconfig
index 48464ca..1457456 100644
--- a/net/rfkill/Kconfig
+++ b/net/rfkill/Kconfig
@@ -33,3 +33,11 @@ config RFKILL_REGULATOR
 
           To compile this driver as a module, choose M here: the module will
           be called rfkill-regulator.
+
+config RFKILL_GPIO
+	tristate "GPIO RFKILL driver"
+	depends on RFKILL && GPIOLIB
+	help
+	  If you say yes here you get support of a generic gpio RFKILL
+	  driver. The platform should fill in the appropriate fields in the
+	  rfkill_gpio_platform_data structure and pass that to the driver.
diff --git a/net/rfkill/Makefile b/net/rfkill/Makefile
index d9a5a58..3117687 100644
--- a/net/rfkill/Makefile
+++ b/net/rfkill/Makefile
@@ -6,3 +6,4 @@ rfkill-y			+= core.o
 rfkill-$(CONFIG_RFKILL_INPUT)	+= input.o
 obj-$(CONFIG_RFKILL)		+= rfkill.o
 obj-$(CONFIG_RFKILL_REGULATOR)	+= rfkill-regulator.o
+obj-$(CONFIG_RFKILL_GPIO)	+= rfkill-gpio.o
diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
new file mode 100644
index 0000000..256c5dd
--- /dev/null
+++ b/net/rfkill/rfkill-gpio.c
@@ -0,0 +1,227 @@
+/*
+ * Copyright (c) 2011, NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ */
+
+#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/rfkill.h>
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+#include <linux/slab.h>
+
+#include <linux/rfkill-gpio.h>
+
+enum rfkill_gpio_clk_state {
+	UNSPECIFIED = 0,
+	PWR_ENABLED,
+	PWR_DISABLED
+};
+
+#define PWR_CLK_SET(_RF, _EN) \
+	((_RF)->pwr_clk_enabled = (!(_EN) ? PWR_ENABLED : PWR_DISABLED))
+#define PWR_CLK_ENABLED(_RF) ((_RF)->pwr_clk_enabled == PWR_ENABLED)
+#define PWR_CLK_DISABLED(_RF) ((_RF)->pwr_clk_enabled != PWR_ENABLED)
+
+struct rfkill_gpio_data {
+	struct rfkill_gpio_platform_data	*pdata;
+	struct rfkill				*rfkill_dev;
+	char					*reset_name;
+	char					*shutdown_name;
+	enum rfkill_gpio_clk_state		pwr_clk_enabled;
+	struct clk				*pwr_clk;
+};
+
+static int rfkill_gpio_set_power(void *data, bool blocked)
+{
+	struct rfkill_gpio_data *rfkill = data;
+
+	if (blocked) {
+		if (gpio_is_valid(rfkill->pdata->shutdown_gpio))
+			gpio_direction_output(rfkill->pdata->shutdown_gpio, 0);
+		if (gpio_is_valid(rfkill->pdata->reset_gpio))
+			gpio_direction_output(rfkill->pdata->reset_gpio, 0);
+		if (rfkill->pwr_clk && PWR_CLK_ENABLED(rfkill))
+			clk_disable(rfkill->pwr_clk);
+	} else {
+		if (rfkill->pwr_clk && PWR_CLK_DISABLED(rfkill))
+			clk_enable(rfkill->pwr_clk);
+		if (gpio_is_valid(rfkill->pdata->reset_gpio))
+			gpio_direction_output(rfkill->pdata->reset_gpio, 1);
+		if (gpio_is_valid(rfkill->pdata->shutdown_gpio))
+			gpio_direction_output(rfkill->pdata->shutdown_gpio, 1);
+	}
+
+	if (rfkill->pwr_clk)
+		PWR_CLK_SET(rfkill, blocked);
+
+	return 0;
+}
+
+static const struct rfkill_ops rfkill_gpio_ops = {
+	.set_block = rfkill_gpio_set_power,
+};
+
+static int rfkill_gpio_probe(struct platform_device *pdev)
+{
+	struct rfkill_gpio_data *rfkill;
+	struct rfkill_gpio_platform_data *pdata = pdev->dev.platform_data;
+	int ret = 0;
+	int len = 0;
+
+	if (!pdata) {
+		pr_warn("%s: No platform data specified\n", __func__);
+		return -EINVAL;
+	}
+
+	/* make sure at-least one of the GPIO is defined and that
+	 * a name is specified for this instance */
+	if (!pdata->name || (!gpio_is_valid(pdata->reset_gpio) &&
+		!gpio_is_valid(pdata->shutdown_gpio))) {
+		pr_warn("%s: invalid platform data\n", __func__);
+		return -EINVAL;
+	}
+
+	rfkill = kzalloc(sizeof(*rfkill), GFP_KERNEL);
+	if (!rfkill)
+		return -ENOMEM;
+
+	rfkill->pdata = pdata;
+
+	len = strlen(pdata->name);
+	rfkill->reset_name = kzalloc(len + 7, GFP_KERNEL);
+	if (!rfkill->reset_name) {
+		ret = -ENOMEM;
+		goto fail_alloc;
+	}
+
+	rfkill->shutdown_name = kzalloc(len + 10, GFP_KERNEL);
+	if (!rfkill->shutdown_name) {
+		ret = -ENOMEM;
+		goto fail_reset_name;
+	}
+
+	snprintf(rfkill->reset_name, len + 6 , "%s_reset", pdata->name);
+	snprintf(rfkill->shutdown_name, len + 9, "%s_shutdown", pdata->name);
+
+	if (pdata->power_clk_name) {
+		rfkill->pwr_clk = clk_get(&pdev->dev, pdata->power_clk_name);
+		if (IS_ERR(rfkill->pwr_clk)) {
+			pr_warn("%s: can't find pwr_clk.\n", __func__);
+			goto fail_shutdown_name;
+		}
+	}
+
+	if (gpio_is_valid(pdata->reset_gpio)) {
+		ret = gpio_request(pdata->reset_gpio, rfkill->reset_name);
+		if (ret) {
+			pr_warn("%s: failed to get reset gpio.\n", __func__);
+			goto fail_clock;
+		}
+	}
+
+	if (gpio_is_valid(pdata->shutdown_gpio)) {
+		ret = gpio_request(pdata->shutdown_gpio, rfkill->shutdown_name);
+		if (ret) {
+			pr_warn("%s: failed to get shutdown gpio.\n", __func__);
+			goto fail_reset;
+		}
+	}
+
+	rfkill->rfkill_dev = rfkill_alloc(pdata->name, &pdev->dev, pdata->type,
+				&rfkill_gpio_ops, rfkill);
+	if (!rfkill->rfkill_dev)
+		goto fail_shutdown;
+
+	ret = rfkill_register(rfkill->rfkill_dev);
+	if (ret < 0)
+		goto fail_rfkill;
+
+	platform_set_drvdata(pdev, rfkill);
+
+	dev_info(&pdev->dev, "%s device registered.\n", pdata->name);
+
+	return 0;
+
+fail_rfkill:
+	rfkill_destroy(rfkill->rfkill_dev);
+fail_shutdown:
+	if (gpio_is_valid(pdata->shutdown_gpio))
+		gpio_free(pdata->shutdown_gpio);
+fail_reset:
+	if (gpio_is_valid(pdata->reset_gpio))
+		gpio_free(pdata->reset_gpio);
+fail_clock:
+	if (rfkill->pwr_clk)
+		clk_put(rfkill->pwr_clk);
+fail_shutdown_name:
+	kfree(rfkill->shutdown_name);
+fail_reset_name:
+	kfree(rfkill->reset_name);
+fail_alloc:
+	kfree(rfkill);
+
+	return ret;
+}
+
+static int rfkill_gpio_remove(struct platform_device *pdev)
+{
+	struct rfkill_gpio_data *rfkill = platform_get_drvdata(pdev);
+
+	rfkill_unregister(rfkill->rfkill_dev);
+	rfkill_destroy(rfkill->rfkill_dev);
+	if (gpio_is_valid(rfkill->pdata->shutdown_gpio))
+		gpio_free(rfkill->pdata->shutdown_gpio);
+	if (gpio_is_valid(rfkill->pdata->reset_gpio))
+		gpio_free(rfkill->pdata->reset_gpio);
+	if (rfkill->pwr_clk && PWR_CLK_ENABLED(rfkill))
+		clk_disable(rfkill->pwr_clk);
+	if (rfkill->pwr_clk)
+		clk_put(rfkill->pwr_clk);
+	kfree(rfkill->shutdown_name);
+	kfree(rfkill->reset_name);
+	kfree(rfkill);
+
+	return 0;
+}
+
+static struct platform_driver rfkill_gpio_driver = {
+	.probe = rfkill_gpio_probe,
+	.remove = __devexit_p(rfkill_gpio_remove),
+	.driver = {
+		   .name = "rfkill_gpio",
+		   .owner = THIS_MODULE,
+	},
+};
+
+static int __init rfkill_gpio_init(void)
+{
+	return platform_driver_register(&rfkill_gpio_driver);
+}
+
+static void __exit rfkill_gpio_exit(void)
+{
+	platform_driver_unregister(&rfkill_gpio_driver);
+}
+
+module_init(rfkill_gpio_init);
+module_exit(rfkill_gpio_exit);
+
+MODULE_DESCRIPTION("gpio rfkill");
+MODULE_AUTHOR("NVIDIA");
+MODULE_LICENSE("GPL");
-- 
1.7.5.1


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] net: rfkill: add generic gpio rfkill driver
  2011-05-12  0:21 [PATCH v2] net: rfkill: add generic gpio rfkill driver Rhyland Klein
@ 2011-05-12  8:31 ` Johannes Berg
  2011-05-12 18:23   ` Rhyland Klein
  0 siblings, 1 reply; 12+ messages in thread
From: Johannes Berg @ 2011-05-12  8:31 UTC (permalink / raw)
  To: Rhyland Klein; +Cc: olof, linux-wireless, linux-kernel

On Wed, 2011-05-11 at 17:21 -0700, Rhyland Klein wrote:

> +enum rfkill_gpio_clk_state {
> +	UNSPECIFIED = 0,
> +	PWR_ENABLED,
> +	PWR_DISABLED

Are you sure starting out with UNSPECIFIED works? Then you'll always
change, but if the clock was enabled already you still enable it on the
first set_block() from rfkill, which still has the refcount problem, no?
It seems to me that the original state has to be passed in from the
platform?

johannes


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] net: rfkill: add generic gpio rfkill driver
  2011-05-12  8:31 ` Johannes Berg
@ 2011-05-12 18:23   ` Rhyland Klein
  2011-05-12 18:40     ` Johannes Berg
  0 siblings, 1 reply; 12+ messages in thread
From: Rhyland Klein @ 2011-05-12 18:23 UTC (permalink / raw)
  To: Johannes Berg; +Cc: olof, linux-wireless, linux-kernel

On Thu, 2011-05-12 at 01:31 -0700, Johannes Berg wrote:
> On Wed, 2011-05-11 at 17:21 -0700, Rhyland Klein wrote:
> 
> > +enum rfkill_gpio_clk_state {
> > +	UNSPECIFIED = 0,
> > +	PWR_ENABLED,
> > +	PWR_DISABLED
> 
> Are you sure starting out with UNSPECIFIED works? Then you'll always
> change, but if the clock was enabled already you still enable it on the
> first set_block() from rfkill, which still has the refcount problem, no?
> It seems to me that the original state has to be passed in from the
> platform?
> 
> johannes
> 

I thought about that. But I decided the clock that it is possible to
have the clock used for the radio used for something else right? in
which case, the driver will leave the clk in whatever state it initially
finds it. I.e. if the clock is disabled, then it will enable it only
once and work, if it is enabled, it will add a refcount (only once) and
then work and disable it again only once. It never changes the refcount
in either direction by more than 1, and this way the initial setting of
the clock is irrelevant. The board files can simply initialize the block
as off if that is the initial clk state they want.

rhyland




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] net: rfkill: add generic gpio rfkill driver
  2011-05-12 18:23   ` Rhyland Klein
@ 2011-05-12 18:40     ` Johannes Berg
  2011-05-12 18:52       ` Rhyland Klein
  0 siblings, 1 reply; 12+ messages in thread
From: Johannes Berg @ 2011-05-12 18:40 UTC (permalink / raw)
  To: Rhyland Klein; +Cc: olof, linux-wireless, linux-kernel

On Thu, 2011-05-12 at 11:23 -0700, Rhyland Klein wrote:

> > Are you sure starting out with UNSPECIFIED works? Then you'll always
> > change, but if the clock was enabled already you still enable it on the
> > first set_block() from rfkill, which still has the refcount problem, no?
> > It seems to me that the original state has to be passed in from the
> > platform?

> I thought about that. But I decided the clock that it is possible to
> have the clock used for the radio used for something else right? 

Sure.

> in
> which case, the driver will leave the clk in whatever state it initially
> finds it. I.e. if the clock is disabled, then it will enable it only
> once and work, if it is enabled, it will add a refcount (only once) and
> then work and disable it again only once. It never changes the refcount
> in either direction by more than 1, and this way the initial setting of
> the clock is irrelevant. The board files can simply initialize the block
> as off if that is the initial clk state they want.

The issue is that depending on how you boot, the first refcount change
might be +1 or it might be -1.

If rfkill decides that at the time of loading wifi should be off, then
the first change would be -1, and after that it would flip between 0 and
-1.

If, on the other hand, rfkill decides that at the time of loading the
driver wifi should be on, then the first change would be +1 and it'll
flip between 0 and +1.

This seems like it'll cause issues at some point, so I think you should
either allow the driver to set the initial state or hardcode one of
these possibilities (so at least it's predictable)

johannes


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] net: rfkill: add generic gpio rfkill driver
  2011-05-12 18:40     ` Johannes Berg
@ 2011-05-12 18:52       ` Rhyland Klein
  2011-05-12 19:02         ` Johannes Berg
  0 siblings, 1 reply; 12+ messages in thread
From: Rhyland Klein @ 2011-05-12 18:52 UTC (permalink / raw)
  To: Johannes Berg; +Cc: olof, linux-wireless, linux-kernel

On Thu, 2011-05-12 at 11:40 -0700, Johannes Berg wrote:
> On Thu, 2011-05-12 at 11:23 -0700, Rhyland Klein wrote:
> 
> > > Are you sure starting out with UNSPECIFIED works? Then you'll always
> > > change, but if the clock was enabled already you still enable it on the
> > > first set_block() from rfkill, which still has the refcount problem, no?
> > > It seems to me that the original state has to be passed in from the
> > > platform?
> 
> > I thought about that. But I decided the clock that it is possible to
> > have the clock used for the radio used for something else right? 
> 
> Sure.
> 
> > in
> > which case, the driver will leave the clk in whatever state it initially
> > finds it. I.e. if the clock is disabled, then it will enable it only
> > once and work, if it is enabled, it will add a refcount (only once) and
> > then work and disable it again only once. It never changes the refcount
> > in either direction by more than 1, and this way the initial setting of
> > the clock is irrelevant. The board files can simply initialize the block
> > as off if that is the initial clk state they want.
> 
> The issue is that depending on how you boot, the first refcount change
> might be +1 or it might be -1.
> 
> If rfkill decides that at the time of loading wifi should be off, then
> the first change would be -1, and after that it would flip between 0 and
> -1.
> 
> If, on the other hand, rfkill decides that at the time of loading the
> driver wifi should be on, then the first change would be +1 and it'll
> flip between 0 and +1.
> 
> This seems like it'll cause issues at some point, so I think you should
> either allow the driver to set the initial state or hardcode one of
> these possibilities (so at least it's predictable)
> 
> johannes
> 

I won't go negative, if you look, it only will disable clock if it knows
it has already enabled it. 

rhyland


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] net: rfkill: add generic gpio rfkill driver
  2011-05-12 18:52       ` Rhyland Klein
@ 2011-05-12 19:02         ` Johannes Berg
  2011-05-12 21:23           ` Rhyland Klein
  0 siblings, 1 reply; 12+ messages in thread
From: Johannes Berg @ 2011-05-12 19:02 UTC (permalink / raw)
  To: Rhyland Klein; +Cc: olof, linux-wireless, linux-kernel

On Thu, 2011-05-12 at 11:52 -0700, Rhyland Klein wrote:

> > If, on the other hand, rfkill decides that at the time of loading the
> > driver wifi should be on, then the first change would be +1 and it'll
> > flip between 0 and +1.
> > 
> > This seems like it'll cause issues at some point, so I think you should
> > either allow the driver to set the initial state or hardcode one of
> > these possibilities (so at least it's predictable)

> I won't go negative, if you look, it only will disable clock if it knows
> it has already enabled it. 

Ah, you're right, I misread the macros.

johannes


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] net: rfkill: add generic gpio rfkill driver
  2011-05-12 19:02         ` Johannes Berg
@ 2011-05-12 21:23           ` Rhyland Klein
  2011-05-13  7:15             ` Johannes Berg
  0 siblings, 1 reply; 12+ messages in thread
From: Rhyland Klein @ 2011-05-12 21:23 UTC (permalink / raw)
  To: Johannes Berg; +Cc: olof, linux-wireless, linux-kernel

On Thu, 2011-05-12 at 12:02 -0700, Johannes Berg wrote:
> On Thu, 2011-05-12 at 11:52 -0700, Rhyland Klein wrote:
> 
> > > If, on the other hand, rfkill decides that at the time of loading the
> > > driver wifi should be on, then the first change would be +1 and it'll
> > > flip between 0 and +1.
> > > 
> > > This seems like it'll cause issues at some point, so I think you should
> > > either allow the driver to set the initial state or hardcode one of
> > > these possibilities (so at least it's predictable)
> 
> > I won't go negative, if you look, it only will disable clock if it knows
> > it has already enabled it. 
> 
> Ah, you're right, I misread the macros.
> 
> johannes
> 
So the patch is good as is?

rhyland



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] net: rfkill: add generic gpio rfkill driver
  2011-05-12 21:23           ` Rhyland Klein
@ 2011-05-13  7:15             ` Johannes Berg
  2011-05-13 19:02               ` Rhyland Klein
  0 siblings, 1 reply; 12+ messages in thread
From: Johannes Berg @ 2011-05-13  7:15 UTC (permalink / raw)
  To: Rhyland Klein; +Cc: olof, linux-wireless, linux-kernel

On Thu, 2011-05-12 at 14:23 -0700, Rhyland Klein wrote:
> On Thu, 2011-05-12 at 12:02 -0700, Johannes Berg wrote:
> > On Thu, 2011-05-12 at 11:52 -0700, Rhyland Klein wrote:
> > 
> > > > If, on the other hand, rfkill decides that at the time of loading the
> > > > driver wifi should be on, then the first change would be +1 and it'll
> > > > flip between 0 and +1.
> > > > 
> > > > This seems like it'll cause issues at some point, so I think you should
> > > > either allow the driver to set the initial state or hardcode one of
> > > > these possibilities (so at least it's predictable)
> > 
> > > I won't go negative, if you look, it only will disable clock if it knows
> > > it has already enabled it. 
> > 
> > Ah, you're right, I misread the macros.

> So the patch is good as is?

I think so, yes.

johannes


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] net: rfkill: add generic gpio rfkill driver
  2011-05-13  7:15             ` Johannes Berg
@ 2011-05-13 19:02               ` Rhyland Klein
  2011-05-13 19:20                 ` John W. Linville
  0 siblings, 1 reply; 12+ messages in thread
From: Rhyland Klein @ 2011-05-13 19:02 UTC (permalink / raw)
  To: John W. Linville; +Cc: olof, linux-wireless, linux-kernel, Johannes Berg

On Fri, 2011-05-13 at 00:15 -0700, Johannes Berg wrote:
> On Thu, 2011-05-12 at 14:23 -0700, Rhyland Klein wrote:
> > On Thu, 2011-05-12 at 12:02 -0700, Johannes Berg wrote:
> > > On Thu, 2011-05-12 at 11:52 -0700, Rhyland Klein wrote:
> > > 
> > > > > If, on the other hand, rfkill decides that at the time of loading the
> > > > > driver wifi should be on, then the first change would be +1 and it'll
> > > > > flip between 0 and +1.
> > > > > 
> > > > > This seems like it'll cause issues at some point, so I think you should
> > > > > either allow the driver to set the initial state or hardcode one of
> > > > > these possibilities (so at least it's predictable)
> > > 
> > > > I won't go negative, if you look, it only will disable clock if it knows
> > > > it has already enabled it. 
> > > 
> > > Ah, you're right, I misread the macros.
> 
> > So the patch is good as is?
> 
> I think so, yes.
> 
> johannes
> 

John, Johannes suggested you are able to pull in this patch?

rhyland


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] net: rfkill: add generic gpio rfkill driver
  2011-05-13 19:02               ` Rhyland Klein
@ 2011-05-13 19:20                 ` John W. Linville
  2011-05-13 20:11                   ` John W. Linville
  0 siblings, 1 reply; 12+ messages in thread
From: John W. Linville @ 2011-05-13 19:20 UTC (permalink / raw)
  To: Rhyland Klein; +Cc: olof, linux-wireless, linux-kernel, Johannes Berg

On Fri, May 13, 2011 at 12:02:54PM -0700, Rhyland Klein wrote:
> On Fri, 2011-05-13 at 00:15 -0700, Johannes Berg wrote:
> > On Thu, 2011-05-12 at 14:23 -0700, Rhyland Klein wrote:
> > > On Thu, 2011-05-12 at 12:02 -0700, Johannes Berg wrote:
> > > > On Thu, 2011-05-12 at 11:52 -0700, Rhyland Klein wrote:
> > > > 
> > > > > > If, on the other hand, rfkill decides that at the time of loading the
> > > > > > driver wifi should be on, then the first change would be +1 and it'll
> > > > > > flip between 0 and +1.
> > > > > > 
> > > > > > This seems like it'll cause issues at some point, so I think you should
> > > > > > either allow the driver to set the initial state or hardcode one of
> > > > > > these possibilities (so at least it's predictable)
> > > > 
> > > > > I won't go negative, if you look, it only will disable clock if it knows
> > > > > it has already enabled it. 
> > > > 
> > > > Ah, you're right, I misread the macros.
> > 
> > > So the patch is good as is?
> > 
> > I think so, yes.
> > 
> > johannes
> > 
> 
> John, Johannes suggested you are able to pull in this patch?

I've got it, thanks.

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] net: rfkill: add generic gpio rfkill driver
  2011-05-13 19:20                 ` John W. Linville
@ 2011-05-13 20:11                   ` John W. Linville
  2011-05-16 18:13                     ` wireless-next-2.6 rebased -- " John W. Linville
  0 siblings, 1 reply; 12+ messages in thread
From: John W. Linville @ 2011-05-13 20:11 UTC (permalink / raw)
  To: Rhyland Klein; +Cc: olof, linux-wireless, linux-kernel, Johannes Berg

On Fri, May 13, 2011 at 03:20:20PM -0400, John W. Linville wrote:
> On Fri, May 13, 2011 at 12:02:54PM -0700, Rhyland Klein wrote:
> > On Fri, 2011-05-13 at 00:15 -0700, Johannes Berg wrote:
> > > On Thu, 2011-05-12 at 14:23 -0700, Rhyland Klein wrote:
> > > > On Thu, 2011-05-12 at 12:02 -0700, Johannes Berg wrote:
> > > > > On Thu, 2011-05-12 at 11:52 -0700, Rhyland Klein wrote:
> > > > > 
> > > > > > > If, on the other hand, rfkill decides that at the time of loading the
> > > > > > > driver wifi should be on, then the first change would be +1 and it'll
> > > > > > > flip between 0 and +1.
> > > > > > > 
> > > > > > > This seems like it'll cause issues at some point, so I think you should
> > > > > > > either allow the driver to set the initial state or hardcode one of
> > > > > > > these possibilities (so at least it's predictable)
> > > > > 
> > > > > > I won't go negative, if you look, it only will disable clock if it knows
> > > > > > it has already enabled it. 
> > > > > 
> > > > > Ah, you're right, I misread the macros.
> > > 
> > > > So the patch is good as is?
> > > 
> > > I think so, yes.
> > > 
> > > johannes
> > > 
> > 
> > John, Johannes suggested you are able to pull in this patch?
> 
> I've got it, thanks.

  Building modules, stage 2.
  MODPOST 2346 modules
ERROR: "clk_get" [net/rfkill/rfkill-gpio.ko] undefined!
ERROR: "clk_enable" [net/rfkill/rfkill-gpio.ko] undefined!
ERROR: "clk_put" [net/rfkill/rfkill-gpio.ko] undefined!
ERROR: "clk_disable" [net/rfkill/rfkill-gpio.ko] undefined!
WARNING: modpost: Found 5 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Is there something we should add to Kconfig to prevent this?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* wireless-next-2.6 rebased -- Re: [PATCH v2] net: rfkill: add generic gpio rfkill driver
  2011-05-13 20:11                   ` John W. Linville
@ 2011-05-16 18:13                     ` John W. Linville
  0 siblings, 0 replies; 12+ messages in thread
From: John W. Linville @ 2011-05-16 18:13 UTC (permalink / raw)
  To: Rhyland Klein; +Cc: olof, linux-wireless, linux-kernel, Johannes Berg

FYI, I'm rebasing wireless-next to avoid pushing this bad commit to
net-next-2.6.  If you pulled wireless-next-2.6.git over the weekend,
you may experience some rebase-related problems.

John

On Fri, May 13, 2011 at 04:11:31PM -0400, John W. Linville wrote:
> On Fri, May 13, 2011 at 03:20:20PM -0400, John W. Linville wrote:
> > On Fri, May 13, 2011 at 12:02:54PM -0700, Rhyland Klein wrote:
> > > On Fri, 2011-05-13 at 00:15 -0700, Johannes Berg wrote:
> > > > On Thu, 2011-05-12 at 14:23 -0700, Rhyland Klein wrote:
> > > > > On Thu, 2011-05-12 at 12:02 -0700, Johannes Berg wrote:
> > > > > > On Thu, 2011-05-12 at 11:52 -0700, Rhyland Klein wrote:
> > > > > > 
> > > > > > > > If, on the other hand, rfkill decides that at the time of loading the
> > > > > > > > driver wifi should be on, then the first change would be +1 and it'll
> > > > > > > > flip between 0 and +1.
> > > > > > > > 
> > > > > > > > This seems like it'll cause issues at some point, so I think you should
> > > > > > > > either allow the driver to set the initial state or hardcode one of
> > > > > > > > these possibilities (so at least it's predictable)
> > > > > > 
> > > > > > > I won't go negative, if you look, it only will disable clock if it knows
> > > > > > > it has already enabled it. 
> > > > > > 
> > > > > > Ah, you're right, I misread the macros.
> > > > 
> > > > > So the patch is good as is?
> > > > 
> > > > I think so, yes.
> > > > 
> > > > johannes
> > > > 
> > > 
> > > John, Johannes suggested you are able to pull in this patch?
> > 
> > I've got it, thanks.
> 
>   Building modules, stage 2.
>   MODPOST 2346 modules
> ERROR: "clk_get" [net/rfkill/rfkill-gpio.ko] undefined!
> ERROR: "clk_enable" [net/rfkill/rfkill-gpio.ko] undefined!
> ERROR: "clk_put" [net/rfkill/rfkill-gpio.ko] undefined!
> ERROR: "clk_disable" [net/rfkill/rfkill-gpio.ko] undefined!
> WARNING: modpost: Found 5 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> 
> Is there something we should add to Kconfig to prevent this?
> 
> John
> -- 
> John W. Linville		Someday the world will need a hero, and you
> linville@tuxdriver.com			might be all we have.  Be ready.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2011-05-16 18:16 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-12  0:21 [PATCH v2] net: rfkill: add generic gpio rfkill driver Rhyland Klein
2011-05-12  8:31 ` Johannes Berg
2011-05-12 18:23   ` Rhyland Klein
2011-05-12 18:40     ` Johannes Berg
2011-05-12 18:52       ` Rhyland Klein
2011-05-12 19:02         ` Johannes Berg
2011-05-12 21:23           ` Rhyland Klein
2011-05-13  7:15             ` Johannes Berg
2011-05-13 19:02               ` Rhyland Klein
2011-05-13 19:20                 ` John W. Linville
2011-05-13 20:11                   ` John W. Linville
2011-05-16 18:13                     ` wireless-next-2.6 rebased -- " John W. Linville

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.