Re: Q: a_ops-readpage() struct file
On Mon, 2012-06-11 at 21:09 +0200, Oleg Nesterov wrote: Stupid question. I'm afraid the answer is no but I'll ask anyway. Is it safe to pass filp == NULL to mapping-readpage()? In fact I do not understand why it needs struct file* and I do not see any example of actual usage. Looking at afs_readpage it looks like its OK to pass in NULL. Same for nfs_readpage. They use the file, if provided, to avoid some lookups, but seem to deal with not having it. This answer by example is of course not authorative nor complete. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Replacement to of_register_platform_driver ?
Hello all,
I just updated to the most recent kernel and a driver I wrote last year
won't compile:
xad.c:534:2: error: implicit declaration of function
'of_register_platform_driver'
I see references to this function as 'obsolete' but could not find
what's the new recommended way to do things. Here's a bit of the
offending code:
static struct of_platform_driver xad_driver = {
.probe = xad_driver_probe,
.remove = xad_driver_remove,
.driver = {
.owner = THIS_MODULE,
.name = xad-driver,
.of_match_table = xad_device_id,
},
};
...
static int __init xad_init(void) {
...
first = MKDEV (my_major, my_minor);
register_chrdev_region(first, count, DEVNAME);
my_cdev = cdev_alloc ();
if (NULL==my_cdev) goto Err;
cdev_init(my_cdev, fops);
rc=cdev_add (my_cdev, first, count);
...
rc = of_register_platform_driver(xad_driver);
...
}
--
Guillaume Dargaud
http://www.gdargaud.net/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Replacement to of_register_platform_driver ?
On Wed, Jun 13, 2012 at 05:21:22PM +0200, Guillaume Dargaud wrote:
Hello all,
I just updated to the most recent kernel and a driver I wrote last year
won't compile:
xad.c:534:2: error: implicit declaration of function
'of_register_platform_driver'
I see references to this function as 'obsolete' but could not find
what's the new recommended way to do things. Here's a bit of the
offending code:
static struct of_platform_driver xad_driver = {
.probe = xad_driver_probe,
.remove = xad_driver_remove,
.driver = {
.owner = THIS_MODULE,
.name = xad-driver,
.of_match_table = xad_device_id,
},
};
...
static int __init xad_init(void) {
...
first = MKDEV (my_major, my_minor);
register_chrdev_region(first, count, DEVNAME);
my_cdev = cdev_alloc ();
if (NULL==my_cdev) goto Err;
cdev_init(my_cdev, fops);
rc=cdev_add (my_cdev, first, count);
...
rc = of_register_platform_driver(xad_driver);
...
}
--
Guillaume Dargaud
http://www.gdargaud.net/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
The history of drivers/misc/carma/carma-fpga.c will show you the code
changes necessary. Specifically, these two commits perform the
conversion:
493340207 carma-fpga: Missed switch from of_register_platform_driver()
b00e126ff MISC: convert drivers/misc/* to use module_platform_driver()
Hope it helps,
Ira
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [PATCH 05/10] powerpc/ps3: Use highmem region from repository
Hi Michael, On Wed, 2012-06-13 at 11:49 +1000, Michael Ellerman wrote: On Wed, 2012-04-25 at 19:19 +, Andre Heider wrote: Use any preallocated highmem region setup by the bootloader. This implementation only checks for the existance of a single region at region_index=0. This feature allows the bootloader to preallocate highmem regions and pass the region locations to the kernel through the repository. Preallocated regions can be used to hold the initrd or other large data. If no region info exists, the kernel retains the old behavior and attempts to allocate the highmem region itself. Based on Hector Martin's patch Get lv1 high memory region from devtree. Apologies if this has been covered before, but why not use the device tree? FreeBSD (and other OS's) don't know about the Linux device tree. This mechanism is for the bootloader to tell the OS about a highmem region it setup, and we want to support more than just Linux. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] drivers: crypto: move nx build to driver/crypto Makefile
When the nx driver was pulled, the Makefile that actually builds it is arch/powerpc/Makefile. This is unnatural. This patch moves the line that builds the nx driver from arch/powerpc/Makefile to drivers/crypto/Makefile where it belongs. Cc: Kent Yoder k...@linux.vnet.ibm.com Signed-off-by: Seth Jennings sjenn...@linux.vnet.ibm.com --- arch/powerpc/Makefile |1 - drivers/crypto/Makefile |3 ++- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 950d1f7..159e94f 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -149,7 +149,6 @@ core-$(CONFIG_KVM) += arch/powerpc/kvm/ core-$(CONFIG_PERF_EVENTS) += arch/powerpc/perf/ drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/ -drivers-$(CONFIG_CRYPTO_DEV_NX) += drivers/crypto/nx/ # Default to zImage, override when needed all: zImage diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index 0139032..67b4fbf 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -14,4 +14,5 @@ obj-$(CONFIG_CRYPTO_DEV_OMAP_AES) += omap-aes.o obj-$(CONFIG_CRYPTO_DEV_PICOXCELL) += picoxcell_crypto.o obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o obj-$(CONFIG_CRYPTO_DEV_TEGRA_AES) += tegra-aes.o -obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/ \ No newline at end of file +obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/ +obj-$(CONFIG_CRYPTO_DEV_NX) += nx/ -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] drivers: crypto: fix typo in nx driver config option
Cc: Kent Yoder k...@linux.vnet.ibm.com Signed-off-by: Seth Jennings sjenn...@linux.vnet.ibm.com --- drivers/crypto/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 1092a77..b9b11a6 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -298,7 +298,7 @@ config CRYPTO_DEV_TEGRA_AES will be called tegra-aes. config CRYPTO_DEV_NX - tristate Support for Power7+ in-Nest cryptographic accleration + tristate Support for Power7+ in-Nest cryptographic acceleration depends on PPC64 IBMVIO select CRYPTO_AES select CRYPTO_CBC -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] drivers: crypto: move nx build to driver/crypto Makefile
On Wed, 2012-06-13 at 13:22 -0500, Seth Jennings wrote: When the nx driver was pulled, the Makefile that actually builds it is arch/powerpc/Makefile. This is unnatural. This patch moves the line that builds the nx driver from arch/powerpc/Makefile to drivers/crypto/Makefile where it belongs. Acked-by: Kent Yoder k...@linux.vnet.ibm.com Cc: Kent Yoder k...@linux.vnet.ibm.com Signed-off-by: Seth Jennings sjenn...@linux.vnet.ibm.com --- arch/powerpc/Makefile |1 - drivers/crypto/Makefile |3 ++- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 950d1f7..159e94f 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -149,7 +149,6 @@ core-$(CONFIG_KVM)+= arch/powerpc/kvm/ core-$(CONFIG_PERF_EVENTS) += arch/powerpc/perf/ drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/ -drivers-$(CONFIG_CRYPTO_DEV_NX) += drivers/crypto/nx/ # Default to zImage, override when needed all: zImage diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index 0139032..67b4fbf 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -14,4 +14,5 @@ obj-$(CONFIG_CRYPTO_DEV_OMAP_AES) += omap-aes.o obj-$(CONFIG_CRYPTO_DEV_PICOXCELL) += picoxcell_crypto.o obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o obj-$(CONFIG_CRYPTO_DEV_TEGRA_AES) += tegra-aes.o -obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/ \ No newline at end of file +obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/ +obj-$(CONFIG_CRYPTO_DEV_NX) += nx/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] uprobes: Pass probed vaddr to arch_uprobe_analyze_insn()
On 06/12, Oleg Nesterov wrote: On 06/12, Srikar Dronamraju wrote: Note also that we should move this !UPROBE_COPY_INSN from install_breakpoint() to somewhere near alloc_uprobe(). This code is called only once, it looks a bit strange to use the random mm (the first mm vma_prio_tree_foreach() finds) and its mapping to verify the insn. In fact this is simply not correct and should be fixed, note that on x86 arch_uprobe_analyze_insn() checks The reason we delay the copy_insn to the first insert is because we have to get access to mm. For archs like x86, we want to know if the executable is 32 bit or not Yes. And this is wrong afaics. Once again. This !UPROBE_COPY_INSN code is called only once, and it uses the random mm. After that install_breakpoint() just calls set_swbp(another_mm) while the insn can be invalid because another_mm-ia32_compat != mm-ia32_compat. So in effect, if we get access to struct file corresponding to the inode and if the inode corresponds to 32 bit executable file or 64 bit executable file during register, then we can move it around alloc_uprobe(). I don't think this can work. I have another simple fix in mind, I'll write another email later. For example. Suppose there is some instruction in /lib64/libc.so which is valid for 64-bit, but not for 32-bit. Suppose that a 32-bit application does mmap(/lib64/libc.so, PROT_EXEC). Now. If vma_prio_tree_foreach() finds this 32-bit mm first, uprobe_register() fails even if there are other 64-bit applications which could be traced. Or. uprobe_register() succeeds because it finds a 64-bit mm first, and then that 32-bit application actually executes the invalid insn. We can move arch_uprobe_analyze_insn() outside of !UPROBE_COPY_INSN block. Or, perhaps, validate_insn_bits() should call both validate_insn_32bits() and validate_insn_64bits(), and set the UPROBE_VALID_IF_32 / UPROBE_VALID_IF_64 flags. install_breakpoint() should do the additinal check before set_swbp() and verify that .ia32_compat matches UPROBE_VALID_IF_*. What do you think? Oleg. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Q: a_ops-readpage() struct file
On 06/13, Peter Zijlstra wrote: On Mon, 2012-06-11 at 21:09 +0200, Oleg Nesterov wrote: Stupid question. I'm afraid the answer is no but I'll ask anyway. Is it safe to pass filp == NULL to mapping-readpage()? In fact I do not understand why it needs struct file* and I do not see any example of actual usage. Looking at afs_readpage it looks like its OK to pass in NULL. Same for nfs_readpage. They use the file, if provided, to avoid some lookups, but seem to deal with not having it. Yes, and reiser4 does the same. This answer by example is of course not authorative nor complete. Yes... perhaps we should simply change this code to use NULL and collect the bug-reports ;) Oleg. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [PATCH 05/10] powerpc/ps3: Use highmem region from repository
On 06/13/12 12:58, Geoff Levand wrote: Hi Michael, On Wed, 2012-06-13 at 11:49 +1000, Michael Ellerman wrote: On Wed, 2012-04-25 at 19:19 +, Andre Heider wrote: Use any preallocated highmem region setup by the bootloader. This implementation only checks for the existance of a single region at region_index=0. This feature allows the bootloader to preallocate highmem regions and pass the region locations to the kernel through the repository. Preallocated regions can be used to hold the initrd or other large data. If no region info exists, the kernel retains the old behavior and attempts to allocate the highmem region itself. Based on Hector Martin's patch Get lv1 high memory region from devtree. Apologies if this has been covered before, but why not use the device tree? FreeBSD (and other OS's) don't know about the Linux device tree. This mechanism is for the bootloader to tell the OS about a highmem region it setup, and we want to support more than just Linux. -Geoff FreeBSD actually does have FDT support -- it's just not used for the PS3 platform at the moment since it is (currently) totally redundant with the HV repository. If people decide that FDT has an advantage, FreeBSD at least can easily be adapted to use it. -Nathan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] drivers: crypto: fix typo in nx driver config option
On Wed, 2012-06-13 at 13:22 -0500, Seth Jennings wrote: Cc: Kent Yoder k...@linux.vnet.ibm.com Signed-off-by: Seth Jennings sjenn...@linux.vnet.ibm.com --- drivers/crypto/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Kent Yoder k...@linux.vnet.ibm.com diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 1092a77..b9b11a6 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -298,7 +298,7 @@ config CRYPTO_DEV_TEGRA_AES will be called tegra-aes. config CRYPTO_DEV_NX - tristate Support for Power7+ in-Nest cryptographic accleration + tristate Support for Power7+ in-Nest cryptographic acceleration depends on PPC64 IBMVIO select CRYPTO_AES select CRYPTO_CBC ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] i2c: let the core register devices from devicetree
Currently, every driver has to do it on its own, but it should be done
in the core, like we already do with board_info structs.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
Based on v3.5-rc2. Only build tested, I don't have a OF based device
around at the moment.
@Peter: Why does ocores do the device registration manually via
platform_data instead of using board_info?
drivers/i2c/busses/i2c-cpm.c|5 -
drivers/i2c/busses/i2c-designware-platdrv.c |1 -
drivers/i2c/busses/i2c-gpio.c |2 --
drivers/i2c/busses/i2c-ibm_iic.c|3 ---
drivers/i2c/busses/i2c-imx.c|2 --
drivers/i2c/busses/i2c-mpc.c|1 -
drivers/i2c/busses/i2c-mxs.c|2 --
drivers/i2c/busses/i2c-ocores.c |2 --
drivers/i2c/busses/i2c-omap.c |2 --
drivers/i2c/busses/i2c-pnx.c|2 --
drivers/i2c/busses/i2c-pxa.c|1 -
drivers/i2c/busses/i2c-s3c2410.c|1 -
drivers/i2c/busses/i2c-sh_mobile.c |1 -
drivers/i2c/busses/i2c-tegra.c |2 --
drivers/i2c/busses/i2c-versatile.c |1 -
drivers/i2c/busses/i2c-xiic.c |2 --
drivers/i2c/i2c-core.c |3 +++
17 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index c1e1096..749e63c 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -673,11 +673,6 @@ static int __devinit cpm_i2c_probe(struct platform_device
*ofdev)
dev_dbg(ofdev-dev, hw routines for %s registered.\n,
cpm-adap.name);
- /*
-* register OF I2C devices
-*/
- of_i2c_register_devices(cpm-adap);
-
return 0;
out_shut:
cpm_i2c_shutdown(cpm);
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 0506fef..cf3b23c 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -147,7 +147,6 @@ static int __devinit dw_i2c_probe(struct platform_device
*pdev)
dev_err(pdev-dev, failure adding adapter\n);
goto err_free_irq;
}
- of_i2c_register_devices(adap);
return 0;
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index e62d2d9..75e26b9 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -195,8 +195,6 @@ static int __devinit i2c_gpio_probe(struct platform_device
*pdev)
if (ret)
goto err_add_bus;
- of_i2c_register_devices(adap);
-
platform_set_drvdata(pdev, priv);
dev_info(pdev-dev, using pins %u (SDA) and %u (SCL%s)\n,
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 806e225..8894ab6 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -759,9 +759,6 @@ static int __devinit iic_probe(struct platform_device
*ofdev)
dev_info(ofdev-dev, using %s mode\n,
dev-fast_mode ? fast (400 kHz) : standard (100 kHz));
- /* Now register all the child nodes */
- of_i2c_register_devices(adap);
-
return 0;
error_cleanup:
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 8d6b504..16d9356 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -568,8 +568,6 @@ static int __init i2c_imx_probe(struct platform_device
*pdev)
goto fail5;
}
- of_i2c_register_devices(i2c_imx-adapter);
-
/* Set up platform driver data */
platform_set_drvdata(pdev, i2c_imx);
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index b76731e..a86049a 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -675,7 +675,6 @@ static int __devinit fsl_i2c_probe(struct platform_device
*op)
dev_err(i2c-dev, failed to add adapter\n);
goto fail_add;
}
- of_i2c_register_devices(i2c-adap);
return result;
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index 04eb441..2bc0ec6 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -379,8 +379,6 @@ static int __devinit mxs_i2c_probe(struct platform_device
*pdev)
return err;
}
- of_i2c_register_devices(adap);
-
return 0;
}
diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 75194c5..a6a11cb 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -344,8 +344,6 @@ static int __devinit ocores_i2c_probe(struct
platform_device *pdev)
if (pdata) {
for (i = 0; i pdata-num_devices; i++)
i2c_new_device(i2c-adap, pdata-devices +
Re: [PATCH] i2c: let the core register devices from devicetree
On Wed, 2012-06-13 at 23:12 +0200, Wolfram Sang wrote: Currently, every driver has to do it on its own, but it should be done in the core, like we already do with board_info structs. Signed-off-by: Wolfram Sang w.s...@pengutronix.de --- Based on v3.5-rc2. Only build tested, I don't have a OF based device around at the moment. Won't that conflict with i2c-powermac doing it its own way ? Cheers, Ben. @Peter: Why does ocores do the device registration manually via platform_data instead of using board_info? drivers/i2c/busses/i2c-cpm.c|5 - drivers/i2c/busses/i2c-designware-platdrv.c |1 - drivers/i2c/busses/i2c-gpio.c |2 -- drivers/i2c/busses/i2c-ibm_iic.c|3 --- drivers/i2c/busses/i2c-imx.c|2 -- drivers/i2c/busses/i2c-mpc.c|1 - drivers/i2c/busses/i2c-mxs.c|2 -- drivers/i2c/busses/i2c-ocores.c |2 -- drivers/i2c/busses/i2c-omap.c |2 -- drivers/i2c/busses/i2c-pnx.c|2 -- drivers/i2c/busses/i2c-pxa.c|1 - drivers/i2c/busses/i2c-s3c2410.c|1 - drivers/i2c/busses/i2c-sh_mobile.c |1 - drivers/i2c/busses/i2c-tegra.c |2 -- drivers/i2c/busses/i2c-versatile.c |1 - drivers/i2c/busses/i2c-xiic.c |2 -- drivers/i2c/i2c-core.c |3 +++ 17 files changed, 3 insertions(+), 30 deletions(-) diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c index c1e1096..749e63c 100644 --- a/drivers/i2c/busses/i2c-cpm.c +++ b/drivers/i2c/busses/i2c-cpm.c @@ -673,11 +673,6 @@ static int __devinit cpm_i2c_probe(struct platform_device *ofdev) dev_dbg(ofdev-dev, hw routines for %s registered.\n, cpm-adap.name); - /* - * register OF I2C devices - */ - of_i2c_register_devices(cpm-adap); - return 0; out_shut: cpm_i2c_shutdown(cpm); diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c index 0506fef..cf3b23c 100644 --- a/drivers/i2c/busses/i2c-designware-platdrv.c +++ b/drivers/i2c/busses/i2c-designware-platdrv.c @@ -147,7 +147,6 @@ static int __devinit dw_i2c_probe(struct platform_device *pdev) dev_err(pdev-dev, failure adding adapter\n); goto err_free_irq; } - of_i2c_register_devices(adap); return 0; diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c index e62d2d9..75e26b9 100644 --- a/drivers/i2c/busses/i2c-gpio.c +++ b/drivers/i2c/busses/i2c-gpio.c @@ -195,8 +195,6 @@ static int __devinit i2c_gpio_probe(struct platform_device *pdev) if (ret) goto err_add_bus; - of_i2c_register_devices(adap); - platform_set_drvdata(pdev, priv); dev_info(pdev-dev, using pins %u (SDA) and %u (SCL%s)\n, diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c index 806e225..8894ab6 100644 --- a/drivers/i2c/busses/i2c-ibm_iic.c +++ b/drivers/i2c/busses/i2c-ibm_iic.c @@ -759,9 +759,6 @@ static int __devinit iic_probe(struct platform_device *ofdev) dev_info(ofdev-dev, using %s mode\n, dev-fast_mode ? fast (400 kHz) : standard (100 kHz)); - /* Now register all the child nodes */ - of_i2c_register_devices(adap); - return 0; error_cleanup: diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c index 8d6b504..16d9356 100644 --- a/drivers/i2c/busses/i2c-imx.c +++ b/drivers/i2c/busses/i2c-imx.c @@ -568,8 +568,6 @@ static int __init i2c_imx_probe(struct platform_device *pdev) goto fail5; } - of_i2c_register_devices(i2c_imx-adapter); - /* Set up platform driver data */ platform_set_drvdata(pdev, i2c_imx); diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c index b76731e..a86049a 100644 --- a/drivers/i2c/busses/i2c-mpc.c +++ b/drivers/i2c/busses/i2c-mpc.c @@ -675,7 +675,6 @@ static int __devinit fsl_i2c_probe(struct platform_device *op) dev_err(i2c-dev, failed to add adapter\n); goto fail_add; } - of_i2c_register_devices(i2c-adap); return result; diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c index 04eb441..2bc0ec6 100644 --- a/drivers/i2c/busses/i2c-mxs.c +++ b/drivers/i2c/busses/i2c-mxs.c @@ -379,8 +379,6 @@ static int __devinit mxs_i2c_probe(struct platform_device *pdev) return err; } - of_i2c_register_devices(adap); - return 0; } diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c index 75194c5..a6a11cb 100644 --- a/drivers/i2c/busses/i2c-ocores.c +++ b/drivers/i2c/busses/i2c-ocores.c @@ -344,8 +344,6 @@ static int
Re: [PATCH] i2c: let the core register devices from devicetree
On 06/13/2012 03:12 PM, Wolfram Sang wrote: Currently, every driver has to do it on its own, but it should be done in the core, like we already do with board_info structs. At least on Tegra this works fine, Tested-by: Stephen Warren swar...@wwwdotorg.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Replacement to of_register_platform_driver ?
On Wed, 2012-06-13 at 17:21 +0200, Guillaume Dargaud wrote: Hello all, I just updated to the most recent kernel and a driver I wrote last year won't compile: xad.c:534:2: error: implicit declaration of function 'of_register_platform_driver' I see references to this function as 'obsolete' but could not find what's the new recommended way to do things. The of bits were merged with the regular platform driver. So you should use a platform_driver, which basically means remove of_ everywhere. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/15] powerpc: convert to %r for all GPR usage
Jesse Larrew jlar...@linux.vnet.ibm.com wrote: On 06/08/2012 06:36 AM, Michael Neuling wrote: -/* General Purpose Registers (GPRs) */ +/* + * General Purpose Registers (GPRs) + * + * The lower case r0-r31 should be used in preference to the upper + * case R0-R31 as they provide more error checking in the assembler. + * Use R0-31 only when really nessesary. + */ -#definer0 0 -#definer1 1 -#definer2 2 -#definer3 3 -#definer4 4 -#definer5 5 -#definer6 6 -#definer7 7 -#definer8 8 -#definer9 9 -#definer10 10 -#definer11 11 -#definer12 12 -#definer13 13 -#definer14 14 -#definer15 15 -#definer16 16 -#definer17 17 -#definer18 18 -#definer19 19 -#definer20 20 -#definer21 21 -#definer22 22 -#definer23 23 -#definer24 24 -#definer25 25 -#definer26 26 -#definer27 27 -#definer28 28 -#definer29 29 -#definer30 30 -#definer31 31 +#definer0 %r0 +#definer1 %r1 +#definer2 %r2 +#definer3 %r3 +#definer4 %r4 +#definer5 %r5 +#definer6 %r6 +#definer7 %r7 +#definer8 %r8 +#definer9 %r9 +#definer10 %r10 +#definer11 %r11 +#definer12 %r12 +#definer13 %r13 +#definer14 %r14 +#definer15 %r15 +#definer16 %r16 +#definer17 %r17 +#definer18 %r18 +#definer19 %r19 +#definer20 %r20 +#definer21 %r21 +#definer22 %r22 +#definer23 %r23 +#definer24 %r24 +#definer25 %r25 +#definer26 %r26 +#definer27 %r27 +#definer28 %r28 +#definer29 %r29 +#definer30 %r30 +#definer31 %r31 #defineR0 0 #defineR1 1 I think your patch was truncated somehow. How so? Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] i2c: let the core register devices from devicetree
On Wed, 13 Jun 2012 23:12:10 +0200, Wolfram Sang w.s...@pengutronix.de wrote: Currently, every driver has to do it on its own, but it should be done in the core, like we already do with board_info structs. Signed-off-by: Wolfram Sang w.s...@pengutronix.de FWIW, and without any actual compiling or testing: Acked-by: Grant Likely grant.lik...@secretlab.ca On this topic, I'd also like to see all of drivers/of/of_i2c.c move into drivers/i2c. I've done the same for spi and gpio and I think the result is cleaner. g. --- Based on v3.5-rc2. Only build tested, I don't have a OF based device around at the moment. @Peter: Why does ocores do the device registration manually via platform_data instead of using board_info? drivers/i2c/busses/i2c-cpm.c|5 - drivers/i2c/busses/i2c-designware-platdrv.c |1 - drivers/i2c/busses/i2c-gpio.c |2 -- drivers/i2c/busses/i2c-ibm_iic.c|3 --- drivers/i2c/busses/i2c-imx.c|2 -- drivers/i2c/busses/i2c-mpc.c|1 - drivers/i2c/busses/i2c-mxs.c|2 -- drivers/i2c/busses/i2c-ocores.c |2 -- drivers/i2c/busses/i2c-omap.c |2 -- drivers/i2c/busses/i2c-pnx.c|2 -- drivers/i2c/busses/i2c-pxa.c|1 - drivers/i2c/busses/i2c-s3c2410.c|1 - drivers/i2c/busses/i2c-sh_mobile.c |1 - drivers/i2c/busses/i2c-tegra.c |2 -- drivers/i2c/busses/i2c-versatile.c |1 - drivers/i2c/busses/i2c-xiic.c |2 -- drivers/i2c/i2c-core.c |3 +++ 17 files changed, 3 insertions(+), 30 deletions(-) diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c index c1e1096..749e63c 100644 --- a/drivers/i2c/busses/i2c-cpm.c +++ b/drivers/i2c/busses/i2c-cpm.c @@ -673,11 +673,6 @@ static int __devinit cpm_i2c_probe(struct platform_device *ofdev) dev_dbg(ofdev-dev, hw routines for %s registered.\n, cpm-adap.name); - /* - * register OF I2C devices - */ - of_i2c_register_devices(cpm-adap); - return 0; out_shut: cpm_i2c_shutdown(cpm); diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c index 0506fef..cf3b23c 100644 --- a/drivers/i2c/busses/i2c-designware-platdrv.c +++ b/drivers/i2c/busses/i2c-designware-platdrv.c @@ -147,7 +147,6 @@ static int __devinit dw_i2c_probe(struct platform_device *pdev) dev_err(pdev-dev, failure adding adapter\n); goto err_free_irq; } - of_i2c_register_devices(adap); return 0; diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c index e62d2d9..75e26b9 100644 --- a/drivers/i2c/busses/i2c-gpio.c +++ b/drivers/i2c/busses/i2c-gpio.c @@ -195,8 +195,6 @@ static int __devinit i2c_gpio_probe(struct platform_device *pdev) if (ret) goto err_add_bus; - of_i2c_register_devices(adap); - platform_set_drvdata(pdev, priv); dev_info(pdev-dev, using pins %u (SDA) and %u (SCL%s)\n, diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c index 806e225..8894ab6 100644 --- a/drivers/i2c/busses/i2c-ibm_iic.c +++ b/drivers/i2c/busses/i2c-ibm_iic.c @@ -759,9 +759,6 @@ static int __devinit iic_probe(struct platform_device *ofdev) dev_info(ofdev-dev, using %s mode\n, dev-fast_mode ? fast (400 kHz) : standard (100 kHz)); - /* Now register all the child nodes */ - of_i2c_register_devices(adap); - return 0; error_cleanup: diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c index 8d6b504..16d9356 100644 --- a/drivers/i2c/busses/i2c-imx.c +++ b/drivers/i2c/busses/i2c-imx.c @@ -568,8 +568,6 @@ static int __init i2c_imx_probe(struct platform_device *pdev) goto fail5; } - of_i2c_register_devices(i2c_imx-adapter); - /* Set up platform driver data */ platform_set_drvdata(pdev, i2c_imx); diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c index b76731e..a86049a 100644 --- a/drivers/i2c/busses/i2c-mpc.c +++ b/drivers/i2c/busses/i2c-mpc.c @@ -675,7 +675,6 @@ static int __devinit fsl_i2c_probe(struct platform_device *op) dev_err(i2c-dev, failed to add adapter\n); goto fail_add; } - of_i2c_register_devices(i2c-adap); return result; diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c index 04eb441..2bc0ec6 100644 --- a/drivers/i2c/busses/i2c-mxs.c +++ b/drivers/i2c/busses/i2c-mxs.c @@ -379,8 +379,6 @@ static int __devinit mxs_i2c_probe(struct platform_device *pdev) return err; } - of_i2c_register_devices(adap); - return 0; } diff
