[PATCH] of: Have of_device_add call platform_device_add rather than device_add

Grant Likely grant.likely at secretlab.ca
Tue Nov 27 01:30:02 EST 2012


On Thu, 22 Nov 2012 10:30:20 -0700, Jason Gunthorpe <jgunthorpe at obsidianresearch.com> wrote:
> On Thu, Nov 22, 2012 at 03:36:21PM +0000, Grant Likely wrote:
> 
> > Hmm... I've not tried it with assigned-address. I tried with two sibling
> > platform devices using just the 'reg' property. That the kernel will
> > complain about. For powerpc-only, the patch I posted allows the device
> > to get registered anyway even though the range incorrectly overlaps.
> 
> My second example was done with the reg property..
> 
>                 gpio0: gpio at 10100 {
>                         compatible = "marvell,orion-gpio";
>                         #gpio-cells = <2>;
>                         gpio-controller;
>                         reg = <0x10100 0x40>;
>                 }
>                 chip_cfg at 0 {
>                         compatible = "orc,chip_config";
>                         // Doubles up on gpio0
>                         reg = <0x10100 0x4>;
>                 };
> 
> 
> f1010100-f101013f : /internal at f1000000/gpio at 10100
>   f1010100-f1010103 : /internal at f1000000/chip_cfg at 0
> 
> What did you try? Maybe order matters?

It might. I tried on qemu with versatile. I've written a new test block
with different overlaps. Here's the block and the results:

     dummy at 10201000 {
             compatible = "acme,test";
             reg = <0x10201000 0x1000>;
     };

     overlap at 10200800 {
             compatible = "acme,test";
             reg = <0x10200800 0x1000>;
     };

     overlap at 10201800 {
             compatible = "acme,test";
             reg = <0x10201800 0x1000>;
     };

     overlap at 10201400 {
             compatible = "acme,test";
             reg = <0x10201400 0x800>;
     };

     overlap at 10200c00 {
             compatible = "acme,test";
             reg = <0x10200c00 0x1800>;
     };

>From the kernel log:
10200800.overlap: failed to claim resource 0
10201800.overlap: failed to claim resource 0

# ls /sys/bus/platform/devices/
10002000.i2c      10010000.net      10201000.dummy    alarmtimer
10003000.intc     10140000.intc     10201400.overlap  amba.0
10008000.lcd      10200c00.overlap  34000000.flash    fpga.1

So, overlaps that are completely inside or completely outside the
already registered range don't appear to be detected. That may be a bug
(unless it is designed to work that way)

g.

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


More information about the devicetree-discuss mailing list