[PATCH v3] gpio: driver for Xtensa GPIO32

[PATCH v3] gpio: driver for Xtensa GPIO32

[Baruch Siach]

GPIO32 is a standard optional extension to the Xtensa architecture core that
provides preconfigured output and input ports for intra SoC signaling. The
GPIO32 option is implemented as 32bit Tensilica Instruction Extension (TIE)
output state called EXPSTATE, and 32bit input wire called IMPWIRE. This
driver treats input and output states as two distinct devices.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v3:
   * Use BUG() in xtensa_impwire_set_value() to indicate that it should never
     be called (Linus Walleij)

v2:
   * Address the comments of Linus Walleij:
      - Add a few comments
      - Expand commit log message
      - Use the BIT() macro for bit offsets
      - Rewrite CPENABLE handling as static inlines
      - Use device_initcall()

   * Depend on !SMP for reason explained in the comments (Marc Gauthier)

   * Use XCHAL_CP_ID_XTIOP to enable/disable GPIO32 only
---
 drivers/gpio/Kconfig       |   8 +++
 drivers/gpio/Makefile      |   1 +
 drivers/gpio/gpio-xtensa.c | 163 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 172 insertions(+)
 create mode 100644 drivers/gpio/gpio-xtensa.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0f04444..67f5ce6 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -281,6 +281,14 @@ config GPIO_XILINX
 	help
 	  Say yes here to support the Xilinx FPGA GPIO device
 
+config GPIO_XTENSA
+	bool "Xtensa GPIO32 support"
+	depends on XTENSA
+	depends on !SMP
+	help
+	  Say yes here to support the Xtensa internal GPIO32 IMPWIRE (input)
+	  and EXPSTATE (output) ports
+
 config GPIO_VR41XX
 	tristate "NEC VR4100 series General-purpose I/O Uint support"
 	depends on CPU_VR41XX
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 7971e36..23b9c72 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_GPIO_WM831X)	+= gpio-wm831x.o
 obj-$(CONFIG_GPIO_WM8350)	+= gpio-wm8350.o
 obj-$(CONFIG_GPIO_WM8994)	+= gpio-wm8994.o
 obj-$(CONFIG_GPIO_XILINX)	+= gpio-xilinx.o
+obj-$(CONFIG_GPIO_XTENSA)	+= gpio-xtensa.o
diff --git a/drivers/gpio/gpio-xtensa.c b/drivers/gpio/gpio-xtensa.c
new file mode 100644
index 0000000..1d136ec
--- /dev/null
+++ b/drivers/gpio/gpio-xtensa.c
@@ -0,0 +1,163 @@
+/*
+ * Copyright (C) 2013 TangoTec Ltd.
+ * Author: Baruch Siach <baruch@tkos.co.il>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Driver for the Xtensa LX4 GPIO32 Option
+ *
+ * Documentation: Xtensa LX4 Microprocessor Data Book, Section 2.22
+ *
+ * GPIO32 is a standard optional extension to the Xtensa architecture core that
+ * provides preconfigured output and input ports for intra SoC signaling. The
+ * GPIO32 option is implemented as 32bit Tensilica Instruction Extension (TIE)
+ * output state called EXPSTATE, and 32bit input wire called IMPWIRE. This
+ * driver treats input and output states as two distinct devices.
+ *
+ * Access to GPIO32 specific instructions is controlled by the CPENABLE
+ * (Coprocessor Enable Bits) register. By default Xtensa Linux startup code
+ * disables access to all coprocessors. This driver sets the CPENABLE bit
+ * corresponding to GPIO32 before any GPIO32 specific instruction, and restores
+ * CPENABLE state after that.
+ *
+ * This driver is currently incompatible with SMP. The GPIO32 extension is not
+ * guaranteed to be available in all cores. Moreover, each core controls a
+ * different set of IO wires. A theoretical SMP aware version of this driver
+ * would need to have a per core workqueue to do the actual GPIO manipulation.
+ */
+
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/gpio.h>
+#include <linux/bitops.h>
+#include <linux/platform_device.h>
+
+#include <asm/coprocessor.h> /* CPENABLE read/write macros */
+
+#ifndef XCHAL_CP_ID_XTIOP
+#error GPIO32 option is not enabled for your xtensa core variant
+#endif
+
+static inline unsigned long enable_cp(unsigned long *cpenable)
+{
+	unsigned long flags;
+
+	local_irq_save(flags);
+	RSR_CPENABLE(*cpenable);
+	WSR_CPENABLE(*cpenable | BIT(XCHAL_CP_ID_XTIOP));
+
+	return flags;
+}
+
+static inline void disable_cp(unsigned long flags, unsigned long cpenable)
+{
+	WSR_CPENABLE(cpenable);
+	local_irq_restore(flags);
+}
+
+static int xtensa_impwire_get_direction(struct gpio_chip *gc, unsigned offset)
+{
+	return 1; /* input only */
+}
+
+static int xtensa_impwire_get_value(struct gpio_chip *gc, unsigned offset)
+{
+	unsigned long flags, saved_cpenable;
+	u32 impwire;
+
+	flags = enable_cp(&saved_cpenable);
+	__asm__ __volatile__("read_impwire %0" : "=a" (impwire));
+	disable_cp(flags, saved_cpenable);
+
+	return !!(impwire & BIT(offset));
+}
+
+static void xtensa_impwire_set_value(struct gpio_chip *gc, unsigned offset,
+				    int value)
+{
+	BUG(); /* output only; should never be called */
+}
+
+static int xtensa_expstate_get_direction(struct gpio_chip *gc, unsigned offset)
+{
+	return 0; /* output only */
+}
+
+static int xtensa_expstate_get_value(struct gpio_chip *gc, unsigned offset)
+{
+	unsigned long flags, saved_cpenable;
+	u32 expstate;
+
+	flags = enable_cp(&saved_cpenable);
+	__asm__ __volatile__("rur.expstate %0" : "=a" (expstate));
+	disable_cp(flags, saved_cpenable);
+
+	return !!(expstate & BIT(offset));
+}
+
+static void xtensa_expstate_set_value(struct gpio_chip *gc, unsigned offset,
+				     int value)
+{
+	unsigned long flags, saved_cpenable;
+	u32 mask = BIT(offset);
+	u32 val = value ? BIT(offset) : 0;
+
+	flags = enable_cp(&saved_cpenable);
+	__asm__ __volatile__("wrmsk_expstate %0, %1"
+			     :: "a" (val), "a" (mask));
+	disable_cp(flags, saved_cpenable);
+}
+
+static struct gpio_chip impwire_chip = {
+	.label		= "impwire",
+	.base		= -1,
+	.ngpio		= 32,
+	.get_direction	= xtensa_impwire_get_direction,
+	.get		= xtensa_impwire_get_value,
+	.set		= xtensa_impwire_set_value,
+};
+
+static struct gpio_chip expstate_chip = {
+	.label		= "expstate",
+	.base		= -1,
+	.ngpio		= 32,
+	.get_direction	= xtensa_expstate_get_direction,
+	.get		= xtensa_expstate_get_value,
+	.set		= xtensa_expstate_set_value,
+};
+
+static int xtensa_gpio_probe(struct platform_device *pdev)
+{
+	int ret;
+
+	ret = gpiochip_add(&impwire_chip);
+	if (ret)
+		return ret;
+	return gpiochip_add(&expstate_chip);
+}
+
+static struct platform_driver xtensa_gpio_driver = {
+	.driver		= {
+		.name		= "xtensa-gpio",
+		.owner		= THIS_MODULE,
+	},
+	.probe		= xtensa_gpio_probe,
+};
+
+static int __init xtensa_gpio_init(void)
+{
+	struct platform_device *pdev;
+
+	pdev = platform_device_register_simple("xtensa-gpio", 0, NULL, 0);
+	if (IS_ERR(pdev))
+		return PTR_ERR(pdev);
+
+	return platform_driver_register(&xtensa_gpio_driver);
+}
+device_initcall(xtensa_gpio_init);
+
+MODULE_AUTHOR("Baruch Siach <baruch@tkos.co.il>");
+MODULE_DESCRIPTION("Xtensa LX4 GPIO32 driver");
+MODULE_LICENSE("GPL");
-- 
1.8.5.1

Re: [PATCH v3] gpio: driver for Xtensa GPIO32

[Linus Walleij]

On Thu, Dec 12, 2013 at 10:18 AM, Baruch Siach <baruch@tkos.co.il> wrote:

> GPIO32 is a standard optional extension to the Xtensa architecture core that
> provides preconfigured output and input ports for intra SoC signaling. The
> GPIO32 option is implemented as 32bit Tensilica Instruction Extension (TIE)
> output state called EXPSTATE, and 32bit input wire called IMPWIRE. This
> driver treats input and output states as two distinct devices.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> v3:
>    * Use BUG() in xtensa_impwire_set_value() to indicate that it should never
>      be called (Linus Walleij)

OK no remaining issues with this version, patch applied!

Thanks!
Linus Walleij

Re: [PATCH v3] gpio: driver for Xtensa GPIO32

[David Cohen]

Hi Baruch,

On Thu, Dec 12, 2013 at 11:18:41AM +0200, Baruch Siach wrote:
> GPIO32 is a standard optional extension to the Xtensa architecture core that
> provides preconfigured output and input ports for intra SoC signaling. The
> GPIO32 option is implemented as 32bit Tensilica Instruction Extension (TIE)
> output state called EXPSTATE, and 32bit input wire called IMPWIRE. This
> driver treats input and output states as two distinct devices.
> 
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> v3:
>    * Use BUG() in xtensa_impwire_set_value() to indicate that it should never
>      be called (Linus Walleij)
> 
> v2:
>    * Address the comments of Linus Walleij:
>       - Add a few comments
>       - Expand commit log message
>       - Use the BIT() macro for bit offsets
>       - Rewrite CPENABLE handling as static inlines
>       - Use device_initcall()
> 
>    * Depend on !SMP for reason explained in the comments (Marc Gauthier)
> 
>    * Use XCHAL_CP_ID_XTIOP to enable/disable GPIO32 only
> ---
>  drivers/gpio/Kconfig       |   8 +++
>  drivers/gpio/Makefile      |   1 +
>  drivers/gpio/gpio-xtensa.c | 163 +++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 172 insertions(+)
>  create mode 100644 drivers/gpio/gpio-xtensa.c
> 
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 0f04444..67f5ce6 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -281,6 +281,14 @@ config GPIO_XILINX
>  	help
>  	  Say yes here to support the Xilinx FPGA GPIO device
>  
> +config GPIO_XTENSA
> +	bool "Xtensa GPIO32 support"
> +	depends on XTENSA
> +	depends on !SMP
> +	help
> +	  Say yes here to support the Xtensa internal GPIO32 IMPWIRE (input)
> +	  and EXPSTATE (output) ports
> +
>  config GPIO_VR41XX
>  	tristate "NEC VR4100 series General-purpose I/O Uint support"
>  	depends on CPU_VR41XX
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 7971e36..23b9c72 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -95,3 +95,4 @@ obj-$(CONFIG_GPIO_WM831X)	+= gpio-wm831x.o
>  obj-$(CONFIG_GPIO_WM8350)	+= gpio-wm8350.o
>  obj-$(CONFIG_GPIO_WM8994)	+= gpio-wm8994.o
>  obj-$(CONFIG_GPIO_XILINX)	+= gpio-xilinx.o
> +obj-$(CONFIG_GPIO_XTENSA)	+= gpio-xtensa.o
> diff --git a/drivers/gpio/gpio-xtensa.c b/drivers/gpio/gpio-xtensa.c

[snip]

> +static int __init xtensa_gpio_init(void)
> +{
> +	struct platform_device *pdev;
> +
> +	pdev = platform_device_register_simple("xtensa-gpio", 0, NULL, 0);

Is it what you really want to do? It means this driver will probe
regardless it really should or not.

Br, David Cohen

> +	if (IS_ERR(pdev))
> +		return PTR_ERR(pdev);
> +
> +	return platform_driver_register(&xtensa_gpio_driver);
> +}
> +device_initcall(xtensa_gpio_init);
> +
> +MODULE_AUTHOR("Baruch Siach <baruch@tkos.co.il>");
> +MODULE_DESCRIPTION("Xtensa LX4 GPIO32 driver");
> +MODULE_LICENSE("GPL");
> -- 
> 1.8.5.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] gpio: driver for Xtensa GPIO32

[Baruch Siach]

Hi David,

On Thu, Dec 12, 2013 at 10:15:58AM -0800, David Cohen wrote:
> On Thu, Dec 12, 2013 at 11:18:41AM +0200, Baruch Siach wrote:
> > GPIO32 is a standard optional extension to the Xtensa architecture core that
> > provides preconfigured output and input ports for intra SoC signaling. The
> > GPIO32 option is implemented as 32bit Tensilica Instruction Extension (TIE)
> > output state called EXPSTATE, and 32bit input wire called IMPWIRE. This
> > driver treats input and output states as two distinct devices.
> > 
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> > v3:
> >    * Use BUG() in xtensa_impwire_set_value() to indicate that it should never
> >      be called (Linus Walleij)
> > 
> > v2:
> >    * Address the comments of Linus Walleij:
> >       - Add a few comments
> >       - Expand commit log message
> >       - Use the BIT() macro for bit offsets
> >       - Rewrite CPENABLE handling as static inlines
> >       - Use device_initcall()
> > 
> >    * Depend on !SMP for reason explained in the comments (Marc Gauthier)
> > 
> >    * Use XCHAL_CP_ID_XTIOP to enable/disable GPIO32 only
> > ---
> >  drivers/gpio/Kconfig       |   8 +++
> >  drivers/gpio/Makefile      |   1 +
> >  drivers/gpio/gpio-xtensa.c | 163 +++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 172 insertions(+)
> >  create mode 100644 drivers/gpio/gpio-xtensa.c
> > 
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> > index 0f04444..67f5ce6 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -281,6 +281,14 @@ config GPIO_XILINX
> >  	help
> >  	  Say yes here to support the Xilinx FPGA GPIO device
> >  
> > +config GPIO_XTENSA
> > +	bool "Xtensa GPIO32 support"
> > +	depends on XTENSA
> > +	depends on !SMP
> > +	help
> > +	  Say yes here to support the Xtensa internal GPIO32 IMPWIRE (input)
> > +	  and EXPSTATE (output) ports
> > +
> >  config GPIO_VR41XX
> >  	tristate "NEC VR4100 series General-purpose I/O Uint support"
> >  	depends on CPU_VR41XX
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> > index 7971e36..23b9c72 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -95,3 +95,4 @@ obj-$(CONFIG_GPIO_WM831X)	+= gpio-wm831x.o
> >  obj-$(CONFIG_GPIO_WM8350)	+= gpio-wm8350.o
> >  obj-$(CONFIG_GPIO_WM8994)	+= gpio-wm8994.o
> >  obj-$(CONFIG_GPIO_XILINX)	+= gpio-xilinx.o
> > +obj-$(CONFIG_GPIO_XTENSA)	+= gpio-xtensa.o
> > diff --git a/drivers/gpio/gpio-xtensa.c b/drivers/gpio/gpio-xtensa.c
> 
> [snip]
> 
> > +static int __init xtensa_gpio_init(void)
> > +{
> > +	struct platform_device *pdev;
> > +
> > +	pdev = platform_device_register_simple("xtensa-gpio", 0, NULL, 0);
> 
> Is it what you really want to do? It means this driver will probe
> regardless it really should or not.

If you have XCHAL_CP_ID_XTIOP defined in your xtensa variant tie.h header, 
then this device is available. Otherwise, this driver doesn't even build. If 
you don't want the kernel to manage the GPIO32 IO port, then just disable the 
driver in the kernel configuration.

Does this sound reasonable enough?

baruch

> > +	if (IS_ERR(pdev))
> > +		return PTR_ERR(pdev);
> > +
> > +	return platform_driver_register(&xtensa_gpio_driver);
> > +}
> > +device_initcall(xtensa_gpio_init);
> > +
> > +MODULE_AUTHOR("Baruch Siach <baruch@tkos.co.il>");
> > +MODULE_DESCRIPTION("Xtensa LX4 GPIO32 driver");
> > +MODULE_LICENSE("GPL");

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Re: [PATCH v3] gpio: driver for Xtensa GPIO32

[David Cohen]

On Thu, Dec 12, 2013 at 08:24:42PM +0200, Baruch Siach wrote:
> Hi David,
> 
> On Thu, Dec 12, 2013 at 10:15:58AM -0800, David Cohen wrote:
> > On Thu, Dec 12, 2013 at 11:18:41AM +0200, Baruch Siach wrote:
> > > GPIO32 is a standard optional extension to the Xtensa architecture core that
> > > provides preconfigured output and input ports for intra SoC signaling. The
> > > GPIO32 option is implemented as 32bit Tensilica Instruction Extension (TIE)
> > > output state called EXPSTATE, and 32bit input wire called IMPWIRE. This
> > > driver treats input and output states as two distinct devices.
> > > 
> > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > > ---
> > > v3:
> > >    * Use BUG() in xtensa_impwire_set_value() to indicate that it should never
> > >      be called (Linus Walleij)
> > > 
> > > v2:
> > >    * Address the comments of Linus Walleij:
> > >       - Add a few comments
> > >       - Expand commit log message
> > >       - Use the BIT() macro for bit offsets
> > >       - Rewrite CPENABLE handling as static inlines
> > >       - Use device_initcall()
> > > 
> > >    * Depend on !SMP for reason explained in the comments (Marc Gauthier)
> > > 
> > >    * Use XCHAL_CP_ID_XTIOP to enable/disable GPIO32 only
> > > ---
> > >  drivers/gpio/Kconfig       |   8 +++
> > >  drivers/gpio/Makefile      |   1 +
> > >  drivers/gpio/gpio-xtensa.c | 163 +++++++++++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 172 insertions(+)
> > >  create mode 100644 drivers/gpio/gpio-xtensa.c
> > > 
> > > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> > > index 0f04444..67f5ce6 100644
> > > --- a/drivers/gpio/Kconfig
> > > +++ b/drivers/gpio/Kconfig
> > > @@ -281,6 +281,14 @@ config GPIO_XILINX
> > >  	help
> > >  	  Say yes here to support the Xilinx FPGA GPIO device
> > >  
> > > +config GPIO_XTENSA
> > > +	bool "Xtensa GPIO32 support"
> > > +	depends on XTENSA
> > > +	depends on !SMP
> > > +	help
> > > +	  Say yes here to support the Xtensa internal GPIO32 IMPWIRE (input)
> > > +	  and EXPSTATE (output) ports
> > > +
> > >  config GPIO_VR41XX
> > >  	tristate "NEC VR4100 series General-purpose I/O Uint support"
> > >  	depends on CPU_VR41XX
> > > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> > > index 7971e36..23b9c72 100644
> > > --- a/drivers/gpio/Makefile
> > > +++ b/drivers/gpio/Makefile
> > > @@ -95,3 +95,4 @@ obj-$(CONFIG_GPIO_WM831X)	+= gpio-wm831x.o
> > >  obj-$(CONFIG_GPIO_WM8350)	+= gpio-wm8350.o
> > >  obj-$(CONFIG_GPIO_WM8994)	+= gpio-wm8994.o
> > >  obj-$(CONFIG_GPIO_XILINX)	+= gpio-xilinx.o
> > > +obj-$(CONFIG_GPIO_XTENSA)	+= gpio-xtensa.o
> > > diff --git a/drivers/gpio/gpio-xtensa.c b/drivers/gpio/gpio-xtensa.c
> > 
> > [snip]
> > 
> > > +static int __init xtensa_gpio_init(void)
> > > +{
> > > +	struct platform_device *pdev;
> > > +
> > > +	pdev = platform_device_register_simple("xtensa-gpio", 0, NULL, 0);
> > 
> > Is it what you really want to do? It means this driver will probe
> > regardless it really should or not.
> 
> If you have XCHAL_CP_ID_XTIOP defined in your xtensa variant tie.h header, 
> then this device is available. Otherwise, this driver doesn't even build. If 
> you don't want the kernel to manage the GPIO32 IO port, then just disable the 
> driver in the kernel configuration.
> 
> Does this sound reasonable enough?

Then I think it's a bit worse :)
You can't make kernel compilation to fail when this GPIO driver is not
meant to be probed.
I'm not familiar with xtensa, so can't be strongly against platform
device registration inside the driver's init function. But you need to
fix your Kconfig to not make this driver available when it's not
compilable.

Br, David

> 
> baruch
> 
> > > +	if (IS_ERR(pdev))
> > > +		return PTR_ERR(pdev);
> > > +
> > > +	return platform_driver_register(&xtensa_gpio_driver);
> > > +}
> > > +device_initcall(xtensa_gpio_init);
> > > +
> > > +MODULE_AUTHOR("Baruch Siach <baruch@tkos.co.il>");
> > > +MODULE_DESCRIPTION("Xtensa LX4 GPIO32 driver");
> > > +MODULE_LICENSE("GPL");
> 
> -- 
>      http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
>    - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] gpio: driver for Xtensa GPIO32

[Baruch Siach]

Hi David,

On Thu, Dec 12, 2013 at 11:23:00AM -0800, David Cohen wrote:
> On Thu, Dec 12, 2013 at 08:24:42PM +0200, Baruch Siach wrote:
> > On Thu, Dec 12, 2013 at 10:15:58AM -0800, David Cohen wrote:
> > > On Thu, Dec 12, 2013 at 11:18:41AM +0200, Baruch Siach wrote:
> > > > +static int __init xtensa_gpio_init(void)
> > > > +{
> > > > +	struct platform_device *pdev;
> > > > +
> > > > +	pdev = platform_device_register_simple("xtensa-gpio", 0, NULL, 0);
> > > 
> > > Is it what you really want to do? It means this driver will probe
> > > regardless it really should or not.
> > 
> > If you have XCHAL_CP_ID_XTIOP defined in your xtensa variant tie.h header, 
> > then this device is available. Otherwise, this driver doesn't even build. If 
> > you don't want the kernel to manage the GPIO32 IO port, then just disable the 
> > driver in the kernel configuration.
> > 
> > Does this sound reasonable enough?
> 
> Then I think it's a bit worse :)
> You can't make kernel compilation to fail when this GPIO driver is not
> meant to be probed.
> I'm not familiar with xtensa, so can't be strongly against platform
> device registration inside the driver's init function. But you need to
> fix your Kconfig to not make this driver available when it's not
> compilable.

I understand your concern, as currently randconfig enabling this driver will 
break the build. I'm not sure what is the right solution though. We could 
depend on, say HAVE_XTENSA_GPIO32, and select it from arch/xtensa/Kconfig for 
the appropriate xtensa variants. The problem is that no current mainline 
xtensa variant supports GPIO32. So, at some future point one of those who are 
looking for unreferenced Kconfig symbols will just remove the whole driver.

Suggestions for a better solution are welcome.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

RE: [Linux-Xtensa] [PATCH v3] gpio: driver for Xtensa GPIO32

[Marc Gauthier]

Baruch Siach wrote:
[...]
> We could depend on, say HAVE_XTENSA_GPIO32, and select it
> from arch/xtensa/Kconfig for the appropriate xtensa variants.
> The problem is that no current mainline xtensa variant
> supports GPIO32. So, at some future point one of those who are 
> looking for unreferenced Kconfig symbols will just remove the 
> whole driver.


The Diamond 233L core has GPIO32.
The GPIO32 option is not mentioned in the variant core.h, however.

-Marc

Re: [Linux-Xtensa] [PATCH v3] gpio: driver for Xtensa GPIO32

[Baruch Siach]

Hi Marc,

On Sun, Dec 15, 2013 at 10:11:06PM -0800, Marc Gauthier wrote:
> Baruch Siach wrote:
> [...]
> > We could depend on, say HAVE_XTENSA_GPIO32, and select it
> > from arch/xtensa/Kconfig for the appropriate xtensa variants.
> > The problem is that no current mainline xtensa variant
> > supports GPIO32. So, at some future point one of those who are 
> > looking for unreferenced Kconfig symbols will just remove the 
> > whole driver.
> 
> The Diamond 233L core has GPIO32.
> The GPIO32 option is not mentioned in the variant core.h, however.

Thanks, your are right. The fsf and 232c variants also support GPIO32 
according to their tie.h. I should have used grep earlier. A patch is on the 
way.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -