[RFC V2 PATCH 0/8] ARM: kirkwood: cleanup DT conversion

[Ezequiel Garcia]

Hi Thomas,

On Mon, Jan 28, 2013 at 3:24 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
>
> Instead, I think the "address decoding window driver" in the kernel
> should provide an API for device drivers to request an address decoding
> window at a given address, with a given size and target/attribute. This
> is already what the PCIe code is doing (I'm going to submit v2 of the
> PCIe code soon), and I think we should to the same for other devices as
> well.
>

Note that in Jason's proposal, it's possible to instantiate a bus' child
device, configure its address window and then call the corresponding
driver using a regular of_node.

For instance,

// MBUS Decoder window for NAND
nand at f4000000 {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "simple-bus", "marvell,orion-mbus";
        mbus-target = <0x01 0x2f>;
        ranges = <0 0xf4000000 0x10000>;

        nand at 0 {
                // ...
               compatible = "marvell,orion-nand";
               reg = <0x0 0x400>;
        };
};

In this example, we can configure the window using both mbus-target and ranges
properties and then use the child node to instantiate an "orion-nand" device.

I understand your point regarding PCIe flexibility needs.
So I wonder, in your proposed scheme,
who should call this "address decoding window" driver
in order to still be able to instantiate child devices easily?

Thanks,

-- 
    Ezequiel