linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
@ 2014-01-23 12:43 Linus Walleij
  2014-01-23 13:31 ` Lee Jones
  2014-02-03 11:01 ` Lee Jones
  0 siblings, 2 replies; 7+ messages in thread
From: Linus Walleij @ 2014-01-23 12:43 UTC (permalink / raw)
  To: devicetree, Dmitry Torokhov, linux-input, Samuel Ortiz, Lee Jones
  Cc: linux-kernel, linux-arm-kernel, Mark Rutland, Linus Walleij

This changes the following mechanisms in the TC3589x device tree
probing path:

- Use the .of_match_table in struct device_driver to match the
  device in the device tree.
- Add matches for the proper compatible strings "toshiba,..."
  and all sub-variants, just as is done for the .id matches.
- Move over all the allocation of platform data etc to the
  tc3589x_of_probe() function and follow the pattern of passing
  a platform data pointer back, or an error pointer on error,
  as found in the STMPE driver.
- Match the new (proper) compatible strings for the GPIO and
  keypad MFD cells.
- Use of_device_is_compatible() rather than just !strcmp()
  to discover which cells to instantiate.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/mfd/tc3589x.c | 84 ++++++++++++++++++++++++++++++++++++---------------
 1 file changed, 59 insertions(+), 25 deletions(-)

diff --git a/drivers/mfd/tc3589x.c b/drivers/mfd/tc3589x.c
index 87ea51dc6234..ed1ee2634809 100644
--- a/drivers/mfd/tc3589x.c
+++ b/drivers/mfd/tc3589x.c
@@ -13,8 +13,10 @@
 #include <linux/slab.h>
 #include <linux/i2c.h>
 #include <linux/of.h>
+#include <linux/of_device.h>
 #include <linux/mfd/core.h>
 #include <linux/mfd/tc3589x.h>
+#include <linux/err.h>
 
 /**
  * enum tc3589x_version - indicates the TC3589x version
@@ -160,7 +162,7 @@ static struct mfd_cell tc3589x_dev_gpio[] = {
 		.name		= "tc3589x-gpio",
 		.num_resources	= ARRAY_SIZE(gpio_resources),
 		.resources	= &gpio_resources[0],
-		.of_compatible	= "tc3589x-gpio",
+		.of_compatible	= "toshiba,tc3589x-gpio",
 	},
 };
 
@@ -169,7 +171,7 @@ static struct mfd_cell tc3589x_dev_keypad[] = {
 		.name           = "tc3589x-keypad",
 		.num_resources  = ARRAY_SIZE(keypad_resources),
 		.resources      = &keypad_resources[0],
-		.of_compatible	= "tc3589x-keypad",
+		.of_compatible	= "toshiba,tc3589x-keypad",
 	},
 };
 
@@ -318,45 +320,74 @@ static int tc3589x_device_init(struct tc3589x *tc3589x)
 	return ret;
 }
 
-static int tc3589x_of_probe(struct device_node *np,
-			struct tc3589x_platform_data *pdata)
+#ifdef CONFIG_OF
+static const struct of_device_id tc3589x_match[] = {
+	/* Legacy compatible string */
+	{ .compatible = "tc3589x", .data = (void *) TC3589X_UNKNOWN },
+	{ .compatible = "toshiba,tc35890", .data = (void *) TC3589X_TC35890 },
+	{ .compatible = "toshiba,tc35892", .data = (void *) TC3589X_TC35892 },
+	{ .compatible = "toshiba,tc35893", .data = (void *) TC3589X_TC35893 },
+	{ .compatible = "toshiba,tc35894", .data = (void *) TC3589X_TC35894 },
+	{ .compatible = "toshiba,tc35895", .data = (void *) TC3589X_TC35895 },
+	{ .compatible = "toshiba,tc35896", .data = (void *) TC3589X_TC35896 },
+	{ }
+};
+
+MODULE_DEVICE_TABLE(of, tc3589x_match);
+
+static struct tc3589x_platform_data *
+tc3589x_of_probe(struct device *dev, enum tc3589x_version *version)
 {
+	struct device_node *np = dev->of_node;
+	struct tc3589x_platform_data *pdata;
 	struct device_node *child;
+	const struct of_device_id *of_id;
+
+	pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return ERR_PTR(-ENOMEM);
+
+	of_id = of_match_device(tc3589x_match, dev);
+	if (!of_id)
+		return ERR_PTR(-ENODEV);
+	*version = (enum tc3589x_version) of_id->data;
 
 	for_each_child_of_node(np, child) {
-		if (!strcmp(child->name, "tc3589x_gpio")) {
+		if (of_device_is_compatible(child, "toshiba,tc3589x-gpio"))
 			pdata->block |= TC3589x_BLOCK_GPIO;
-		}
-		if (!strcmp(child->name, "tc3589x_keypad")) {
+		if (of_device_is_compatible(child, "toshiba,tc3589x-keypad"))
 			pdata->block |= TC3589x_BLOCK_KEYPAD;
-		}
 	}
 
-	return 0;
+	return pdata;
 }
+#else
+static inline struct tc3589x_platform_data *
+tc3589x_of_probe(struct device *dev, enum tc3589x_version *version)
+{
+	dev_err(dev, "no device tree support\n");
+	return ERR_PTR(-ENODEV);
+}
+#endif
 
 static int tc3589x_probe(struct i2c_client *i2c,
 				   const struct i2c_device_id *id)
 {
-	struct tc3589x_platform_data *pdata = dev_get_platdata(&i2c->dev);
 	struct device_node *np = i2c->dev.of_node;
+	struct tc3589x_platform_data *pdata = dev_get_platdata(&i2c->dev);
 	struct tc3589x *tc3589x;
+	enum tc3589x_version version;
 	int ret;
 
 	if (!pdata) {
-		if (np) {
-			pdata = devm_kzalloc(&i2c->dev, sizeof(*pdata), GFP_KERNEL);
-			if (!pdata)
-				return -ENOMEM;
-
-			ret = tc3589x_of_probe(np, pdata);
-			if (ret)
-				return ret;
-		}
-		else {
+		pdata = tc3589x_of_probe(&i2c->dev, &version);
+		if (IS_ERR(pdata)) {
 			dev_err(&i2c->dev, "No platform data or DT found\n");
-			return -EINVAL;
+			return PTR_ERR(pdata);
 		}
+	} else {
+		/* When not probing from device tree we have this ID */
+		version = id->driver_data;
 	}
 
 	if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_SMBUS_BYTE_DATA
@@ -375,7 +406,7 @@ static int tc3589x_probe(struct i2c_client *i2c,
 	tc3589x->pdata = pdata;
 	tc3589x->irq_base = pdata->irq_base;
 
-	switch (id->driver_data) {
+	switch (version) {
 	case TC3589X_TC35893:
 	case TC3589X_TC35895:
 	case TC3589X_TC35896:
@@ -471,9 +502,12 @@ static const struct i2c_device_id tc3589x_id[] = {
 MODULE_DEVICE_TABLE(i2c, tc3589x_id);
 
 static struct i2c_driver tc3589x_driver = {
-	.driver.name	= "tc3589x",
-	.driver.owner	= THIS_MODULE,
-	.driver.pm	= &tc3589x_dev_pm_ops,
+	.driver = {
+		.name	= "tc3589x",
+		.owner	= THIS_MODULE,
+		.pm	= &tc3589x_dev_pm_ops,
+		.of_match_table = of_match_ptr(tc3589x_match),
+	},
 	.probe		= tc3589x_probe,
 	.remove		= tc3589x_remove,
 	.id_table	= tc3589x_id,
-- 
1.8.4.2


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

* Re: [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
  2014-01-23 12:43 [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing Linus Walleij
@ 2014-01-23 13:31 ` Lee Jones
  2014-01-23 15:04   ` Linus Walleij
  2014-02-03 11:01 ` Lee Jones
  1 sibling, 1 reply; 7+ messages in thread
From: Lee Jones @ 2014-01-23 13:31 UTC (permalink / raw)
  To: Linus Walleij
  Cc: devicetree, Dmitry Torokhov, linux-input, Samuel Ortiz,
	linux-kernel, linux-arm-kernel, Mark Rutland

> This changes the following mechanisms in the TC3589x device tree
> probing path:
> 
> - Use the .of_match_table in struct device_driver to match the
>   device in the device tree.
> - Add matches for the proper compatible strings "toshiba,..."
>   and all sub-variants, just as is done for the .id matches.
> - Move over all the allocation of platform data etc to the
>   tc3589x_of_probe() function and follow the pattern of passing
>   a platform data pointer back, or an error pointer on error,
>   as found in the STMPE driver.
> - Match the new (proper) compatible strings for the GPIO and
>   keypad MFD cells.
> - Use of_device_is_compatible() rather than just !strcmp()
>   to discover which cells to instantiate.
> 
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>  drivers/mfd/tc3589x.c | 84 ++++++++++++++++++++++++++++++++++++---------------
>  1 file changed, 59 insertions(+), 25 deletions(-)

Patch looks good to me. Is there any reason why we should rush this in
for v3.14, or is it okay to go to -next?

Acked-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

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

* Re: [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
  2014-01-23 13:31 ` Lee Jones
@ 2014-01-23 15:04   ` Linus Walleij
  2014-01-23 15:11     ` Lee Jones
  0 siblings, 1 reply; 7+ messages in thread
From: Linus Walleij @ 2014-01-23 15:04 UTC (permalink / raw)
  To: Lee Jones
  Cc: devicetree, Dmitry Torokhov, Linux Input, Samuel Ortiz,
	linux-kernel, linux-arm-kernel, Mark Rutland

On Thu, Jan 23, 2014 at 2:31 PM, Lee Jones <lee.jones@linaro.org> wrote:

> Patch looks good to me. Is there any reason why we should rush this in
> for v3.14, or is it okay to go to -next?

No rush, but it's been on review like forever so unless there is
some noise from the DT people at -rc1 I'd be very happy if you
could apply patches 1 & 2 by then.

The third one can be applied out-of-order to the input tree after
that.

Yours,
Linus Walleij

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

* Re: [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
  2014-01-23 15:04   ` Linus Walleij
@ 2014-01-23 15:11     ` Lee Jones
  2014-02-03 10:32       ` Linus Walleij
  0 siblings, 1 reply; 7+ messages in thread
From: Lee Jones @ 2014-01-23 15:11 UTC (permalink / raw)
  To: Linus Walleij
  Cc: devicetree, Dmitry Torokhov, Linux Input, Samuel Ortiz,
	linux-kernel, linux-arm-kernel, Mark Rutland

> > Patch looks good to me. Is there any reason why we should rush this in
> > for v3.14, or is it okay to go to -next?
> 
> No rush, but it's been on review like forever so unless there is
> some noise from the DT people at -rc1 I'd be very happy if you
> could apply patches 1 & 2 by then.

I'm just waiting for their Ack. If I don't have it soon I'll review it
myself and any changes will have to come in via subsequent patch
submissions.

I think it's sensible to head for v3.15 for this set.

> The third one can be applied out-of-order to the input tree after
> that.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

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

* Re: [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
  2014-01-23 15:11     ` Lee Jones
@ 2014-02-03 10:32       ` Linus Walleij
  2014-02-03 11:02         ` Lee Jones
  0 siblings, 1 reply; 7+ messages in thread
From: Linus Walleij @ 2014-02-03 10:32 UTC (permalink / raw)
  To: Lee Jones
  Cc: devicetree, Dmitry Torokhov, Linux Input, Samuel Ortiz,
	linux-kernel, linux-arm-kernel, Mark Rutland

On Thu, Jan 23, 2014 at 4:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>> > Patch looks good to me. Is there any reason why we should rush this in
>> > for v3.14, or is it okay to go to -next?
>>
>> No rush, but it's been on review like forever so unless there is
>> some noise from the DT people at -rc1 I'd be very happy if you
>> could apply patches 1 & 2 by then.
>
> I'm just waiting for their Ack. If I don't have it soon I'll review it
> myself and any changes will have to come in via subsequent patch
> submissions.
>
> I think it's sensible to head for v3.15 for this set.

So now that v3.14-rc1 is out can we queue this stuff?

Yours,
Linus Walleij

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

* Re: [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
  2014-01-23 12:43 [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing Linus Walleij
  2014-01-23 13:31 ` Lee Jones
@ 2014-02-03 11:01 ` Lee Jones
  1 sibling, 0 replies; 7+ messages in thread
From: Lee Jones @ 2014-02-03 11:01 UTC (permalink / raw)
  To: Linus Walleij
  Cc: devicetree, Dmitry Torokhov, linux-input, Samuel Ortiz,
	linux-kernel, linux-arm-kernel, Mark Rutland

> This changes the following mechanisms in the TC3589x device tree
> probing path:
> 
> - Use the .of_match_table in struct device_driver to match the
>   device in the device tree.
> - Add matches for the proper compatible strings "toshiba,..."
>   and all sub-variants, just as is done for the .id matches.
> - Move over all the allocation of platform data etc to the
>   tc3589x_of_probe() function and follow the pattern of passing
>   a platform data pointer back, or an error pointer on error,
>   as found in the STMPE driver.
> - Match the new (proper) compatible strings for the GPIO and
>   keypad MFD cells.
> - Use of_device_is_compatible() rather than just !strcmp()
>   to discover which cells to instantiate.
> 
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>  drivers/mfd/tc3589x.c | 84 ++++++++++++++++++++++++++++++++++++---------------
>  1 file changed, 59 insertions(+), 25 deletions(-)

Looks good, applied.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

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

* Re: [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
  2014-02-03 10:32       ` Linus Walleij
@ 2014-02-03 11:02         ` Lee Jones
  0 siblings, 0 replies; 7+ messages in thread
From: Lee Jones @ 2014-02-03 11:02 UTC (permalink / raw)
  To: Linus Walleij
  Cc: devicetree, Dmitry Torokhov, Linux Input, Samuel Ortiz,
	linux-kernel, linux-arm-kernel, Mark Rutland

> >> > Patch looks good to me. Is there any reason why we should rush this in
> >> > for v3.14, or is it okay to go to -next?
> >>
> >> No rush, but it's been on review like forever so unless there is
> >> some noise from the DT people at -rc1 I'd be very happy if you
> >> could apply patches 1 & 2 by then.
> >
> > I'm just waiting for their Ack. If I don't have it soon I'll review it
> > myself and any changes will have to come in via subsequent patch
> > submissions.
> >
> > I think it's sensible to head for v3.15 for this set.
> 
> So now that v3.14-rc1 is out can we queue this stuff?

Queued.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

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

end of thread, other threads:[~2014-02-03 11:02 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-23 12:43 [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing Linus Walleij
2014-01-23 13:31 ` Lee Jones
2014-01-23 15:04   ` Linus Walleij
2014-01-23 15:11     ` Lee Jones
2014-02-03 10:32       ` Linus Walleij
2014-02-03 11:02         ` Lee Jones
2014-02-03 11:01 ` Lee Jones

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).