Re: [patch 1/6] gpiolib: introduce chip addition/removal notifier

Re: [patch 1/6] gpiolib: introduce chip addition/removal notifier

[Anton Vorontsov]

(Cc'ing devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org)

On Sat, May 01, 2010 at 12:50:15AM -0600, Grant Likely wrote:
> Not till now.  Here's what I've been working on.  It's based on my
> test-devicetree branch.
[...]
> As you can see, I've pretty much come full circle on the adding
> 'automatic' OF support to gpio chips.  Originally (as you well know) I
> was strongly opposed to any addition of OF code to the core gpiolib.
> All of the notifier work was a response to that.
> 
> However, now that I actually have played with the code and looked and
> the issues deeply, I've got an entirely different opinion.

ROFL :-D

> (The fact
> that OF support is being ported to more architectures is also a
> factor.)

Yeah, I guess without multi-arch OF effort such an OF+gpiolib
integration would be very dubious. But as OF spreads to other
architectures, and we already have of_node in the 'struct
device'... I guess that makes sense now.

> Anyway, please take a look.

It works here with some small fixes (patches on the way).

Tested with MCU (I2C), and QE GPIO (memory mapped) GPIO controllers.

Thanks!

-- 
Anton Vorontsov
email: cbouatmailru-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
irc://irc.freenode.net/bd2

[PATCH 1/3] powerpc/83xx/mcu: Add OF match table

[Anton Vorontsov]

of_modalias_node() matches on the first (most specific) entries,
which isn't quite practical but it was discussed that this won't
change.

The bindings specifies verbose information for the devices, but
it doesn't fit in the I2C ID's 20 characters limit. The limit won't
change, and the bindings won't change either as they're correct.

So we have to put an explicit OF matching table for the
MPC8349E-mITX-compatible MCUs.

(Previously this was in the OF exception table, see commit
4c3ed7d61bd474380e0d3e1eb0da164942f7c84e.)

Signed-off-by: Anton Vorontsov <avorontsov-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
---
 arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
index 59b0ed1..70798ac 100644
--- a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
+++ b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
@@ -160,10 +160,16 @@ static const struct i2c_device_id mcu_ids[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mcu_ids);
 
+static struct of_device_id mcu_of_match_table[] __devinitdata = {
+	{ .compatible = "fsl,mcu-mpc8349emitx", },
+	{ },
+};
+
 static struct i2c_driver mcu_driver = {
 	.driver = {
 		.name = "mcu-mpc8349emitx",
 		.owner = THIS_MODULE,
+		.of_match_table = mcu_of_match_table,
 	},
 	.probe = mcu_probe,
 	.remove	= __devexit_p(mcu_remove),
-- 
1.7.0.5

[PATCH 2/3] serial/ucc_uart: Use .dev.of_node instead of .node in struct of_device

[Anton Vorontsov]

Fixes following build failure:

drivers/serial/ucc_uart.c: In function 'ucc_uart_probe':
drivers/serial/ucc_uart.c:1200: error: 'struct platform_device' has no member named 'node'

Signed-off-by: Anton Vorontsov <avorontsov-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
---
 drivers/serial/ucc_uart.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/serial/ucc_uart.c b/drivers/serial/ucc_uart.c
index fce07be..907b06f 100644
--- a/drivers/serial/ucc_uart.c
+++ b/drivers/serial/ucc_uart.c
@@ -1197,7 +1197,7 @@ static void uart_firmware_cont(const struct firmware *fw, void *context)
 static int ucc_uart_probe(struct of_device *ofdev,
 	const struct of_device_id *match)
 {
-	struct device_node *np = ofdev->node;
+	struct device_node *np = ofdev->dev.of_node;
 	const unsigned int *iprop;      /* Integer OF properties */
 	const char *sprop;      /* String OF properties */
 	struct uart_qe_port *qe_port = NULL;
-- 
1.7.0.5

[PATCH 3/3] USB: FHCI: Use .dev.of_node instead of .node in struct of_device

[Anton Vorontsov]

Fixes following build failure:

drivers/usb/host/fhci-hcd.c: In function 'of_fhci_probe':
drivers/usb/host/fhci-hcd.c:568: error: 'struct platform_device' has no member named 'node'
drivers/usb/host/fhci-hcd.c:673: error: 'struct platform_device' has no member named 'node'

Signed-off-by: Anton Vorontsov <avorontsov-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
---
 drivers/usb/host/fhci-hcd.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/fhci-hcd.c b/drivers/usb/host/fhci-hcd.c
index 84adca4..7b5c626 100644
--- a/drivers/usb/host/fhci-hcd.c
+++ b/drivers/usb/host/fhci-hcd.c
@@ -565,7 +565,7 @@ static int __devinit of_fhci_probe(struct of_device *ofdev,
 				   const struct of_device_id *ofid)
 {
 	struct device *dev = &ofdev->dev;
-	struct device_node *node = ofdev->node;
+	struct device_node *node = dev->of_node;
 	struct usb_hcd *hcd;
 	struct fhci_hcd *fhci;
 	struct resource usb_regs;
@@ -670,7 +670,7 @@ static int __devinit of_fhci_probe(struct of_device *ofdev,
 	}
 
 	for (j = 0; j < NUM_PINS; j++) {
-		fhci->pins[j] = qe_pin_request(ofdev->node, j);
+		fhci->pins[j] = qe_pin_request(node, j);
 		if (IS_ERR(fhci->pins[j])) {
 			ret = PTR_ERR(fhci->pins[j]);
 			dev_err(dev, "can't get pin %d: %d\n", j, ret);
-- 
1.7.0.5

Re: [patch 1/6] gpiolib: introduce chip addition/removal notifier

[Grant Likely]

On Sun, May 2, 2010 at 10:59 AM, Anton Vorontsov <cbouatmailru-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> (Cc'ing devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org)
>
> On Sat, May 01, 2010 at 12:50:15AM -0600, Grant Likely wrote:
>> Not till now.  Here's what I've been working on.  It's based on my
>> test-devicetree branch.
> [...]
>> As you can see, I've pretty much come full circle on the adding
>> 'automatic' OF support to gpio chips.  Originally (as you well know) I
>> was strongly opposed to any addition of OF code to the core gpiolib.
>> All of the notifier work was a response to that.
>>
>> However, now that I actually have played with the code and looked and
>> the issues deeply, I've got an entirely different opinion.
>
> ROFL :-D
>
>> (The fact
>> that OF support is being ported to more architectures is also a
>> factor.)
>
> Yeah, I guess without multi-arch OF effort such an OF+gpiolib
> integration would be very dubious. But as OF spreads to other
> architectures, and we already have of_node in the 'struct
> device'... I guess that makes sense now.
>
>> Anyway, please take a look.
>
> It works here with some small fixes (patches on the way).

Thanks Anton.  I'll look for them and pick them up.

g.