Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-16 Thread David Gibson 
On Tue, Dec 15, 2015 at 11:03:48AM +0100, Geert Uytterhoeven wrote:
> Hi David,
> 
> On Tue, Dec 15, 2015 at 7:00 AM, David Gibson
>  wrote:
> >> If the only property needed is the partition table offset, it can be 
> >> encoded
> >> in the unit-address, and the "reg" property:
> >>
> >> partitions {
> >>
> >> partition-table@ {
> >> reg = <0 ...>;
> >> ...
> >> };
> >>
> >> ...
> >> };
> >
> > Urgh.. and that's abusing the unit address.
> 
> Why? The partition is part of the FLASH. In this respect, it doesn't differ
> from other hardcoded partitions using the same DT syntax.
> It would just have a compatible value indicating it's a partition
> table.

Ah.. yes, fair enough.  I'd forgotten that the encoding of explicit
partitions in the device tree already established the address space
here as being the flash blocks.  So, no, it's not an abuse of unit
address.

Doesn't help for partition table types which require scanning the
device, of course.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-16 Thread David Gibson 
On Tue, Dec 15, 2015 at 11:03:48AM +0100, Geert Uytterhoeven wrote:
> Hi David,
> 
> On Tue, Dec 15, 2015 at 7:00 AM, David Gibson
>  wrote:
> >> If the only property needed is the partition table offset, it can be 
> >> encoded
> >> in the unit-address, and the "reg" property:
> >>
> >> partitions {
> >>
> >> partition-table@ {
> >> reg = <0 ...>;
> >> ...
> >> };
> >>
> >> ...
> >> };
> >
> > Urgh.. and that's abusing the unit address.
> 
> Why? The partition is part of the FLASH. In this respect, it doesn't differ
> from other hardcoded partitions using the same DT syntax.
> It would just have a compatible value indicating it's a partition
> table.

Ah.. yes, fair enough.  I'd forgotten that the encoding of explicit
partitions in the device tree already established the address space
here as being the flash blocks.  So, no, it's not an abuse of unit
address.

Doesn't help for partition table types which require scanning the
device, of course.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-15 Thread Geert Uytterhoeven 
Hi David,

On Tue, Dec 15, 2015 at 7:00 AM, David Gibson
 wrote:
>> If the only property needed is the partition table offset, it can be encoded
>> in the unit-address, and the "reg" property:
>>
>> partitions {
>>
>> partition-table@ {
>> reg = <0 ...>;
>> ...
>> };
>>
>> ...
>> };
>
> Urgh.. and that's abusing the unit address.

Why? The partition is part of the FLASH. In this respect, it doesn't differ
from other hardcoded partitions using the same DT syntax.
It would just have a compatible value indicating it's a partition table.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-15 Thread David Gibson 
On Mon, Dec 14, 2015 at 11:22:46AM +0100, Geert Uytterhoeven wrote:
> On Sat, Dec 12, 2015 at 6:51 AM, David Gibson
>  wrote:
> > On Thu, Dec 10, 2015 at 12:43:24PM -0800, Brian Norris wrote:
> >> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
> >> > On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
> >> > > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
> >> > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
> >> > > >  wrote:
> >> > >
> >> > > >> +
> >> > > >> +Examples:
> >> > > >> +
> >> > > >> +flash@0 {
> >> > > >> +   partitions {
> >> > > >> +   compatible = "google,fmap";
> >> > > >> +   };
> >> > > >> +};
> >> > > >
> >> > > > I wonder if this wouldn't be better served in a separate binding doc
> >> > > > with its compatible name as the filename, like we do with
> >> > > > driver^Whardware blocks, especially if we want to add more parsers.
> >> > >
> >> > >
> >> > > I find that *very* counter productive for bindings that go to the same
> >> > > node. You have a description of a node, and then suddenly there you
> >> > > have another file with another description of the same node. Totally
> >> > > awesome.
> >> >
> >> > I can't actually work out from that if you're agreeing with the
> >> > original post or the first reply.
> >>
> >> Perhaps I'm biased, but I think he was agreeing with the first reply.
> >> (Particularly, "I find that *very* counter productive" uses the word
> >> "that" to refer to "separate binding doc[s]".)
> >>
> >> > > Also how do you plan to write partitioning schemes with parameters
> >> > > like with non-zero offset of the partition table.
> >>
> >> If you are directing this question at me: I don't have a specific plan
> >> for it. MTD parsers don't currently take external input for this; many
> >> scan the whole device, but some might also have conventions built into
> >> the parser itself too, so this just gets hooked based on "compatible".
> >> But if the need arose, I would hope we could work out a common binding.
> >>
> >> > Presumably with properties in the patitions node.  Not seeing the
> >> > problem here.
> >>
> >> I believe Michal is bringing up the (important, IMO) point that if
> >> distinct partition types are being described in the same node, then any
> >> use of additional properties *must* be closely coordinated. We can't
> >> have two parsers "foo" and "bar" defining conflicting uses of the same
> >> property in the same node, like this:
> >>
> >>   partitions {
> >>   compatible = "foo", "bar";
> >>   property-baz = ...; // e.g., reg = <...>;
> >>   };
> >>
> >> where if "foo" is not found, we fall back to "bar". But what if "foo"
> >> and "bar" use "property-baz" differently?
> >
> > Ah.. that is an excellent point, and leads me to realise that using
> > compatible in this way is wrong.  The whole point of compatible is
> > that the node is, well, compatible with *all* the things in the list,
> > and therefore the things in the list are compatible with each other.
> >
> > Using it for a list of entirely different things to attempt in order
> > is not correct.
> 
> Isn't the idea behind a partition table that all partition information is
> stored on the device in a well-known format, so you don't need additional
> properties?

I guess that's the idea, but I wouldn't like to count on it.

And more importantly, it's still abusing the 'compatible' property.  A
node is supposed to be compatible with *everything* in 'compatible',
not just one of the things listed there.

> If the only property needed is the partition table offset, it can be encoded
> in the unit-address, and the "reg" property:
> 
> partitions {
> 
> partition-table@ {
> reg = <0 ...>;
> ...
> };
> 
> ...
> };

Urgh.. and that's abusing the unit address.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-15 Thread David Gibson 
On Mon, Dec 14, 2015 at 11:22:46AM +0100, Geert Uytterhoeven wrote:
> On Sat, Dec 12, 2015 at 6:51 AM, David Gibson
>  wrote:
> > On Thu, Dec 10, 2015 at 12:43:24PM -0800, Brian Norris wrote:
> >> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
> >> > On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
> >> > > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
> >> > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
> >> > > >  wrote:
> >> > >
> >> > > >> +
> >> > > >> +Examples:
> >> > > >> +
> >> > > >> +flash@0 {
> >> > > >> +   partitions {
> >> > > >> +   compatible = "google,fmap";
> >> > > >> +   };
> >> > > >> +};
> >> > > >
> >> > > > I wonder if this wouldn't be better served in a separate binding doc
> >> > > > with its compatible name as the filename, like we do with
> >> > > > driver^Whardware blocks, especially if we want to add more parsers.
> >> > >
> >> > >
> >> > > I find that *very* counter productive for bindings that go to the same
> >> > > node. You have a description of a node, and then suddenly there you
> >> > > have another file with another description of the same node. Totally
> >> > > awesome.
> >> >
> >> > I can't actually work out from that if you're agreeing with the
> >> > original post or the first reply.
> >>
> >> Perhaps I'm biased, but I think he was agreeing with the first reply.
> >> (Particularly, "I find that *very* counter productive" uses the word
> >> "that" to refer to "separate binding doc[s]".)
> >>
> >> > > Also how do you plan to write partitioning schemes with parameters
> >> > > like with non-zero offset of the partition table.
> >>
> >> If you are directing this question at me: I don't have a specific plan
> >> for it. MTD parsers don't currently take external input for this; many
> >> scan the whole device, but some might also have conventions built into
> >> the parser itself too, so this just gets hooked based on "compatible".
> >> But if the need arose, I would hope we could work out a common binding.
> >>
> >> > Presumably with properties in the patitions node.  Not seeing the
> >> > problem here.
> >>
> >> I believe Michal is bringing up the (important, IMO) point that if
> >> distinct partition types are being described in the same node, then any
> >> use of additional properties *must* be closely coordinated. We can't
> >> have two parsers "foo" and "bar" defining conflicting uses of the same
> >> property in the same node, like this:
> >>
> >>   partitions {
> >>   compatible = "foo", "bar";
> >>   property-baz = ...; // e.g., reg = <...>;
> >>   };
> >>
> >> where if "foo" is not found, we fall back to "bar". But what if "foo"
> >> and "bar" use "property-baz" differently?
> >
> > Ah.. that is an excellent point, and leads me to realise that using
> > compatible in this way is wrong.  The whole point of compatible is
> > that the node is, well, compatible with *all* the things in the list,
> > and therefore the things in the list are compatible with each other.
> >
> > Using it for a list of entirely different things to attempt in order
> > is not correct.
> 
> Isn't the idea behind a partition table that all partition information is
> stored on the device in a well-known format, so you don't need additional
> properties?

I guess that's the idea, but I wouldn't like to count on it.

And more importantly, it's still abusing the 'compatible' property.  A
node is supposed to be compatible with *everything* in 'compatible',
not just one of the things listed there.

> If the only property needed is the partition table offset, it can be encoded
> in the unit-address, and the "reg" property:
> 
> partitions {
> 
> partition-table@ {
> reg = <0 ...>;
> ...
> };
> 
> ...
> };

Urgh.. and that's abusing the unit address.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-15 Thread Geert Uytterhoeven 
Hi David,

On Tue, Dec 15, 2015 at 7:00 AM, David Gibson
 wrote:
>> If the only property needed is the partition table offset, it can be encoded
>> in the unit-address, and the "reg" property:
>>
>> partitions {
>>
>> partition-table@ {
>> reg = <0 ...>;
>> ...
>> };
>>
>> ...
>> };
>
> Urgh.. and that's abusing the unit address.

Why? The partition is part of the FLASH. In this respect, it doesn't differ
from other hardcoded partitions using the same DT syntax.
It would just have a compatible value indicating it's a partition table.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-14 Thread Michal Suchanek 
On 14 December 2015 at 11:22, Geert Uytterhoeven  wrote:
> On Sat, Dec 12, 2015 at 6:51 AM, David Gibson
>  wrote:
>> On Thu, Dec 10, 2015 at 12:43:24PM -0800, Brian Norris wrote:
>>> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
>>> > On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
>>> > > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
>>> > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>>> > > >  wrote:
>>> > >
>>> > > >> +
>>> > > >> +Examples:
>>> > > >> +
>>> > > >> +flash@0 {
>>> > > >> +   partitions {
>>> > > >> +   compatible = "google,fmap";
>>> > > >> +   };
>>> > > >> +};
>>> > > >
>>> > > > I wonder if this wouldn't be better served in a separate binding doc
>>> > > > with its compatible name as the filename, like we do with
>>> > > > driver^Whardware blocks, especially if we want to add more parsers.
>>> > >
>>> > >
>>> > > I find that *very* counter productive for bindings that go to the same
>>> > > node. You have a description of a node, and then suddenly there you
>>> > > have another file with another description of the same node. Totally
>>> > > awesome.
>>> >
>>> > I can't actually work out from that if you're agreeing with the
>>> > original post or the first reply.
>>>
>>> Perhaps I'm biased, but I think he was agreeing with the first reply.
>>> (Particularly, "I find that *very* counter productive" uses the word
>>> "that" to refer to "separate binding doc[s]".)
>>>
>>> > > Also how do you plan to write partitioning schemes with parameters
>>> > > like with non-zero offset of the partition table.
>>>
>>> If you are directing this question at me: I don't have a specific plan
>>> for it. MTD parsers don't currently take external input for this; many
>>> scan the whole device, but some might also have conventions built into
>>> the parser itself too, so this just gets hooked based on "compatible".
>>> But if the need arose, I would hope we could work out a common binding.
>>>
>>> > Presumably with properties in the patitions node.  Not seeing the
>>> > problem here.
>>>
>>> I believe Michal is bringing up the (important, IMO) point that if
>>> distinct partition types are being described in the same node, then any
>>> use of additional properties *must* be closely coordinated. We can't
>>> have two parsers "foo" and "bar" defining conflicting uses of the same
>>> property in the same node, like this:
>>>
>>>   partitions {
>>>   compatible = "foo", "bar";
>>>   property-baz = ...; // e.g., reg = <...>;
>>>   };
>>>
>>> where if "foo" is not found, we fall back to "bar". But what if "foo"
>>> and "bar" use "property-baz" differently?
>>
>> Ah.. that is an excellent point, and leads me to realise that using
>> compatible in this way is wrong.  The whole point of compatible is
>> that the node is, well, compatible with *all* the things in the list,
>> and therefore the things in the list are compatible with each other.
>>
>> Using it for a list of entirely different things to attempt in order
>> is not correct.
>
> Isn't the idea behind a partition table that all partition information is
> stored on the device in a well-known format, so you don't need additional
> properties?
>
> If the only property needed is the partition table offset, it can be encoded
> in the unit-address, and the "reg" property:
>
> partitions {
>
> partition-table@ {
> reg = <0 ...>;
> ...
> };
>
> ...
> };
>
> If you do need additional properties, you'll have to add separate partition
> table nodes.
> Where? Outside the "partitions" subnode?
> What with multiple partition tables
>   - some needing properties (outside "partitions"),
>   - others not (outside/inside "partitions"),
>   - others needing the offset (inside "partitions"?

Hello,

IIRC there is RedBoot on-flash partition format support in kernel
which has the partition table offset as compile time configuration
parameter. Moving this to DT would make unified kernel for boards with
different RedBoot table offsets possible.

I don't use any board with RedBoot so I would not know if there is
other issue preventing such unified kernel.

It might be an actual use case for both the binding and the extra
argument with current partitioning scheme, though.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-14 Thread Geert Uytterhoeven 
On Sat, Dec 12, 2015 at 6:51 AM, David Gibson
 wrote:
> On Thu, Dec 10, 2015 at 12:43:24PM -0800, Brian Norris wrote:
>> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
>> > On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
>> > > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
>> > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>> > > >  wrote:
>> > >
>> > > >> +
>> > > >> +Examples:
>> > > >> +
>> > > >> +flash@0 {
>> > > >> +   partitions {
>> > > >> +   compatible = "google,fmap";
>> > > >> +   };
>> > > >> +};
>> > > >
>> > > > I wonder if this wouldn't be better served in a separate binding doc
>> > > > with its compatible name as the filename, like we do with
>> > > > driver^Whardware blocks, especially if we want to add more parsers.
>> > >
>> > >
>> > > I find that *very* counter productive for bindings that go to the same
>> > > node. You have a description of a node, and then suddenly there you
>> > > have another file with another description of the same node. Totally
>> > > awesome.
>> >
>> > I can't actually work out from that if you're agreeing with the
>> > original post or the first reply.
>>
>> Perhaps I'm biased, but I think he was agreeing with the first reply.
>> (Particularly, "I find that *very* counter productive" uses the word
>> "that" to refer to "separate binding doc[s]".)
>>
>> > > Also how do you plan to write partitioning schemes with parameters
>> > > like with non-zero offset of the partition table.
>>
>> If you are directing this question at me: I don't have a specific plan
>> for it. MTD parsers don't currently take external input for this; many
>> scan the whole device, but some might also have conventions built into
>> the parser itself too, so this just gets hooked based on "compatible".
>> But if the need arose, I would hope we could work out a common binding.
>>
>> > Presumably with properties in the patitions node.  Not seeing the
>> > problem here.
>>
>> I believe Michal is bringing up the (important, IMO) point that if
>> distinct partition types are being described in the same node, then any
>> use of additional properties *must* be closely coordinated. We can't
>> have two parsers "foo" and "bar" defining conflicting uses of the same
>> property in the same node, like this:
>>
>>   partitions {
>>   compatible = "foo", "bar";
>>   property-baz = ...; // e.g., reg = <...>;
>>   };
>>
>> where if "foo" is not found, we fall back to "bar". But what if "foo"
>> and "bar" use "property-baz" differently?
>
> Ah.. that is an excellent point, and leads me to realise that using
> compatible in this way is wrong.  The whole point of compatible is
> that the node is, well, compatible with *all* the things in the list,
> and therefore the things in the list are compatible with each other.
>
> Using it for a list of entirely different things to attempt in order
> is not correct.

Isn't the idea behind a partition table that all partition information is
stored on the device in a well-known format, so you don't need additional
properties?

If the only property needed is the partition table offset, it can be encoded
in the unit-address, and the "reg" property:

partitions {

partition-table@ {
reg = <0 ...>;
...
};

...
};

If you do need additional properties, you'll have to add separate partition
table nodes.
Where? Outside the "partitions" subnode?
What with multiple partition tables
  - some needing properties (outside "partitions"),
  - others not (outside/inside "partitions"),
  - others needing the offset (inside "partitions"?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-14 Thread Geert Uytterhoeven 
On Sat, Dec 12, 2015 at 6:51 AM, David Gibson
 wrote:
> On Thu, Dec 10, 2015 at 12:43:24PM -0800, Brian Norris wrote:
>> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
>> > On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
>> > > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
>> > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>> > > >  wrote:
>> > >
>> > > >> +
>> > > >> +Examples:
>> > > >> +
>> > > >> +flash@0 {
>> > > >> +   partitions {
>> > > >> +   compatible = "google,fmap";
>> > > >> +   };
>> > > >> +};
>> > > >
>> > > > I wonder if this wouldn't be better served in a separate binding doc
>> > > > with its compatible name as the filename, like we do with
>> > > > driver^Whardware blocks, especially if we want to add more parsers.
>> > >
>> > >
>> > > I find that *very* counter productive for bindings that go to the same
>> > > node. You have a description of a node, and then suddenly there you
>> > > have another file with another description of the same node. Totally
>> > > awesome.
>> >
>> > I can't actually work out from that if you're agreeing with the
>> > original post or the first reply.
>>
>> Perhaps I'm biased, but I think he was agreeing with the first reply.
>> (Particularly, "I find that *very* counter productive" uses the word
>> "that" to refer to "separate binding doc[s]".)
>>
>> > > Also how do you plan to write partitioning schemes with parameters
>> > > like with non-zero offset of the partition table.
>>
>> If you are directing this question at me: I don't have a specific plan
>> for it. MTD parsers don't currently take external input for this; many
>> scan the whole device, but some might also have conventions built into
>> the parser itself too, so this just gets hooked based on "compatible".
>> But if the need arose, I would hope we could work out a common binding.
>>
>> > Presumably with properties in the patitions node.  Not seeing the
>> > problem here.
>>
>> I believe Michal is bringing up the (important, IMO) point that if
>> distinct partition types are being described in the same node, then any
>> use of additional properties *must* be closely coordinated. We can't
>> have two parsers "foo" and "bar" defining conflicting uses of the same
>> property in the same node, like this:
>>
>>   partitions {
>>   compatible = "foo", "bar";
>>   property-baz = ...; // e.g., reg = <...>;
>>   };
>>
>> where if "foo" is not found, we fall back to "bar". But what if "foo"
>> and "bar" use "property-baz" differently?
>
> Ah.. that is an excellent point, and leads me to realise that using
> compatible in this way is wrong.  The whole point of compatible is
> that the node is, well, compatible with *all* the things in the list,
> and therefore the things in the list are compatible with each other.
>
> Using it for a list of entirely different things to attempt in order
> is not correct.

Isn't the idea behind a partition table that all partition information is
stored on the device in a well-known format, so you don't need additional
properties?

If the only property needed is the partition table offset, it can be encoded
in the unit-address, and the "reg" property:

partitions {

partition-table@ {
reg = <0 ...>;
...
};

...
};

If you do need additional properties, you'll have to add separate partition
table nodes.
Where? Outside the "partitions" subnode?
What with multiple partition tables
  - some needing properties (outside "partitions"),
  - others not (outside/inside "partitions"),
  - others needing the offset (inside "partitions"?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-14 Thread Michal Suchanek 
On 14 December 2015 at 11:22, Geert Uytterhoeven  wrote:
> On Sat, Dec 12, 2015 at 6:51 AM, David Gibson
>  wrote:
>> On Thu, Dec 10, 2015 at 12:43:24PM -0800, Brian Norris wrote:
>>> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
>>> > On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
>>> > > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
>>> > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>>> > > >  wrote:
>>> > >
>>> > > >> +
>>> > > >> +Examples:
>>> > > >> +
>>> > > >> +flash@0 {
>>> > > >> +   partitions {
>>> > > >> +   compatible = "google,fmap";
>>> > > >> +   };
>>> > > >> +};
>>> > > >
>>> > > > I wonder if this wouldn't be better served in a separate binding doc
>>> > > > with its compatible name as the filename, like we do with
>>> > > > driver^Whardware blocks, especially if we want to add more parsers.
>>> > >
>>> > >
>>> > > I find that *very* counter productive for bindings that go to the same
>>> > > node. You have a description of a node, and then suddenly there you
>>> > > have another file with another description of the same node. Totally
>>> > > awesome.
>>> >
>>> > I can't actually work out from that if you're agreeing with the
>>> > original post or the first reply.
>>>
>>> Perhaps I'm biased, but I think he was agreeing with the first reply.
>>> (Particularly, "I find that *very* counter productive" uses the word
>>> "that" to refer to "separate binding doc[s]".)
>>>
>>> > > Also how do you plan to write partitioning schemes with parameters
>>> > > like with non-zero offset of the partition table.
>>>
>>> If you are directing this question at me: I don't have a specific plan
>>> for it. MTD parsers don't currently take external input for this; many
>>> scan the whole device, but some might also have conventions built into
>>> the parser itself too, so this just gets hooked based on "compatible".
>>> But if the need arose, I would hope we could work out a common binding.
>>>
>>> > Presumably with properties in the patitions node.  Not seeing the
>>> > problem here.
>>>
>>> I believe Michal is bringing up the (important, IMO) point that if
>>> distinct partition types are being described in the same node, then any
>>> use of additional properties *must* be closely coordinated. We can't
>>> have two parsers "foo" and "bar" defining conflicting uses of the same
>>> property in the same node, like this:
>>>
>>>   partitions {
>>>   compatible = "foo", "bar";
>>>   property-baz = ...; // e.g., reg = <...>;
>>>   };
>>>
>>> where if "foo" is not found, we fall back to "bar". But what if "foo"
>>> and "bar" use "property-baz" differently?
>>
>> Ah.. that is an excellent point, and leads me to realise that using
>> compatible in this way is wrong.  The whole point of compatible is
>> that the node is, well, compatible with *all* the things in the list,
>> and therefore the things in the list are compatible with each other.
>>
>> Using it for a list of entirely different things to attempt in order
>> is not correct.
>
> Isn't the idea behind a partition table that all partition information is
> stored on the device in a well-known format, so you don't need additional
> properties?
>
> If the only property needed is the partition table offset, it can be encoded
> in the unit-address, and the "reg" property:
>
> partitions {
>
> partition-table@ {
> reg = <0 ...>;
> ...
> };
>
> ...
> };
>
> If you do need additional properties, you'll have to add separate partition
> table nodes.
> Where? Outside the "partitions" subnode?
> What with multiple partition tables
>   - some needing properties (outside "partitions"),
>   - others not (outside/inside "partitions"),
>   - others needing the offset (inside "partitions"?

Hello,

IIRC there is RedBoot on-flash partition format support in kernel
which has the partition table offset as compile time configuration
parameter. Moving this to DT would make unified kernel for boards with
different RedBoot table offsets possible.

I don't use any board with RedBoot so I would not know if there is
other issue preventing such unified kernel.

It might be an actual use case for both the binding and the extra
argument with current partitioning scheme, though.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-12 Thread David Gibson 
On Thu, Dec 10, 2015 at 12:43:24PM -0800, Brian Norris wrote:
> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
> > On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
> > > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
> > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
> > > >  wrote:
> > > 
> > > >> +
> > > >> +Examples:
> > > >> +
> > > >> +flash@0 {
> > > >> +   partitions {
> > > >> +   compatible = "google,fmap";
> > > >> +   };
> > > >> +};
> > > >
> > > > I wonder if this wouldn't be better served in a separate binding doc
> > > > with its compatible name as the filename, like we do with
> > > > driver^Whardware blocks, especially if we want to add more parsers.
> > > 
> > > 
> > > I find that *very* counter productive for bindings that go to the same
> > > node. You have a description of a node, and then suddenly there you
> > > have another file with another description of the same node. Totally
> > > awesome.
> > 
> > I can't actually work out from that if you're agreeing with the
> > original post or the first reply.
> 
> Perhaps I'm biased, but I think he was agreeing with the first reply.
> (Particularly, "I find that *very* counter productive" uses the word
> "that" to refer to "separate binding doc[s]".)
> 
> > > Also how do you plan to write partitioning schemes with parameters
> > > like with non-zero offset of the partition table.
> 
> If you are directing this question at me: I don't have a specific plan
> for it. MTD parsers don't currently take external input for this; many
> scan the whole device, but some might also have conventions built into
> the parser itself too, so this just gets hooked based on "compatible".
> But if the need arose, I would hope we could work out a common binding.
> 
> > Presumably with properties in the patitions node.  Not seeing the
> > problem here.
> 
> I believe Michal is bringing up the (important, IMO) point that if
> distinct partition types are being described in the same node, then any
> use of additional properties *must* be closely coordinated. We can't
> have two parsers "foo" and "bar" defining conflicting uses of the same
> property in the same node, like this:
> 
>   partitions {
>   compatible = "foo", "bar";
>   property-baz = ...; // e.g., reg = <...>;
>   };
> 
> where if "foo" is not found, we fall back to "bar". But what if "foo"
> and "bar" use "property-baz" differently?

Ah.. that is an excellent point, and leads me to realise that using
compatible in this way is wrong.  The whole point of compatible is
that the node is, well, compatible with *all* the things in the list,
and therefore the things in the list are compatible with each other.

Using it for a list of entirely different things to attempt in order
is not correct.


> Having everything in one doc would help ensure that the entire
> "partitions" binding is considered as a whole when extending it, in my
> (and an in my interpretation of Michal's) opinion.
> 
> Brian

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-12 Thread David Gibson 
On Thu, Dec 10, 2015 at 12:43:24PM -0800, Brian Norris wrote:
> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
> > On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
> > > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
> > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
> > > >  wrote:
> > > 
> > > >> +
> > > >> +Examples:
> > > >> +
> > > >> +flash@0 {
> > > >> +   partitions {
> > > >> +   compatible = "google,fmap";
> > > >> +   };
> > > >> +};
> > > >
> > > > I wonder if this wouldn't be better served in a separate binding doc
> > > > with its compatible name as the filename, like we do with
> > > > driver^Whardware blocks, especially if we want to add more parsers.
> > > 
> > > 
> > > I find that *very* counter productive for bindings that go to the same
> > > node. You have a description of a node, and then suddenly there you
> > > have another file with another description of the same node. Totally
> > > awesome.
> > 
> > I can't actually work out from that if you're agreeing with the
> > original post or the first reply.
> 
> Perhaps I'm biased, but I think he was agreeing with the first reply.
> (Particularly, "I find that *very* counter productive" uses the word
> "that" to refer to "separate binding doc[s]".)
> 
> > > Also how do you plan to write partitioning schemes with parameters
> > > like with non-zero offset of the partition table.
> 
> If you are directing this question at me: I don't have a specific plan
> for it. MTD parsers don't currently take external input for this; many
> scan the whole device, but some might also have conventions built into
> the parser itself too, so this just gets hooked based on "compatible".
> But if the need arose, I would hope we could work out a common binding.
> 
> > Presumably with properties in the patitions node.  Not seeing the
> > problem here.
> 
> I believe Michal is bringing up the (important, IMO) point that if
> distinct partition types are being described in the same node, then any
> use of additional properties *must* be closely coordinated. We can't
> have two parsers "foo" and "bar" defining conflicting uses of the same
> property in the same node, like this:
> 
>   partitions {
>   compatible = "foo", "bar";
>   property-baz = ...; // e.g., reg = <...>;
>   };
> 
> where if "foo" is not found, we fall back to "bar". But what if "foo"
> and "bar" use "property-baz" differently?

Ah.. that is an excellent point, and leads me to realise that using
compatible in this way is wrong.  The whole point of compatible is
that the node is, well, compatible with *all* the things in the list,
and therefore the things in the list are compatible with each other.

Using it for a list of entirely different things to attempt in order
is not correct.


> Having everything in one doc would help ensure that the entire
> "partitions" binding is considered as a whole when extending it, in my
> (and an in my interpretation of Michal's) opinion.
> 
> Brian

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-11 Thread Michal Suchanek 
Hello,

On 10 December 2015 at 21:43, Brian Norris  wrote:
> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
>> On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
>> > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
>> > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>> > >  wrote:
>> >
>> > >> +
>> > >> +Examples:
>> > >> +
>> > >> +flash@0 {
>> > >> +   partitions {
>> > >> +   compatible = "google,fmap";
>> > >> +   };
>> > >> +};
>> > >
>> > > I wonder if this wouldn't be better served in a separate binding doc
>> > > with its compatible name as the filename, like we do with
>> > > driver^Whardware blocks, especially if we want to add more parsers.
>> >
>> >
>> > I find that *very* counter productive for bindings that go to the same
>> > node. You have a description of a node, and then suddenly there you
>> > have another file with another description of the same node. Totally
>> > awesome.
>>
>> I can't actually work out from that if you're agreeing with the
>> original post or the first reply.
>
> Perhaps I'm biased, but I think he was agreeing with the first reply.
> (Particularly, "I find that *very* counter productive" uses the word
> "that" to refer to "separate binding doc[s]".)
>
>
> I believe Michal is bringing up the (important, IMO) point that if
> distinct partition types are being described in the same node, then any
> use of additional properties *must* be closely coordinated. We can't
> have two parsers "foo" and "bar" defining conflicting uses of the same
> property in the same node, like this:
>

I have seen some MFD bindings which are described in multiple files
with no crossreference whatsoever.

If on-flash partition table bindings are going to be the same then
people are not going to find there are even some on-flash partition
table bindings (because the document describing the in-DT bindings is
complete and exhaustive, right). Can't even imagine coordination.

When you have to grep the tree for docs anyway what's even the point
of the Documentation directory?

You can just grep the whole tree.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-11 Thread Michal Suchanek 
Hello,

On 10 December 2015 at 21:43, Brian Norris  wrote:
> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
>> On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
>> > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
>> > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>> > >  wrote:
>> >
>> > >> +
>> > >> +Examples:
>> > >> +
>> > >> +flash@0 {
>> > >> +   partitions {
>> > >> +   compatible = "google,fmap";
>> > >> +   };
>> > >> +};
>> > >
>> > > I wonder if this wouldn't be better served in a separate binding doc
>> > > with its compatible name as the filename, like we do with
>> > > driver^Whardware blocks, especially if we want to add more parsers.
>> >
>> >
>> > I find that *very* counter productive for bindings that go to the same
>> > node. You have a description of a node, and then suddenly there you
>> > have another file with another description of the same node. Totally
>> > awesome.
>>
>> I can't actually work out from that if you're agreeing with the
>> original post or the first reply.
>
> Perhaps I'm biased, but I think he was agreeing with the first reply.
> (Particularly, "I find that *very* counter productive" uses the word
> "that" to refer to "separate binding doc[s]".)
>
>
> I believe Michal is bringing up the (important, IMO) point that if
> distinct partition types are being described in the same node, then any
> use of additional properties *must* be closely coordinated. We can't
> have two parsers "foo" and "bar" defining conflicting uses of the same
> property in the same node, like this:
>

I have seen some MFD bindings which are described in multiple files
with no crossreference whatsoever.

If on-flash partition table bindings are going to be the same then
people are not going to find there are even some on-flash partition
table bindings (because the document describing the in-DT bindings is
complete and exhaustive, right). Can't even imagine coordination.

When you have to grep the tree for docs anyway what's even the point
of the Documentation directory?

You can just grep the whole tree.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-10 Thread Brian Norris 
On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
> On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
> > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
> > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
> > >  wrote:
> > 
> > >> +
> > >> +Examples:
> > >> +
> > >> +flash@0 {
> > >> +   partitions {
> > >> +   compatible = "google,fmap";
> > >> +   };
> > >> +};
> > >
> > > I wonder if this wouldn't be better served in a separate binding doc
> > > with its compatible name as the filename, like we do with
> > > driver^Whardware blocks, especially if we want to add more parsers.
> > 
> > 
> > I find that *very* counter productive for bindings that go to the same
> > node. You have a description of a node, and then suddenly there you
> > have another file with another description of the same node. Totally
> > awesome.
> 
> I can't actually work out from that if you're agreeing with the
> original post or the first reply.

Perhaps I'm biased, but I think he was agreeing with the first reply.
(Particularly, "I find that *very* counter productive" uses the word
"that" to refer to "separate binding doc[s]".)

> > Also how do you plan to write partitioning schemes with parameters
> > like with non-zero offset of the partition table.

If you are directing this question at me: I don't have a specific plan
for it. MTD parsers don't currently take external input for this; many
scan the whole device, but some might also have conventions built into
the parser itself too, so this just gets hooked based on "compatible".
But if the need arose, I would hope we could work out a common binding.

> Presumably with properties in the patitions node.  Not seeing the
> problem here.

I believe Michal is bringing up the (important, IMO) point that if
distinct partition types are being described in the same node, then any
use of additional properties *must* be closely coordinated. We can't
have two parsers "foo" and "bar" defining conflicting uses of the same
property in the same node, like this:

partitions {
compatible = "foo", "bar";
property-baz = ...; // e.g., reg = <...>;
};

where if "foo" is not found, we fall back to "bar". But what if "foo"
and "bar" use "property-baz" differently?

Having everything in one doc would help ensure that the entire
"partitions" binding is considered as a whole when extending it, in my
(and an in my interpretation of Michal's) opinion.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-10 Thread Brian Norris 
On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
> On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
> > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
> > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
> > >  wrote:
> > 
> > >> +
> > >> +Examples:
> > >> +
> > >> +flash@0 {
> > >> +   partitions {
> > >> +   compatible = "google,fmap";
> > >> +   };
> > >> +};
> > >
> > > I wonder if this wouldn't be better served in a separate binding doc
> > > with its compatible name as the filename, like we do with
> > > driver^Whardware blocks, especially if we want to add more parsers.
> > 
> > 
> > I find that *very* counter productive for bindings that go to the same
> > node. You have a description of a node, and then suddenly there you
> > have another file with another description of the same node. Totally
> > awesome.
> 
> I can't actually work out from that if you're agreeing with the
> original post or the first reply.

Perhaps I'm biased, but I think he was agreeing with the first reply.
(Particularly, "I find that *very* counter productive" uses the word
"that" to refer to "separate binding doc[s]".)

> > Also how do you plan to write partitioning schemes with parameters
> > like with non-zero offset of the partition table.

If you are directing this question at me: I don't have a specific plan
for it. MTD parsers don't currently take external input for this; many
scan the whole device, but some might also have conventions built into
the parser itself too, so this just gets hooked based on "compatible".
But if the need arose, I would hope we could work out a common binding.

> Presumably with properties in the patitions node.  Not seeing the
> problem here.

I believe Michal is bringing up the (important, IMO) point that if
distinct partition types are being described in the same node, then any
use of additional properties *must* be closely coordinated. We can't
have two parsers "foo" and "bar" defining conflicting uses of the same
property in the same node, like this:

partitions {
compatible = "foo", "bar";
property-baz = ...; // e.g., reg = <...>;
};

where if "foo" is not found, we fall back to "bar". But what if "foo"
and "bar" use "property-baz" differently?

Having everything in one doc would help ensure that the entire
"partitions" binding is considered as a whole when extending it, in my
(and an in my interpretation of Michal's) opinion.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-06 Thread Rob Herring 
On Fri, Dec 04, 2015 at 09:19:19PM -0800, Brian Norris wrote:
> The platform description (such as the type of partition formats used on
> a given flash) should be done independently of the flash driver in use.
> However, we can't reasonably have *all* partition parsers run on all
> flash (until they find a match), so let's overload the 'partitions'
> subnode to support specifying which format(s) to try in the device tree.
> 
> Start by supporting Google's (Chrome OS) FMAP structure.
> 
> There have been others interested in extending devicetree support to
> other parsers, like the bcm47xxpart parser:
> 
>   http://patchwork.ozlabs.org/patch/475986/
> 
> and the AFS (ARM Flash Structure?) parser:
> 
>   http://patchwork.ozlabs.org/patch/537827/
> 
> Signed-off-by: Brian Norris 

Looks good to me. If you had lots of partitions, I'd agree with comments 
that they should be separate files, but I doubt we'll have many 10s of 
them. Plus all we really need here is a list of compatible strings. 

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/mtd/partition.txt  | 75 
> --
>  1 file changed, 69 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
> b/Documentation/devicetree/bindings/mtd/partition.txt
> index 28ae56f5c972..1bf9a7243993 100644
> --- a/Documentation/devicetree/bindings/mtd/partition.txt
> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> @@ -1,29 +1,56 @@
> -Representing flash partitions in devicetree
> +Flash partitions in device tree
> +===
>  
> -Partitions can be represented by sub-nodes of an mtd device. This can be used
> +Flash devices can be partitioned into one or more functional ranges (e.g.,
> +"boot code", "nvram", and "kernel") in at least two distinct ways:
> +
> + (A) a fixed flash layout at production time or
> + (B) with an on-flash partition table, such as RedBoot, that describes the
> + geometry and naming/purpose of each functional region
> +
> +The former typically requires an operating system to learn about the
> +partitioning from some kind of metadata provided by the bootloader/firmware.
> +Such partitions can be described using the method in "Section A: Fixed 
> Partitions".
> +
> +The latter is somewhat analogous to partition tables used on block devices
> +(e.g., MBR or GPT), except that there is less standardization for flash
> +devices, and it is not always safe or efficient to attempt to search for all 
> of
> +them on every flash device in the system, particularly since many of them 
> allow
> +their data structures to be placed anywhere on the flash, and so require
> +scanning the entire flash device to find them.
> +
> +To assist system software in locating these partition tables, we provide a
> +binding to describe which partition format(s) may be used on a given flash,
> +found below in "Section B: On-Flash Partition Tables".
> +
> +
> +Section A: Fixed Partitions
> +---
> +
> +Partitions can be represented by sub-nodes of a flash device. This can be 
> used
>  on platforms which have strong conventions about which portions of a flash 
> are
>  used for what purposes, but which don't use an on-flash partition table such
>  as RedBoot.
>  
> -The partition table should be a subnode of the mtd node and should be named
> +The partition table should be a subnode of the flash node and should be named
>  'partitions'. This node should have the following property:
>  - compatible : (required) must be "partitions"
>  Partitions are then defined in subnodes of the partitions node.
>  
> -For backwards compatibility partitions as direct subnodes of the mtd device 
> are
> +For backwards compatibility partitions as direct subnodes of the flash 
> device are
>  supported. This use is discouraged.
>  NOTE: also for backwards compatibility, direct subnodes that have a 
> compatible
>  string are not considered partitions, as they may be used for other bindings.
>  
>  #address-cells & #size-cells must both be present in the partitions subnode 
> of the
> -mtd device. There are two valid values for both:
> +flash device. There are two valid values for both:
>  <1>: for partitions that require a single 32-bit cell to represent their
>   size/address (aka the value is below 4 GiB)
>  <2>: for partitions that require two 32-bit cells to represent their
>   size/address (aka the value is 4 GiB or greater).
>  
>  Required properties:
> -- reg : The partition's offset and size within the mtd bank.
> +- reg : The partition's offset and size within the flash
>  
>  Optional properties:
>  - label : The label / name for this partition.  If omitted, the label is 
> taken
> @@ -89,3 +116,39 @@ flash@2 {
>   };
>   };
>  };
> +
> +
> +Section B: On-Flash Partition Tables
> +
> +
> +System designers use a variety of on-flash data structures to describe the
> +layout of the flash.

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-06 Thread David Gibson 
On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
> On 5 December 2015 at 12:39, Jonas Gorski  wrote:
> > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
> >  wrote:
> 
> >> +
> >> +Examples:
> >> +
> >> +flash@0 {
> >> +   partitions {
> >> +   compatible = "google,fmap";
> >> +   };
> >> +};
> >
> > I wonder if this wouldn't be better served in a separate binding doc
> > with its compatible name as the filename, like we do with
> > driver^Whardware blocks, especially if we want to add more parsers.
> 
> 
> I find that *very* counter productive for bindings that go to the same
> node. You have a description of a node, and then suddenly there you
> have another file with another description of the same node. Totally
> awesome.

I can't actually work out from that if you're agreeing with the
original post or the first reply.

> Also how do you plan to write partitioning schemes with parameters
> like with non-zero offset of the partition table.

Presumably with properties in the patitions node.  Not seeing the
problem here.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-06 Thread David Gibson 
On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
> On 5 December 2015 at 12:39, Jonas Gorski  wrote:
> > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
> >  wrote:
> 
> >> +
> >> +Examples:
> >> +
> >> +flash@0 {
> >> +   partitions {
> >> +   compatible = "google,fmap";
> >> +   };
> >> +};
> >
> > I wonder if this wouldn't be better served in a separate binding doc
> > with its compatible name as the filename, like we do with
> > driver^Whardware blocks, especially if we want to add more parsers.
> 
> 
> I find that *very* counter productive for bindings that go to the same
> node. You have a description of a node, and then suddenly there you
> have another file with another description of the same node. Totally
> awesome.

I can't actually work out from that if you're agreeing with the
original post or the first reply.

> Also how do you plan to write partitioning schemes with parameters
> like with non-zero offset of the partition table.

Presumably with properties in the patitions node.  Not seeing the
problem here.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-06 Thread Rob Herring 
On Fri, Dec 04, 2015 at 09:19:19PM -0800, Brian Norris wrote:
> The platform description (such as the type of partition formats used on
> a given flash) should be done independently of the flash driver in use.
> However, we can't reasonably have *all* partition parsers run on all
> flash (until they find a match), so let's overload the 'partitions'
> subnode to support specifying which format(s) to try in the device tree.
> 
> Start by supporting Google's (Chrome OS) FMAP structure.
> 
> There have been others interested in extending devicetree support to
> other parsers, like the bcm47xxpart parser:
> 
>   http://patchwork.ozlabs.org/patch/475986/
> 
> and the AFS (ARM Flash Structure?) parser:
> 
>   http://patchwork.ozlabs.org/patch/537827/
> 
> Signed-off-by: Brian Norris 

Looks good to me. If you had lots of partitions, I'd agree with comments 
that they should be separate files, but I doubt we'll have many 10s of 
them. Plus all we really need here is a list of compatible strings. 

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/mtd/partition.txt  | 75 
> --
>  1 file changed, 69 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
> b/Documentation/devicetree/bindings/mtd/partition.txt
> index 28ae56f5c972..1bf9a7243993 100644
> --- a/Documentation/devicetree/bindings/mtd/partition.txt
> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> @@ -1,29 +1,56 @@
> -Representing flash partitions in devicetree
> +Flash partitions in device tree
> +===
>  
> -Partitions can be represented by sub-nodes of an mtd device. This can be used
> +Flash devices can be partitioned into one or more functional ranges (e.g.,
> +"boot code", "nvram", and "kernel") in at least two distinct ways:
> +
> + (A) a fixed flash layout at production time or
> + (B) with an on-flash partition table, such as RedBoot, that describes the
> + geometry and naming/purpose of each functional region
> +
> +The former typically requires an operating system to learn about the
> +partitioning from some kind of metadata provided by the bootloader/firmware.
> +Such partitions can be described using the method in "Section A: Fixed 
> Partitions".
> +
> +The latter is somewhat analogous to partition tables used on block devices
> +(e.g., MBR or GPT), except that there is less standardization for flash
> +devices, and it is not always safe or efficient to attempt to search for all 
> of
> +them on every flash device in the system, particularly since many of them 
> allow
> +their data structures to be placed anywhere on the flash, and so require
> +scanning the entire flash device to find them.
> +
> +To assist system software in locating these partition tables, we provide a
> +binding to describe which partition format(s) may be used on a given flash,
> +found below in "Section B: On-Flash Partition Tables".
> +
> +
> +Section A: Fixed Partitions
> +---
> +
> +Partitions can be represented by sub-nodes of a flash device. This can be 
> used
>  on platforms which have strong conventions about which portions of a flash 
> are
>  used for what purposes, but which don't use an on-flash partition table such
>  as RedBoot.
>  
> -The partition table should be a subnode of the mtd node and should be named
> +The partition table should be a subnode of the flash node and should be named
>  'partitions'. This node should have the following property:
>  - compatible : (required) must be "partitions"
>  Partitions are then defined in subnodes of the partitions node.
>  
> -For backwards compatibility partitions as direct subnodes of the mtd device 
> are
> +For backwards compatibility partitions as direct subnodes of the flash 
> device are
>  supported. This use is discouraged.
>  NOTE: also for backwards compatibility, direct subnodes that have a 
> compatible
>  string are not considered partitions, as they may be used for other bindings.
>  
>  #address-cells & #size-cells must both be present in the partitions subnode 
> of the
> -mtd device. There are two valid values for both:
> +flash device. There are two valid values for both:
>  <1>: for partitions that require a single 32-bit cell to represent their
>   size/address (aka the value is below 4 GiB)
>  <2>: for partitions that require two 32-bit cells to represent their
>   size/address (aka the value is 4 GiB or greater).
>  
>  Required properties:
> -- reg : The partition's offset and size within the mtd bank.
> +- reg : The partition's offset and size within the flash
>  
>  Optional properties:
>  - label : The label / name for this partition.  If omitted, the label is 
> taken
> @@ -89,3 +116,39 @@ flash@2 {
>   };
>   };
>  };
> +
> +
> +Section B: On-Flash Partition Tables
> +
> +
> +System designers use a variety of on-flash data

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-05 Thread Michal Suchanek 
On 5 December 2015 at 12:39, Jonas Gorski  wrote:
> On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>  wrote:

>> +
>> +Examples:
>> +
>> +flash@0 {
>> +   partitions {
>> +   compatible = "google,fmap";
>> +   };
>> +};
>
> I wonder if this wouldn't be better served in a separate binding doc
> with its compatible name as the filename, like we do with
> driver^Whardware blocks, especially if we want to add more parsers.


I find that *very* counter productive for bindings that go to the same
node. You have a description of a node, and then suddenly there you
have another file with another description of the same node. Totally
awesome.

Also how do you plan to write partitioning schemes with parameters
like with non-zero offset of the partition table.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-05 Thread Jonas Gorski 
On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
 wrote:
> The platform description (such as the type of partition formats used on
> a given flash) should be done independently of the flash driver in use.
> However, we can't reasonably have *all* partition parsers run on all
> flash (until they find a match), so let's overload the 'partitions'
> subnode to support specifying which format(s) to try in the device tree.
>
> Start by supporting Google's (Chrome OS) FMAP structure.
>
> There have been others interested in extending devicetree support to
> other parsers, like the bcm47xxpart parser:
>
>   http://patchwork.ozlabs.org/patch/475986/
>
> and the AFS (ARM Flash Structure?) parser:
>
>   http://patchwork.ozlabs.org/patch/537827/
>
> Signed-off-by: Brian Norris 
> ---
>  .../devicetree/bindings/mtd/partition.txt  | 75 
> --
>  1 file changed, 69 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
> b/Documentation/devicetree/bindings/mtd/partition.txt
> index 28ae56f5c972..1bf9a7243993 100644
> --- a/Documentation/devicetree/bindings/mtd/partition.txt
> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> @@ -1,29 +1,56 @@
> -Representing flash partitions in devicetree
> +Flash partitions in device tree
> +===
>
> -Partitions can be represented by sub-nodes of an mtd device. This can be used
> +Flash devices can be partitioned into one or more functional ranges (e.g.,
> +"boot code", "nvram", and "kernel") in at least two distinct ways:
> +
> + (A) a fixed flash layout at production time or
> + (B) with an on-flash partition table, such as RedBoot, that describes the
> + geometry and naming/purpose of each functional region
> +
> +The former typically requires an operating system to learn about the
> +partitioning from some kind of metadata provided by the bootloader/firmware.
> +Such partitions can be described using the method in "Section A: Fixed 
> Partitions".
> +
> +The latter is somewhat analogous to partition tables used on block devices
> +(e.g., MBR or GPT), except that there is less standardization for flash
> +devices, and it is not always safe or efficient to attempt to search for all 
> of
> +them on every flash device in the system, particularly since many of them 
> allow
> +their data structures to be placed anywhere on the flash, and so require
> +scanning the entire flash device to find them.
> +
> +To assist system software in locating these partition tables, we provide a
> +binding to describe which partition format(s) may be used on a given flash,
> +found below in "Section B: On-Flash Partition Tables".
> +
> +
> +Section A: Fixed Partitions
> +---
> +
> +Partitions can be represented by sub-nodes of a flash device. This can be 
> used
>  on platforms which have strong conventions about which portions of a flash 
> are
>  used for what purposes, but which don't use an on-flash partition table such
>  as RedBoot.
>
> -The partition table should be a subnode of the mtd node and should be named
> +The partition table should be a subnode of the flash node and should be named
>  'partitions'. This node should have the following property:
>  - compatible : (required) must be "partitions"
>  Partitions are then defined in subnodes of the partitions node.
>
> -For backwards compatibility partitions as direct subnodes of the mtd device 
> are
> +For backwards compatibility partitions as direct subnodes of the flash 
> device are
>  supported. This use is discouraged.
>  NOTE: also for backwards compatibility, direct subnodes that have a 
> compatible
>  string are not considered partitions, as they may be used for other bindings.
>
>  #address-cells & #size-cells must both be present in the partitions subnode 
> of the
> -mtd device. There are two valid values for both:
> +flash device. There are two valid values for both:
>  <1>: for partitions that require a single 32-bit cell to represent their
>   size/address (aka the value is below 4 GiB)
>  <2>: for partitions that require two 32-bit cells to represent their
>   size/address (aka the value is 4 GiB or greater).
>
>  Required properties:
> -- reg : The partition's offset and size within the mtd bank.
> +- reg : The partition's offset and size within the flash
>
>  Optional properties:
>  - label : The label / name for this partition.  If omitted, the label is 
> taken
> @@ -89,3 +116,39 @@ flash@2 {
> };
> };
>  };
> +
> +
> +Section B: On-Flash Partition Tables
> +
> +
> +System designers use a variety of on-flash data structures to describe the
> +layout of the flash. Because it's not always optimal for system software to
> +scan for every sort of data structure that might be used, one can specify 
> which
> +structure(s) might be used on a given flash using the 'partitions' subnode of
> +the flash node.
> +
> +Node name:

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-05 Thread Jonas Gorski 
On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
 wrote:
> The platform description (such as the type of partition formats used on
> a given flash) should be done independently of the flash driver in use.
> However, we can't reasonably have *all* partition parsers run on all
> flash (until they find a match), so let's overload the 'partitions'
> subnode to support specifying which format(s) to try in the device tree.
>
> Start by supporting Google's (Chrome OS) FMAP structure.
>
> There have been others interested in extending devicetree support to
> other parsers, like the bcm47xxpart parser:
>
>   http://patchwork.ozlabs.org/patch/475986/
>
> and the AFS (ARM Flash Structure?) parser:
>
>   http://patchwork.ozlabs.org/patch/537827/
>
> Signed-off-by: Brian Norris 
> ---
>  .../devicetree/bindings/mtd/partition.txt  | 75 
> --
>  1 file changed, 69 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
> b/Documentation/devicetree/bindings/mtd/partition.txt
> index 28ae56f5c972..1bf9a7243993 100644
> --- a/Documentation/devicetree/bindings/mtd/partition.txt
> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> @@ -1,29 +1,56 @@
> -Representing flash partitions in devicetree
> +Flash partitions in device tree
> +===
>
> -Partitions can be represented by sub-nodes of an mtd device. This can be used
> +Flash devices can be partitioned into one or more functional ranges (e.g.,
> +"boot code", "nvram", and "kernel") in at least two distinct ways:
> +
> + (A) a fixed flash layout at production time or
> + (B) with an on-flash partition table, such as RedBoot, that describes the
> + geometry and naming/purpose of each functional region
> +
> +The former typically requires an operating system to learn about the
> +partitioning from some kind of metadata provided by the bootloader/firmware.
> +Such partitions can be described using the method in "Section A: Fixed 
> Partitions".
> +
> +The latter is somewhat analogous to partition tables used on block devices
> +(e.g., MBR or GPT), except that there is less standardization for flash
> +devices, and it is not always safe or efficient to attempt to search for all 
> of
> +them on every flash device in the system, particularly since many of them 
> allow
> +their data structures to be placed anywhere on the flash, and so require
> +scanning the entire flash device to find them.
> +
> +To assist system software in locating these partition tables, we provide a
> +binding to describe which partition format(s) may be used on a given flash,
> +found below in "Section B: On-Flash Partition Tables".
> +
> +
> +Section A: Fixed Partitions
> +---
> +
> +Partitions can be represented by sub-nodes of a flash device. This can be 
> used
>  on platforms which have strong conventions about which portions of a flash 
> are
>  used for what purposes, but which don't use an on-flash partition table such
>  as RedBoot.
>
> -The partition table should be a subnode of the mtd node and should be named
> +The partition table should be a subnode of the flash node and should be named
>  'partitions'. This node should have the following property:
>  - compatible : (required) must be "partitions"
>  Partitions are then defined in subnodes of the partitions node.
>
> -For backwards compatibility partitions as direct subnodes of the mtd device 
> are
> +For backwards compatibility partitions as direct subnodes of the flash 
> device are
>  supported. This use is discouraged.
>  NOTE: also for backwards compatibility, direct subnodes that have a 
> compatible
>  string are not considered partitions, as they may be used for other bindings.
>
>  #address-cells & #size-cells must both be present in the partitions subnode 
> of the
> -mtd device. There are two valid values for both:
> +flash device. There are two valid values for both:
>  <1>: for partitions that require a single 32-bit cell to represent their
>   size/address (aka the value is below 4 GiB)
>  <2>: for partitions that require two 32-bit cells to represent their
>   size/address (aka the value is 4 GiB or greater).
>
>  Required properties:
> -- reg : The partition's offset and size within the mtd bank.
> +- reg : The partition's offset and size within the flash
>
>  Optional properties:
>  - label : The label / name for this partition.  If omitted, the label is 
> taken
> @@ -89,3 +116,39 @@ flash@2 {
> };
> };
>  };
> +
> +
> +Section B: On-Flash Partition Tables
> +
> +
> +System designers use a variety of on-flash data structures to describe the
> +layout of the flash. Because it's not always optimal for system software to
> +scan for every sort of data structure that might be used, one can specify 
> which
> +structure(s) might be used on a given flash using the

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

2015-12-05 Thread Michal Suchanek 
On 5 December 2015 at 12:39, Jonas Gorski  wrote:
> On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>  wrote:

>> +
>> +Examples:
>> +
>> +flash@0 {
>> +   partitions {
>> +   compatible = "google,fmap";
>> +   };
>> +};
>
> I wonder if this wouldn't be better served in a separate binding doc
> with its compatible name as the filename, like we do with
> driver^Whardware blocks, especially if we want to add more parsers.


I find that *very* counter productive for bindings that go to the same
node. You have a description of a node, and then suddenly there you
have another file with another description of the same node. Totally
awesome.

Also how do you plan to write partitioning schemes with parameters
like with non-zero offset of the partition table.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/