Re: [PATCH V2, 3/4] arm: dts: Add bcm-nsp and bcm958625k support

Re: [PATCH V2, 3/4] arm: dts: Add bcm-nsp and bcm958625k support

[Brian Norris]

Hi Florian,

(HTML mail. What is this??)

On Fri, May 27, 2016 at 01:33:20PM -0700, Florian Fainelli wrote:
>    On May 27, 2016 1:28 PM, "Scott Branden"
>    <[1]scott.branden@broadcom.com> wrote:
> 
>    >> +&qspi {
>    >> +       bspi-sel = <0>;
>    >> +       flash: m25p80@0 {
>    >> +               #address-cells = <1>;
>    >> +               #size-cells = <1>;
>    >> +               compatible = "m25p80";
>    >> +               reg = <0x0>;
>    >> +               spi-max-frequency = <12500000>;
>    >> +               m25p,fast-read;
>    >> +               spi-cpol;
>    >> +               spi-cpha;
>    >> +
>    >> +               partition@0 {
>    >> +                       label = "boot";
>    >> +                       reg = <0x00000000 0x000a0000>;
>    >> +               };
>    >> +
>    >> +               partition@1 {
>    >> +                       label = "env";
>    >> +                       reg = <0x000a0000 0x00060000>;
>    >> +               };
>    >> +
>    >> +               partition@2 {
>    >> +                       label = "system";
>    >> +                       reg = <0x00100000 0x00600000>;
>    >> +               };
>    >> +
>    >> +               partition@3 {
>    >> +                       label = "rootfs";
>    >> +                       reg = <0x00700000 0x01900000>;
>    >> +               };
>    >
>    >
>    > The partitions are applications specific so should be passed on the
>    boot command line rather than embedded in the dts file.

Scott kinda has a point; they can be application specific, and so in
some cases, you might want to avoid putting this description in DT, at
least if there are good alternatives. The command line may or may not be
a good alternative (I don't think it's a very good one).

>    Partitions are typically part of the platform definition and are
>    suitable for being in Device Tree. AFAICT there is not a good way to
>    supply partitions in an OF configuration other than putting them in DT
>    at the moment. There is also a lot of platform inconsistency whether
>    the command line is appended, extended or overrides the command line in
>    the Device Tree, so I would not really consider this an issue here.

My intention is to allow cmdline to take priority, so you could have
application-specific overrides. If that doesn't work correctly, then
I'd consider it a bug. I know that has irked some people (e.g.,
OpenWRT?), where they deal with products where they may not control the
command line. But that's a separate issue IMO.

You might want to take a look at supporting a partition parser, if this
really is so application-specific. I had all the pieces working late
last year:

https://lkml.org/lkml/2015/12/5/9

but I unfortunately got distracted once the conversation on bindings
derailed:

https://lkml.org/lkml/2015/12/12/31

I should probably revive that...

Anyway, if you utilize that, then you can specify which parser(s) are
valid for your platform, rather than specifying the exact partition
layout.

Brian

Re: [PATCH V2, 3/4] arm: dts: Add bcm-nsp and bcm958625k support

[Florian Fainelli]

On 05/27/2016 01:47 PM, Brian Norris wrote:
> Hi Florian,
> 
> (HTML mail. What is this??)

Made the mistake to reply with the Gmail application on my cellphone,
does not look like they addressed my feature request ;)


>>    > The partitions are applications specific so should be passed on the
>>    boot command line rather than embedded in the dts file.
> 
> Scott kinda has a point; they can be application specific, and so in
> some cases, you might want to avoid putting this description in DT, at
> least if there are good alternatives. The command line may or may not be
> a good alternative (I don't think it's a very good one).

Fair enough

> 
>>    Partitions are typically part of the platform definition and are
>>    suitable for being in Device Tree. AFAICT there is not a good way to
>>    supply partitions in an OF configuration other than putting them in DT
>>    at the moment. There is also a lot of platform inconsistency whether
>>    the command line is appended, extended or overrides the command line in
>>    the Device Tree, so I would not really consider this an issue here.
> 
> My intention is to allow cmdline to take priority, so you could have
> application-specific overrides. If that doesn't work correctly, then
> I'd consider it a bug. I know that has irked some people (e.g.,
> OpenWRT?), where they deal with products where they may not control the
> command line. But that's a separate issue IMO.

I think this behavior makes sense, my problem is more with the fact that
different architecture behave differently with respect to providing the
command line to the kernel, some support taking the bootloader argument
and merging it with the built-in/Device Tree bootargs command line, some
do not, it's not always obvious.

> 
> You might want to take a look at supporting a partition parser, if this
> really is so application-specific. I had all the pieces working late
> last year:
> 
> https://lkml.org/lkml/2015/12/5/9
> 
> but I unfortunately got distracted once the conversation on bindings
> derailed:
> 
> https://lkml.org/lkml/2015/12/12/31
> 
> I should probably revive that...
> 
> Anyway, if you utilize that, then you can specify which parser(s) are
> valid for your platform, rather than specifying the exact partition
> layout.

/me goes reading, thanks!
-- 
Florian