Hi,
On Wed, Dec 02, 2015 at 07:41:07PM +0000, Simon Arlott wrote:
> >> + nand0: nandcs@0 {
> >> + compatible = "brcm,nandcs";
> >> + reg = <0>;
> >> + nand-on-flash-bbt;
> >> + nand-ecc-strength = <1>;
> >> + nand-ecc-step-size = <512>;
> >> +
> >> + #address-cells = <0>;
> >> + #size-cells = <0>;
> >
> > What are these {address,size}-cells for? If you need them for
> > partitioning, then those are wrong -- they shouldn't be zero. Maybe just
> > drop them? (I can cut them out when applying, if that's the only change
> > to make.)
>
> This is the correct way to do partitioning, there would be a
> "partitions" block with no address/size that contains the partitions as
> child nodes. [Documentation/devicetree/bindings/mtd/partition.txt]
That doc says nothing about {address,size}-cells = 0. When using the new
binding with a 'partitions' subnode, I'm not sure the address
translation specification really matters anyway; the flash space is a
new address space unrelated to the parents, and we don't do any
translation from the 'flash' node to the 'partitions' node. So you don't
need #{address,size}-cells in the flash node, but you do in the
'partitions' node.
> I think they're also implicit so you can just remove those two lines.
>From ePAPR: "The #address-cells and #size-cells properties are not
inherited from ancestors in the device tree. They shall be explicitly
defined."
But we don't want to define them. I'd drop them, at least from the
example, as they're not relevant.
> I've created a bcm963268part driver so there won't need to be any
> partitions in DT for bcm63268.
Just curious, do you plan to submit this driver? We're working on
matching up partition parsers to flash devices via device tree
of_match_table's, so you could do something like this:
nand0: nandcs@0 {
compatible = "brcm,nandcs";
...
partitions {
compatible = "brcm,bcm963268-partitions";
...
};
};
FYI.
> >> + };
> >> +};
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
