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 <[email protected]>
Signed-off-by: Rhyland Klein <[email protected]>
---
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
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
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
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
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
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
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
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
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
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
[email protected] might be all we have. Be ready.
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
[email protected] might be all we have. Be ready.
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
> [email protected] 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 [email protected]
> 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
[email protected] might be all we have. Be ready.