[PATCH RFC 0/7] ARM: OMAP: add DT binding for gpmc-smsc911x

[PATCH RFC 0/7] ARM: OMAP: add DT binding for gpmc-smsc911x

[Javier Martinez Canillas]

Hello,

This is an RFC to add Device Tree support for SMSC LAN chips connected
to OMAP processors though its General-Purpose Memory Controller.

The patch-set is composed of the following patches:

[PATCH RFC 1/7] platform: add a device node
[PATCH RFC 2/7] net: smsc911x: add pinctrl support
[PATCH RFC 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function
[PATCH RFC 4/7] ARM: OMAP: gpmc-smsc911x: pass a dev node to platform
[PATCH RFC 5/7] ARM: OMAP: gpmc: add support for gpmc-smsc911x child
[PATCH RFC 6/7] ARM: dts: OMAP: Add an GPMC node for OMAP3
[PATCH RFC 7/7] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support

It is an RFC because I had to modify the platform_device_register_resndata()
platform device registration function to allow passing a device node and
associate to the platform device after allocation. The patch-set updates all
current users and this shouldn't have a function effect on them.

I think that the need for platform code to pass the DT device node to the
platform registration infraestructure will be needed for other devices too
whose probe function needs to access the device node associated with the
device.

The binding has been tested on an TI OMAP3 based board (IGEPv2) and added
support is included on the RFC as an example.

It is based on Linus' latest master branch + linux-omap/omap-for-v3.9/gpmc
+ linux-omap-dt/for_3.9/dts

Thanks a lot and best regards,
Javier

[PATCH RFC 0/7] ARM: OMAP: add DT binding for gpmc-smsc911x

[Javier Martinez Canillas]

Hello,

This is an RFC to add Device Tree support for SMSC LAN chips connected
to OMAP processors though its General-Purpose Memory Controller.

The patch-set is composed of the following patches:

[PATCH RFC 1/7] platform: add a device node
[PATCH RFC 2/7] net: smsc911x: add pinctrl support
[PATCH RFC 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function
[PATCH RFC 4/7] ARM: OMAP: gpmc-smsc911x: pass a dev node to platform
[PATCH RFC 5/7] ARM: OMAP: gpmc: add support for gpmc-smsc911x child
[PATCH RFC 6/7] ARM: dts: OMAP: Add an GPMC node for OMAP3
[PATCH RFC 7/7] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support

It is an RFC because I had to modify the platform_device_register_resndata()
platform device registration function to allow passing a device node and
associate to the platform device after allocation. The patch-set updates all
current users and this shouldn't have a function effect on them.

I think that the need for platform code to pass the DT device node to the
platform registration infraestructure will be needed for other devices too
whose probe function needs to access the device node associated with the
device.

The binding has been tested on an TI OMAP3 based board (IGEPv2) and added
support is included on the RFC as an example.

It is based on Linus' latest master branch + linux-omap/omap-for-v3.9/gpmc
+ linux-omap-dt/for_3.9/dts

Thanks a lot and best regards,
Javier

[PATCH RFC 1/7] platform: add a device node

[Javier Martinez Canillas]

When using Device Trees, it is necessary to associate a
device node with a platform device.

Usually this device node has to used in the device probe
function (e.g: to initizalize the pinctrl pads assocaited
with the device).

So, platform code needs to pass a device node as a platform
device info to the platform device registration function.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/mach-imx/devices/platform-gpio-mxc.c |    2 +-
 arch/arm/mach-imx/devices/platform-imx-dma.c  |    4 ++--
 arch/arm/mach-imx/mach-armadillo5x0.c         |    2 +-
 arch/arm/mach-imx/mach-imx27_visstrim_m10.c   |    3 ++-
 arch/arm/mach-imx/mach-mx1ads.c               |    2 +-
 arch/arm/mach-nomadik/cpu-8815.c              |    2 +-
 arch/arm/mach-omap2/fb.c                      |    2 +-
 arch/arm/mach-omap2/gpmc-smsc911x.c           |    2 +-
 arch/arm/mach-ux500/board-mop500-audio.c      |    2 +-
 arch/arm/mach-ux500/devices-common.c          |    3 ++-
 arch/arm/mach-ux500/devices-db8500.h          |    2 +-
 arch/unicore32/kernel/puv3-core.c             |    2 +-
 arch/unicore32/kernel/puv3-nb0916.c           |    2 +-
 drivers/base/platform.c                       |    1 +
 drivers/leds/leds-gpio-register.c             |    2 +-
 drivers/virtio/virtio_mmio.c                  |    2 +-
 include/linux/platform_device.h               |    9 ++++++---
 sound/soc/samsung/i2s.c                       |    2 +-
 18 files changed, 26 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-imx/devices/platform-gpio-mxc.c b/arch/arm/mach-imx/devices/platform-gpio-mxc.c
index 26483fa..4f4d8f9 100644
--- a/arch/arm/mach-imx/devices/platform-gpio-mxc.c
+++ b/arch/arm/mach-imx/devices/platform-gpio-mxc.c
@@ -28,5 +28,5 @@ struct platform_device *__init mxc_register_gpio(char *name, int id,
 	};
 
 	return platform_device_register_resndata(&mxc_aips_bus,
-			name, id, res, ARRAY_SIZE(res), NULL, 0);
+			name, id, res, ARRAY_SIZE(res), NULL, 0, NULL);
 }
diff --git a/arch/arm/mach-imx/devices/platform-imx-dma.c b/arch/arm/mach-imx/devices/platform-imx-dma.c
index ccdb5dc..1e3838c 100644
--- a/arch/arm/mach-imx/devices/platform-imx-dma.c
+++ b/arch/arm/mach-imx/devices/platform-imx-dma.c
@@ -28,7 +28,7 @@ struct platform_device __init __maybe_unused *imx_add_imx_dma(char *name,
 	};
 
 	return platform_device_register_resndata(&mxc_ahb_bus,
-			name, -1, res, ARRAY_SIZE(res), NULL, 0);
+			name, -1, res, ARRAY_SIZE(res), NULL, 0, NULL);
 }
 
 struct platform_device __init __maybe_unused *imx_add_imx_sdma(char *name,
@@ -47,5 +47,5 @@ struct platform_device __init __maybe_unused *imx_add_imx_sdma(char *name,
 	};
 
 	return platform_device_register_resndata(&mxc_ahb_bus, name,
-			-1, res, ARRAY_SIZE(res), pdata, sizeof(*pdata));
+			-1, res, ARRAY_SIZE(res), pdata, sizeof(*pdata), NULL);
 }
diff --git a/arch/arm/mach-imx/mach-armadillo5x0.c b/arch/arm/mach-imx/mach-armadillo5x0.c
index 59bd6b0..e664681 100644
--- a/arch/arm/mach-imx/mach-armadillo5x0.c
+++ b/arch/arm/mach-imx/mach-armadillo5x0.c
@@ -519,7 +519,7 @@ static void __init armadillo5x0_init(void)
 	platform_device_register_resndata(NULL, "physmap-flash", -1,
 			&armadillo5x0_nor_flash_resource, 1,
 			&armadillo5x0_nor_flash_pdata,
-			sizeof(armadillo5x0_nor_flash_pdata));
+			sizeof(armadillo5x0_nor_flash_pdata), NULL);
 
 	/* Register NAND Flash */
 	imx31_add_mxc_nand(&armadillo5x0_nand_board_info);
diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 318bd8d..5065f67 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -570,7 +570,8 @@ static void __init visstrim_m10_board_init(void)
 	imx_add_platform_device("mx27vis", 0, NULL, 0, &snd_mx27vis_pdata,
 				sizeof(snd_mx27vis_pdata));
 	platform_device_register_resndata(NULL, "soc-camera-pdrv", 0, NULL, 0,
-				      &iclink_tvp5150, sizeof(iclink_tvp5150));
+				      &iclink_tvp5150, sizeof(iclink_tvp5150),
+				      NULL);
 	gpio_led_register_device(0, &visstrim_m10_led_data);
 
 	/* Use mother board version to decide what video devices we shall use */
diff --git a/arch/arm/mach-imx/mach-mx1ads.c b/arch/arm/mach-imx/mach-mx1ads.c
index 06b4837..9ce64a5 100644
--- a/arch/arm/mach-imx/mach-mx1ads.c
+++ b/arch/arm/mach-imx/mach-mx1ads.c
@@ -118,7 +118,7 @@ static void __init mx1ads_init(void)
 	/* Physmap flash */
 	platform_device_register_resndata(NULL, "physmap-flash", 0,
 			&flash_resource, 1,
-			&mx1ads_flash_data, sizeof(mx1ads_flash_data));
+			&mx1ads_flash_data, sizeof(mx1ads_flash_data), NULL);
 
 	/* I2C */
 	i2c_register_board_info(0, mx1ads_i2c_devices,
diff --git a/arch/arm/mach-nomadik/cpu-8815.c b/arch/arm/mach-nomadik/cpu-8815.c
index 1273931..b117d6c 100644
--- a/arch/arm/mach-nomadik/cpu-8815.c
+++ b/arch/arm/mach-nomadik/cpu-8815.c
@@ -65,7 +65,7 @@ cpu8815_add_gpio(int id, resource_size_t addr, int irq,
 
 	return platform_device_register_resndata(NULL, "gpio", id,
 				resources, ARRAY_SIZE(resources),
-				pdata, sizeof(*pdata));
+				pdata, sizeof(*pdata), NULL);
 }
 
 void cpu8815_add_gpios(resource_size_t *base, int num, int irq,
diff --git a/arch/arm/mach-omap2/fb.c b/arch/arm/mach-omap2/fb.c
index 190ae49..ba2e5ae 100644
--- a/arch/arm/mach-omap2/fb.c
+++ b/arch/arm/mach-omap2/fb.c
@@ -81,7 +81,7 @@ static int __init omap_init_vrfb(void)
 	}
 
 	pdev = platform_device_register_resndata(NULL, "omapvrfb", -1,
-			res, num_res, NULL, 0);
+			res, num_res, NULL, 0, NULL);
 
 	if (IS_ERR(pdev))
 		return PTR_ERR(pdev);
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
index ef99011..5ce00ad2 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -82,7 +82,7 @@ void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *gpmc_cfg)
 
 	pdev = platform_device_register_resndata(NULL, "smsc911x", gpmc_cfg->id,
 		 gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
-		 &gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config));
+		 &gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config), NULL);
 	if (!pdev) {
 		pr_err("Unable to register platform device\n");
 		gpio_free(gpmc_cfg->gpio_reset);
diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index 7209db7..5ebbc65 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -129,7 +129,7 @@ static struct platform_device *db8500_add_msp_i2s(struct device *parent,
 		id, irq);
 	pdev = platform_device_register_resndata(parent, "ux500-msp-i2s", id,
 						res, ARRAY_SIZE(res),
-						pdata, sizeof(*pdata));
+						pdata, sizeof(*pdata), NULL);
 	if (!pdev) {
 		pr_err("Failed to register platform-device 'ux500-msp-i2s.%d'!\n",
 			id);
diff --git a/arch/arm/mach-ux500/devices-common.c b/arch/arm/mach-ux500/devices-common.c
index 16b5f71..dcbe6c2 100644
--- a/arch/arm/mach-ux500/devices-common.c
+++ b/arch/arm/mach-ux500/devices-common.c
@@ -42,7 +42,8 @@ dbx500_add_gpio(struct device *parent, int id, resource_size_t addr, int irq,
 		resources,
 		ARRAY_SIZE(resources),
 		pdata,
-		sizeof(*pdata));
+		sizeof(*pdata),
+		NULL);
 }
 
 void dbx500_add_gpios(struct device *parent, resource_size_t *base, int num,
diff --git a/arch/arm/mach-ux500/devices-db8500.h b/arch/arm/mach-ux500/devices-db8500.h
index a5e05f6..5a8ed73 100644
--- a/arch/arm/mach-ux500/devices-db8500.h
+++ b/arch/arm/mach-ux500/devices-db8500.h
@@ -26,7 +26,7 @@ db8500_add_ske_keypad(struct device *parent,
 	};
 
 	return platform_device_register_resndata(parent, "nmk-ske-keypad", -1,
-						 resources, 2, pdata, size);
+						 resources, 2, pdata, size, NULL);
 }
 
 static inline struct amba_device *
diff --git a/arch/unicore32/kernel/puv3-core.c b/arch/unicore32/kernel/puv3-core.c
index 254adee..8143a18 100644
--- a/arch/unicore32/kernel/puv3-core.c
+++ b/arch/unicore32/kernel/puv3-core.c
@@ -274,6 +274,6 @@ void __init puv3_core_init(void)
 	platform_device_register_simple("PKUnity-v3-AC97", -1, NULL, 0);
 	platform_device_register_resndata(&platform_bus, "musb_hdrc", -1,
 			puv3_usb_resources, ARRAY_SIZE(puv3_usb_resources),
-			&puv3_usb_plat, sizeof(puv3_usb_plat));
+			&puv3_usb_plat, sizeof(puv3_usb_plat), NULL);
 }
 
diff --git a/arch/unicore32/kernel/puv3-nb0916.c b/arch/unicore32/kernel/puv3-nb0916.c
index 181108b..b2a55cb 100644
--- a/arch/unicore32/kernel/puv3-nb0916.c
+++ b/arch/unicore32/kernel/puv3-nb0916.c
@@ -119,7 +119,7 @@ int __init mach_nb0916_init(void)
 
 	platform_device_register_resndata(&platform_bus, "physmap-flash", -1,
 			&physmap_flash_resource, 1,
-			&physmap_flash_data, sizeof(physmap_flash_data));
+			&physmap_flash_data, sizeof(physmap_flash_data), NULL);
 
 	if (request_irq(gpio_to_irq(GPI_LCD_CASE_OFF),
 		&nb0916_lcdcaseoff_handler,
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index c0b8df3..79ba66a 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -437,6 +437,7 @@ struct platform_device *platform_device_register_full(
 		goto err_alloc;
 
 	pdev->dev.parent = pdevinfo->parent;
+	pdev->dev.of_node = pdevinfo->of_node;
 	ACPI_HANDLE_SET(&pdev->dev, pdevinfo->acpi_node.handle);
 
 	if (pdevinfo->dma_mask) {
diff --git a/drivers/leds/leds-gpio-register.c b/drivers/leds/leds-gpio-register.c
index 1c4ed55..e1f1c15 100644
--- a/drivers/leds/leds-gpio-register.c
+++ b/drivers/leds/leds-gpio-register.c
@@ -34,7 +34,7 @@ struct platform_device *__init gpio_led_register_device(
 		return ERR_PTR(-ENOMEM);
 
 	ret = platform_device_register_resndata(NULL, "leds-gpio", id,
-			NULL, 0, &_pdata, sizeof(_pdata));
+			NULL, 0, &_pdata, sizeof(_pdata), NULL);
 	if (IS_ERR(ret))
 		kfree(_pdata.leds);
 
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 31f966f..0709ad6 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -566,7 +566,7 @@ static int vm_cmdline_set(const char *device,
 
 	pdev = platform_device_register_resndata(&vm_cmdline_parent,
 			"virtio-mmio", vm_cmdline_id++,
-			resources, ARRAY_SIZE(resources), NULL, 0);
+			resources, ARRAY_SIZE(resources), NULL, 0, NULL);
 	if (IS_ERR(pdev))
 		return PTR_ERR(pdev);
 
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index a9ded9a..29393bd 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -66,6 +66,7 @@ struct platform_device_info {
 		const void *data;
 		size_t size_data;
 		u64 dma_mask;
+		struct device_node *of_node;
 };
 extern struct platform_device *platform_device_register_full(
 		const struct platform_device_info *pdevinfo);
@@ -81,13 +82,14 @@ extern struct platform_device *platform_device_register_full(
  * @num: number of resources
  * @data: platform specific data for this platform device
  * @size: size of platform specific data
+ * @of_node: device node of this platform device
  *
  * Returns &struct platform_device pointer on success, or ERR_PTR() on error.
  */
 static inline struct platform_device *platform_device_register_resndata(
 		struct device *parent, const char *name, int id,
 		const struct resource *res, unsigned int num,
-		const void *data, size_t size) {
+		const void *data, size_t size, struct device_node *of_node) {
 
 	struct platform_device_info pdevinfo = {
 		.parent = parent,
@@ -98,6 +100,7 @@ static inline struct platform_device *platform_device_register_resndata(
 		.data = data,
 		.size_data = size,
 		.dma_mask = 0,
+		.of_node = of_node,
 	};
 
 	return platform_device_register_full(&pdevinfo);
@@ -130,7 +133,7 @@ static inline struct platform_device *platform_device_register_simple(
 		const struct resource *res, unsigned int num)
 {
 	return platform_device_register_resndata(NULL, name, id,
-			res, num, NULL, 0);
+			res, num, NULL, 0, NULL);
 }
 
 /**
@@ -154,7 +157,7 @@ static inline struct platform_device *platform_device_register_data(
 		const void *data, size_t size)
 {
 	return platform_device_register_resndata(parent, name, id,
-			NULL, 0, data, size);
+			NULL, 0, data, size, NULL);
 }
 
 extern struct platform_device *platform_device_alloc(const char *name, int id);
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index d2d124f..e6eabb9 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -982,7 +982,7 @@ static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec)
 	} else {	/* Create a new platform_device for Secondary */
 		i2s->pdev = platform_device_register_resndata(NULL,
 				pdev->name, pdev->id + SAMSUNG_I2S_SECOFF,
-				NULL, 0, NULL, 0);
+				NULL, 0, NULL, 0, NULL);
 		if (IS_ERR(i2s->pdev))
 			return NULL;
 	}
-- 
1.7.7.6

[PATCH RFC 1/7] platform: add a device node

[Javier Martinez Canillas]

When using Device Trees, it is necessary to associate a
device node with a platform device.

Usually this device node has to used in the device probe
function (e.g: to initizalize the pinctrl pads assocaited
with the device).

So, platform code needs to pass a device node as a platform
device info to the platform device registration function.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/mach-imx/devices/platform-gpio-mxc.c |    2 +-
 arch/arm/mach-imx/devices/platform-imx-dma.c  |    4 ++--
 arch/arm/mach-imx/mach-armadillo5x0.c         |    2 +-
 arch/arm/mach-imx/mach-imx27_visstrim_m10.c   |    3 ++-
 arch/arm/mach-imx/mach-mx1ads.c               |    2 +-
 arch/arm/mach-nomadik/cpu-8815.c              |    2 +-
 arch/arm/mach-omap2/fb.c                      |    2 +-
 arch/arm/mach-omap2/gpmc-smsc911x.c           |    2 +-
 arch/arm/mach-ux500/board-mop500-audio.c      |    2 +-
 arch/arm/mach-ux500/devices-common.c          |    3 ++-
 arch/arm/mach-ux500/devices-db8500.h          |    2 +-
 arch/unicore32/kernel/puv3-core.c             |    2 +-
 arch/unicore32/kernel/puv3-nb0916.c           |    2 +-
 drivers/base/platform.c                       |    1 +
 drivers/leds/leds-gpio-register.c             |    2 +-
 drivers/virtio/virtio_mmio.c                  |    2 +-
 include/linux/platform_device.h               |    9 ++++++---
 sound/soc/samsung/i2s.c                       |    2 +-
 18 files changed, 26 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-imx/devices/platform-gpio-mxc.c b/arch/arm/mach-imx/devices/platform-gpio-mxc.c
index 26483fa..4f4d8f9 100644
--- a/arch/arm/mach-imx/devices/platform-gpio-mxc.c
+++ b/arch/arm/mach-imx/devices/platform-gpio-mxc.c
@@ -28,5 +28,5 @@ struct platform_device *__init mxc_register_gpio(char *name, int id,
 	};
 
 	return platform_device_register_resndata(&mxc_aips_bus,
-			name, id, res, ARRAY_SIZE(res), NULL, 0);
+			name, id, res, ARRAY_SIZE(res), NULL, 0, NULL);
 }
diff --git a/arch/arm/mach-imx/devices/platform-imx-dma.c b/arch/arm/mach-imx/devices/platform-imx-dma.c
index ccdb5dc..1e3838c 100644
--- a/arch/arm/mach-imx/devices/platform-imx-dma.c
+++ b/arch/arm/mach-imx/devices/platform-imx-dma.c
@@ -28,7 +28,7 @@ struct platform_device __init __maybe_unused *imx_add_imx_dma(char *name,
 	};
 
 	return platform_device_register_resndata(&mxc_ahb_bus,
-			name, -1, res, ARRAY_SIZE(res), NULL, 0);
+			name, -1, res, ARRAY_SIZE(res), NULL, 0, NULL);
 }
 
 struct platform_device __init __maybe_unused *imx_add_imx_sdma(char *name,
@@ -47,5 +47,5 @@ struct platform_device __init __maybe_unused *imx_add_imx_sdma(char *name,
 	};
 
 	return platform_device_register_resndata(&mxc_ahb_bus, name,
-			-1, res, ARRAY_SIZE(res), pdata, sizeof(*pdata));
+			-1, res, ARRAY_SIZE(res), pdata, sizeof(*pdata), NULL);
 }
diff --git a/arch/arm/mach-imx/mach-armadillo5x0.c b/arch/arm/mach-imx/mach-armadillo5x0.c
index 59bd6b0..e664681 100644
--- a/arch/arm/mach-imx/mach-armadillo5x0.c
+++ b/arch/arm/mach-imx/mach-armadillo5x0.c
@@ -519,7 +519,7 @@ static void __init armadillo5x0_init(void)
 	platform_device_register_resndata(NULL, "physmap-flash", -1,
 			&armadillo5x0_nor_flash_resource, 1,
 			&armadillo5x0_nor_flash_pdata,
-			sizeof(armadillo5x0_nor_flash_pdata));
+			sizeof(armadillo5x0_nor_flash_pdata), NULL);
 
 	/* Register NAND Flash */
 	imx31_add_mxc_nand(&armadillo5x0_nand_board_info);
diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 318bd8d..5065f67 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -570,7 +570,8 @@ static void __init visstrim_m10_board_init(void)
 	imx_add_platform_device("mx27vis", 0, NULL, 0, &snd_mx27vis_pdata,
 				sizeof(snd_mx27vis_pdata));
 	platform_device_register_resndata(NULL, "soc-camera-pdrv", 0, NULL, 0,
-				      &iclink_tvp5150, sizeof(iclink_tvp5150));
+				      &iclink_tvp5150, sizeof(iclink_tvp5150),
+				      NULL);
 	gpio_led_register_device(0, &visstrim_m10_led_data);
 
 	/* Use mother board version to decide what video devices we shall use */
diff --git a/arch/arm/mach-imx/mach-mx1ads.c b/arch/arm/mach-imx/mach-mx1ads.c
index 06b4837..9ce64a5 100644
--- a/arch/arm/mach-imx/mach-mx1ads.c
+++ b/arch/arm/mach-imx/mach-mx1ads.c
@@ -118,7 +118,7 @@ static void __init mx1ads_init(void)
 	/* Physmap flash */
 	platform_device_register_resndata(NULL, "physmap-flash", 0,
 			&flash_resource, 1,
-			&mx1ads_flash_data, sizeof(mx1ads_flash_data));
+			&mx1ads_flash_data, sizeof(mx1ads_flash_data), NULL);
 
 	/* I2C */
 	i2c_register_board_info(0, mx1ads_i2c_devices,
diff --git a/arch/arm/mach-nomadik/cpu-8815.c b/arch/arm/mach-nomadik/cpu-8815.c
index 1273931..b117d6c 100644
--- a/arch/arm/mach-nomadik/cpu-8815.c
+++ b/arch/arm/mach-nomadik/cpu-8815.c
@@ -65,7 +65,7 @@ cpu8815_add_gpio(int id, resource_size_t addr, int irq,
 
 	return platform_device_register_resndata(NULL, "gpio", id,
 				resources, ARRAY_SIZE(resources),
-				pdata, sizeof(*pdata));
+				pdata, sizeof(*pdata), NULL);
 }
 
 void cpu8815_add_gpios(resource_size_t *base, int num, int irq,
diff --git a/arch/arm/mach-omap2/fb.c b/arch/arm/mach-omap2/fb.c
index 190ae49..ba2e5ae 100644
--- a/arch/arm/mach-omap2/fb.c
+++ b/arch/arm/mach-omap2/fb.c
@@ -81,7 +81,7 @@ static int __init omap_init_vrfb(void)
 	}
 
 	pdev = platform_device_register_resndata(NULL, "omapvrfb", -1,
-			res, num_res, NULL, 0);
+			res, num_res, NULL, 0, NULL);
 
 	if (IS_ERR(pdev))
 		return PTR_ERR(pdev);
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
index ef99011..5ce00ad2 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -82,7 +82,7 @@ void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *gpmc_cfg)
 
 	pdev = platform_device_register_resndata(NULL, "smsc911x", gpmc_cfg->id,
 		 gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
-		 &gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config));
+		 &gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config), NULL);
 	if (!pdev) {
 		pr_err("Unable to register platform device\n");
 		gpio_free(gpmc_cfg->gpio_reset);
diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index 7209db7..5ebbc65 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -129,7 +129,7 @@ static struct platform_device *db8500_add_msp_i2s(struct device *parent,
 		id, irq);
 	pdev = platform_device_register_resndata(parent, "ux500-msp-i2s", id,
 						res, ARRAY_SIZE(res),
-						pdata, sizeof(*pdata));
+						pdata, sizeof(*pdata), NULL);
 	if (!pdev) {
 		pr_err("Failed to register platform-device 'ux500-msp-i2s.%d'!\n",
 			id);
diff --git a/arch/arm/mach-ux500/devices-common.c b/arch/arm/mach-ux500/devices-common.c
index 16b5f71..dcbe6c2 100644
--- a/arch/arm/mach-ux500/devices-common.c
+++ b/arch/arm/mach-ux500/devices-common.c
@@ -42,7 +42,8 @@ dbx500_add_gpio(struct device *parent, int id, resource_size_t addr, int irq,
 		resources,
 		ARRAY_SIZE(resources),
 		pdata,
-		sizeof(*pdata));
+		sizeof(*pdata),
+		NULL);
 }
 
 void dbx500_add_gpios(struct device *parent, resource_size_t *base, int num,
diff --git a/arch/arm/mach-ux500/devices-db8500.h b/arch/arm/mach-ux500/devices-db8500.h
index a5e05f6..5a8ed73 100644
--- a/arch/arm/mach-ux500/devices-db8500.h
+++ b/arch/arm/mach-ux500/devices-db8500.h
@@ -26,7 +26,7 @@ db8500_add_ske_keypad(struct device *parent,
 	};
 
 	return platform_device_register_resndata(parent, "nmk-ske-keypad", -1,
-						 resources, 2, pdata, size);
+						 resources, 2, pdata, size, NULL);
 }
 
 static inline struct amba_device *
diff --git a/arch/unicore32/kernel/puv3-core.c b/arch/unicore32/kernel/puv3-core.c
index 254adee..8143a18 100644
--- a/arch/unicore32/kernel/puv3-core.c
+++ b/arch/unicore32/kernel/puv3-core.c
@@ -274,6 +274,6 @@ void __init puv3_core_init(void)
 	platform_device_register_simple("PKUnity-v3-AC97", -1, NULL, 0);
 	platform_device_register_resndata(&platform_bus, "musb_hdrc", -1,
 			puv3_usb_resources, ARRAY_SIZE(puv3_usb_resources),
-			&puv3_usb_plat, sizeof(puv3_usb_plat));
+			&puv3_usb_plat, sizeof(puv3_usb_plat), NULL);
 }
 
diff --git a/arch/unicore32/kernel/puv3-nb0916.c b/arch/unicore32/kernel/puv3-nb0916.c
index 181108b..b2a55cb 100644
--- a/arch/unicore32/kernel/puv3-nb0916.c
+++ b/arch/unicore32/kernel/puv3-nb0916.c
@@ -119,7 +119,7 @@ int __init mach_nb0916_init(void)
 
 	platform_device_register_resndata(&platform_bus, "physmap-flash", -1,
 			&physmap_flash_resource, 1,
-			&physmap_flash_data, sizeof(physmap_flash_data));
+			&physmap_flash_data, sizeof(physmap_flash_data), NULL);
 
 	if (request_irq(gpio_to_irq(GPI_LCD_CASE_OFF),
 		&nb0916_lcdcaseoff_handler,
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index c0b8df3..79ba66a 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -437,6 +437,7 @@ struct platform_device *platform_device_register_full(
 		goto err_alloc;
 
 	pdev->dev.parent = pdevinfo->parent;
+	pdev->dev.of_node = pdevinfo->of_node;
 	ACPI_HANDLE_SET(&pdev->dev, pdevinfo->acpi_node.handle);
 
 	if (pdevinfo->dma_mask) {
diff --git a/drivers/leds/leds-gpio-register.c b/drivers/leds/leds-gpio-register.c
index 1c4ed55..e1f1c15 100644
--- a/drivers/leds/leds-gpio-register.c
+++ b/drivers/leds/leds-gpio-register.c
@@ -34,7 +34,7 @@ struct platform_device *__init gpio_led_register_device(
 		return ERR_PTR(-ENOMEM);
 
 	ret = platform_device_register_resndata(NULL, "leds-gpio", id,
-			NULL, 0, &_pdata, sizeof(_pdata));
+			NULL, 0, &_pdata, sizeof(_pdata), NULL);
 	if (IS_ERR(ret))
 		kfree(_pdata.leds);
 
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 31f966f..0709ad6 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -566,7 +566,7 @@ static int vm_cmdline_set(const char *device,
 
 	pdev = platform_device_register_resndata(&vm_cmdline_parent,
 			"virtio-mmio", vm_cmdline_id++,
-			resources, ARRAY_SIZE(resources), NULL, 0);
+			resources, ARRAY_SIZE(resources), NULL, 0, NULL);
 	if (IS_ERR(pdev))
 		return PTR_ERR(pdev);
 
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index a9ded9a..29393bd 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -66,6 +66,7 @@ struct platform_device_info {
 		const void *data;
 		size_t size_data;
 		u64 dma_mask;
+		struct device_node *of_node;
 };
 extern struct platform_device *platform_device_register_full(
 		const struct platform_device_info *pdevinfo);
@@ -81,13 +82,14 @@ extern struct platform_device *platform_device_register_full(
  * @num: number of resources
  * @data: platform specific data for this platform device
  * @size: size of platform specific data
+ * @of_node: device node of this platform device
  *
  * Returns &struct platform_device pointer on success, or ERR_PTR() on error.
  */
 static inline struct platform_device *platform_device_register_resndata(
 		struct device *parent, const char *name, int id,
 		const struct resource *res, unsigned int num,
-		const void *data, size_t size) {
+		const void *data, size_t size, struct device_node *of_node) {
 
 	struct platform_device_info pdevinfo = {
 		.parent = parent,
@@ -98,6 +100,7 @@ static inline struct platform_device *platform_device_register_resndata(
 		.data = data,
 		.size_data = size,
 		.dma_mask = 0,
+		.of_node = of_node,
 	};
 
 	return platform_device_register_full(&pdevinfo);
@@ -130,7 +133,7 @@ static inline struct platform_device *platform_device_register_simple(
 		const struct resource *res, unsigned int num)
 {
 	return platform_device_register_resndata(NULL, name, id,
-			res, num, NULL, 0);
+			res, num, NULL, 0, NULL);
 }
 
 /**
@@ -154,7 +157,7 @@ static inline struct platform_device *platform_device_register_data(
 		const void *data, size_t size)
 {
 	return platform_device_register_resndata(parent, name, id,
-			NULL, 0, data, size);
+			NULL, 0, data, size, NULL);
 }
 
 extern struct platform_device *platform_device_alloc(const char *name, int id);
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index d2d124f..e6eabb9 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -982,7 +982,7 @@ static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec)
 	} else {	/* Create a new platform_device for Secondary */
 		i2s->pdev = platform_device_register_resndata(NULL,
 				pdev->name, pdev->id + SAMSUNG_I2S_SECOFF,
-				NULL, 0, NULL, 0);
+				NULL, 0, NULL, 0, NULL);
 		if (IS_ERR(i2s->pdev))
 			return NULL;
 	}
-- 
1.7.7.6

[PATCH RFC 2/7] net: smsc911x: add pinctrl support

[Javier Martinez Canillas]

If no pinctrl is available just report a warning since
it may not needed in some cases (e.g: non-DT kernels).

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/net/ethernet/smsc/smsc911x.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index e112877..40766c7 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -59,6 +59,7 @@
 #include <linux/of_device.h>
 #include <linux/of_gpio.h>
 #include <linux/of_net.h>
+#include <linux/pinctrl/consumer.h>
 #include "smsc911x.h"
 
 #define SMSC_CHIPNAME		"smsc911x"
@@ -2352,6 +2353,7 @@ static int smsc911x_drv_probe(struct platform_device *pdev)
 	struct smsc911x_data *pdata;
 	struct smsc911x_platform_config *config = pdev->dev.platform_data;
 	struct resource *res, *irq_res;
+	struct pinctrl *pinctrl;
 	unsigned int intcfg = 0;
 	int res_size, irq_flags;
 	int retval;
@@ -2381,6 +2383,15 @@ static int smsc911x_drv_probe(struct platform_device *pdev)
 		goto out_0;
 	}
 
+	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+	if (IS_ERR(pinctrl)) {
+		retval = PTR_ERR(pinctrl);
+		if (retval == -EPROBE_DEFER)
+			goto out_0;
+
+		dev_warn(&pdev->dev, "No pinctrl provided\n");
+	}
+
 	dev = alloc_etherdev(sizeof(struct smsc911x_data));
 	if (!dev) {
 		retval = -ENOMEM;
-- 
1.7.7.6

[PATCH RFC 2/7] net: smsc911x: add pinctrl support

[Javier Martinez Canillas]

If no pinctrl is available just report a warning since
it may not needed in some cases (e.g: non-DT kernels).

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/net/ethernet/smsc/smsc911x.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index e112877..40766c7 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -59,6 +59,7 @@
 #include <linux/of_device.h>
 #include <linux/of_gpio.h>
 #include <linux/of_net.h>
+#include <linux/pinctrl/consumer.h>
 #include "smsc911x.h"
 
 #define SMSC_CHIPNAME		"smsc911x"
@@ -2352,6 +2353,7 @@ static int smsc911x_drv_probe(struct platform_device *pdev)
 	struct smsc911x_data *pdata;
 	struct smsc911x_platform_config *config = pdev->dev.platform_data;
 	struct resource *res, *irq_res;
+	struct pinctrl *pinctrl;
 	unsigned int intcfg = 0;
 	int res_size, irq_flags;
 	int retval;
@@ -2381,6 +2383,15 @@ static int smsc911x_drv_probe(struct platform_device *pdev)
 		goto out_0;
 	}
 
+	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+	if (IS_ERR(pinctrl)) {
+		retval = PTR_ERR(pinctrl);
+		if (retval == -EPROBE_DEFER)
+			goto out_0;
+
+		dev_warn(&pdev->dev, "No pinctrl provided\n");
+	}
+
 	dev = alloc_etherdev(sizeof(struct smsc911x_data));
 	if (!dev) {
 		retval = -ENOMEM;
-- 
1.7.7.6

[PATCH RFC 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function

[Javier Martinez Canillas]

This patch adds a helper function to parse a device node that
contains all the properties needed to initialize an smsc911x
device connected to an OMAP processor through OMAP's GPMC.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 .../devicetree/bindings/net/gpmc-smsc911x.txt      |   39 ++++++++++++++++++++
 arch/arm/mach-omap2/gpmc-smsc911x.c                |   29 +++++++++++++++
 arch/arm/mach-omap2/gpmc-smsc911x.h                |    6 +++
 3 files changed, 74 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/gpmc-smsc911x.txt

diff --git a/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
new file mode 100644
index 0000000..8bb0df2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
@@ -0,0 +1,39 @@
+* GPMC connected Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
+
+GPMC connected SMSC LAN911x/912x Controllers are represented as child nodes
+of the OMAP General-Purpose Memory Controller with a name of "gpmc_smsc911x".
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- gpmc,cs : The chip select line the pheripheral is connected to
+- gpmc,gpio_irq : The GPIO pin that is connected to the SMSC LAN IRQ line
+
+Optional properties:
+- gpmc,flags : SMSC LAN flags - please refer to include/linux/smsc911x.h
+- gpmc,gpio_reset : The GPIO pin connected to the SMSC LAN reset line
+
+Note: Besides these properties, the gpmc_smsc911x device node could need
+aditional setup such as pin/pad mux settings and voltage regulators. This
+depend on how the pheripheral is wired and his board specific.
+
+Example (for an OMAP3 board):
+
+gpmc@6e000000 {
+	      compatible = "ti,omap3430-gpmc";
+	      ti,hwmods = "gpmc";
+	      reg = <0x6e000000 0x1000000>;
+	      interrupts = <20>;
+	      gpmc,num-cs = <8>;
+	      gpmc,num-waitpins = <4>;
+	      #address-cells = <2>;
+	      #size-cells = <1>;
+
+	      gpmc_smsc911x@0 {
+			      gpmc,cs = <5>;
+			      gpmc,gpio_irq = <176>;
+			      gpmc,flags = <4>; /* SMSC911X_USE_32BIT */
+	      };
+};
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 5ce00ad2..59a2ee4 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -19,6 +19,7 @@
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/smsc911x.h>
+#include <linux/of.h>
 
 #include "gpmc.h"
 #include "gpmc-smsc911x.h"
@@ -98,3 +99,31 @@ free1:
 
 	pr_err("Could not initialize smsc911x device\n");
 }
+
+int gpmc_smsc911x_init_dt(struct device_node *node)
+{
+	struct omap_smsc911x_platform_data gpmc_cfg;
+
+	if (WARN_ON(!node))
+		return -ENODEV;
+
+	if (of_property_read_u32(node, "gpmc,cs", &gpmc_cfg.cs)) {
+		pr_err("Unable to get GPMC smsc911x chip select\n");
+		return -EINVAL;
+	}
+
+	if (of_property_read_u32(node, "gpmc,gpio_irq", &gpmc_cfg.gpio_irq)) {
+		pr_err("Unable to get GPMC smsc911x GPIO IRQ\n");
+		return -EINVAL;
+	}
+
+	if (of_property_read_u32(node, "gpmc,gpio_reset", &gpmc_cfg.gpio_reset))
+		gpmc_cfg.gpio_reset = -EINVAL;
+
+	if (of_property_read_u32(node, "gpmc,flags", &gpmc_cfg.flags))
+		gpmc_cfg.flags = 0;
+
+	gpmc_smsc911x_init(&gpmc_cfg);
+
+	return 0;
+}
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.h b/arch/arm/mach-omap2/gpmc-smsc911x.h
index ea6c9c8..bbcb8bc 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.h
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.h
@@ -25,11 +25,17 @@ struct omap_smsc911x_platform_data {
 
 extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
 
+extern int gpmc_smsc911x_init_dt(struct device_node *node);
+
 #else
 
 static inline void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d)
 {
 }
 
+static inline int gpmc_smsc911x_init_dt(struct device_node *node)
+{
+}
+
 #endif
 #endif
-- 
1.7.7.6

[PATCH RFC 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function

[Javier Martinez Canillas]

This patch adds a helper function to parse a device node that
contains all the properties needed to initialize an smsc911x
device connected to an OMAP processor through OMAP's GPMC.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 .../devicetree/bindings/net/gpmc-smsc911x.txt      |   39 ++++++++++++++++++++
 arch/arm/mach-omap2/gpmc-smsc911x.c                |   29 +++++++++++++++
 arch/arm/mach-omap2/gpmc-smsc911x.h                |    6 +++
 3 files changed, 74 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/gpmc-smsc911x.txt

diff --git a/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
new file mode 100644
index 0000000..8bb0df2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
@@ -0,0 +1,39 @@
+* GPMC connected Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
+
+GPMC connected SMSC LAN911x/912x Controllers are represented as child nodes
+of the OMAP General-Purpose Memory Controller with a name of "gpmc_smsc911x".
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- gpmc,cs : The chip select line the pheripheral is connected to
+- gpmc,gpio_irq : The GPIO pin that is connected to the SMSC LAN IRQ line
+
+Optional properties:
+- gpmc,flags : SMSC LAN flags - please refer to include/linux/smsc911x.h
+- gpmc,gpio_reset : The GPIO pin connected to the SMSC LAN reset line
+
+Note: Besides these properties, the gpmc_smsc911x device node could need
+aditional setup such as pin/pad mux settings and voltage regulators. This
+depend on how the pheripheral is wired and his board specific.
+
+Example (for an OMAP3 board):
+
+gpmc at 6e000000 {
+	      compatible = "ti,omap3430-gpmc";
+	      ti,hwmods = "gpmc";
+	      reg = <0x6e000000 0x1000000>;
+	      interrupts = <20>;
+	      gpmc,num-cs = <8>;
+	      gpmc,num-waitpins = <4>;
+	      #address-cells = <2>;
+	      #size-cells = <1>;
+
+	      gpmc_smsc911x at 0 {
+			      gpmc,cs = <5>;
+			      gpmc,gpio_irq = <176>;
+			      gpmc,flags = <4>; /* SMSC911X_USE_32BIT */
+	      };
+};
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 5ce00ad2..59a2ee4 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -19,6 +19,7 @@
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/smsc911x.h>
+#include <linux/of.h>
 
 #include "gpmc.h"
 #include "gpmc-smsc911x.h"
@@ -98,3 +99,31 @@ free1:
 
 	pr_err("Could not initialize smsc911x device\n");
 }
+
+int gpmc_smsc911x_init_dt(struct device_node *node)
+{
+	struct omap_smsc911x_platform_data gpmc_cfg;
+
+	if (WARN_ON(!node))
+		return -ENODEV;
+
+	if (of_property_read_u32(node, "gpmc,cs", &gpmc_cfg.cs)) {
+		pr_err("Unable to get GPMC smsc911x chip select\n");
+		return -EINVAL;
+	}
+
+	if (of_property_read_u32(node, "gpmc,gpio_irq", &gpmc_cfg.gpio_irq)) {
+		pr_err("Unable to get GPMC smsc911x GPIO IRQ\n");
+		return -EINVAL;
+	}
+
+	if (of_property_read_u32(node, "gpmc,gpio_reset", &gpmc_cfg.gpio_reset))
+		gpmc_cfg.gpio_reset = -EINVAL;
+
+	if (of_property_read_u32(node, "gpmc,flags", &gpmc_cfg.flags))
+		gpmc_cfg.flags = 0;
+
+	gpmc_smsc911x_init(&gpmc_cfg);
+
+	return 0;
+}
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.h b/arch/arm/mach-omap2/gpmc-smsc911x.h
index ea6c9c8..bbcb8bc 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.h
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.h
@@ -25,11 +25,17 @@ struct omap_smsc911x_platform_data {
 
 extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
 
+extern int gpmc_smsc911x_init_dt(struct device_node *node);
+
 #else
 
 static inline void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d)
 {
 }
 
+static inline int gpmc_smsc911x_init_dt(struct device_node *node)
+{
+}
+
 #endif
 #endif
-- 
1.7.7.6

[PATCH RFC 4/7] ARM: OMAP: gpmc-smsc911x: pass a dev node to platform registration

[Javier Martinez Canillas]

The smsc911x driver needs the GPMC smsc911x associated device
node to set the OMAP mux pins using the pinctrl framework.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/mach-omap2/gpmc-smsc911x.c |    5 ++++-
 arch/arm/mach-omap2/gpmc-smsc911x.h |    1 +
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 59a2ee4..9f3b0a5 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -83,7 +83,8 @@ void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *gpmc_cfg)
 
 	pdev = platform_device_register_resndata(NULL, "smsc911x", gpmc_cfg->id,
 		 gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
-		 &gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config), NULL);
+		 &gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config),
+		 gpmc_cfg->of_node);
 	if (!pdev) {
 		pr_err("Unable to register platform device\n");
 		gpio_free(gpmc_cfg->gpio_reset);
@@ -107,6 +108,8 @@ int gpmc_smsc911x_init_dt(struct device_node *node)
 	if (WARN_ON(!node))
 		return -ENODEV;
 
+	gpmc_cfg.of_node = node;
+
 	if (of_property_read_u32(node, "gpmc,cs", &gpmc_cfg.cs)) {
 		pr_err("Unable to get GPMC smsc911x chip select\n");
 		return -EINVAL;
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.h b/arch/arm/mach-omap2/gpmc-smsc911x.h
index bbcb8bc..32a7df0 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.h
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.h
@@ -19,6 +19,7 @@ struct omap_smsc911x_platform_data {
 	int	gpio_irq;
 	int	gpio_reset;
 	u32	flags;
+	struct device_node *of_node;
 };
 
 #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
-- 
1.7.7.6

[PATCH RFC 4/7] ARM: OMAP: gpmc-smsc911x: pass a dev node to platform registration

[Javier Martinez Canillas]

The smsc911x driver needs the GPMC smsc911x associated device
node to set the OMAP mux pins using the pinctrl framework.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/mach-omap2/gpmc-smsc911x.c |    5 ++++-
 arch/arm/mach-omap2/gpmc-smsc911x.h |    1 +
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 59a2ee4..9f3b0a5 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -83,7 +83,8 @@ void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *gpmc_cfg)
 
 	pdev = platform_device_register_resndata(NULL, "smsc911x", gpmc_cfg->id,
 		 gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
-		 &gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config), NULL);
+		 &gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config),
+		 gpmc_cfg->of_node);
 	if (!pdev) {
 		pr_err("Unable to register platform device\n");
 		gpio_free(gpmc_cfg->gpio_reset);
@@ -107,6 +108,8 @@ int gpmc_smsc911x_init_dt(struct device_node *node)
 	if (WARN_ON(!node))
 		return -ENODEV;
 
+	gpmc_cfg.of_node = node;
+
 	if (of_property_read_u32(node, "gpmc,cs", &gpmc_cfg.cs)) {
 		pr_err("Unable to get GPMC smsc911x chip select\n");
 		return -EINVAL;
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.h b/arch/arm/mach-omap2/gpmc-smsc911x.h
index bbcb8bc..32a7df0 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.h
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.h
@@ -19,6 +19,7 @@ struct omap_smsc911x_platform_data {
 	int	gpio_irq;
 	int	gpio_reset;
 	u32	flags;
+	struct device_node *of_node;
 };
 
 #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
-- 
1.7.7.6

[PATCH RFC 5/7] ARM: OMAP: gpmc: add support for gpmc-smsc911x child nodes

[Javier Martinez Canillas]

Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices to the OMAP processor that use the GPMC
as a data bus. One of these devices is the smsc911x LAN chip.

This patch allows an smsc911x LAN pheripheral to be defined
as an GPMC child node an call its corresponding setup function.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/mach-omap2/gpmc.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index f55b504..fd22c62 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -40,6 +40,7 @@
 #include "gpmc.h"
 #include "gpmc-nand.h"
 #include "gpmc-onenand.h"
+#include "gpmc-smsc911x.h"
 
 #define	DEVICE_NAME		"omap-gpmc"
 
@@ -1320,6 +1321,14 @@ static int gpmc_probe_dt(struct platform_device *pdev)
 			return ret;
 		}
 	}
+
+	for_each_node_by_name(child, "gpmc_smsc911x") {
+		ret = gpmc_smsc911x_init_dt(child);
+		if (ret < 0) {
+			of_node_put(child);
+			return ret;
+		}
+	}
 	return 0;
 }
 #else
-- 
1.7.7.6

[PATCH RFC 5/7] ARM: OMAP: gpmc: add support for gpmc-smsc911x child nodes

[Javier Martinez Canillas]

Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices to the OMAP processor that use the GPMC
as a data bus. One of these devices is the smsc911x LAN chip.

This patch allows an smsc911x LAN pheripheral to be defined
as an GPMC child node an call its corresponding setup function.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/mach-omap2/gpmc.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index f55b504..fd22c62 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -40,6 +40,7 @@
 #include "gpmc.h"
 #include "gpmc-nand.h"
 #include "gpmc-onenand.h"
+#include "gpmc-smsc911x.h"
 
 #define	DEVICE_NAME		"omap-gpmc"
 
@@ -1320,6 +1321,14 @@ static int gpmc_probe_dt(struct platform_device *pdev)
 			return ret;
 		}
 	}
+
+	for_each_node_by_name(child, "gpmc_smsc911x") {
+		ret = gpmc_smsc911x_init_dt(child);
+		if (ret < 0) {
+			of_node_put(child);
+			return ret;
+		}
+	}
 	return 0;
 }
 #else
-- 
1.7.7.6

[PATCH RFC 6/7] ARM: dts: OMAP: Add an GPMC node for OMAP3

[Javier Martinez Canillas]

This patch adds a General-Purpose Memory Controller (GPMC)
device node to be used for OMAP3 based SoC boards.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/boot/dts/omap3.dtsi |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6c63118..38b52b3 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -403,5 +403,16 @@
 			ti,timer-alwon;
 			ti,timer-secure;
 		};
+
+		gpmc: gpmc@6e000000 {
+		        compatible = "ti,omap3430-gpmc";
+			ti,hwmods = "gpmc";
+			reg = <0x6e000000 0x1000000>;
+			interrupts = <20>; /* M_IRQ_20 interrupt */
+			gpmc,num-cs = <8>;
+			gpmc,num-waitpins = <4>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+		};
 	};
 };
-- 
1.7.7.6

[PATCH RFC 6/7] ARM: dts: OMAP: Add an GPMC node for OMAP3

[Javier Martinez Canillas]

This patch adds a General-Purpose Memory Controller (GPMC)
device node to be used for OMAP3 based SoC boards.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/boot/dts/omap3.dtsi |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6c63118..38b52b3 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -403,5 +403,16 @@
 			ti,timer-alwon;
 			ti,timer-secure;
 		};
+
+		gpmc: gpmc at 6e000000 {
+		        compatible = "ti,omap3430-gpmc";
+			ti,hwmods = "gpmc";
+			reg = <0x6e000000 0x1000000>;
+			interrupts = <20>; /* M_IRQ_20 interrupt */
+			gpmc,num-cs = <8>;
+			gpmc,num-waitpins = <4>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+		};
 	};
 };
-- 
1.7.7.6

[PATCH RFC 7/7] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support

[Javier Martinez Canillas]

IGEPv2 boards has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.

This patch adds a device node for the ethernet chip so the GPMC
driver will call the gpmc-smsc911x setup code.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/boot/dts/omap3-igep.dtsi    |    6 ++++++
 arch/arm/boot/dts/omap3-igep0020.dts |   24 ++++++++++++++++++++++++
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
index 100eb41..2f02581 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -48,6 +48,12 @@
 			0x126 0x0100	/* sdmmc1_dat7.sdmmc1_dat7 INPUT | MODE 0 */
 		>;
 	};
+
+        smsc911x_pins: pinmux_smsc911x_pins {
+                pinctrl-single,pins = <
+                        0x1a2 0x0104    /* mcspi1_cs2.gpio_176 INPUT | MODE4 */
+                >;
+        };
 };
 
 &i2c1 {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
index e2b9849..68b7cf3 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -40,6 +40,18 @@
 			gpios = <&twl_gpio 19 1>;
 		};
 	};
+
+        vddvario: regulator-vddvario {
+                compatible = "regulator-fixed";
+                regulator-name = "vddvario";
+                regulator-always-on;
+        };
+
+        vdd33a: regulator-vdd33a {
+                compatible = "regulator-fixed";
+                regulator-name = "vdd33a";
+                regulator-always-on;
+        };
 };
 
 &i2c3 {
@@ -54,3 +66,15 @@
 		reg = <0x50>;
 	};
 };
+
+&gpmc {
+	gpmc_smsc911x@0 {
+		pinctrl-names = "default";
+		pinctrl-0 = <&smsc911x_pins>;
+		gpmc,cs = <5>; /* IGEP2_SMSC911X_CS */
+		gpmc,gpio_irq = <176>; /* IGEP2_SMSC911X_GPIO */
+		gpmc,flags = <18>; /* SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS */
+		vmmc-supply = <&vddvario>;
+		vmmc_aux-supply = <&vdd33a>;
+      };
+};
-- 
1.7.7.6

[PATCH RFC 7/7] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support

[Javier Martinez Canillas]

IGEPv2 boards has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.

This patch adds a device node for the ethernet chip so the GPMC
driver will call the gpmc-smsc911x setup code.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/boot/dts/omap3-igep.dtsi    |    6 ++++++
 arch/arm/boot/dts/omap3-igep0020.dts |   24 ++++++++++++++++++++++++
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
index 100eb41..2f02581 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -48,6 +48,12 @@
 			0x126 0x0100	/* sdmmc1_dat7.sdmmc1_dat7 INPUT | MODE 0 */
 		>;
 	};
+
+        smsc911x_pins: pinmux_smsc911x_pins {
+                pinctrl-single,pins = <
+                        0x1a2 0x0104    /* mcspi1_cs2.gpio_176 INPUT | MODE4 */
+                >;
+        };
 };
 
 &i2c1 {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
index e2b9849..68b7cf3 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -40,6 +40,18 @@
 			gpios = <&twl_gpio 19 1>;
 		};
 	};
+
+        vddvario: regulator-vddvario {
+                compatible = "regulator-fixed";
+                regulator-name = "vddvario";
+                regulator-always-on;
+        };
+
+        vdd33a: regulator-vdd33a {
+                compatible = "regulator-fixed";
+                regulator-name = "vdd33a";
+                regulator-always-on;
+        };
 };
 
 &i2c3 {
@@ -54,3 +66,15 @@
 		reg = <0x50>;
 	};
 };
+
+&gpmc {
+	gpmc_smsc911x at 0 {
+		pinctrl-names = "default";
+		pinctrl-0 = <&smsc911x_pins>;
+		gpmc,cs = <5>; /* IGEP2_SMSC911X_CS */
+		gpmc,gpio_irq = <176>; /* IGEP2_SMSC911X_GPIO */
+		gpmc,flags = <18>; /* SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS */
+		vmmc-supply = <&vddvario>;
+		vmmc_aux-supply = <&vdd33a>;
+      };
+};
-- 
1.7.7.6

Re: [PATCH RFC 1/7] platform: add a device node

[Greg Kroah-Hartman]

On Sat, Feb 09, 2013 at 09:44:25PM +0100, Javier Martinez Canillas wrote:
> When using Device Trees, it is necessary to associate a
> device node with a platform device.
> 
> Usually this device node has to used in the device probe
> function (e.g: to initizalize the pinctrl pads assocaited
> with the device).
> 
> So, platform code needs to pass a device node as a platform
> device info to the platform device registration function.

Really?  We don't already have enough other pointers in the platform
device structure that we need another one?

I don't buy it, sorry.  Any reason you didn't run this by Grant as well?

greg k-h

[PATCH RFC 1/7] platform: add a device node

[Greg Kroah-Hartman]

On Sat, Feb 09, 2013 at 09:44:25PM +0100, Javier Martinez Canillas wrote:
> When using Device Trees, it is necessary to associate a
> device node with a platform device.
> 
> Usually this device node has to used in the device probe
> function (e.g: to initizalize the pinctrl pads assocaited
> with the device).
> 
> So, platform code needs to pass a device node as a platform
> device info to the platform device registration function.

Really?  We don't already have enough other pointers in the platform
device structure that we need another one?

I don't buy it, sorry.  Any reason you didn't run this by Grant as well?

greg k-h

Re: [PATCH RFC 1/7] platform: add a device node

[Javier Martinez Canillas]

Hi Greg,

Thanks a lot for your feedback.

On 02/10/2013 02:02 AM, Greg Kroah-Hartman wrote:
> On Sat, Feb 09, 2013 at 09:44:25PM +0100, Javier Martinez Canillas wrote:
>> When using Device Trees, it is necessary to associate a
>> device node with a platform device.
>> 
>> Usually this device node has to used in the device probe
>> function (e.g: to initizalize the pinctrl pads assocaited
>> with the device).
>> 
>> So, platform code needs to pass a device node as a platform
>> device info to the platform device registration function.
> 
> Really?  We don't already have enough other pointers in the platform
> device structure that we need another one?
>

I knew this would be controversial and that's why I didn't mean it to be a patch
but a RFC :)

The problem basically is that you have to associate the platform device with its
corresponding DT device node because it can be used in the driver probe function.

But you can't do this before calling platform_device_register_resndata() since
the platform_device has not been allocated yet and you can't do it after since
by then the driver probe function has been executed already.

You could certainly pass the device node as a platform device resource by for
example storing the dev node pointer in the struct resource .start member or by
adding it to the structure (struct smsc911x_platform_config in this case) that
gets copied to the struct platform_device_info void *data.

Then in the driver probe function you could get the device node from either the
platform_data or a dev->resource.

But I expect most users of platform_device_register_resndata() will have a
similar issue as more and more platform drivers are migrated to DT.

So, to avoid each driver to do the same (encode and decode the DT device node
using platform_data or a device resource) I thought that it could make sense to
add yet another pointer to the struct platform_device_info structure and set:

pdev->dev.of_node = pdevinfo->of_node

inside platform_device_register_full().

> I don't buy it, sorry.  Any reason you didn't run this by Grant as well?
> 

No reason at all, it is just me being goofy. I thought that Grant was cc'ed
already and I just realized that he wasn't. cc'ing him as well.

> greg k-h
> 

Thanks a lot and best regards,
Javier

[PATCH RFC 1/7] platform: add a device node

[Javier Martinez Canillas]

Hi Greg,

Thanks a lot for your feedback.

On 02/10/2013 02:02 AM, Greg Kroah-Hartman wrote:
> On Sat, Feb 09, 2013 at 09:44:25PM +0100, Javier Martinez Canillas wrote:
>> When using Device Trees, it is necessary to associate a
>> device node with a platform device.
>> 
>> Usually this device node has to used in the device probe
>> function (e.g: to initizalize the pinctrl pads assocaited
>> with the device).
>> 
>> So, platform code needs to pass a device node as a platform
>> device info to the platform device registration function.
> 
> Really?  We don't already have enough other pointers in the platform
> device structure that we need another one?
>

I knew this would be controversial and that's why I didn't mean it to be a patch
but a RFC :)

The problem basically is that you have to associate the platform device with its
corresponding DT device node because it can be used in the driver probe function.

But you can't do this before calling platform_device_register_resndata() since
the platform_device has not been allocated yet and you can't do it after since
by then the driver probe function has been executed already.

You could certainly pass the device node as a platform device resource by for
example storing the dev node pointer in the struct resource .start member or by
adding it to the structure (struct smsc911x_platform_config in this case) that
gets copied to the struct platform_device_info void *data.

Then in the driver probe function you could get the device node from either the
platform_data or a dev->resource.

But I expect most users of platform_device_register_resndata() will have a
similar issue as more and more platform drivers are migrated to DT.

So, to avoid each driver to do the same (encode and decode the DT device node
using platform_data or a device resource) I thought that it could make sense to
add yet another pointer to the struct platform_device_info structure and set:

pdev->dev.of_node = pdevinfo->of_node

inside platform_device_register_full().

> I don't buy it, sorry.  Any reason you didn't run this by Grant as well?
> 

No reason at all, it is just me being goofy. I thought that Grant was cc'ed
already and I just realized that he wasn't. cc'ing him as well.

> greg k-h
> 

Thanks a lot and best regards,
Javier

Re: [PATCH RFC 1/7] platform: add a device node

[Russell King - ARM Linux]

On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
> I knew this would be controversial and that's why I didn't mean it to be a patch
> but a RFC :)
> 
> The problem basically is that you have to associate the platform device with its
> corresponding DT device node because it can be used in the driver probe function.

When DT is being used, doesn't DT create the platform devices for you,
with the device node already set correctly?

Manually creating platform devices and adding DT nodes to it sounds like
the wrong thing to be doing.

[PATCH RFC 1/7] platform: add a device node

[Russell King - ARM Linux]

On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
> I knew this would be controversial and that's why I didn't mean it to be a patch
> but a RFC :)
> 
> The problem basically is that you have to associate the platform device with its
> corresponding DT device node because it can be used in the driver probe function.

When DT is being used, doesn't DT create the platform devices for you,
with the device node already set correctly?

Manually creating platform devices and adding DT nodes to it sounds like
the wrong thing to be doing.

Re: [PATCH RFC 1/7] platform: add a device node

[Javier Martinez Canillas]

On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>> I knew this would be controversial and that's why I didn't mean it to be a patch
>> but a RFC :)
>>
>> The problem basically is that you have to associate the platform device with its
>> corresponding DT device node because it can be used in the driver probe function.
>
> When DT is being used, doesn't DT create the platform devices for you,
> with the device node already set correctly?
>

Well they usually do but not always just like usually you have a
platform_device in your board code and call platform_device_register().

But in some configurations you can't just define the platform_device
required resources (I/O memory, IRQ, etc) as static platform data.
In some cases you need a level of indirection.

In this particular case a SMSC ethernet chip is connected to an
OMAP3 processor through its General-Purpose Memory Controller.

You can't just define the I/O memory used by the device since you first
need to request that address to the GPMC. The same happens with the
IRQ line since a OMAP GPIO pin is used so you have to first configure
the GPIO line as input.

So in platform code you call to gpmc_smsc911x_init() passing all the
GPMC specific configurations (GPIO used for IRQ, GPMC chip select, etc)

Then gpmc_smsc911x_init() does all the needed setup, fills a platform_data
for the real platform_device and calls  platform_device_register_resndata().

>From the smsc911x platform_driver probe function point of view it just have
resources and doesn't know if it's I/O memory is directly mapped or is
through a memory controller as the GPMC. It also doesn't know if the IRQ is
a GPIO or not.

Another approach could be extending the current SMSC LAN DT binding with
GPMC-specific properties so the platform driver could do this setup when the
device node is found and the probe function is called.

> Manually creating platform devices and adding DT nodes to it sounds like
> the wrong thing to be doing.
> --

Yes, I don't like this approach to much either but I didn't find a better way to
do it. That was the main point of this RFC.

I'm still learning about Device Trees so I hope that someone with more
experience with DT or more familiarized with OMAP GPMC and the SMSC
driver could take a step forward and help me giving a better idea.

Thanks a lot for your feedback and best regards,
Javier

[PATCH RFC 1/7] platform: add a device node

[Javier Martinez Canillas]

On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>> I knew this would be controversial and that's why I didn't mean it to be a patch
>> but a RFC :)
>>
>> The problem basically is that you have to associate the platform device with its
>> corresponding DT device node because it can be used in the driver probe function.
>
> When DT is being used, doesn't DT create the platform devices for you,
> with the device node already set correctly?
>

Well they usually do but not always just like usually you have a
platform_device in your board code and call platform_device_register().

But in some configurations you can't just define the platform_device
required resources (I/O memory, IRQ, etc) as static platform data.
In some cases you need a level of indirection.

In this particular case a SMSC ethernet chip is connected to an
OMAP3 processor through its General-Purpose Memory Controller.

You can't just define the I/O memory used by the device since you first
need to request that address to the GPMC. The same happens with the
IRQ line since a OMAP GPIO pin is used so you have to first configure
the GPIO line as input.

So in platform code you call to gpmc_smsc911x_init() passing all the
GPMC specific configurations (GPIO used for IRQ, GPMC chip select, etc)

Then gpmc_smsc911x_init() does all the needed setup, fills a platform_data
for the real platform_device and calls  platform_device_register_resndata().

>From the smsc911x platform_driver probe function point of view it just have
resources and doesn't know if it's I/O memory is directly mapped or is
through a memory controller as the GPMC. It also doesn't know if the IRQ is
a GPIO or not.

Another approach could be extending the current SMSC LAN DT binding with
GPMC-specific properties so the platform driver could do this setup when the
device node is found and the probe function is called.

> Manually creating platform devices and adding DT nodes to it sounds like
> the wrong thing to be doing.
> --

Yes, I don't like this approach to much either but I didn't find a better way to
do it. That was the main point of this RFC.

I'm still learning about Device Trees so I hope that someone with more
experience with DT or more familiarized with OMAP GPMC and the SMSC
driver could take a step forward and help me giving a better idea.

Thanks a lot for your feedback and best regards,
Javier

Re: [PATCH RFC 1/7] platform: add a device node

[Sascha Hauer]

On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote:
> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
> >> I knew this would be controversial and that's why I didn't mean it to be a patch
> >> but a RFC :)
> >>
> >> The problem basically is that you have to associate the platform device with its
> >> corresponding DT device node because it can be used in the driver probe function.
> >
> > When DT is being used, doesn't DT create the platform devices for you,
> > with the device node already set correctly?
> >
> 
> Well they usually do but not always just like usually you have a
> platform_device in your board code and call platform_device_register().
> 
> But in some configurations you can't just define the platform_device
> required resources (I/O memory, IRQ, etc) as static platform data.
> In some cases you need a level of indirection.
> 
> In this particular case a SMSC ethernet chip is connected to an
> OMAP3 processor through its General-Purpose Memory Controller.
> 
> You can't just define the I/O memory used by the device since you first
> need to request that address to the GPMC. The same happens with the
> IRQ line since a OMAP GPIO pin is used so you have to first configure
> the GPIO line as input.

For the gpio interrupt you can use, example taken from omap4-var-som.dts:

	interrupt-parent = <&gpio6>;
	interrupts = <11>; /* gpio line 171 */

Other architectures allow to specify the edge/level hi/low active
parameters from the devicetree aswell. The gpio direction should be
handled by the gpio driver as necessary, at least that's what done on
other architectures.

If the SMSC hangs on the GPMC then the SMSC should be a child node of
the GPMC. The GPMC would then act as a bus driver and configure the
chipselects and timings for its children automatically, maybe based
on timing information from the devicetree. I've never tried this before,
but I think that's the way things should be.

No need to manually create platform devices from the devicetree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH RFC 1/7] platform: add a device node

[Sascha Hauer]

On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote:
> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
> >> I knew this would be controversial and that's why I didn't mean it to be a patch
> >> but a RFC :)
> >>
> >> The problem basically is that you have to associate the platform device with its
> >> corresponding DT device node because it can be used in the driver probe function.
> >
> > When DT is being used, doesn't DT create the platform devices for you,
> > with the device node already set correctly?
> >
> 
> Well they usually do but not always just like usually you have a
> platform_device in your board code and call platform_device_register().
> 
> But in some configurations you can't just define the platform_device
> required resources (I/O memory, IRQ, etc) as static platform data.
> In some cases you need a level of indirection.
> 
> In this particular case a SMSC ethernet chip is connected to an
> OMAP3 processor through its General-Purpose Memory Controller.
> 
> You can't just define the I/O memory used by the device since you first
> need to request that address to the GPMC. The same happens with the
> IRQ line since a OMAP GPIO pin is used so you have to first configure
> the GPIO line as input.

For the gpio interrupt you can use, example taken from omap4-var-som.dts:

	interrupt-parent = <&gpio6>;
	interrupts = <11>; /* gpio line 171 */

Other architectures allow to specify the edge/level hi/low active
parameters from the devicetree aswell. The gpio direction should be
handled by the gpio driver as necessary, at least that's what done on
other architectures.

If the SMSC hangs on the GPMC then the SMSC should be a child node of
the GPMC. The GPMC would then act as a bus driver and configure the
chipselects and timings for its children automatically, maybe based
on timing information from the devicetree. I've never tried this before,
but I think that's the way things should be.

No need to manually create platform devices from the devicetree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH RFC 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function

[Mark Rutland]

Hi,

I have a few comments on the binding and the way it's parsed.

On Sat, Feb 09, 2013 at 08:44:27PM +0000, Javier Martinez Canillas wrote:
> This patch adds a helper function to parse a device node that
> contains all the properties needed to initialize an smsc911x
> device connected to an OMAP processor through OMAP's GPMC.
> 
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  .../devicetree/bindings/net/gpmc-smsc911x.txt      |   39 ++++++++++++++++++++
>  arch/arm/mach-omap2/gpmc-smsc911x.c                |   29 +++++++++++++++
>  arch/arm/mach-omap2/gpmc-smsc911x.h                |    6 +++
>  3 files changed, 74 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
> new file mode 100644
> index 0000000..8bb0df2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
> @@ -0,0 +1,39 @@
> +* GPMC connected Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
> +
> +GPMC connected SMSC LAN911x/912x Controllers are represented as child nodes
> +of the OMAP General-Purpose Memory Controller with a name of "gpmc_smsc911x".
> +
> +All timing relevant properties as well as generic gpmc child properties are
> +explained in a separate documents - please refer to
> +Documentation/devicetree/bindings/bus/ti-gpmc.txt
> +
> +Required properties:
> +- gpmc,cs : The chip select line the pheripheral is connected to
> +- gpmc,gpio_irq : The GPIO pin that is connected to the SMSC LAN IRQ line

In devicetree land, we use '-' in preference of '_' in property names.

So this should be "gpio-irq"

> +
> +Optional properties:
> +- gpmc,flags : SMSC LAN flags - please refer to include/linux/smsc911x.h

Please don't do this. It should only be necessary to read binding documents and
hardware datasheets to write a dts. Referring to Linux internals creates a
flaky ABI that's only going to break when things get renamed/moved/modified.

The flags variable used internally by the driver don't have to have a 1-1
correspondence with a single property in the binding. You can have boolean
properties (named, but without a value) in the dt specifying each flag
individually. That way the dts is easier to read, is less tied to linux
internals (and every property is *fully* documented), and it's far easier to
add new flags in future if necessary.

> +- gpmc,gpio_reset : The GPIO pin connected to the SMSC LAN reset line

Preferably: "gpio-reset".

> +
> +Note: Besides these properties, the gpmc_smsc911x device node could need
> +aditional setup such as pin/pad mux settings and voltage regulators. This
> +depend on how the pheripheral is wired and his board specific.
> +
> +Example (for an OMAP3 board):
> +
> +gpmc@6e000000 {
> +	      compatible = "ti,omap3430-gpmc";
> +	      ti,hwmods = "gpmc";
> +	      reg = <0x6e000000 0x1000000>;
> +	      interrupts = <20>;
> +	      gpmc,num-cs = <8>;
> +	      gpmc,num-waitpins = <4>;
> +	      #address-cells = <2>;
> +	      #size-cells = <1>;
> +
> +	      gpmc_smsc911x@0 {
> +			      gpmc,cs = <5>;
> +			      gpmc,gpio_irq = <176>;
> +			      gpmc,flags = <4>; /* SMSC911X_USE_32BIT */

Here you could have a boolean property "gpmc,use-32bit" (or possibly
"gpmc,use-bits", which can either be 32 or 16).

> +	      };
> +};
> diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
> index 5ce00ad2..59a2ee4 100644
> --- a/arch/arm/mach-omap2/gpmc-smsc911x.c
> +++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
> @@ -19,6 +19,7 @@
>  #include <linux/interrupt.h>
>  #include <linux/io.h>
>  #include <linux/smsc911x.h>
> +#include <linux/of.h>
>  
>  #include "gpmc.h"
>  #include "gpmc-smsc911x.h"
> @@ -98,3 +99,31 @@ free1:
>  
>  	pr_err("Could not initialize smsc911x device\n");
>  }
> +
> +int gpmc_smsc911x_init_dt(struct device_node *node)
> +{
> +	struct omap_smsc911x_platform_data gpmc_cfg;
> +
> +	if (WARN_ON(!node))
> +		return -ENODEV;
> +
> +	if (of_property_read_u32(node, "gpmc,cs", &gpmc_cfg.cs)) {
> +		pr_err("Unable to get GPMC smsc911x chip select\n");
> +		return -EINVAL;
> +	}
> +
> +	if (of_property_read_u32(node, "gpmc,gpio_irq", &gpmc_cfg.gpio_irq)) {
> +		pr_err("Unable to get GPMC smsc911x GPIO IRQ\n");
> +		return -EINVAL;
> +	}
> +
> +	if (of_property_read_u32(node, "gpmc,gpio_reset", &gpmc_cfg.gpio_reset))
> +		gpmc_cfg.gpio_reset = -EINVAL;
> +
> +	if (of_property_read_u32(node, "gpmc,flags", &gpmc_cfg.flags))
> +		gpmc_cfg.flags = 0;

Is no sanity checking required for any of the above properties?

To handle separate flags here, you can use something like:

if (of_property_read_bool(node, "gpmc,use-32bit")
	flags |= SMSC911X_USE_32BIT;

[...]

Thanks,
Mark.

[PATCH RFC 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function

[Mark Rutland]

Hi,

I have a few comments on the binding and the way it's parsed.

On Sat, Feb 09, 2013 at 08:44:27PM +0000, Javier Martinez Canillas wrote:
> This patch adds a helper function to parse a device node that
> contains all the properties needed to initialize an smsc911x
> device connected to an OMAP processor through OMAP's GPMC.
> 
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  .../devicetree/bindings/net/gpmc-smsc911x.txt      |   39 ++++++++++++++++++++
>  arch/arm/mach-omap2/gpmc-smsc911x.c                |   29 +++++++++++++++
>  arch/arm/mach-omap2/gpmc-smsc911x.h                |    6 +++
>  3 files changed, 74 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
> new file mode 100644
> index 0000000..8bb0df2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
> @@ -0,0 +1,39 @@
> +* GPMC connected Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
> +
> +GPMC connected SMSC LAN911x/912x Controllers are represented as child nodes
> +of the OMAP General-Purpose Memory Controller with a name of "gpmc_smsc911x".
> +
> +All timing relevant properties as well as generic gpmc child properties are
> +explained in a separate documents - please refer to
> +Documentation/devicetree/bindings/bus/ti-gpmc.txt
> +
> +Required properties:
> +- gpmc,cs : The chip select line the pheripheral is connected to
> +- gpmc,gpio_irq : The GPIO pin that is connected to the SMSC LAN IRQ line

In devicetree land, we use '-' in preference of '_' in property names.

So this should be "gpio-irq"

> +
> +Optional properties:
> +- gpmc,flags : SMSC LAN flags - please refer to include/linux/smsc911x.h

Please don't do this. It should only be necessary to read binding documents and
hardware datasheets to write a dts. Referring to Linux internals creates a
flaky ABI that's only going to break when things get renamed/moved/modified.

The flags variable used internally by the driver don't have to have a 1-1
correspondence with a single property in the binding. You can have boolean
properties (named, but without a value) in the dt specifying each flag
individually. That way the dts is easier to read, is less tied to linux
internals (and every property is *fully* documented), and it's far easier to
add new flags in future if necessary.

> +- gpmc,gpio_reset : The GPIO pin connected to the SMSC LAN reset line

Preferably: "gpio-reset".

> +
> +Note: Besides these properties, the gpmc_smsc911x device node could need
> +aditional setup such as pin/pad mux settings and voltage regulators. This
> +depend on how the pheripheral is wired and his board specific.
> +
> +Example (for an OMAP3 board):
> +
> +gpmc at 6e000000 {
> +	      compatible = "ti,omap3430-gpmc";
> +	      ti,hwmods = "gpmc";
> +	      reg = <0x6e000000 0x1000000>;
> +	      interrupts = <20>;
> +	      gpmc,num-cs = <8>;
> +	      gpmc,num-waitpins = <4>;
> +	      #address-cells = <2>;
> +	      #size-cells = <1>;
> +
> +	      gpmc_smsc911x at 0 {
> +			      gpmc,cs = <5>;
> +			      gpmc,gpio_irq = <176>;
> +			      gpmc,flags = <4>; /* SMSC911X_USE_32BIT */

Here you could have a boolean property "gpmc,use-32bit" (or possibly
"gpmc,use-bits", which can either be 32 or 16).

> +	      };
> +};
> diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
> index 5ce00ad2..59a2ee4 100644
> --- a/arch/arm/mach-omap2/gpmc-smsc911x.c
> +++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
> @@ -19,6 +19,7 @@
>  #include <linux/interrupt.h>
>  #include <linux/io.h>
>  #include <linux/smsc911x.h>
> +#include <linux/of.h>
>  
>  #include "gpmc.h"
>  #include "gpmc-smsc911x.h"
> @@ -98,3 +99,31 @@ free1:
>  
>  	pr_err("Could not initialize smsc911x device\n");
>  }
> +
> +int gpmc_smsc911x_init_dt(struct device_node *node)
> +{
> +	struct omap_smsc911x_platform_data gpmc_cfg;
> +
> +	if (WARN_ON(!node))
> +		return -ENODEV;
> +
> +	if (of_property_read_u32(node, "gpmc,cs", &gpmc_cfg.cs)) {
> +		pr_err("Unable to get GPMC smsc911x chip select\n");
> +		return -EINVAL;
> +	}
> +
> +	if (of_property_read_u32(node, "gpmc,gpio_irq", &gpmc_cfg.gpio_irq)) {
> +		pr_err("Unable to get GPMC smsc911x GPIO IRQ\n");
> +		return -EINVAL;
> +	}
> +
> +	if (of_property_read_u32(node, "gpmc,gpio_reset", &gpmc_cfg.gpio_reset))
> +		gpmc_cfg.gpio_reset = -EINVAL;
> +
> +	if (of_property_read_u32(node, "gpmc,flags", &gpmc_cfg.flags))
> +		gpmc_cfg.flags = 0;

Is no sanity checking required for any of the above properties?

To handle separate flags here, you can use something like:

if (of_property_read_bool(node, "gpmc,use-32bit")
	flags |= SMSC911X_USE_32BIT;

[...]

Thanks,
Mark.

Re: [PATCH RFC 1/7] platform: add a device node

[Javier Martinez Canillas]

On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote:
>> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>> >> I knew this would be controversial and that's why I didn't mean it to be a patch
>> >> but a RFC :)
>> >>
>> >> The problem basically is that you have to associate the platform device with its
>> >> corresponding DT device node because it can be used in the driver probe function.
>> >
>> > When DT is being used, doesn't DT create the platform devices for you,
>> > with the device node already set correctly?
>> >
>>
>> Well they usually do but not always just like usually you have a
>> platform_device in your board code and call platform_device_register().
>>
>> But in some configurations you can't just define the platform_device
>> required resources (I/O memory, IRQ, etc) as static platform data.
>> In some cases you need a level of indirection.
>>
>> In this particular case a SMSC ethernet chip is connected to an
>> OMAP3 processor through its General-Purpose Memory Controller.
>>
>> You can't just define the I/O memory used by the device since you first
>> need to request that address to the GPMC. The same happens with the
>> IRQ line since a OMAP GPIO pin is used so you have to first configure
>> the GPIO line as input.
>
> For the gpio interrupt you can use, example taken from omap4-var-som.dts:
>
>         interrupt-parent = <&gpio6>;
>         interrupts = <11>; /* gpio line 171 */
>
> Other architectures allow to specify the edge/level hi/low active
> parameters from the devicetree aswell. The gpio direction should be
> handled by the gpio driver as necessary, at least that's what done on
> other architectures.
>
> If the SMSC hangs on the GPMC then the SMSC should be a child node of
> the GPMC. The GPMC would then act as a bus driver and configure the
> chipselects and timings for its children automatically, maybe based
> on timing information from the devicetree. I've never tried this before,
> but I think that's the way things should be.
>

Hi Sasha,

The SMSC is already a child node of the GPMC in the device tree but instead
using the generic SMSC binding I added a GPMC-specific SMSC binding.

Since the SMSC binding doesn't have a chip select property and it expects
the I/O memory address to be explicitly defined in the reg property while
the GPMC needs to request this memory according to the chip select used.

> No need to manually create platform devices from the devicetree.
>

Thanks a lot for your feedback, I'll go back and think more about this and try
to solve this using a different approach that won't require changing
the platform
device info structure and reusing the generic SMSC LAN DT binding.

> Sascha
>

Best regards,
Javier

[PATCH RFC 1/7] platform: add a device node

[Javier Martinez Canillas]

On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote:
>> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>> >> I knew this would be controversial and that's why I didn't mean it to be a patch
>> >> but a RFC :)
>> >>
>> >> The problem basically is that you have to associate the platform device with its
>> >> corresponding DT device node because it can be used in the driver probe function.
>> >
>> > When DT is being used, doesn't DT create the platform devices for you,
>> > with the device node already set correctly?
>> >
>>
>> Well they usually do but not always just like usually you have a
>> platform_device in your board code and call platform_device_register().
>>
>> But in some configurations you can't just define the platform_device
>> required resources (I/O memory, IRQ, etc) as static platform data.
>> In some cases you need a level of indirection.
>>
>> In this particular case a SMSC ethernet chip is connected to an
>> OMAP3 processor through its General-Purpose Memory Controller.
>>
>> You can't just define the I/O memory used by the device since you first
>> need to request that address to the GPMC. The same happens with the
>> IRQ line since a OMAP GPIO pin is used so you have to first configure
>> the GPIO line as input.
>
> For the gpio interrupt you can use, example taken from omap4-var-som.dts:
>
>         interrupt-parent = <&gpio6>;
>         interrupts = <11>; /* gpio line 171 */
>
> Other architectures allow to specify the edge/level hi/low active
> parameters from the devicetree aswell. The gpio direction should be
> handled by the gpio driver as necessary, at least that's what done on
> other architectures.
>
> If the SMSC hangs on the GPMC then the SMSC should be a child node of
> the GPMC. The GPMC would then act as a bus driver and configure the
> chipselects and timings for its children automatically, maybe based
> on timing information from the devicetree. I've never tried this before,
> but I think that's the way things should be.
>

Hi Sasha,

The SMSC is already a child node of the GPMC in the device tree but instead
using the generic SMSC binding I added a GPMC-specific SMSC binding.

Since the SMSC binding doesn't have a chip select property and it expects
the I/O memory address to be explicitly defined in the reg property while
the GPMC needs to request this memory according to the chip select used.

> No need to manually create platform devices from the devicetree.
>

Thanks a lot for your feedback, I'll go back and think more about this and try
to solve this using a different approach that won't require changing
the platform
device info structure and reusing the generic SMSC LAN DT binding.

> Sascha
>

Best regards,
Javier

Re: [PATCH RFC 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function

[Javier Martinez Canillas]

On Mon, Feb 11, 2013 at 11:30 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi,
>
> I have a few comments on the binding and the way it's parsed.
>
> On Sat, Feb 09, 2013 at 08:44:27PM +0000, Javier Martinez Canillas wrote:
>> This patch adds a helper function to parse a device node that
>> contains all the properties needed to initialize an smsc911x
>> device connected to an OMAP processor through OMAP's GPMC.
>>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> ---
>>  .../devicetree/bindings/net/gpmc-smsc911x.txt      |   39 ++++++++++++++++++++
>>  arch/arm/mach-omap2/gpmc-smsc911x.c                |   29 +++++++++++++++
>>  arch/arm/mach-omap2/gpmc-smsc911x.h                |    6 +++
>>  3 files changed, 74 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
>> new file mode 100644
>> index 0000000..8bb0df2
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
>> @@ -0,0 +1,39 @@
>> +* GPMC connected Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
>> +
>> +GPMC connected SMSC LAN911x/912x Controllers are represented as child nodes
>> +of the OMAP General-Purpose Memory Controller with a name of "gpmc_smsc911x".
>> +
>> +All timing relevant properties as well as generic gpmc child properties are
>> +explained in a separate documents - please refer to
>> +Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> +
>> +Required properties:
>> +- gpmc,cs : The chip select line the pheripheral is connected to
>> +- gpmc,gpio_irq : The GPIO pin that is connected to the SMSC LAN IRQ line
>
> In devicetree land, we use '-' in preference of '_' in property names.
>
> So this should be "gpio-irq"
>
>> +
>> +Optional properties:
>> +- gpmc,flags : SMSC LAN flags - please refer to include/linux/smsc911x.h
>
> Please don't do this. It should only be necessary to read binding documents and
> hardware datasheets to write a dts. Referring to Linux internals creates a
> flaky ABI that's only going to break when things get renamed/moved/modified.
>
> The flags variable used internally by the driver don't have to have a 1-1
> correspondence with a single property in the binding. You can have boolean
> properties (named, but without a value) in the dt specifying each flag
> individually. That way the dts is easier to read, is less tied to linux
> internals (and every property is *fully* documented), and it's far easier to
> add new flags in future if necessary.
>
>> +- gpmc,gpio_reset : The GPIO pin connected to the SMSC LAN reset line
>
> Preferably: "gpio-reset".
>
>> +
>> +Note: Besides these properties, the gpmc_smsc911x device node could need
>> +aditional setup such as pin/pad mux settings and voltage regulators. This
>> +depend on how the pheripheral is wired and his board specific.
>> +
>> +Example (for an OMAP3 board):
>> +
>> +gpmc@6e000000 {
>> +           compatible = "ti,omap3430-gpmc";
>> +           ti,hwmods = "gpmc";
>> +           reg = <0x6e000000 0x1000000>;
>> +           interrupts = <20>;
>> +           gpmc,num-cs = <8>;
>> +           gpmc,num-waitpins = <4>;
>> +           #address-cells = <2>;
>> +           #size-cells = <1>;
>> +
>> +           gpmc_smsc911x@0 {
>> +                           gpmc,cs = <5>;
>> +                           gpmc,gpio_irq = <176>;
>> +                           gpmc,flags = <4>; /* SMSC911X_USE_32BIT */
>
> Here you could have a boolean property "gpmc,use-32bit" (or possibly
> "gpmc,use-bits", which can either be 32 or 16).
>
>> +           };
>> +};
>> diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
>> index 5ce00ad2..59a2ee4 100644
>> --- a/arch/arm/mach-omap2/gpmc-smsc911x.c
>> +++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
>> @@ -19,6 +19,7 @@
>>  #include <linux/interrupt.h>
>>  #include <linux/io.h>
>>  #include <linux/smsc911x.h>
>> +#include <linux/of.h>
>>
>>  #include "gpmc.h"
>>  #include "gpmc-smsc911x.h"
>> @@ -98,3 +99,31 @@ free1:
>>
>>       pr_err("Could not initialize smsc911x device\n");
>>  }
>> +
>> +int gpmc_smsc911x_init_dt(struct device_node *node)
>> +{
>> +     struct omap_smsc911x_platform_data gpmc_cfg;
>> +
>> +     if (WARN_ON(!node))
>> +             return -ENODEV;
>> +
>> +     if (of_property_read_u32(node, "gpmc,cs", &gpmc_cfg.cs)) {
>> +             pr_err("Unable to get GPMC smsc911x chip select\n");
>> +             return -EINVAL;
>> +     }
>> +
>> +     if (of_property_read_u32(node, "gpmc,gpio_irq", &gpmc_cfg.gpio_irq)) {
>> +             pr_err("Unable to get GPMC smsc911x GPIO IRQ\n");
>> +             return -EINVAL;
>> +     }
>> +
>> +     if (of_property_read_u32(node, "gpmc,gpio_reset", &gpmc_cfg.gpio_reset))
>> +             gpmc_cfg.gpio_reset = -EINVAL;
>> +
>> +     if (of_property_read_u32(node, "gpmc,flags", &gpmc_cfg.flags))
>> +             gpmc_cfg.flags = 0;
>
> Is no sanity checking required for any of the above properties?
>
> To handle separate flags here, you can use something like:
>
> if (of_property_read_bool(node, "gpmc,use-32bit")
>         flags |= SMSC911X_USE_32BIT;
>
> [...]
>
> Thanks,
> Mark.
>

Hello Mark,

I really appreciate your feedback.

I'll drop this binding anyways and try to reuse the generic SMSC LAN binding
so it won't be necessary to manually asign the device node to the platform
device.

But I'll keep in mind your comments for the next time I need to write
a DT binding

Thanks a lot and best regards,
Javier

[PATCH RFC 3/7] ARM: OMAP: gpmc-smsc911x: add DT dev node init function

[Javier Martinez Canillas]

On Mon, Feb 11, 2013 at 11:30 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi,
>
> I have a few comments on the binding and the way it's parsed.
>
> On Sat, Feb 09, 2013 at 08:44:27PM +0000, Javier Martinez Canillas wrote:
>> This patch adds a helper function to parse a device node that
>> contains all the properties needed to initialize an smsc911x
>> device connected to an OMAP processor through OMAP's GPMC.
>>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> ---
>>  .../devicetree/bindings/net/gpmc-smsc911x.txt      |   39 ++++++++++++++++++++
>>  arch/arm/mach-omap2/gpmc-smsc911x.c                |   29 +++++++++++++++
>>  arch/arm/mach-omap2/gpmc-smsc911x.h                |    6 +++
>>  3 files changed, 74 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
>> new file mode 100644
>> index 0000000..8bb0df2
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/gpmc-smsc911x.txt
>> @@ -0,0 +1,39 @@
>> +* GPMC connected Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
>> +
>> +GPMC connected SMSC LAN911x/912x Controllers are represented as child nodes
>> +of the OMAP General-Purpose Memory Controller with a name of "gpmc_smsc911x".
>> +
>> +All timing relevant properties as well as generic gpmc child properties are
>> +explained in a separate documents - please refer to
>> +Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> +
>> +Required properties:
>> +- gpmc,cs : The chip select line the pheripheral is connected to
>> +- gpmc,gpio_irq : The GPIO pin that is connected to the SMSC LAN IRQ line
>
> In devicetree land, we use '-' in preference of '_' in property names.
>
> So this should be "gpio-irq"
>
>> +
>> +Optional properties:
>> +- gpmc,flags : SMSC LAN flags - please refer to include/linux/smsc911x.h
>
> Please don't do this. It should only be necessary to read binding documents and
> hardware datasheets to write a dts. Referring to Linux internals creates a
> flaky ABI that's only going to break when things get renamed/moved/modified.
>
> The flags variable used internally by the driver don't have to have a 1-1
> correspondence with a single property in the binding. You can have boolean
> properties (named, but without a value) in the dt specifying each flag
> individually. That way the dts is easier to read, is less tied to linux
> internals (and every property is *fully* documented), and it's far easier to
> add new flags in future if necessary.
>
>> +- gpmc,gpio_reset : The GPIO pin connected to the SMSC LAN reset line
>
> Preferably: "gpio-reset".
>
>> +
>> +Note: Besides these properties, the gpmc_smsc911x device node could need
>> +aditional setup such as pin/pad mux settings and voltage regulators. This
>> +depend on how the pheripheral is wired and his board specific.
>> +
>> +Example (for an OMAP3 board):
>> +
>> +gpmc at 6e000000 {
>> +           compatible = "ti,omap3430-gpmc";
>> +           ti,hwmods = "gpmc";
>> +           reg = <0x6e000000 0x1000000>;
>> +           interrupts = <20>;
>> +           gpmc,num-cs = <8>;
>> +           gpmc,num-waitpins = <4>;
>> +           #address-cells = <2>;
>> +           #size-cells = <1>;
>> +
>> +           gpmc_smsc911x at 0 {
>> +                           gpmc,cs = <5>;
>> +                           gpmc,gpio_irq = <176>;
>> +                           gpmc,flags = <4>; /* SMSC911X_USE_32BIT */
>
> Here you could have a boolean property "gpmc,use-32bit" (or possibly
> "gpmc,use-bits", which can either be 32 or 16).
>
>> +           };
>> +};
>> diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c b/arch/arm/mach-omap2/gpmc-smsc911x.c
>> index 5ce00ad2..59a2ee4 100644
>> --- a/arch/arm/mach-omap2/gpmc-smsc911x.c
>> +++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
>> @@ -19,6 +19,7 @@
>>  #include <linux/interrupt.h>
>>  #include <linux/io.h>
>>  #include <linux/smsc911x.h>
>> +#include <linux/of.h>
>>
>>  #include "gpmc.h"
>>  #include "gpmc-smsc911x.h"
>> @@ -98,3 +99,31 @@ free1:
>>
>>       pr_err("Could not initialize smsc911x device\n");
>>  }
>> +
>> +int gpmc_smsc911x_init_dt(struct device_node *node)
>> +{
>> +     struct omap_smsc911x_platform_data gpmc_cfg;
>> +
>> +     if (WARN_ON(!node))
>> +             return -ENODEV;
>> +
>> +     if (of_property_read_u32(node, "gpmc,cs", &gpmc_cfg.cs)) {
>> +             pr_err("Unable to get GPMC smsc911x chip select\n");
>> +             return -EINVAL;
>> +     }
>> +
>> +     if (of_property_read_u32(node, "gpmc,gpio_irq", &gpmc_cfg.gpio_irq)) {
>> +             pr_err("Unable to get GPMC smsc911x GPIO IRQ\n");
>> +             return -EINVAL;
>> +     }
>> +
>> +     if (of_property_read_u32(node, "gpmc,gpio_reset", &gpmc_cfg.gpio_reset))
>> +             gpmc_cfg.gpio_reset = -EINVAL;
>> +
>> +     if (of_property_read_u32(node, "gpmc,flags", &gpmc_cfg.flags))
>> +             gpmc_cfg.flags = 0;
>
> Is no sanity checking required for any of the above properties?
>
> To handle separate flags here, you can use something like:
>
> if (of_property_read_bool(node, "gpmc,use-32bit")
>         flags |= SMSC911X_USE_32BIT;
>
> [...]
>
> Thanks,
> Mark.
>

Hello Mark,

I really appreciate your feedback.

I'll drop this binding anyways and try to reuse the generic SMSC LAN binding
so it won't be necessary to manually asign the device node to the platform
device.

But I'll keep in mind your comments for the next time I need to write
a DT binding

Thanks a lot and best regards,
Javier

Re: [PATCH RFC 1/7] platform: add a device node

[Sascha Hauer]

On Mon, Feb 11, 2013 at 11:33:19AM +0100, Javier Martinez Canillas wrote:
> On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote:
> >> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
> >> >> I knew this would be controversial and that's why I didn't mean it to be a patch
> >> >> but a RFC :)
> >> >>
> >> >> The problem basically is that you have to associate the platform device with its
> >> >> corresponding DT device node because it can be used in the driver probe function.
> >> >
> >> > When DT is being used, doesn't DT create the platform devices for you,
> >> > with the device node already set correctly?
> >> >
> >>
> >> Well they usually do but not always just like usually you have a
> >> platform_device in your board code and call platform_device_register().
> >>
> >> But in some configurations you can't just define the platform_device
> >> required resources (I/O memory, IRQ, etc) as static platform data.
> >> In some cases you need a level of indirection.
> >>
> >> In this particular case a SMSC ethernet chip is connected to an
> >> OMAP3 processor through its General-Purpose Memory Controller.
> >>
> >> You can't just define the I/O memory used by the device since you first
> >> need to request that address to the GPMC. The same happens with the
> >> IRQ line since a OMAP GPIO pin is used so you have to first configure
> >> the GPIO line as input.
> >
> > For the gpio interrupt you can use, example taken from omap4-var-som.dts:
> >
> >         interrupt-parent = <&gpio6>;
> >         interrupts = <11>; /* gpio line 171 */
> >
> > Other architectures allow to specify the edge/level hi/low active
> > parameters from the devicetree aswell. The gpio direction should be
> > handled by the gpio driver as necessary, at least that's what done on
> > other architectures.
> >
> > If the SMSC hangs on the GPMC then the SMSC should be a child node of
> > the GPMC. The GPMC would then act as a bus driver and configure the
> > chipselects and timings for its children automatically, maybe based
> > on timing information from the devicetree. I've never tried this before,
> > but I think that's the way things should be.
> >
> 
> Hi Sasha,
> 
> The SMSC is already a child node of the GPMC in the device tree but instead
> using the generic SMSC binding I added a GPMC-specific SMSC binding.
> 
> Since the SMSC binding doesn't have a chip select property and it expects
> the I/O memory address to be explicitly defined in the reg property while
> the GPMC needs to request this memory according to the chip select used.

So you probably have this:

	gpmc {
		compatible = "ti,gpmc", "simple-bus";
		ranges;

		smsc911x {
			compatible = "smsc,91x";
		}
	}

If you remove the simple-bus property the gpmc devices would not be
probed. If then you add a driver which matches "ti,gpmc" you can
configure the chip selects in its probe callback. After this you
can call of_platform_populate() starting from the gpmc device node
to instantiate the gpmc child devices.

Please somebody interrupt me if I'm talking total rubbish here. I never
tried this and only assume it should work like this.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH RFC 1/7] platform: add a device node

[Sascha Hauer]

On Mon, Feb 11, 2013 at 11:33:19AM +0100, Javier Martinez Canillas wrote:
> On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote:
> >> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
> >> >> I knew this would be controversial and that's why I didn't mean it to be a patch
> >> >> but a RFC :)
> >> >>
> >> >> The problem basically is that you have to associate the platform device with its
> >> >> corresponding DT device node because it can be used in the driver probe function.
> >> >
> >> > When DT is being used, doesn't DT create the platform devices for you,
> >> > with the device node already set correctly?
> >> >
> >>
> >> Well they usually do but not always just like usually you have a
> >> platform_device in your board code and call platform_device_register().
> >>
> >> But in some configurations you can't just define the platform_device
> >> required resources (I/O memory, IRQ, etc) as static platform data.
> >> In some cases you need a level of indirection.
> >>
> >> In this particular case a SMSC ethernet chip is connected to an
> >> OMAP3 processor through its General-Purpose Memory Controller.
> >>
> >> You can't just define the I/O memory used by the device since you first
> >> need to request that address to the GPMC. The same happens with the
> >> IRQ line since a OMAP GPIO pin is used so you have to first configure
> >> the GPIO line as input.
> >
> > For the gpio interrupt you can use, example taken from omap4-var-som.dts:
> >
> >         interrupt-parent = <&gpio6>;
> >         interrupts = <11>; /* gpio line 171 */
> >
> > Other architectures allow to specify the edge/level hi/low active
> > parameters from the devicetree aswell. The gpio direction should be
> > handled by the gpio driver as necessary, at least that's what done on
> > other architectures.
> >
> > If the SMSC hangs on the GPMC then the SMSC should be a child node of
> > the GPMC. The GPMC would then act as a bus driver and configure the
> > chipselects and timings for its children automatically, maybe based
> > on timing information from the devicetree. I've never tried this before,
> > but I think that's the way things should be.
> >
> 
> Hi Sasha,
> 
> The SMSC is already a child node of the GPMC in the device tree but instead
> using the generic SMSC binding I added a GPMC-specific SMSC binding.
> 
> Since the SMSC binding doesn't have a chip select property and it expects
> the I/O memory address to be explicitly defined in the reg property while
> the GPMC needs to request this memory according to the chip select used.

So you probably have this:

	gpmc {
		compatible = "ti,gpmc", "simple-bus";
		ranges;

		smsc911x {
			compatible = "smsc,91x";
		}
	}

If you remove the simple-bus property the gpmc devices would not be
probed. If then you add a driver which matches "ti,gpmc" you can
configure the chip selects in its probe callback. After this you
can call of_platform_populate() starting from the gpmc device node
to instantiate the gpmc child devices.

Please somebody interrupt me if I'm talking total rubbish here. I never
tried this and only assume it should work like this.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH RFC 1/7] platform: add a device node

[Javier Martinez Canillas]

On Mon, Feb 11, 2013 at 12:24 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Mon, Feb 11, 2013 at 11:33:19AM +0100, Javier Martinez Canillas wrote:
>> On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> > On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote:
>> >> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
>> >> <linux@arm.linux.org.uk> wrote:
>> >> > On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>> >> >> I knew this would be controversial and that's why I didn't mean it to be a patch
>> >> >> but a RFC :)
>> >> >>
>> >> >> The problem basically is that you have to associate the platform device with its
>> >> >> corresponding DT device node because it can be used in the driver probe function.
>> >> >
>> >> > When DT is being used, doesn't DT create the platform devices for you,
>> >> > with the device node already set correctly?
>> >> >
>> >>
>> >> Well they usually do but not always just like usually you have a
>> >> platform_device in your board code and call platform_device_register().
>> >>
>> >> But in some configurations you can't just define the platform_device
>> >> required resources (I/O memory, IRQ, etc) as static platform data.
>> >> In some cases you need a level of indirection.
>> >>
>> >> In this particular case a SMSC ethernet chip is connected to an
>> >> OMAP3 processor through its General-Purpose Memory Controller.
>> >>
>> >> You can't just define the I/O memory used by the device since you first
>> >> need to request that address to the GPMC. The same happens with the
>> >> IRQ line since a OMAP GPIO pin is used so you have to first configure
>> >> the GPIO line as input.
>> >
>> > For the gpio interrupt you can use, example taken from omap4-var-som.dts:
>> >
>> >         interrupt-parent = <&gpio6>;
>> >         interrupts = <11>; /* gpio line 171 */
>> >
>> > Other architectures allow to specify the edge/level hi/low active
>> > parameters from the devicetree aswell. The gpio direction should be
>> > handled by the gpio driver as necessary, at least that's what done on
>> > other architectures.
>> >
>> > If the SMSC hangs on the GPMC then the SMSC should be a child node of
>> > the GPMC. The GPMC would then act as a bus driver and configure the
>> > chipselects and timings for its children automatically, maybe based
>> > on timing information from the devicetree. I've never tried this before,
>> > but I think that's the way things should be.
>> >
>>
>> Hi Sasha,
>>
>> The SMSC is already a child node of the GPMC in the device tree but instead
>> using the generic SMSC binding I added a GPMC-specific SMSC binding.
>>
>> Since the SMSC binding doesn't have a chip select property and it expects
>> the I/O memory address to be explicitly defined in the reg property while
>> the GPMC needs to request this memory according to the chip select used.
>
> So you probably have this:
>
>         gpmc {
>                 compatible = "ti,gpmc", "simple-bus";
>                 ranges;
>
>                 smsc911x {
>                         compatible = "smsc,91x";
>                 }
>         }
>

Yes

> If you remove the simple-bus property the gpmc devices would not be
> probed. If then you add a driver which matches "ti,gpmc" you can
> configure the chip selects in its probe callback. After this you
> can call of_platform_populate() starting from the gpmc device node
> to instantiate the gpmc child devices.
>
> Please somebody interrupt me if I'm talking total rubbish here. I never
> tried this and only assume it should work like this.
>

Nice, I haven't thought about that and I don't see why it shouldn't work.

I won't have time to work on this for at least the next 3 weeks but I'll try
once I have more free time and post another RFC if I got things working.

> Sascha
>

Thanks a lot and best regards,
Javier

[PATCH RFC 1/7] platform: add a device node

[Javier Martinez Canillas]

On Mon, Feb 11, 2013 at 12:24 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Mon, Feb 11, 2013 at 11:33:19AM +0100, Javier Martinez Canillas wrote:
>> On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> > On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote:
>> >> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
>> >> <linux@arm.linux.org.uk> wrote:
>> >> > On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>> >> >> I knew this would be controversial and that's why I didn't mean it to be a patch
>> >> >> but a RFC :)
>> >> >>
>> >> >> The problem basically is that you have to associate the platform device with its
>> >> >> corresponding DT device node because it can be used in the driver probe function.
>> >> >
>> >> > When DT is being used, doesn't DT create the platform devices for you,
>> >> > with the device node already set correctly?
>> >> >
>> >>
>> >> Well they usually do but not always just like usually you have a
>> >> platform_device in your board code and call platform_device_register().
>> >>
>> >> But in some configurations you can't just define the platform_device
>> >> required resources (I/O memory, IRQ, etc) as static platform data.
>> >> In some cases you need a level of indirection.
>> >>
>> >> In this particular case a SMSC ethernet chip is connected to an
>> >> OMAP3 processor through its General-Purpose Memory Controller.
>> >>
>> >> You can't just define the I/O memory used by the device since you first
>> >> need to request that address to the GPMC. The same happens with the
>> >> IRQ line since a OMAP GPIO pin is used so you have to first configure
>> >> the GPIO line as input.
>> >
>> > For the gpio interrupt you can use, example taken from omap4-var-som.dts:
>> >
>> >         interrupt-parent = <&gpio6>;
>> >         interrupts = <11>; /* gpio line 171 */
>> >
>> > Other architectures allow to specify the edge/level hi/low active
>> > parameters from the devicetree aswell. The gpio direction should be
>> > handled by the gpio driver as necessary, at least that's what done on
>> > other architectures.
>> >
>> > If the SMSC hangs on the GPMC then the SMSC should be a child node of
>> > the GPMC. The GPMC would then act as a bus driver and configure the
>> > chipselects and timings for its children automatically, maybe based
>> > on timing information from the devicetree. I've never tried this before,
>> > but I think that's the way things should be.
>> >
>>
>> Hi Sasha,
>>
>> The SMSC is already a child node of the GPMC in the device tree but instead
>> using the generic SMSC binding I added a GPMC-specific SMSC binding.
>>
>> Since the SMSC binding doesn't have a chip select property and it expects
>> the I/O memory address to be explicitly defined in the reg property while
>> the GPMC needs to request this memory according to the chip select used.
>
> So you probably have this:
>
>         gpmc {
>                 compatible = "ti,gpmc", "simple-bus";
>                 ranges;
>
>                 smsc911x {
>                         compatible = "smsc,91x";
>                 }
>         }
>

Yes

> If you remove the simple-bus property the gpmc devices would not be
> probed. If then you add a driver which matches "ti,gpmc" you can
> configure the chip selects in its probe callback. After this you
> can call of_platform_populate() starting from the gpmc device node
> to instantiate the gpmc child devices.
>
> Please somebody interrupt me if I'm talking total rubbish here. I never
> tried this and only assume it should work like this.
>

Nice, I haven't thought about that and I don't see why it shouldn't work.

I won't have time to work on this for at least the next 3 weeks but I'll try
once I have more free time and post another RFC if I got things working.

> Sascha
>

Thanks a lot and best regards,
Javier

Re: [PATCH RFC 2/7] net: smsc911x: add pinctrl support

[Linus Walleij]

On Sat, Feb 9, 2013 at 9:44 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:

> If no pinctrl is available just report a warning since
> it may not needed in some cases (e.g: non-DT kernels).
>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
(...)
> +       struct pinctrl *pinctrl;
(...)
> +       pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> +       if (IS_ERR(pinctrl)) {
> +               retval = PTR_ERR(pinctrl);
> +               if (retval == -EPROBE_DEFER)
> +                       goto out_0;
> +
> +               dev_warn(&pdev->dev, "No pinctrl provided\n");
> +       }

NACK.

This will be handled from the device core after the v3.9 merge
window.

See:
http://marc.info/?l=linux-kernel&m=135887740715083&w=2

Yours,
Linus Walleij

[PATCH RFC 2/7] net: smsc911x: add pinctrl support

[Linus Walleij]

On Sat, Feb 9, 2013 at 9:44 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:

> If no pinctrl is available just report a warning since
> it may not needed in some cases (e.g: non-DT kernels).
>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
(...)
> +       struct pinctrl *pinctrl;
(...)
> +       pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> +       if (IS_ERR(pinctrl)) {
> +               retval = PTR_ERR(pinctrl);
> +               if (retval == -EPROBE_DEFER)
> +                       goto out_0;
> +
> +               dev_warn(&pdev->dev, "No pinctrl provided\n");
> +       }

NACK.

This will be handled from the device core after the v3.9 merge
window.

See:
http://marc.info/?l=linux-kernel&m=135887740715083&w=2

Yours,
Linus Walleij

Re: [PATCH RFC 2/7] net: smsc911x: add pinctrl support

[Javier Martinez Canillas]

On Mon, Feb 11, 2013 at 3:23 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Sat, Feb 9, 2013 at 9:44 PM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>
>> If no pinctrl is available just report a warning since
>> it may not needed in some cases (e.g: non-DT kernels).
>>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> (...)
>> +       struct pinctrl *pinctrl;
> (...)
>> +       pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
>> +       if (IS_ERR(pinctrl)) {
>> +               retval = PTR_ERR(pinctrl);
>> +               if (retval == -EPROBE_DEFER)
>> +                       goto out_0;
>> +
>> +               dev_warn(&pdev->dev, "No pinctrl provided\n");
>> +       }
>
> NACK.
>
> This will be handled from the device core after the v3.9 merge
> window.
>
> See:
> http://marc.info/?l=linux-kernel&m=135887740715083&w=2
>

Great, I also wondered why it couldn't be part of the device core
since we basically duplicate this in all the DT aware drivers and
pinctrl was not used anywhere after setting to its default state.

This is a nice improvement.

> Yours,
> Linus Walleij
> --

Thanks a lot and best regards,
Javier

[PATCH RFC 2/7] net: smsc911x: add pinctrl support

[Javier Martinez Canillas]

On Mon, Feb 11, 2013 at 3:23 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Sat, Feb 9, 2013 at 9:44 PM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>
>> If no pinctrl is available just report a warning since
>> it may not needed in some cases (e.g: non-DT kernels).
>>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> (...)
>> +       struct pinctrl *pinctrl;
> (...)
>> +       pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
>> +       if (IS_ERR(pinctrl)) {
>> +               retval = PTR_ERR(pinctrl);
>> +               if (retval == -EPROBE_DEFER)
>> +                       goto out_0;
>> +
>> +               dev_warn(&pdev->dev, "No pinctrl provided\n");
>> +       }
>
> NACK.
>
> This will be handled from the device core after the v3.9 merge
> window.
>
> See:
> http://marc.info/?l=linux-kernel&m=135887740715083&w=2
>

Great, I also wondered why it couldn't be part of the device core
since we basically duplicate this in all the DT aware drivers and
pinctrl was not used anywhere after setting to its default state.

This is a nice improvement.

> Yours,
> Linus Walleij
> --

Thanks a lot and best regards,
Javier

Re: [PATCH RFC 1/7] platform: add a device node

[Grant Likely]

On Sun, Feb 10, 2013 at 9:37 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>> I knew this would be controversial and that's why I didn't mean it to be a patch
>> but a RFC :)
>>
>> The problem basically is that you have to associate the platform device with its
>> corresponding DT device node because it can be used in the driver probe function.
>
> When DT is being used, doesn't DT create the platform devices for you,
> with the device node already set correctly?
>
> Manually creating platform devices and adding DT nodes to it sounds like
> the wrong thing to be doing.

Right; I'd expect your platform device creation to go through the
of_platform_populate() route. What is your use-case?

g.



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

[PATCH RFC 1/7] platform: add a device node

[Grant Likely]

On Sun, Feb 10, 2013 at 9:37 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>> I knew this would be controversial and that's why I didn't mean it to be a patch
>> but a RFC :)
>>
>> The problem basically is that you have to associate the platform device with its
>> corresponding DT device node because it can be used in the driver probe function.
>
> When DT is being used, doesn't DT create the platform devices for you,
> with the device node already set correctly?
>
> Manually creating platform devices and adding DT nodes to it sounds like
> the wrong thing to be doing.

Right; I'd expect your platform device creation to go through the
of_platform_populate() route. What is your use-case?

g.



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH RFC 1/7] platform: add a device node

[Grant Likely]

On Sun, Feb 10, 2013 at 11:35 AM, Javier Martinez Canillas
<martinez.javier@gmail.com> wrote:
> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>>> I knew this would be controversial and that's why I didn't mean it to be a patch
>>> but a RFC :)
>>>
>>> The problem basically is that you have to associate the platform device with its
>>> corresponding DT device node because it can be used in the driver probe function.
>>
>> When DT is being used, doesn't DT create the platform devices for you,
>> with the device node already set correctly?
>>
>
> Well they usually do but not always just like usually you have a
> platform_device in your board code and call platform_device_register().
>
> But in some configurations you can't just define the platform_device
> required resources (I/O memory, IRQ, etc) as static platform data.
> In some cases you need a level of indirection.
>
> In this particular case a SMSC ethernet chip is connected to an
> OMAP3 processor through its General-Purpose Memory Controller.
>
> You can't just define the I/O memory used by the device since you first
> need to request that address to the GPMC. The same happens with the
> IRQ line since a OMAP GPIO pin is used so you have to first configure
> the GPIO line as input.
>
> So in platform code you call to gpmc_smsc911x_init() passing all the
> GPMC specific configurations (GPIO used for IRQ, GPMC chip select, etc)
>
> Then gpmc_smsc911x_init() does all the needed setup, fills a platform_data
> for the real platform_device and calls  platform_device_register_resndata().
>
> From the smsc911x platform_driver probe function point of view it just have
> resources and doesn't know if it's I/O memory is directly mapped or is
> through a memory controller as the GPMC. It also doesn't know if the IRQ is
> a GPIO or not.

It's still the same difference as far as the device is concerned.
External bus chip-select lines are well understood. The key here is to
encode the CS line number into the reg property of the child node so
that the GPMC driver has the information it needs to configure the
chip selects. You do this by setting #address-cells to '2' in the GPMC
node, and  use the ranges property to map from the gpmc address space
to the cpu address space. Like so (if you had 2 Ethernet controllers)

        gpmc {
                #address-cells = <2>;  // First cell is CS#, second
cell is offset from CS base
                #size-cells = <1>;
                compatible = "ti,gpmc";
                ranges = <0 0 0xf1000000 0x1000>, //CS0 mapped to
0xf1000000..0xf1000fff
                                <1 0 0xf1001000 0x1000>; //CS1 mapped
to 0xf1001000..0xf1001fff

                ethernet@0,0 {
                        compatible = "smsc,91c111";
                        reg = <0 0 0x1000>;
                }
                ethernet@1,0 {
                        compatible = "smsc,91c111";
                        reg = <1 0 0x1000>;
               }
      }

The GPMC driver can use the information in the ranges property for
setting up the chip select mappings. For the smsc,91c111 driver the
mapping becomes transparent.

You can see another example of this in
arch/powerpc/boot/dts/media5200.dts in the localbus node.

g.

[PATCH RFC 1/7] platform: add a device node

[Grant Likely]

On Sun, Feb 10, 2013 at 11:35 AM, Javier Martinez Canillas
<martinez.javier@gmail.com> wrote:
> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>>> I knew this would be controversial and that's why I didn't mean it to be a patch
>>> but a RFC :)
>>>
>>> The problem basically is that you have to associate the platform device with its
>>> corresponding DT device node because it can be used in the driver probe function.
>>
>> When DT is being used, doesn't DT create the platform devices for you,
>> with the device node already set correctly?
>>
>
> Well they usually do but not always just like usually you have a
> platform_device in your board code and call platform_device_register().
>
> But in some configurations you can't just define the platform_device
> required resources (I/O memory, IRQ, etc) as static platform data.
> In some cases you need a level of indirection.
>
> In this particular case a SMSC ethernet chip is connected to an
> OMAP3 processor through its General-Purpose Memory Controller.
>
> You can't just define the I/O memory used by the device since you first
> need to request that address to the GPMC. The same happens with the
> IRQ line since a OMAP GPIO pin is used so you have to first configure
> the GPIO line as input.
>
> So in platform code you call to gpmc_smsc911x_init() passing all the
> GPMC specific configurations (GPIO used for IRQ, GPMC chip select, etc)
>
> Then gpmc_smsc911x_init() does all the needed setup, fills a platform_data
> for the real platform_device and calls  platform_device_register_resndata().
>
> From the smsc911x platform_driver probe function point of view it just have
> resources and doesn't know if it's I/O memory is directly mapped or is
> through a memory controller as the GPMC. It also doesn't know if the IRQ is
> a GPIO or not.

It's still the same difference as far as the device is concerned.
External bus chip-select lines are well understood. The key here is to
encode the CS line number into the reg property of the child node so
that the GPMC driver has the information it needs to configure the
chip selects. You do this by setting #address-cells to '2' in the GPMC
node, and  use the ranges property to map from the gpmc address space
to the cpu address space. Like so (if you had 2 Ethernet controllers)

        gpmc {
                #address-cells = <2>;  // First cell is CS#, second
cell is offset from CS base
                #size-cells = <1>;
                compatible = "ti,gpmc";
                ranges = <0 0 0xf1000000 0x1000>, //CS0 mapped to
0xf1000000..0xf1000fff
                                <1 0 0xf1001000 0x1000>; //CS1 mapped
to 0xf1001000..0xf1001fff

                ethernet at 0,0 {
                        compatible = "smsc,91c111";
                        reg = <0 0 0x1000>;
                }
                ethernet at 1,0 {
                        compatible = "smsc,91c111";
                        reg = <1 0 0x1000>;
               }
      }

The GPMC driver can use the information in the ranges property for
setting up the chip select mappings. For the smsc,91c111 driver the
mapping becomes transparent.

You can see another example of this in
arch/powerpc/boot/dts/media5200.dts in the localbus node.

g.

Re: [PATCH RFC 1/7] platform: add a device node

[Javier Martinez Canillas]

On 02/18/2013 02:51 PM, Grant Likely wrote:
> On Sun, Feb 10, 2013 at 11:35 AM, Javier Martinez Canillas
> <martinez.javier@gmail.com> wrote:
>> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>>>> I knew this would be controversial and that's why I didn't mean it to be a patch
>>>> but a RFC :)
>>>>
>>>> The problem basically is that you have to associate the platform device with its
>>>> corresponding DT device node because it can be used in the driver probe function.
>>>
>>> When DT is being used, doesn't DT create the platform devices for you,
>>> with the device node already set correctly?
>>>
>>
>> Well they usually do but not always just like usually you have a
>> platform_device in your board code and call platform_device_register().
>>
>> But in some configurations you can't just define the platform_device
>> required resources (I/O memory, IRQ, etc) as static platform data.
>> In some cases you need a level of indirection.
>>
>> In this particular case a SMSC ethernet chip is connected to an
>> OMAP3 processor through its General-Purpose Memory Controller.
>>
>> You can't just define the I/O memory used by the device since you first
>> need to request that address to the GPMC. The same happens with the
>> IRQ line since a OMAP GPIO pin is used so you have to first configure
>> the GPIO line as input.
>>
>> So in platform code you call to gpmc_smsc911x_init() passing all the
>> GPMC specific configurations (GPIO used for IRQ, GPMC chip select, etc)
>>
>> Then gpmc_smsc911x_init() does all the needed setup, fills a platform_data
>> for the real platform_device and calls  platform_device_register_resndata().
>>
>> From the smsc911x platform_driver probe function point of view it just have
>> resources and doesn't know if it's I/O memory is directly mapped or is
>> through a memory controller as the GPMC. It also doesn't know if the IRQ is
>> a GPIO or not.
> 
> It's still the same difference as far as the device is concerned.
> External bus chip-select lines are well understood. The key here is to
> encode the CS line number into the reg property of the child node so
> that the GPMC driver has the information it needs to configure the
> chip selects. You do this by setting #address-cells to '2' in the GPMC
> node, and  use the ranges property to map from the gpmc address space
> to the cpu address space. Like so (if you had 2 Ethernet controllers)
> 
>         gpmc {
>                 #address-cells = <2>;  // First cell is CS#, second
> cell is offset from CS base
>                 #size-cells = <1>;
>                 compatible = "ti,gpmc";
>                 ranges = <0 0 0xf1000000 0x1000>, //CS0 mapped to
> 0xf1000000..0xf1000fff
>                                 <1 0 0xf1001000 0x1000>; //CS1 mapped
> to 0xf1001000..0xf1001fff
> 
>                 ethernet@0,0 {
>                         compatible = "smsc,91c111";
>                         reg = <0 0 0x1000>;
>                 }
>                 ethernet@1,0 {
>                         compatible = "smsc,91c111";
>                         reg = <1 0 0x1000>;
>                }
>       }
> 
> The GPMC driver can use the information in the ranges property for
> setting up the chip select mappings. For the smsc,91c111 driver the
> mapping becomes transparent.
> 
> You can see another example of this in
> arch/powerpc/boot/dts/media5200.dts in the localbus node.
> 
> g.
> 

Hello Grant,

Thanks a lot for your explanation. Now is very clear to me how this has to be
done. I'll work on an v2 of this patch-set that do it correctly and will resend.

Best regards,
Javier

[PATCH RFC 1/7] platform: add a device node

[Javier Martinez Canillas]

On 02/18/2013 02:51 PM, Grant Likely wrote:
> On Sun, Feb 10, 2013 at 11:35 AM, Javier Martinez Canillas
> <martinez.javier@gmail.com> wrote:
>> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>>>> I knew this would be controversial and that's why I didn't mean it to be a patch
>>>> but a RFC :)
>>>>
>>>> The problem basically is that you have to associate the platform device with its
>>>> corresponding DT device node because it can be used in the driver probe function.
>>>
>>> When DT is being used, doesn't DT create the platform devices for you,
>>> with the device node already set correctly?
>>>
>>
>> Well they usually do but not always just like usually you have a
>> platform_device in your board code and call platform_device_register().
>>
>> But in some configurations you can't just define the platform_device
>> required resources (I/O memory, IRQ, etc) as static platform data.
>> In some cases you need a level of indirection.
>>
>> In this particular case a SMSC ethernet chip is connected to an
>> OMAP3 processor through its General-Purpose Memory Controller.
>>
>> You can't just define the I/O memory used by the device since you first
>> need to request that address to the GPMC. The same happens with the
>> IRQ line since a OMAP GPIO pin is used so you have to first configure
>> the GPIO line as input.
>>
>> So in platform code you call to gpmc_smsc911x_init() passing all the
>> GPMC specific configurations (GPIO used for IRQ, GPMC chip select, etc)
>>
>> Then gpmc_smsc911x_init() does all the needed setup, fills a platform_data
>> for the real platform_device and calls  platform_device_register_resndata().
>>
>> From the smsc911x platform_driver probe function point of view it just have
>> resources and doesn't know if it's I/O memory is directly mapped or is
>> through a memory controller as the GPMC. It also doesn't know if the IRQ is
>> a GPIO or not.
> 
> It's still the same difference as far as the device is concerned.
> External bus chip-select lines are well understood. The key here is to
> encode the CS line number into the reg property of the child node so
> that the GPMC driver has the information it needs to configure the
> chip selects. You do this by setting #address-cells to '2' in the GPMC
> node, and  use the ranges property to map from the gpmc address space
> to the cpu address space. Like so (if you had 2 Ethernet controllers)
> 
>         gpmc {
>                 #address-cells = <2>;  // First cell is CS#, second
> cell is offset from CS base
>                 #size-cells = <1>;
>                 compatible = "ti,gpmc";
>                 ranges = <0 0 0xf1000000 0x1000>, //CS0 mapped to
> 0xf1000000..0xf1000fff
>                                 <1 0 0xf1001000 0x1000>; //CS1 mapped
> to 0xf1001000..0xf1001fff
> 
>                 ethernet at 0,0 {
>                         compatible = "smsc,91c111";
>                         reg = <0 0 0x1000>;
>                 }
>                 ethernet at 1,0 {
>                         compatible = "smsc,91c111";
>                         reg = <1 0 0x1000>;
>                }
>       }
> 
> The GPMC driver can use the information in the ranges property for
> setting up the chip select mappings. For the smsc,91c111 driver the
> mapping becomes transparent.
> 
> You can see another example of this in
> arch/powerpc/boot/dts/media5200.dts in the localbus node.
> 
> g.
> 

Hello Grant,

Thanks a lot for your explanation. Now is very clear to me how this has to be
done. I'll work on an v2 of this patch-set that do it correctly and will resend.

Best regards,
Javier