* QUICC Engine USB Host controller
From: Guilherme Maciel Ferreira @ 2012-06-12 22:26 UTC (permalink / raw)
To: linuxppc-dev
Hi guys,
I'm struggling to make the QUICC engine USB host controller to work.
Thus, I came here in the hope to get some light =3D)
I am working on MPC8321 processor and kernel 2.6.32. Comparing against
the mainstream version, I applied some patches to fix some p=C5=95oblems in
the FHCI driver, then it got running.
Now, it seems that the driver detects a new device, but is not able to
get its description. I'm aware that the driver uses the timer to
synchronize its packets exchange, but I couldn't find the proper timer
clock frequency. I've already tried every value I could derive from
the documentation, once as long as I am concerned there is no way to
measure it.
Here follows a relevant dmesg USB driver output, where there is a timeout e=
rror:
[ 24.396373] usbcore: registered new interface driver usbfs
[ 24.405860] usbcore: registered new interface driver hub
[ 24.414642] usbcore: registered new device driver usb
[ 24.706132] fsl,usb-fhci e01006c0.usb: at 0xcbaf66c0, irq 23
[ 24.721953] fsl,usb-fhci e01006c0.usb: FHCI HOST Controller
[ 24.734528] fsl,usb-fhci e01006c0.usb: new USB bus registered,
assigned bus number 1
[ 24.745942] fsl,usb-fhci e01006c0.usb: irq 23, io mem 0x00000000
[ 24.853738] usb usb1: New USB device found, idVendor=3D1d6b, idProduct=
=3D0001
[ 24.860623] usb usb1: New USB device strings: Mfr=3D3, Product=3D2,
SerialNumber=3D1
[ 24.867902] usb usb1: Product: FHCI HOST Controller
[ 24.872836] usb usb1: Manufacturer: Linux 2.6.32 fsl,usb-fhci
[ 24.878633] usb usb1: SerialNumber: e01006c0.usb
[ 24.937686] usb usb1: configuration #1 chosen from 1 choice
[ 24.957830] hub 1-0:1.0: USB hub found
[ 24.968867] hub 1-0:1.0: 1 port detected
[ 25.367766] usb 1-1: new full speed USB device using fsl,usb-fhci
and address 2
[ 25.531795] usb 1-1: device descriptor read/64, error -110
[ 25.787864] usb 1-1: device descriptor read/64, error -110
[ 26.024464] usb 1-1: new full speed USB device using fsl,usb-fhci
and address 3
[ 26.199736] usb 1-1: device descriptor read/64, error -110
[ 26.455838] usb 1-1: device descriptor read/64, error -110
[ 26.688100] usb 1-1: new full speed USB device using fsl,usb-fhci
and address 4
[ 27.123765] usb 1-1: device not accepting address 4, error -110
[ 27.271797] usb 1-1: new full speed USB device using fsl,usb-fhci
and address 5
[ 27.712333] usb 1-1: device not accepting address 5, error -110
[ 27.735892] hub 1-0:1.0: unable to enumerate USB device on port 1
And here follows a snippet from my device tree:
qe@e0100000 {
#address-cells =3D <1>;
#size-cells =3D <1>;
device_type =3D "qe";
compatible =3D "fsl,qe";
reg =3D <0xe0100000 0x480>;
ranges =3D <0x0 0xe0100000 0x100000>;
brg-frequency =3D <0>;
bus-frequency =3D <0>;
timer@440 {
compatible =3D "fsl,mpc8321-qe-gtm",
"fsl,mpc8360-qe-gtm",
"fsl,qe-gtm", "fsl,gtm";
reg =3D <0x440 0x40>; // 64 bytes @ offset 0x000440
interrupts =3D <12 13 14 15>;
interrupt-parent =3D <&qeic>;
clock-frequency =3D <100000000>; // 100 MHz???
};
usb@6C0 {
#address-cells =3D <1>;
#size-cells =3D <0>;
compatible =3D "fsl,mpc8321-qe-usb",
"fsl,mpc8323-qe-usb",
"fsl,mpc8360-qe-usb";
reg =3D <0x6c0 0x40 0x700 0x100>;
interrupts =3D <11>;
interrupt-parent =3D <&qeic>;
mode =3D "host";
fsl,fullspeed-clock =3D "clk3";
hub-power-budget =3D "100";
gpios =3D <
&qe_pio_a 8 0 // USBOE
&qe_pio_a 1 0 // USBTXP
&qe_pio_a 0 0 // USBTXN
&qe_pio_a 4 0 // USBRXP
&qe_pio_a 5 0 // USBRXN
&qe_pio_d 21 1 // SPEED
&qe_pio_d 25 0 // POWER/SUSPEND
>;
};
};
Thanks in advance for anyone willing to help me.
Best regards,
--=20
Guilherme Maciel Ferreira
Site: http://guilhermemacielferreira.com/
^ permalink raw reply
* RE: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx SoC and Bluestone board
From: Benjamin Herrenschmidt @ 2012-06-13 0:40 UTC (permalink / raw)
To: Vinh Huu Tuong Nguyen; +Cc: linuxppc-dev
In-Reply-To: <da2d8ae5f5008c4695d1898b9e121c1f@mail.gmail.com>
On Tue, 2012-06-12 at 17:26 +0700, Vinh Huu Tuong Nguyen wrote:
> > -----Original Message-----
> > From: Vinh Nguyen Huu Tuong [mailto:vhtnguyen@apm.com]
> > Sent: Monday, May 07, 2012 10:53 AM
> > To: Benjamin Herrenschmidt; Paul Mackerras; Josh Boyer; Matt Porter;
> > Grant Likely; Rob Herring; Duc Dang; David S. Miller; Kumar Gala; Li
> > Yang; Ashish Kalra; Anatolij Gustschin; Liu Gang; linuxppc-
> > dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; devicetree-
> > discuss@lists.ozlabs.org
> > Cc: Vinh Nguyen Huu Tuong
> > Subject: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx
> > SoC and Bluestone board
Such a CC list won't get you any good will. Send it only to the relevant
mailing lists with possibly the -one- concerned maintainer on CC. I
doubt Dave Miller or Matt Porter give any damn about those patches.
As for why it wasn't reviewed yet, well, reviewers are a finite resource
with limited time dedicated to it. If the patch is properly formed and
was posted to the linuxppc-dev@ozlabs.org, it should be tracked on
patchwork.ozlabs.org and won't be lost. Double check it's there (if it's
not, then the patch was probably corrupt).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] usb: fsl_udc: errata - postpone freeing current dTD
From: Fabio Estevam @ 2012-06-13 1:17 UTC (permalink / raw)
To: Christoph Fritz
Cc: Ben Dooks, Chen Peter-B29397, Nicolas Ferre, Hans J. Koch,
Kukjin Kim, Russell King, Thomas Dahlmann, Sascha Hauer,
Christian Hemp, Haojian Zhuang, Daniel Mack, Neil Zhang,
linux-arm-kernel, Oliver Neukum, Eric Miao, Li Yang-R58472,
Greg Kroah-Hartman, linux-usb@vger.kernel.org, Felipe Balbi,
Ido Shayevitz, Estevam Fabio-R49496,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1339530031.3454.16.camel@mars>
On Tue, Jun 12, 2012 at 4:40 PM, Christoph Fritz
<chf.fritz@googlemail.com> wrote:
> Thanks for your patch. It does indeed load
> "Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007)"
> fine - but now when I want to use it:
>
> modprobe g_ether
> [ =C2=A0 17.099363] g_ether gadget: using random self ethernet address
> [ =C2=A0 17.105316] g_ether gadget: using random host ethernet address
> [ =C2=A0 17.111974] usb0: MAC 1a:c7:9e:76:cc:45
> [ =C2=A0 17.115866] usb0: HOST MAC 66:a2:4a:0a:46:17
> [ =C2=A0 17.120199] g_ether gadget: Ethernet Gadget, version: Memorial Da=
y 2008
> [ =C2=A0 17.126861] g_ether gadget: g_ether ready
>
> these are "the last words": System hangs completely. Same behavior with
> g_serial (these two I've tested).
Ok, I just sent a new patch to the linux-usb mailing list.
Tested it on a mx31 and mx51 and it probed g_ether fine. I don't have
a mx35 handy.
>
> Currently I can't investigate this further, not because of a bug - but a
> flu.
Hope you get better soon.
Regards,
Fabio Estevam
^ permalink raw reply
* Re: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx SoC and Bluestone board
From: Josh Boyer @ 2012-06-13 1:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Vinh Huu Tuong Nguyen, linuxppc-dev
In-Reply-To: <1339548038.9220.80.camel@pasglop>
On Tue, Jun 12, 2012 at 8:40 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2012-06-12 at 17:26 +0700, Vinh Huu Tuong Nguyen wrote:
>> > -----Original Message-----
>> > From: Vinh Nguyen Huu Tuong [mailto:vhtnguyen@apm.com]
>> > Sent: Monday, May 07, 2012 10:53 AM
>> > To: Benjamin Herrenschmidt; Paul Mackerras; Josh Boyer; Matt Porter;
>> > Grant Likely; Rob Herring; Duc Dang; David S. Miller; Kumar Gala; Li
>> > Yang; Ashish Kalra; Anatolij Gustschin; Liu Gang; linuxppc-
>> > dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; devicetree-
>> > discuss@lists.ozlabs.org
>> > Cc: Vinh Nguyen Huu Tuong
>> > Subject: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx
>> > SoC and Bluestone board
>
> Such a CC list won't get you any good will. Send it only to the relevant
> mailing lists with possibly the -one- concerned maintainer on CC. I
> doubt Dave Miller or Matt Porter give any damn about those patches.
>
> As for why it wasn't reviewed yet, well, reviewers are a finite resource
> with limited time dedicated to it. If the patch is properly formed and
> was posted to the linuxppc-dev@ozlabs.org, it should be tracked on
> patchwork.ozlabs.org and won't be lost. Double check it's there (if it's
> not, then the patch was probably corrupt).
It's there. I just missed it until today. My apologies Vinh. I'll
do a more formal review tomorrow, but at first glance I'm concerned
with the sysfs usage. The files in sysfs are supposed to be one file
per value, and you see to have something akin to /proc/meminfo in the
sysfs file being created. Perhaps that would be better either split
into unique file names per field in sysfs, or in a debugfs file
instead?
Again, I'll review more closely tomrorow.
josh
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 05/10] powerpc/ps3: Use highmem region from repository
From: Michael Ellerman @ 2012-06-13 1:49 UTC (permalink / raw)
To: geoff, Andre Heider; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1e755c09926de2d9b0e239ba0ce10fdb6835551a.1335379330.git.geoff@infradead.org>
On Wed, 2012-04-25 at 19:19 +0000, 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?
cheers
^ permalink raw reply
* Re: PowerMac PMU programming
From: Justin Hibbits @ 2012-06-13 2:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1339449862.9220.13.camel@pasglop>
On Tue, 12 Jun 2012 07:24:22 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Sun, 2012-06-10 at 23:31 -0400, Justin Hibbits wrote:
>
> > I'll settle on just getting the CPU speed change working, losing
> > 333MHz on my TiBook is a few too many MHz for the poor thing to
> > lose :) I do have a desktop, but that's my development platform,
> > so needs to be at least somewhat stable, so my TiBook is my guinea
> > pig.
> >
> > I've googled everything I can think of, but do you know of any
> > definitive PMU documentation? Or can you give me any hints on
> > what's needed just for that simple operation?
>
> No doco no, Darwin and Linux source code are your best bet.
>
> It works like sleep as in: you send the switch command and the PMU
> will reboot the processor with the new frequency whenever the
> processor enters NAP mode.
>
> This is tricky because there's a loss of cache coherency vs. ongoing
> DMAs, hence tricky bits of code in there to deal with the various
> caches.
>
> > I noticed that you wind down the ADB queue before killing the PMU.
> > Is this necessary? I only disable the interrupt by writing 0x10 to
> > the IER, but our interrupt model for the PMU is different from the
> > Linux one.
>
> Well that will not disable CB1 (or the external GPIO one). You need to
> make sure no other communication with the PMU takes place once you've
> sent the sleep command and until you're back.
I disable interrupts on the CPU first thing right now with a kernel spin
lock, and don't restore them until I'm ready to return from the speed
switch, so the only communication that should be taking place is what
happens in my thread -- I may be missing something here during the
reset, so I'll have to go over it with a fine-toothed comb, this may be
the wrong thing for me to do.
> > Is it also necessary to disable the interrupt input, even though
> > the register write should be disabling the PMU's asserting of the
> > line? There doesn't seem to be much more different than that, and
> > setting the openpic priority, Linux sets it to 0x0f but I didn't see
> > anything in OS X doing that (might that be a problem, too?)
> >
> > I would love to get my TiBook using the full 1GHz.
>
> I don't remember what openpic does in Darwin, I think interrupts are
> all masked there as a side effect of the code in KeyLargo.cpp but I'm
> not sure that applies to frequency changes.
>
> Cheers,
> Ben.
>
>
Thanks for all this, it's really helping me understand what needs to
happen. When I get some free time I'll take a closer look at what I'm
doing and try to fix it with your comments.
Thanks
- Justin
^ permalink raw reply
* Re: [PATCH] powerpc: pseries: Round up MSI-X requests
From: Michael Ellerman @ 2012-06-13 5:18 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, paulus
In-Reply-To: <20120605124703.12bb4cc3@kryten>
On Tue, 2012-06-05 at 12:47 +1000, Anton Blanchard wrote:
> Hi,
>
> > On Mon, 2012-06-04 at 16:43 +1000, Michael Ellerman wrote:
> > > There is some chance this will result in breakage because the driver
> > > asks for N - and assumes that is what was allocated - and the
> > > device is configured for > N.
> >
> > We can fix that. We can whack the configuration back with N, just know
> > that we have "allocated" > N.
I think whacking config space is more likely to break something than
just configuring more than the driver asked for.
> I agree we don't want to be giving back a larger value than requested.
> There's only one place that can happen in theory and since firmware only
> returns power of two values I dont think it will happen in practise.
Don't follow you here.
> Even so do we want to do something like this (as yet untested)? If the
> rounded up request fails we retry with the original request.
Yes we do. Had a chance to test it?
> The pseries msi free code just sets our vectors to 0 so it doesn't need
> to know how many were originally allocated.
Yep, looks like it will cope.
We only create virqs for what's in pdev->msi_list, which will be what
the driver originally asked for, and we free all those by walking the
list again. So the fact that firmware allocated a few extra for us is
OK, we have nothing extra to cleanup.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: pseries: Round up MSI-X requests
From: Benjamin Herrenschmidt @ 2012-06-13 5:25 UTC (permalink / raw)
To: Michael Ellerman; +Cc: paulus, linuxppc-dev, Anton Blanchard
In-Reply-To: <1339564687.8742.9.camel@concordia>
On Wed, 2012-06-13 at 15:18 +1000, Michael Ellerman wrote:
> On Tue, 2012-06-05 at 12:47 +1000, Anton Blanchard wrote:
> > Hi,
> >
> > > On Mon, 2012-06-04 at 16:43 +1000, Michael Ellerman wrote:
> > > > There is some chance this will result in breakage because the driver
> > > > asks for N - and assumes that is what was allocated - and the
> > > > device is configured for > N.
> > >
> > > We can fix that. We can whack the configuration back with N, just know
> > > that we have "allocated" > N.
>
> I think whacking config space is more likely to break something than
> just configuring more than the driver asked for.
How so ? I tend to disagree here..
.
> > I agree we don't want to be giving back a larger value than requested.
> > There's only one place that can happen in theory and since firmware only
> > returns power of two values I dont think it will happen in practise.
>
> Don't follow you here.
>
> > Even so do we want to do something like this (as yet untested)? If the
> > rounded up request fails we retry with the original request.
>
> Yes we do. Had a chance to test it?
>
> > The pseries msi free code just sets our vectors to 0 so it doesn't need
> > to know how many were originally allocated.
>
> Yep, looks like it will cope.
>
> We only create virqs for what's in pdev->msi_list, which will be what
> the driver originally asked for, and we free all those by walking the
> list again. So the fact that firmware allocated a few extra for us is
> OK, we have nothing extra to cleanup.
The firmware interface is busted anyway. We want to be able to
enable/allocate individual MSI-X at runtime, we need to get a new
interface sorted.
Ben.
^ permalink raw reply
* Re: Q: a_ops->readpage() && struct file
From: Peter Zijlstra @ 2012-06-13 9:58 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Linus Torvalds, lkml, Jim Keniston, Paul Mackerras, Al Viro,
antonb, Ingo Molnar, linuxppc-dev, Srikar Dronamraju
In-Reply-To: <20120611190902.GA19869@redhat.com>
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 =3D=3D 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.=20
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.
^ permalink raw reply
* Replacement to of_register_platform_driver ?
From: Guillaume Dargaud @ 2012-06-13 15:21 UTC (permalink / raw)
To: linuxppc-dev
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/
^ permalink raw reply
* Re: Replacement to of_register_platform_driver ?
From: Ira W. Snyder @ 2012-06-13 17:47 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <4FD8AFF2.6000702@lpsc.in2p3.fr>
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
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 05/10] powerpc/ps3: Use highmem region from repository
From: Geoff Levand @ 2012-06-13 17:58 UTC (permalink / raw)
To: Michael Ellerman
Cc: cbe-oss-dev, Andre Heider, Hector Martin, Nathan Whitehorn,
linuxppc-dev
In-Reply-To: <1339552163.25512.2.camel@concordia>
Hi Michael,
On Wed, 2012-06-13 at 11:49 +1000, Michael Ellerman wrote:
> On Wed, 2012-04-25 at 19:19 +0000, 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
^ permalink raw reply
* [PATCH 1/2] drivers: crypto: move nx build to driver/crypto Makefile
From: Seth Jennings @ 2012-06-13 18:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Seth Jennings, Herbert Xu, linux-kernel, Paul Mackerras,
linux-crypto, Kent Yoder, linuxppc-dev, David S. Miller
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 <key@linux.vnet.ibm.com>
Signed-off-by: Seth Jennings <sjenning@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
^ permalink raw reply related
* [PATCH 2/2] drivers: crypto: fix typo in nx driver config option
From: Seth Jennings @ 2012-06-13 18:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Seth Jennings, trivial, Herbert Xu, linux-kernel, Paul Mackerras,
linux-crypto, Kent Yoder, linuxppc-dev, David S. Miller
In-Reply-To: <1339611763-14603-1-git-send-email-sjenning@linux.vnet.ibm.com>
Cc: Kent Yoder <key@linux.vnet.ibm.com>
Signed-off-by: Seth Jennings <sjenning@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
^ permalink raw reply related
* Re: [Cbe-oss-dev] [PATCH 05/10] powerpc/ps3: Use highmem region from repository
From: Nathan Whitehorn @ 2012-06-13 18:25 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Andre Heider, Hector Martin, linuxppc-dev
In-Reply-To: <1339610324.3986.6.camel@clam>
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 +0000, 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
^ permalink raw reply
* Re: [PATCH 1/2] drivers: crypto: move nx build to driver/crypto Makefile
From: Kent Yoder @ 2012-06-13 18:45 UTC (permalink / raw)
To: Seth Jennings
Cc: Herbert Xu, linux-kernel, Paul Mackerras, linux-crypto,
linuxppc-dev, David S. Miller
In-Reply-To: <1339611763-14603-1-git-send-email-sjenning@linux.vnet.ibm.com>
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 <key@linux.vnet.ibm.com>
> Cc: Kent Yoder <key@linux.vnet.ibm.com>
> Signed-off-by: Seth Jennings <sjenning@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/
^ permalink raw reply
* Re: [PATCH v2 1/2] uprobes: Pass probed vaddr to arch_uprobe_analyze_insn()
From: Oleg Nesterov @ 2012-06-13 19:15 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: peterz, antonb, lkml, Jim Keniston, Paul Mackerras, Ingo Molnar,
linuxppc-dev
In-Reply-To: <20120612174305.GA16349@redhat.com>
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.
^ permalink raw reply
* Re: Q: a_ops->readpage() && struct file
From: Oleg Nesterov @ 2012-06-13 19:19 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Linus Torvalds, lkml, Jim Keniston, Paul Mackerras, Al Viro,
antonb, Ingo Molnar, linuxppc-dev, Srikar Dronamraju
In-Reply-To: <1339581492.31548.133.camel@twins>
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.
^ permalink raw reply
* Re: [PATCH 2/2] drivers: crypto: fix typo in nx driver config option
From: Kent Yoder @ 2012-06-13 20:23 UTC (permalink / raw)
To: Seth Jennings
Cc: trivial, Herbert Xu, linux-kernel, Paul Mackerras, linux-crypto,
linuxppc-dev, David S. Miller
In-Reply-To: <1339611763-14603-2-git-send-email-sjenning@linux.vnet.ibm.com>
On Wed, 2012-06-13 at 13:22 -0500, Seth Jennings wrote:
> Cc: Kent Yoder <key@linux.vnet.ibm.com>
> Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
> ---
> drivers/crypto/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Kent Yoder <key@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
^ permalink raw reply
* [PATCH] i2c: let the core register devices from devicetree
From: Wolfram Sang @ 2012-06-13 21:12 UTC (permalink / raw)
To: linux-i2c
Cc: Viresh Kumar, Mauro Carvalho Chehab, Tony Lindgren, Linus Walleij,
Haojian Zhuang, Laxman Dewangan, Kukjin Kim, Stephen Warren,
Olof Johansson, Barry Song, Deepak Sikri, Haavard Skinnemoen,
Pawel Moll, Wolfram Sang, Sascha Hauer, Rusty Russell,
Tang Yuantian, Jean Delvare (PC drivers, core), Magnus Damm,
Lars-Peter Clausen, Ben Dooks (embedded platforms),
linux-arm-kernel, Jiri Kosina, Wolfram Sang, Kyungmin Park,
Karol Lewandowski, Dirk Brandewie, Shawn Guo, linuxppc-dev
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.sang@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 + i);
- } else {
- of_i2c_register_devices(&i2c->adap);
}
return 0;
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..c290091 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1121,8 +1121,6 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_free_irq;
}
- of_i2c_register_devices(adap);
-
return 0;
err_free_irq:
diff --git a/drivers/i2c/busses/i2c-pnx.c b/drivers/i2c/busses/i2c-pnx.c
index 99389d2..c64d960 100644
--- a/drivers/i2c/busses/i2c-pnx.c
+++ b/drivers/i2c/busses/i2c-pnx.c
@@ -730,8 +730,6 @@ static int __devinit i2c_pnx_probe(struct platform_device *pdev)
goto out_irq;
}
- of_i2c_register_devices(&alg_data->adapter);
-
dev_dbg(&pdev->dev, "%s: Master at %#8x, irq %d.\n",
alg_data->adapter.name, res->start, alg_data->irq);
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index a997c7d..9475235 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1194,7 +1194,6 @@ static int i2c_pxa_probe(struct platform_device *dev)
printk(KERN_INFO "I2C: Failed to add bus\n");
goto eadapt;
}
- of_i2c_register_devices(&i2c->adap);
platform_set_drvdata(dev, i2c);
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 0195915..ad3a79b 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -1058,7 +1058,6 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
goto err_cpufreq;
}
- of_i2c_register_devices(&i2c->adap);
platform_set_drvdata(pdev, i2c);
pm_runtime_enable(&pdev->dev);
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index 8110ca4..9acd286 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -670,7 +670,6 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
dev_info(&dev->dev, "I2C adapter %d with bus speed %lu Hz\n",
adap->nr, pd->bus_speed);
- of_i2c_register_devices(adap);
return 0;
err_all:
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 8b2e555..67388cc 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -684,8 +684,6 @@ static int __devinit tegra_i2c_probe(struct platform_device *pdev)
goto err_free_irq;
}
- of_i2c_register_devices(&i2c_dev->adapter);
-
return 0;
err_free_irq:
free_irq(i2c_dev->irq, i2c_dev);
diff --git a/drivers/i2c/busses/i2c-versatile.c b/drivers/i2c/busses/i2c-versatile.c
index eec20db..14a1432 100644
--- a/drivers/i2c/busses/i2c-versatile.c
+++ b/drivers/i2c/busses/i2c-versatile.c
@@ -108,7 +108,6 @@ static int i2c_versatile_probe(struct platform_device *dev)
ret = i2c_bit_add_numbered_bus(&i2c->adap);
if (ret >= 0) {
platform_set_drvdata(dev, i2c);
- of_i2c_register_devices(&i2c->adap);
return 0;
}
diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
index 641d0e5..d76bb71 100644
--- a/drivers/i2c/busses/i2c-xiic.c
+++ b/drivers/i2c/busses/i2c-xiic.c
@@ -754,8 +754,6 @@ static int __devinit xiic_i2c_probe(struct platform_device *pdev)
i2c_new_device(&i2c->adap, pdata->devices + i);
}
- of_i2c_register_devices(&i2c->adap);
-
return 0;
add_adapter_failed:
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index a6ad32b..4791833 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -39,6 +39,7 @@
#include <linux/irqflags.h>
#include <linux/rwsem.h>
#include <linux/pm_runtime.h>
+#include <linux/of_i2c.h>
#include <asm/uaccess.h>
#include "i2c-core.h"
@@ -880,6 +881,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
#endif
/* create pre-declared device nodes */
+ of_i2c_register_devices(adap);
+
if (adap->nr < __i2c_first_dynamic_bus_num)
i2c_scan_static_board_info(adap);
--
1.7.10
^ permalink raw reply related
* Re: [PATCH] i2c: let the core register devices from devicetree
From: Benjamin Herrenschmidt @ 2012-06-13 21:33 UTC (permalink / raw)
To: Wolfram Sang
Cc: Viresh Kumar, Mauro Carvalho Chehab, Tony Lindgren, Linus Walleij,
Laxman Dewangan, linux-i2c, Kukjin Kim, Stephen Warren,
Barry Song, Haojian Zhuang, Deepak Sikri, Haavard Skinnemoen,
Dirk Brandewie, Pawel Moll, Wolfram Sang, Sascha Hauer,
Rusty Russell, Tang Yuantian, Jean Delvare (PC drivers, core),
Magnus Damm, Lars-Peter Clausen, Ben Dooks (embedded platforms),
linux-arm-kernel, Jiri Kosina, Kyungmin Park, Karol Lewandowski,
Olof Johansson, Shawn Guo, linuxppc-dev
In-Reply-To: <1339622215-4733-1-git-send-email-w.sang@pengutronix.de>
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.sang@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 __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 + i);
> - } else {
> - of_i2c_register_devices(&i2c->adap);
> }
>
> return 0;
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 801df60..c290091 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1121,8 +1121,6 @@ omap_i2c_probe(struct platform_device *pdev)
> goto err_free_irq;
> }
>
> - of_i2c_register_devices(adap);
> -
> return 0;
>
> err_free_irq:
> diff --git a/drivers/i2c/busses/i2c-pnx.c b/drivers/i2c/busses/i2c-pnx.c
> index 99389d2..c64d960 100644
> --- a/drivers/i2c/busses/i2c-pnx.c
> +++ b/drivers/i2c/busses/i2c-pnx.c
> @@ -730,8 +730,6 @@ static int __devinit i2c_pnx_probe(struct platform_device *pdev)
> goto out_irq;
> }
>
> - of_i2c_register_devices(&alg_data->adapter);
> -
> dev_dbg(&pdev->dev, "%s: Master at %#8x, irq %d.\n",
> alg_data->adapter.name, res->start, alg_data->irq);
>
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index a997c7d..9475235 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -1194,7 +1194,6 @@ static int i2c_pxa_probe(struct platform_device *dev)
> printk(KERN_INFO "I2C: Failed to add bus\n");
> goto eadapt;
> }
> - of_i2c_register_devices(&i2c->adap);
>
> platform_set_drvdata(dev, i2c);
>
> diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
> index 0195915..ad3a79b 100644
> --- a/drivers/i2c/busses/i2c-s3c2410.c
> +++ b/drivers/i2c/busses/i2c-s3c2410.c
> @@ -1058,7 +1058,6 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
> goto err_cpufreq;
> }
>
> - of_i2c_register_devices(&i2c->adap);
> platform_set_drvdata(pdev, i2c);
>
> pm_runtime_enable(&pdev->dev);
> diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
> index 8110ca4..9acd286 100644
> --- a/drivers/i2c/busses/i2c-sh_mobile.c
> +++ b/drivers/i2c/busses/i2c-sh_mobile.c
> @@ -670,7 +670,6 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
> dev_info(&dev->dev, "I2C adapter %d with bus speed %lu Hz\n",
> adap->nr, pd->bus_speed);
>
> - of_i2c_register_devices(adap);
> return 0;
>
> err_all:
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index 8b2e555..67388cc 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -684,8 +684,6 @@ static int __devinit tegra_i2c_probe(struct platform_device *pdev)
> goto err_free_irq;
> }
>
> - of_i2c_register_devices(&i2c_dev->adapter);
> -
> return 0;
> err_free_irq:
> free_irq(i2c_dev->irq, i2c_dev);
> diff --git a/drivers/i2c/busses/i2c-versatile.c b/drivers/i2c/busses/i2c-versatile.c
> index eec20db..14a1432 100644
> --- a/drivers/i2c/busses/i2c-versatile.c
> +++ b/drivers/i2c/busses/i2c-versatile.c
> @@ -108,7 +108,6 @@ static int i2c_versatile_probe(struct platform_device *dev)
> ret = i2c_bit_add_numbered_bus(&i2c->adap);
> if (ret >= 0) {
> platform_set_drvdata(dev, i2c);
> - of_i2c_register_devices(&i2c->adap);
> return 0;
> }
>
> diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
> index 641d0e5..d76bb71 100644
> --- a/drivers/i2c/busses/i2c-xiic.c
> +++ b/drivers/i2c/busses/i2c-xiic.c
> @@ -754,8 +754,6 @@ static int __devinit xiic_i2c_probe(struct platform_device *pdev)
> i2c_new_device(&i2c->adap, pdata->devices + i);
> }
>
> - of_i2c_register_devices(&i2c->adap);
> -
> return 0;
>
> add_adapter_failed:
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index a6ad32b..4791833 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -39,6 +39,7 @@
> #include <linux/irqflags.h>
> #include <linux/rwsem.h>
> #include <linux/pm_runtime.h>
> +#include <linux/of_i2c.h>
> #include <asm/uaccess.h>
>
> #include "i2c-core.h"
> @@ -880,6 +881,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
> #endif
>
> /* create pre-declared device nodes */
> + of_i2c_register_devices(adap);
> +
> if (adap->nr < __i2c_first_dynamic_bus_num)
> i2c_scan_static_board_info(adap);
>
^ permalink raw reply
* Re: [PATCH] i2c: let the core register devices from devicetree
From: Stephen Warren @ 2012-06-13 22:03 UTC (permalink / raw)
To: Wolfram Sang
Cc: Viresh Kumar, Mauro Carvalho Chehab, Tony Lindgren, Linus Walleij,
Laxman Dewangan, linux-i2c, Kukjin Kim, Stephen Warren,
Barry Song, Haojian Zhuang, Deepak Sikri, Haavard Skinnemoen,
Dirk Brandewie, Pawel Moll, Wolfram Sang, Sascha Hauer,
Rusty Russell, Tang Yuantian, Jean Delvare (PC drivers, core),
Magnus Damm, Lars-Peter Clausen, Ben Dooks (embedded platforms),
linux-arm-kernel, Jiri Kosina, Kyungmin Park, Karol Lewandowski,
Olof Johansson, Shawn Guo, linuxppc-dev
In-Reply-To: <1339622215-4733-1-git-send-email-w.sang@pengutronix.de>
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 <swarren@wwwdotorg.org>
^ permalink raw reply
* Re: Replacement to of_register_platform_driver ?
From: Michael Ellerman @ 2012-06-14 0:28 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <4FD8AFF2.6000702@lpsc.in2p3.fr>
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
^ permalink raw reply
* Re: [PATCH 5/15] powerpc: convert to %r for all GPR usage
From: Michael Neuling @ 2012-06-14 3:25 UTC (permalink / raw)
To: Jesse Larrew; +Cc: linuxppc-dev
In-Reply-To: <4FD274AF.8080700@linux.vnet.ibm.com>
Jesse Larrew <jlarrew@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.
> > + */
> >
> > -#define r0 0
> > -#define r1 1
> > -#define r2 2
> > -#define r3 3
> > -#define r4 4
> > -#define r5 5
> > -#define r6 6
> > -#define r7 7
> > -#define r8 8
> > -#define r9 9
> > -#define r10 10
> > -#define r11 11
> > -#define r12 12
> > -#define r13 13
> > -#define r14 14
> > -#define r15 15
> > -#define r16 16
> > -#define r17 17
> > -#define r18 18
> > -#define r19 19
> > -#define r20 20
> > -#define r21 21
> > -#define r22 22
> > -#define r23 23
> > -#define r24 24
> > -#define r25 25
> > -#define r26 26
> > -#define r27 27
> > -#define r28 28
> > -#define r29 29
> > -#define r30 30
> > -#define r31 31
> > +#define r0 %r0
> > +#define r1 %r1
> > +#define r2 %r2
> > +#define r3 %r3
> > +#define r4 %r4
> > +#define r5 %r5
> > +#define r6 %r6
> > +#define r7 %r7
> > +#define r8 %r8
> > +#define r9 %r9
> > +#define r10 %r10
> > +#define r11 %r11
> > +#define r12 %r12
> > +#define r13 %r13
> > +#define r14 %r14
> > +#define r15 %r15
> > +#define r16 %r16
> > +#define r17 %r17
> > +#define r18 %r18
> > +#define r19 %r19
> > +#define r20 %r20
> > +#define r21 %r21
> > +#define r22 %r22
> > +#define r23 %r23
> > +#define r24 %r24
> > +#define r25 %r25
> > +#define r26 %r26
> > +#define r27 %r27
> > +#define r28 %r28
> > +#define r29 %r29
> > +#define r30 %r30
> > +#define r31 %r31
> >
> > #define R0 0
> > #define R1 1
>
>
> I think your patch was truncated somehow.
How so?
Mikey
^ permalink raw reply
* Re: [PATCH] i2c: let the core register devices from devicetree
From: Grant Likely @ 2012-06-14 4:40 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: Viresh Kumar, Mauro Carvalho Chehab, Tony Lindgren, Linus Walleij,
Laxman Dewangan, Kukjin Kim, S tephen Warren, Olof Johansson,
Barry Song, Haojian Zhuang, Deepak Sikri, Haavard Skinnemoen,
Pawel Moll, Wolfram Sang, Sascha Hauer, Rusty Russell,
Tang Yuantian, Jean Delvare (PC drivers, core), Magnus Damm,
Lars-Peter Clausen, Ben Dooks (embedded platforms),
linux-arm-kernel, Jiri Kosina, Wolfram Sang, Kyungmin Park,
Karol Lewandowski, Dirk Brandewie, Shawn Guo, linuxppc-dev
In-Reply-To: <1339622215-4733-1-git-send-email-w.sang@pengutronix.de>
On Wed, 13 Jun 2012 23:12:10 +0200, Wolfram Sang <w.sang@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.sang@pengutronix.de>
FWIW, and without any actual compiling or testing:
Acked-by: Grant Likely <grant.likely@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 --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 + i);
> - } else {
> - of_i2c_register_devices(&i2c->adap);
> }
>
> return 0;
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 801df60..c290091 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1121,8 +1121,6 @@ omap_i2c_probe(struct platform_device *pdev)
> goto err_free_irq;
> }
>
> - of_i2c_register_devices(adap);
> -
> return 0;
>
> err_free_irq:
> diff --git a/drivers/i2c/busses/i2c-pnx.c b/drivers/i2c/busses/i2c-pnx.c
> index 99389d2..c64d960 100644
> --- a/drivers/i2c/busses/i2c-pnx.c
> +++ b/drivers/i2c/busses/i2c-pnx.c
> @@ -730,8 +730,6 @@ static int __devinit i2c_pnx_probe(struct platform_device *pdev)
> goto out_irq;
> }
>
> - of_i2c_register_devices(&alg_data->adapter);
> -
> dev_dbg(&pdev->dev, "%s: Master at %#8x, irq %d.\n",
> alg_data->adapter.name, res->start, alg_data->irq);
>
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index a997c7d..9475235 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -1194,7 +1194,6 @@ static int i2c_pxa_probe(struct platform_device *dev)
> printk(KERN_INFO "I2C: Failed to add bus\n");
> goto eadapt;
> }
> - of_i2c_register_devices(&i2c->adap);
>
> platform_set_drvdata(dev, i2c);
>
> diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
> index 0195915..ad3a79b 100644
> --- a/drivers/i2c/busses/i2c-s3c2410.c
> +++ b/drivers/i2c/busses/i2c-s3c2410.c
> @@ -1058,7 +1058,6 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
> goto err_cpufreq;
> }
>
> - of_i2c_register_devices(&i2c->adap);
> platform_set_drvdata(pdev, i2c);
>
> pm_runtime_enable(&pdev->dev);
> diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
> index 8110ca4..9acd286 100644
> --- a/drivers/i2c/busses/i2c-sh_mobile.c
> +++ b/drivers/i2c/busses/i2c-sh_mobile.c
> @@ -670,7 +670,6 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
> dev_info(&dev->dev, "I2C adapter %d with bus speed %lu Hz\n",
> adap->nr, pd->bus_speed);
>
> - of_i2c_register_devices(adap);
> return 0;
>
> err_all:
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index 8b2e555..67388cc 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -684,8 +684,6 @@ static int __devinit tegra_i2c_probe(struct platform_device *pdev)
> goto err_free_irq;
> }
>
> - of_i2c_register_devices(&i2c_dev->adapter);
> -
> return 0;
> err_free_irq:
> free_irq(i2c_dev->irq, i2c_dev);
> diff --git a/drivers/i2c/busses/i2c-versatile.c b/drivers/i2c/busses/i2c-versatile.c
> index eec20db..14a1432 100644
> --- a/drivers/i2c/busses/i2c-versatile.c
> +++ b/drivers/i2c/busses/i2c-versatile.c
> @@ -108,7 +108,6 @@ static int i2c_versatile_probe(struct platform_device *dev)
> ret = i2c_bit_add_numbered_bus(&i2c->adap);
> if (ret >= 0) {
> platform_set_drvdata(dev, i2c);
> - of_i2c_register_devices(&i2c->adap);
> return 0;
> }
>
> diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
> index 641d0e5..d76bb71 100644
> --- a/drivers/i2c/busses/i2c-xiic.c
> +++ b/drivers/i2c/busses/i2c-xiic.c
> @@ -754,8 +754,6 @@ static int __devinit xiic_i2c_probe(struct platform_device *pdev)
> i2c_new_device(&i2c->adap, pdata->devices + i);
> }
>
> - of_i2c_register_devices(&i2c->adap);
> -
> return 0;
>
> add_adapter_failed:
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index a6ad32b..4791833 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -39,6 +39,7 @@
> #include <linux/irqflags.h>
> #include <linux/rwsem.h>
> #include <linux/pm_runtime.h>
> +#include <linux/of_i2c.h>
> #include <asm/uaccess.h>
>
> #include "i2c-core.h"
> @@ -880,6 +881,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
> #endif
>
> /* create pre-declared device nodes */
> + of_i2c_register_devices(adap);
> +
> if (adap->nr < __i2c_first_dynamic_bus_num)
> i2c_scan_static_board_info(adap);
>
> --
> 1.7.10
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox