Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi all,

I’ve just put up a blog-entry explaining the rationale behind yaml and device 
tree.

https://www.konsulko.com/yaml-and-device-tree/

Please give it a quick glance and give feedback if you can.

Regards

— Pantelis

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi all,

I’ve just put up a blog-entry explaining the rationale behind yaml and device 
tree.

https://www.konsulko.com/yaml-and-device-tree/

Please give it a quick glance and give feedback if you can.

Regards

— Pantelis

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Grant,

> On Oct 22, 2017, at 19:54 , Grant Likely <grant.lik...@secretlab.ca> wrote:
> 
> On Fri, Oct 20, 2017 at 8:16 PM, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
>> Hi Grant,
>> 
>>> On Oct 20, 2017, at 20:46 , Grant Likely <grant.lik...@secretlab.ca> wrote:
>>> 
>>> On Thu, Sep 28, 2017 at 8:58 PM, Pantelis Antoniou
>>> <pantelis.anton...@konsulko.com> wrote:
>>>> Hello again,
>>>> 
>>>> Significant progress has been made on yamldt and is now capable of
>>>> not only generating yaml from DTS source but also compiling DTS sources
>>>> and being almost fully compatible with DTC.
>>>> 
>>>> Compiling the kernel's DTBs using yamldt is as simple as using a
>>>> DTC=yamldt.
>>>> 
>>>> Error reporting is accurate and validation against a YAML based schema
>>>> works as well. In a short while I will begin posting patches with
>>>> fixes on bindings and DTS files in the kernel.
>>>> 
>>>> Please try it on your platform and report if you encounter any problems.
>>>> 
>>>> https://github.com/pantoniou/yamldt
>>>> 
>>>> I am eagerly awaiting for your comments.
>>> 
>>> Hi Pantelis,
>>> 
>>> This is good work. I've played around with it and I'm looking forward
>>> to chatting next week.
>>> 
>> 
>> Thanks. I’m looking forward to it too.
>> 
>>> One thing I've done is tried loading the output YAML files into
>>> another YAML interpreter and the current encoding causes problems.
>>> Specifically, in yamldt anchors/aliases are being used as a
>>> replacement for labels/phandles, but that conflicts with the YAML data
>>> model which defines a reference as a way to make a copy of the data
>>> appear in another part of the tree. For example, for the following
>>> snippit:
>>> 
>>> intc: intc@1 {
>>>   #interrupt-cells = <1>;
>>>   compatible = "acme,intc";
>>>   reg = <0x1 0x1000>;
>>>   gpio-controller;
>>> };
>>> 
>>> serial@2 {
>>>   compatible = "acme,uart";
>>>   reg = <0x2 0x1000>;
>>>   interrupt-parent = <>;
>>>   interrupts = <5>;
>>> };
>>> 
>>> yamldt will encode this as:
>>> 
>>> intc@1: 
>>>   "#interrupt-cells": 1
>>>   compatible: acme,intc
>>>   reg: [0x1, 0x1000]
>>>   gpio-controller:
>>> 
>>> serial@2:
>>>   compatible: acme,uart
>>>   reg: [0x2, 0x1000]
>>>   interrupt-parent: *intc
>>>   interrupts: 5
>>> 
>>> But, the expected behaviour for a YAML parser is expand the alias
>>> '*intc' which results in the following structure:
>>> 
>>> intc@1: 
>>>   "#interrupt-cells": 1
>>>   compatible: acme,intc
>>>   reg: [0x1, 0x1000]
>>>   gpio-controller:
>>> 
>>> serial@2:
>>>   compatible: acme,uart
>>>   reg: [0x2, 0x1000]
>>>   interrupt-parent:
>>>   "#interrupt-cells": 1
>>>   compatible: acme,intc
>>>   reg: [0x1, 0x1000]
>>>   gpio-controller:
>>>   interrupts: 5
>>> 
>>> See? It results in the entire interrupt controller node to appear as
>>> an instance under the interrupt-parent property, when the intention is
>>> only to create a phandle. yamldt should not redefine the behaviour of
>>> '*' aliases. Instead, it should use a different indicator, either
>>> using an explicit !phandle tag, or by replacing '*' with something
>>> else. I worked around it in my tests by replacing '*' with '$’.
>> 
>> Yes. This is expected. I don’t think pure YAML form is a good match for all
>> the crazy things that are possible (and actually used in practice) with DTS.
> 
> I don’t think it is as dire as that. The DTS structure is not complex
> and I think can easily be mapped into pure YAML. But, it does require
> treating the DTS structure separately from its semantic meaning. For
> example, the grammar of nodes, properties and labels easily maps to
> pure YAML, but phandles and overlay trees have semantic meaning that
> must be resolved by DT specific code. I’ll respond to you’re specific
> examples below…
> 

We are in complete agreement here. Single nodes and properties map to YAML 
perfectly.
It’s

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Grant,

> On Oct 22, 2017, at 19:54 , Grant Likely  wrote:
> 
> On Fri, Oct 20, 2017 at 8:16 PM, Pantelis Antoniou
>  wrote:
>> Hi Grant,
>> 
>>> On Oct 20, 2017, at 20:46 , Grant Likely  wrote:
>>> 
>>> On Thu, Sep 28, 2017 at 8:58 PM, Pantelis Antoniou
>>>  wrote:
>>>> Hello again,
>>>> 
>>>> Significant progress has been made on yamldt and is now capable of
>>>> not only generating yaml from DTS source but also compiling DTS sources
>>>> and being almost fully compatible with DTC.
>>>> 
>>>> Compiling the kernel's DTBs using yamldt is as simple as using a
>>>> DTC=yamldt.
>>>> 
>>>> Error reporting is accurate and validation against a YAML based schema
>>>> works as well. In a short while I will begin posting patches with
>>>> fixes on bindings and DTS files in the kernel.
>>>> 
>>>> Please try it on your platform and report if you encounter any problems.
>>>> 
>>>> https://github.com/pantoniou/yamldt
>>>> 
>>>> I am eagerly awaiting for your comments.
>>> 
>>> Hi Pantelis,
>>> 
>>> This is good work. I've played around with it and I'm looking forward
>>> to chatting next week.
>>> 
>> 
>> Thanks. I’m looking forward to it too.
>> 
>>> One thing I've done is tried loading the output YAML files into
>>> another YAML interpreter and the current encoding causes problems.
>>> Specifically, in yamldt anchors/aliases are being used as a
>>> replacement for labels/phandles, but that conflicts with the YAML data
>>> model which defines a reference as a way to make a copy of the data
>>> appear in another part of the tree. For example, for the following
>>> snippit:
>>> 
>>> intc: intc@1 {
>>>   #interrupt-cells = <1>;
>>>   compatible = "acme,intc";
>>>   reg = <0x1 0x1000>;
>>>   gpio-controller;
>>> };
>>> 
>>> serial@2 {
>>>   compatible = "acme,uart";
>>>   reg = <0x2 0x1000>;
>>>   interrupt-parent = <>;
>>>   interrupts = <5>;
>>> };
>>> 
>>> yamldt will encode this as:
>>> 
>>> intc@1: 
>>>   "#interrupt-cells": 1
>>>   compatible: acme,intc
>>>   reg: [0x1, 0x1000]
>>>   gpio-controller:
>>> 
>>> serial@2:
>>>   compatible: acme,uart
>>>   reg: [0x2, 0x1000]
>>>   interrupt-parent: *intc
>>>   interrupts: 5
>>> 
>>> But, the expected behaviour for a YAML parser is expand the alias
>>> '*intc' which results in the following structure:
>>> 
>>> intc@1: 
>>>   "#interrupt-cells": 1
>>>   compatible: acme,intc
>>>   reg: [0x1, 0x1000]
>>>   gpio-controller:
>>> 
>>> serial@2:
>>>   compatible: acme,uart
>>>   reg: [0x2, 0x1000]
>>>   interrupt-parent:
>>>   "#interrupt-cells": 1
>>>   compatible: acme,intc
>>>   reg: [0x1, 0x1000]
>>>   gpio-controller:
>>>   interrupts: 5
>>> 
>>> See? It results in the entire interrupt controller node to appear as
>>> an instance under the interrupt-parent property, when the intention is
>>> only to create a phandle. yamldt should not redefine the behaviour of
>>> '*' aliases. Instead, it should use a different indicator, either
>>> using an explicit !phandle tag, or by replacing '*' with something
>>> else. I worked around it in my tests by replacing '*' with '$’.
>> 
>> Yes. This is expected. I don’t think pure YAML form is a good match for all
>> the crazy things that are possible (and actually used in practice) with DTS.
> 
> I don’t think it is as dire as that. The DTS structure is not complex
> and I think can easily be mapped into pure YAML. But, it does require
> treating the DTS structure separately from its semantic meaning. For
> example, the grammar of nodes, properties and labels easily maps to
> pure YAML, but phandles and overlay trees have semantic meaning that
> must be resolved by DT specific code. I’ll respond to you’re specific
> examples below…
> 

We are in complete agreement here. Single nodes and properties map to YAML 
perfectly.
It’s the complex way that we build the complete DTB that stress the YAML 
structures.

>> 
>> For instance there’s no way a

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Grant,

> On Oct 20, 2017, at 20:46 , Grant Likely <grant.lik...@secretlab.ca> wrote:
> 
> On Thu, Sep 28, 2017 at 8:58 PM, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
>> Hello again,
>> 
>> Significant progress has been made on yamldt and is now capable of
>> not only generating yaml from DTS source but also compiling DTS sources
>> and being almost fully compatible with DTC.
>> 
>> Compiling the kernel's DTBs using yamldt is as simple as using a
>> DTC=yamldt.
>> 
>> Error reporting is accurate and validation against a YAML based schema
>> works as well. In a short while I will begin posting patches with
>> fixes on bindings and DTS files in the kernel.
>> 
>> Please try it on your platform and report if you encounter any problems.
>> 
>> https://github.com/pantoniou/yamldt
>> 
>> I am eagerly awaiting for your comments.
> 
> Hi Pantelis,
> 
> This is good work. I've played around with it and I'm looking forward
> to chatting next week.
> 

Thanks. I’m looking forward to it too.

> One thing I've done is tried loading the output YAML files into
> another YAML interpreter and the current encoding causes problems.
> Specifically, in yamldt anchors/aliases are being used as a
> replacement for labels/phandles, but that conflicts with the YAML data
> model which defines a reference as a way to make a copy of the data
> appear in another part of the tree. For example, for the following
> snippit:
> 
> intc: intc@1 {
>#interrupt-cells = <1>;
>compatible = "acme,intc";
>reg = <0x1 0x1000>;
>gpio-controller;
> };
> 
> serial@2 {
>compatible = "acme,uart";
>reg = <0x2 0x1000>;
>interrupt-parent = <>;
>interrupts = <5>;
> };
> 
> yamldt will encode this as:
> 
> intc@1: 
>"#interrupt-cells": 1
>compatible: acme,intc
>reg: [0x1, 0x1000]
>gpio-controller:
> 
> serial@2:
>compatible: acme,uart
>reg: [0x2, 0x1000]
>interrupt-parent: *intc
>interrupts: 5
> 
> But, the expected behaviour for a YAML parser is expand the alias
> '*intc' which results in the following structure:
> 
> intc@1: 
>"#interrupt-cells": 1
>compatible: acme,intc
>reg: [0x1, 0x1000]
>gpio-controller:
> 
> serial@2:
>compatible: acme,uart
>reg: [0x2, 0x1000]
>interrupt-parent:
>"#interrupt-cells": 1
>compatible: acme,intc
>reg: [0x1, 0x1000]
>gpio-controller:
>interrupts: 5
> 
> See? It results in the entire interrupt controller node to appear as
> an instance under the interrupt-parent property, when the intention is
> only to create a phandle. yamldt should not redefine the behaviour of
> '*' aliases. Instead, it should use a different indicator, either
> using an explicit !phandle tag, or by replacing '*' with something
> else. I worked around it in my tests by replacing '*' with '$’.

Yes. This is expected. I don’t think pure YAML form is a good match for all
the crazy things that are possible (and actually used in practice) with DTS.

For instance there’s no way a normal YAML parser won’t choke with something like

/ {
  foo;
};

/ {
  bar;
};

Which is a common idiom in DTS files.

The decision to use the YAML anchors and references was more borne out of a 
desire
to sort of match conceptually the labels and references of DTS. It’s not a big
issue to switch to something different.  

If we were to force YAML/DT file to be regular YAML files parseable by 
everything
we’d have to rethink a lot of conventions that DT files currently use and I’m 
afraid
a machine translation from DTS to YAML might not be feasible then.

OTOH moving to that model might make it possible to use YAML constructs that 
are not
mapped at all to DTS. For instance

- foo: true
  bar: “string”

- foo: false
  bar: “another-string”

is not possible to be mapped to a DT node/property structure right now.

> 

> Plus, it would be useful to use normal YAML anchors/aliases for
> creating node templates. For example:
> 
> serial-template:  . # The anchor for the template
>compatible: acme,uart
>interrupt-parent: *intc
> 
> root:
>serial@2:
><<: *acme-uart   # Alias node merged into serial@2
>interrupts: 5
>reg: [0x2, 0x1000]
>serial@3:
><<: *acme-uart   # Alias node merged into serial@3
>interrupts: 5
>reg: [0x3, 0x1000]
> 

Yes, I’m aware of this and I planned to talk to you about it :)
It can be a very powerful way to cut

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Grant,

> On Oct 20, 2017, at 20:46 , Grant Likely  wrote:
> 
> On Thu, Sep 28, 2017 at 8:58 PM, Pantelis Antoniou
>  wrote:
>> Hello again,
>> 
>> Significant progress has been made on yamldt and is now capable of
>> not only generating yaml from DTS source but also compiling DTS sources
>> and being almost fully compatible with DTC.
>> 
>> Compiling the kernel's DTBs using yamldt is as simple as using a
>> DTC=yamldt.
>> 
>> Error reporting is accurate and validation against a YAML based schema
>> works as well. In a short while I will begin posting patches with
>> fixes on bindings and DTS files in the kernel.
>> 
>> Please try it on your platform and report if you encounter any problems.
>> 
>> https://github.com/pantoniou/yamldt
>> 
>> I am eagerly awaiting for your comments.
> 
> Hi Pantelis,
> 
> This is good work. I've played around with it and I'm looking forward
> to chatting next week.
> 

Thanks. I’m looking forward to it too.

> One thing I've done is tried loading the output YAML files into
> another YAML interpreter and the current encoding causes problems.
> Specifically, in yamldt anchors/aliases are being used as a
> replacement for labels/phandles, but that conflicts with the YAML data
> model which defines a reference as a way to make a copy of the data
> appear in another part of the tree. For example, for the following
> snippit:
> 
> intc: intc@1 {
>#interrupt-cells = <1>;
>compatible = "acme,intc";
>reg = <0x1 0x1000>;
>gpio-controller;
> };
> 
> serial@2 {
>compatible = "acme,uart";
>reg = <0x2 0x1000>;
>interrupt-parent = <>;
>interrupts = <5>;
> };
> 
> yamldt will encode this as:
> 
> intc@1: 
>"#interrupt-cells": 1
>compatible: acme,intc
>reg: [0x1, 0x1000]
>gpio-controller:
> 
> serial@2:
>compatible: acme,uart
>reg: [0x2, 0x1000]
>interrupt-parent: *intc
>interrupts: 5
> 
> But, the expected behaviour for a YAML parser is expand the alias
> '*intc' which results in the following structure:
> 
> intc@1: 
>"#interrupt-cells": 1
>compatible: acme,intc
>reg: [0x1, 0x1000]
>gpio-controller:
> 
> serial@2:
>compatible: acme,uart
>reg: [0x2, 0x1000]
>interrupt-parent:
>"#interrupt-cells": 1
>compatible: acme,intc
>reg: [0x1, 0x1000]
>gpio-controller:
>interrupts: 5
> 
> See? It results in the entire interrupt controller node to appear as
> an instance under the interrupt-parent property, when the intention is
> only to create a phandle. yamldt should not redefine the behaviour of
> '*' aliases. Instead, it should use a different indicator, either
> using an explicit !phandle tag, or by replacing '*' with something
> else. I worked around it in my tests by replacing '*' with '$’.

Yes. This is expected. I don’t think pure YAML form is a good match for all
the crazy things that are possible (and actually used in practice) with DTS.

For instance there’s no way a normal YAML parser won’t choke with something like

/ {
  foo;
};

/ {
  bar;
};

Which is a common idiom in DTS files.

The decision to use the YAML anchors and references was more borne out of a 
desire
to sort of match conceptually the labels and references of DTS. It’s not a big
issue to switch to something different.  

If we were to force YAML/DT file to be regular YAML files parseable by 
everything
we’d have to rethink a lot of conventions that DT files currently use and I’m 
afraid
a machine translation from DTS to YAML might not be feasible then.

OTOH moving to that model might make it possible to use YAML constructs that 
are not
mapped at all to DTS. For instance

- foo: true
  bar: “string”

- foo: false
  bar: “another-string”

is not possible to be mapped to a DT node/property structure right now.

> 

> Plus, it would be useful to use normal YAML anchors/aliases for
> creating node templates. For example:
> 
> serial-template:  . # The anchor for the template
>compatible: acme,uart
>interrupt-parent: *intc
> 
> root:
>serial@2:
><<: *acme-uart   # Alias node merged into serial@2
>interrupts: 5
>reg: [0x2, 0x1000]
>serial@3:
><<: *acme-uart   # Alias node merged into serial@3
>interrupts: 5
>reg: [0x3, 0x1000]
> 

Yes, I’m aware of this and I planned to talk to you about it :)
It can be a very powerful way to cut down the churn of DT right now.

It’s not going to be a problem f

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

[Pantelis Antoniou]

Hi Frank,

> On Oct 20, 2017, at 00:46 , Frank Rowand  wrote:
> 
> On 10/19/17 13:06, Moritz Fischer wrote:
> 
> < snip >
> 
>> We also have plenty of code that is just not aware of overlays, and
>> assumes certain parts of the tree to stay static.
> 
> I would state that somewhat differently.  :-)  There is very little
> code that is aware of overlays, and most code assumes the device tree
> does not change after early boot.
> 
> This is one of the areas where the creation of overlays needs to be
> done with care.
> 

Correct. But this is not breaking the kernel.

In general we have the following case where we load overlays (at least
well formed overlays that are not doing stupid things).

1. Activation of a new device. Usually this works since is something that’s
normally done at boot.

2. Deactivation of a device. This might break because the removal paths
of platform device especially are not well tested (or never executed for that
matter).

3. Modification of properties in an already activated device. If the device 
driver
has not installed a device tree modification hook (as in almost 99% of the 
devices)
it will do absolutely nothing, since the device tree is parsed only at probe 
time.
I can argue that for these cases we could have a catch-all hook that displays a
message that nothing happened.

4. Modification of some part of the tree that’s not part of a device driver, 
perhaps
the aliases or chosen node. This may potentially be harmful or harmless 
depending on
what has been modified. For instance modifying an already existing alias might 
cause
internal inconsistency about device naming, while adding a new aliases should 
be harmless.
This is a matter of policy per board, whether to allow or not.

Are there other cases that are potentially more harmful?

> 
>> I ran into that issue when I tried to add thermal zones via an overlay,
>> I've been investigating how to fix the thermal framework to work with
>> overlays since then and have some partially working code.
>> Currently the thermal framework parses the thermal-zones node at boot,
>> and assumes this stays static. This breaks with overlays.
>> 
>> I agree we eventually need to fix the parts that break when we use
>> overlays.
> 

Regards

— Pantelis

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

[Pantelis Antoniou]

Hi Frank,

> On Oct 20, 2017, at 00:46 , Frank Rowand  wrote:
> 
> On 10/19/17 13:06, Moritz Fischer wrote:
> 
> < snip >
> 
>> We also have plenty of code that is just not aware of overlays, and
>> assumes certain parts of the tree to stay static.
> 
> I would state that somewhat differently.  :-)  There is very little
> code that is aware of overlays, and most code assumes the device tree
> does not change after early boot.
> 
> This is one of the areas where the creation of overlays needs to be
> done with care.
> 

Correct. But this is not breaking the kernel.

In general we have the following case where we load overlays (at least
well formed overlays that are not doing stupid things).

1. Activation of a new device. Usually this works since is something that’s
normally done at boot.

2. Deactivation of a device. This might break because the removal paths
of platform device especially are not well tested (or never executed for that
matter).

3. Modification of properties in an already activated device. If the device 
driver
has not installed a device tree modification hook (as in almost 99% of the 
devices)
it will do absolutely nothing, since the device tree is parsed only at probe 
time.
I can argue that for these cases we could have a catch-all hook that displays a
message that nothing happened.

4. Modification of some part of the tree that’s not part of a device driver, 
perhaps
the aliases or chosen node. This may potentially be harmful or harmless 
depending on
what has been modified. For instance modifying an already existing alias might 
cause
internal inconsistency about device naming, while adding a new aliases should 
be harmless.
This is a matter of policy per board, whether to allow or not.

Are there other cases that are potentially more harmful?

> 
>> I ran into that issue when I tried to add thermal zones via an overlay,
>> I've been investigating how to fix the thermal framework to work with
>> overlays since then and have some partially working code.
>> Currently the thermal framework parses the thermal-zones node at boot,
>> and assumes this stays static. This breaks with overlays.
>> 
>> I agree we eventually need to fix the parts that break when we use
>> overlays.
> 

Regards

— Pantelis

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

[Pantelis Antoniou]

Hi Rob,

> On Oct 18, 2017, at 21:30 , Rob Herring <r...@kernel.org> wrote:
> 
> On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
>> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote:
>>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull <at...@kernel.org> wrote:
>>>> On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand <frowand.l...@gmail.com> 
>>>> wrote:
>>>>> On 10/17/17 14:46, Rob Herring wrote:
>>>>>> On Tue, Oct 17, 2017 at 4:32 PM, Alan Tull <at...@kernel.org> wrote:
>>>>>>> On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <r...@kernel.org> wrote:
>>>>>>> 
>>>>>>> Hi Rob,
>>>>>>> 
>>>>>>>> With dependencies on a statically allocated full path name converted to
>>>>>>>> use %pOF format specifier, we can store just the basename of node, and
>>>>>>>> the unflattening of the FDT can be simplified.
>>>>>>>> 
>>>>>>>> This commit will affect the remaining users of full_name. After
>>>>>>>> analyzing these users, the remaining cases should only change some 
>>>>>>>> print
>>>>>>>> messages. The main users of full_name are providing a name for struct
>>>>>>>> resource. The resource names shouldn't be important other than 
>>>>>>>> providing
>>>>>>>> /proc/iomem names.
>>>>>>>> 
>>>>>>>> We no longer distinguish between pre and post 0x10 dtb formats as 
>>>>>>>> either
>>>>>>>> a full path or basename will work. However, less than 0x10 formats have
>>>>>>>> been broken since the conversion to use libfdt (and no one has cared).
>>>>>>>> The conversion of the unflattening code to be non-recursive also broke
>>>>>>>> pre 0x10 formats as the populate_node function would return 0 in that
>>>>>>>> case.
>>>>>>>> 
>>>>>>>> Signed-off-by: Rob Herring <r...@kernel.org>
>>>>>>>> ---
>>>>>>>> v2:
>>>>>>>> - rebase to linux-next
>>>>>>>> 
>>>>>>>> drivers/of/fdt.c | 69 
>>>>>>>> +---
>>>>>>>> 1 file changed, 11 insertions(+), 58 deletions(-)
>>>>>>> 
>>>>>>> I've just updated to the latest next branch and am finding problems
>>>>>>> applying overlays.   Reverting this commit alleviates things.  The
>>>>>>> errors I get are:
>>>>>>> 
>>>>>>> [   88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0
>>>>>>> [   88.513447] OF: overlay: apply failed '/__symbols__'
>>>>>>> [   88.518423] create_overlay: Failed to create overlay (err=-12)
>>>>>> 
>>>>>> Frank's series with overlay updates should fix this.
>>>>> 
>>>>> Yes, it does:
>>>>> 
>>>>>  [PATCH v3 11/12] of: overlay: remove a dependency on device node 
>>>>> full_name
>>>> 
>>>> Thanks for the fast response.  I fetched the dt/next branch to test
>>>> this but there are sufficient changes that Pantelis' "OF: DT-Overlay
>>>> configfs interface (v7)" is broken now.  I've been adding that
>>>> downstream since 4.4.  We're using it as an interface for applying
>>>> overlays to program FPGAs.  If we fix it again, is there any chance
>>>> that can go upstream now?
>>> 
>>> With a drive-by posting once every few years, no.
>>> 
>> 
>> I take offense to that. There's nothing changed in the patch for years.
>> Reposting the same patch without changes would achieve nothing.
> 
> Are you still expecting review comments on it or something?
> Furthermore, If something is posted infrequently, then I'm not
> inclined to comment or care if the next posting is going to be after I
> forget what I previously said (which is not very long).
> 
> I'm just saying, don't expect to forward port, post and it will be
> accepted. Below is minimally one of the issues that needs to be
> addressed.
> 
>>> The issue remains that the kernel is not really setup to deal with any
>>> ran

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

[Pantelis Antoniou]

Hi Rob,

> On Oct 18, 2017, at 21:30 , Rob Herring  wrote:
> 
> On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou
>  wrote:
>> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote:
>>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull  wrote:
>>>> On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand  
>>>> wrote:
>>>>> On 10/17/17 14:46, Rob Herring wrote:
>>>>>> On Tue, Oct 17, 2017 at 4:32 PM, Alan Tull  wrote:
>>>>>>> On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring  wrote:
>>>>>>> 
>>>>>>> Hi Rob,
>>>>>>> 
>>>>>>>> With dependencies on a statically allocated full path name converted to
>>>>>>>> use %pOF format specifier, we can store just the basename of node, and
>>>>>>>> the unflattening of the FDT can be simplified.
>>>>>>>> 
>>>>>>>> This commit will affect the remaining users of full_name. After
>>>>>>>> analyzing these users, the remaining cases should only change some 
>>>>>>>> print
>>>>>>>> messages. The main users of full_name are providing a name for struct
>>>>>>>> resource. The resource names shouldn't be important other than 
>>>>>>>> providing
>>>>>>>> /proc/iomem names.
>>>>>>>> 
>>>>>>>> We no longer distinguish between pre and post 0x10 dtb formats as 
>>>>>>>> either
>>>>>>>> a full path or basename will work. However, less than 0x10 formats have
>>>>>>>> been broken since the conversion to use libfdt (and no one has cared).
>>>>>>>> The conversion of the unflattening code to be non-recursive also broke
>>>>>>>> pre 0x10 formats as the populate_node function would return 0 in that
>>>>>>>> case.
>>>>>>>> 
>>>>>>>> Signed-off-by: Rob Herring 
>>>>>>>> ---
>>>>>>>> v2:
>>>>>>>> - rebase to linux-next
>>>>>>>> 
>>>>>>>> drivers/of/fdt.c | 69 
>>>>>>>> +---
>>>>>>>> 1 file changed, 11 insertions(+), 58 deletions(-)
>>>>>>> 
>>>>>>> I've just updated to the latest next branch and am finding problems
>>>>>>> applying overlays.   Reverting this commit alleviates things.  The
>>>>>>> errors I get are:
>>>>>>> 
>>>>>>> [   88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0
>>>>>>> [   88.513447] OF: overlay: apply failed '/__symbols__'
>>>>>>> [   88.518423] create_overlay: Failed to create overlay (err=-12)
>>>>>> 
>>>>>> Frank's series with overlay updates should fix this.
>>>>> 
>>>>> Yes, it does:
>>>>> 
>>>>>  [PATCH v3 11/12] of: overlay: remove a dependency on device node 
>>>>> full_name
>>>> 
>>>> Thanks for the fast response.  I fetched the dt/next branch to test
>>>> this but there are sufficient changes that Pantelis' "OF: DT-Overlay
>>>> configfs interface (v7)" is broken now.  I've been adding that
>>>> downstream since 4.4.  We're using it as an interface for applying
>>>> overlays to program FPGAs.  If we fix it again, is there any chance
>>>> that can go upstream now?
>>> 
>>> With a drive-by posting once every few years, no.
>>> 
>> 
>> I take offense to that. There's nothing changed in the patch for years.
>> Reposting the same patch without changes would achieve nothing.
> 
> Are you still expecting review comments on it or something?
> Furthermore, If something is posted infrequently, then I'm not
> inclined to comment or care if the next posting is going to be after I
> forget what I previously said (which is not very long).
> 
> I'm just saying, don't expect to forward port, post and it will be
> accepted. Below is minimally one of the issues that needs to be
> addressed.
> 
>>> The issue remains that the kernel is not really setup to deal with any
>>> random property or node to be changed at any point in run-time. I
>>> think there needs to be some restrictions around what the overlays can
>>> touch. We can't have it

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

[Pantelis Antoniou]

Hi Frank,

> On Oct 19, 2017, at 00:46 , Frank Rowand <frowand.l...@gmail.com> wrote:
> 
> On 10/18/17 11:30, Rob Herring wrote:
>> On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou
>> <pantelis.anton...@konsulko.com> wrote:
>>> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote:
>>>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull <at...@kernel.org> wrote:
>>>>> On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand <frowand.l...@gmail.com> 
>>>>> wrote:
>>>>>> On 10/17/17 14:46, Rob Herring wrote:
>>>>>>> On Tue, Oct 17, 2017 at 4:32 PM, Alan Tull <at...@kernel.org> wrote:
>>>>>>>> On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <r...@kernel.org> wrote:
>>>>>>>> 
>>>>>>>> Hi Rob,
>>>>>>>> 
>>>>>>>>> With dependencies on a statically allocated full path name converted 
>>>>>>>>> to
>>>>>>>>> use %pOF format specifier, we can store just the basename of node, and
>>>>>>>>> the unflattening of the FDT can be simplified.
>>>>>>>>> 
>>>>>>>>> This commit will affect the remaining users of full_name. After
>>>>>>>>> analyzing these users, the remaining cases should only change some 
>>>>>>>>> print
>>>>>>>>> messages. The main users of full_name are providing a name for struct
>>>>>>>>> resource. The resource names shouldn't be important other than 
>>>>>>>>> providing
>>>>>>>>> /proc/iomem names.
>>>>>>>>> 
>>>>>>>>> We no longer distinguish between pre and post 0x10 dtb formats as 
>>>>>>>>> either
>>>>>>>>> a full path or basename will work. However, less than 0x10 formats 
>>>>>>>>> have
>>>>>>>>> been broken since the conversion to use libfdt (and no one has cared).
>>>>>>>>> The conversion of the unflattening code to be non-recursive also broke
>>>>>>>>> pre 0x10 formats as the populate_node function would return 0 in that
>>>>>>>>> case.
>>>>>>>>> 
>>>>>>>>> Signed-off-by: Rob Herring <r...@kernel.org>
>>>>>>>>> ---
>>>>>>>>> v2:
>>>>>>>>> - rebase to linux-next
>>>>>>>>> 
>>>>>>>>> drivers/of/fdt.c | 69 
>>>>>>>>> +---
>>>>>>>>> 1 file changed, 11 insertions(+), 58 deletions(-)
>>>>>>>> 
>>>>>>>> I've just updated to the latest next branch and am finding problems
>>>>>>>> applying overlays.   Reverting this commit alleviates things.  The
>>>>>>>> errors I get are:
>>>>>>>> 
>>>>>>>> [   88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0
>>>>>>>> [   88.513447] OF: overlay: apply failed '/__symbols__'
>>>>>>>> [   88.518423] create_overlay: Failed to create overlay (err=-12)
>>>>>>> 
>>>>>>> Frank's series with overlay updates should fix this.
>>>>>> 
>>>>>> Yes, it does:
>>>>>> 
>>>>>>  [PATCH v3 11/12] of: overlay: remove a dependency on device node 
>>>>>> full_name
>>>>> 
>>>>> Thanks for the fast response.  I fetched the dt/next branch to test
>>>>> this but there are sufficient changes that Pantelis' "OF: DT-Overlay
>>>>> configfs interface (v7)" is broken now.  I've been adding that
>>>>> downstream since 4.4.  We're using it as an interface for applying
>>>>> overlays to program FPGAs.  If we fix it again, is there any chance
>>>>> that can go upstream now?
>>>> 
>>>> With a drive-by posting once every few years, no.
>>>> 
>>> 
>>> I take offense to that. There's nothing changed in the patch for years.
>>> Reposting the same patch without changes would achieve nothing.
>> 
>> Are you still expecting review comments on it or something?
>> Furthermore, If something is posted infrequently, then I

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

[Pantelis Antoniou]

Hi Frank,

> On Oct 19, 2017, at 00:46 , Frank Rowand  wrote:
> 
> On 10/18/17 11:30, Rob Herring wrote:
>> On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou
>>  wrote:
>>> On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote:
>>>> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull  wrote:
>>>>> On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand  
>>>>> wrote:
>>>>>> On 10/17/17 14:46, Rob Herring wrote:
>>>>>>> On Tue, Oct 17, 2017 at 4:32 PM, Alan Tull  wrote:
>>>>>>>> On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring  wrote:
>>>>>>>> 
>>>>>>>> Hi Rob,
>>>>>>>> 
>>>>>>>>> With dependencies on a statically allocated full path name converted 
>>>>>>>>> to
>>>>>>>>> use %pOF format specifier, we can store just the basename of node, and
>>>>>>>>> the unflattening of the FDT can be simplified.
>>>>>>>>> 
>>>>>>>>> This commit will affect the remaining users of full_name. After
>>>>>>>>> analyzing these users, the remaining cases should only change some 
>>>>>>>>> print
>>>>>>>>> messages. The main users of full_name are providing a name for struct
>>>>>>>>> resource. The resource names shouldn't be important other than 
>>>>>>>>> providing
>>>>>>>>> /proc/iomem names.
>>>>>>>>> 
>>>>>>>>> We no longer distinguish between pre and post 0x10 dtb formats as 
>>>>>>>>> either
>>>>>>>>> a full path or basename will work. However, less than 0x10 formats 
>>>>>>>>> have
>>>>>>>>> been broken since the conversion to use libfdt (and no one has cared).
>>>>>>>>> The conversion of the unflattening code to be non-recursive also broke
>>>>>>>>> pre 0x10 formats as the populate_node function would return 0 in that
>>>>>>>>> case.
>>>>>>>>> 
>>>>>>>>> Signed-off-by: Rob Herring 
>>>>>>>>> ---
>>>>>>>>> v2:
>>>>>>>>> - rebase to linux-next
>>>>>>>>> 
>>>>>>>>> drivers/of/fdt.c | 69 
>>>>>>>>> +---
>>>>>>>>> 1 file changed, 11 insertions(+), 58 deletions(-)
>>>>>>>> 
>>>>>>>> I've just updated to the latest next branch and am finding problems
>>>>>>>> applying overlays.   Reverting this commit alleviates things.  The
>>>>>>>> errors I get are:
>>>>>>>> 
>>>>>>>> [   88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0
>>>>>>>> [   88.513447] OF: overlay: apply failed '/__symbols__'
>>>>>>>> [   88.518423] create_overlay: Failed to create overlay (err=-12)
>>>>>>> 
>>>>>>> Frank's series with overlay updates should fix this.
>>>>>> 
>>>>>> Yes, it does:
>>>>>> 
>>>>>>  [PATCH v3 11/12] of: overlay: remove a dependency on device node 
>>>>>> full_name
>>>>> 
>>>>> Thanks for the fast response.  I fetched the dt/next branch to test
>>>>> this but there are sufficient changes that Pantelis' "OF: DT-Overlay
>>>>> configfs interface (v7)" is broken now.  I've been adding that
>>>>> downstream since 4.4.  We're using it as an interface for applying
>>>>> overlays to program FPGAs.  If we fix it again, is there any chance
>>>>> that can go upstream now?
>>>> 
>>>> With a drive-by posting once every few years, no.
>>>> 
>>> 
>>> I take offense to that. There's nothing changed in the patch for years.
>>> Reposting the same patch without changes would achieve nothing.
>> 
>> Are you still expecting review comments on it or something?
>> Furthermore, If something is posted infrequently, then I'm not
>> inclined to comment or care if the next posting is going to be after I
>> forget what I previously said (which is not very long).
>> 
>> I'm just saying,

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

[Pantelis Antoniou]

On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote:
> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull  wrote:
> > On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand  
> > wrote:
> >> On 10/17/17 14:46, Rob Herring wrote:
> >>> On Tue, Oct 17, 2017 at 4:32 PM, Alan Tull  wrote:
>  On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring  wrote:
> 
>  Hi Rob,
> 
> > With dependencies on a statically allocated full path name converted to
> > use %pOF format specifier, we can store just the basename of node, and
> > the unflattening of the FDT can be simplified.
> >
> > This commit will affect the remaining users of full_name. After
> > analyzing these users, the remaining cases should only change some print
> > messages. The main users of full_name are providing a name for struct
> > resource. The resource names shouldn't be important other than providing
> > /proc/iomem names.
> >
> > We no longer distinguish between pre and post 0x10 dtb formats as either
> > a full path or basename will work. However, less than 0x10 formats have
> > been broken since the conversion to use libfdt (and no one has cared).
> > The conversion of the unflattening code to be non-recursive also broke
> > pre 0x10 formats as the populate_node function would return 0 in that
> > case.
> >
> > Signed-off-by: Rob Herring 
> > ---
> > v2:
> > - rebase to linux-next
> >
> >  drivers/of/fdt.c | 69 
> > +---
> >  1 file changed, 11 insertions(+), 58 deletions(-)
> 
>  I've just updated to the latest next branch and am finding problems
>  applying overlays.   Reverting this commit alleviates things.  The
>  errors I get are:
> 
>  [   88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0
>  [   88.513447] OF: overlay: apply failed '/__symbols__'
>  [   88.518423] create_overlay: Failed to create overlay (err=-12)
> >>>
> >>> Frank's series with overlay updates should fix this.
> >>
> >> Yes, it does:
> >>
> >>   [PATCH v3 11/12] of: overlay: remove a dependency on device node 
> >> full_name
> >
> > Thanks for the fast response.  I fetched the dt/next branch to test
> > this but there are sufficient changes that Pantelis' "OF: DT-Overlay
> > configfs interface (v7)" is broken now.  I've been adding that
> > downstream since 4.4.  We're using it as an interface for applying
> > overlays to program FPGAs.  If we fix it again, is there any chance
> > that can go upstream now?
> 
> With a drive-by posting once every few years, no.
> 

I take offense to that. There's nothing changed in the patch for years.
Reposting the same patch without changes would achieve nothing.

> The issue remains that the kernel is not really setup to deal with any
> random property or node to be changed at any point in run-time. I
> think there needs to be some restrictions around what the overlays can
> touch. We can't have it be wide open and then lock things down later
> and break users. One example of what you could do is you can only add
> sub-trees to whitelisted nodes. That's probably acceptable for your
> usecase.
> 

Defining what can and what cannot be changed is not as trivial as a
list of white-listed nodes.

In some cases there is a whole node hierarchy being inserted (like in
a FPGA). In others, it's merely changing a status property to "okay" and
a few device parameters.

The real issue is that the kernel has no way to verify that a given
device tree, either at boot time or at overlay application time, is
correct.

When the tree is wrong at boot-time you'll hang (if you're lucky).
If the tree is wrong at run-time you'll get some into some unidentified
funky state.

Finally what is, and what is not 'correct' is not for the kernel to
decide arbitrarily, it's a matter of policy, different for each
use-case. 

> Rob

Regards

-- Pantelis

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

[Pantelis Antoniou]

On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote:
> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull  wrote:
> > On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand  
> > wrote:
> >> On 10/17/17 14:46, Rob Herring wrote:
> >>> On Tue, Oct 17, 2017 at 4:32 PM, Alan Tull  wrote:
>  On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring  wrote:
> 
>  Hi Rob,
> 
> > With dependencies on a statically allocated full path name converted to
> > use %pOF format specifier, we can store just the basename of node, and
> > the unflattening of the FDT can be simplified.
> >
> > This commit will affect the remaining users of full_name. After
> > analyzing these users, the remaining cases should only change some print
> > messages. The main users of full_name are providing a name for struct
> > resource. The resource names shouldn't be important other than providing
> > /proc/iomem names.
> >
> > We no longer distinguish between pre and post 0x10 dtb formats as either
> > a full path or basename will work. However, less than 0x10 formats have
> > been broken since the conversion to use libfdt (and no one has cared).
> > The conversion of the unflattening code to be non-recursive also broke
> > pre 0x10 formats as the populate_node function would return 0 in that
> > case.
> >
> > Signed-off-by: Rob Herring 
> > ---
> > v2:
> > - rebase to linux-next
> >
> >  drivers/of/fdt.c | 69 
> > +---
> >  1 file changed, 11 insertions(+), 58 deletions(-)
> 
>  I've just updated to the latest next branch and am finding problems
>  applying overlays.   Reverting this commit alleviates things.  The
>  errors I get are:
> 
>  [   88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0
>  [   88.513447] OF: overlay: apply failed '/__symbols__'
>  [   88.518423] create_overlay: Failed to create overlay (err=-12)
> >>>
> >>> Frank's series with overlay updates should fix this.
> >>
> >> Yes, it does:
> >>
> >>   [PATCH v3 11/12] of: overlay: remove a dependency on device node 
> >> full_name
> >
> > Thanks for the fast response.  I fetched the dt/next branch to test
> > this but there are sufficient changes that Pantelis' "OF: DT-Overlay
> > configfs interface (v7)" is broken now.  I've been adding that
> > downstream since 4.4.  We're using it as an interface for applying
> > overlays to program FPGAs.  If we fix it again, is there any chance
> > that can go upstream now?
> 
> With a drive-by posting once every few years, no.
> 

I take offense to that. There's nothing changed in the patch for years.
Reposting the same patch without changes would achieve nothing.

> The issue remains that the kernel is not really setup to deal with any
> random property or node to be changed at any point in run-time. I
> think there needs to be some restrictions around what the overlays can
> touch. We can't have it be wide open and then lock things down later
> and break users. One example of what you could do is you can only add
> sub-trees to whitelisted nodes. That's probably acceptable for your
> usecase.
> 

Defining what can and what cannot be changed is not as trivial as a
list of white-listed nodes.

In some cases there is a whole node hierarchy being inserted (like in
a FPGA). In others, it's merely changing a status property to "okay" and
a few device parameters.

The real issue is that the kernel has no way to verify that a given
device tree, either at boot time or at overlay application time, is
correct.

When the tree is wrong at boot-time you'll hang (if you're lucky).
If the tree is wrong at run-time you'll get some into some unidentified
funky state.

Finally what is, and what is not 'correct' is not for the kernel to
decide arbitrarily, it's a matter of policy, different for each
use-case. 

> Rob

Regards

-- Pantelis

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi David,

> On Oct 10, 2017, at 04:50 , David Gibson <da...@gibson.dropbear.id.au> wrote:
> 
> On Mon, Oct 09, 2017 at 06:07:28PM +0300, Pantelis Antoniou wrote:
>> Hi David,
>> 
>>> On Oct 9, 2017, at 03:00 , David Gibson <da...@gibson.dropbear.id.au> wrote:
>>> 
>>> On Sun, Oct 08, 2017 at 04:08:03PM -0700, Frank Rowand wrote:
>>>> On 10/07/17 03:23, Pantelis Antoniou wrote:
>>>>> Hi Rob,
>>>>> 
>>>>>> On Oct 6, 2017, at 16:55 , Rob Herring <robherri...@gmail.com> wrote:
>>>>>> 
>>>>>> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou
>>>>>> <pantelis.anton...@konsulko.com> wrote:
>>>>>>> Hi Rob,
>>>> 
>>>> < snip >
>>>> 
>>>>>>> eBPF is portable, can be serialized after compiling in the schema file
>>>>>>> and can be executed in the kernel.
>>>>>> 
>>>>>> Executing in the kernel is a non-goal for me.
>>>> 
>>>> Executing in the kernel is an anti-goal for me.
>>>> 
>>>> We are trying to reduce the device tree footprint inside the kernel,
>>>> not increase it.
>>>> 
>>>> 99.99% of the validation should be possible statically, in the compile
>>>> phase.
>>>> 
>>>> 
>>>>>>> By stripping out all documentation related properties and nodes keeping
>>>>>>> only the compiled filters you can generate a dtb blob that passed to
>>>>>>> kernel can be used for verification of all runtime changes in the
>>>>>>> kernel's live tree. eBPF is enforcing an execution model that is 'safe'
>>>>>>> so we can be sure that no foul play is possible.
>>>> 
>>>> Run time changes can be assumed correct (short of bugs in the overlay
>>>> application code), if the base tree is validated, the overlay is validated,
>>>> and the interface between the live tree and the overlay is a
>>>> connector.
>>> 
>>> In addition, no amount of schema validation can really protect the
>>> kernel from a bad DT.  Even if the schemas can 100% verify that the DT
>>> is "syntactically" correct, which is ambitious, it can't protect
>>> against a DT which is in the right form, but contains information that
>>> is simply wrong for the hardware in question.  That can stuff the
>>> kernel at least as easily as an incorrectly formatted DT.
>>> 
>> 
>> I disagree.
>> 
>> There are multiple levels of validation. For now we’re only talking about
>> binding validation. There can be SoC level validation, board level 
>> validation,
>> revision level validation and finally application specific validation.
>> 
>> Binding validation is making sure properties/nodes follow the binding 
>> document.
>> For instance that for a foo device there’s a mandatory interrupt property.
>> 
>> Simplified
>> 
>> interrupt = ;
>> 
>> Binding validation would ‘catch’ errors like assigning a string or not 
>> having the
>> interrupt property available.
>> 
>> SoC level validation would list the available interrupt number that a given
>> SoC would support for that device.
>> 
>> For example that interrupt can only take the values 10 or 99 in a given SoC.
>> 
>> Board level validation would narrow this down even further to a value of 10 
>> for
>> a given board model.
> 
>> Similar revision level validation would place further restriction on the 
>> allowed
>> configuration.
>> 
>> Finally application specific validation could place restriction based on the 
>> intended
>> application that piece of hardware is used for. For instance devices that 
>> should not
>> exceed a given power budget would have restrictions on the clock frequency 
>> of the processor
>> or bus frequencies etc.
> 
> This doesn't help.  In order to do this, the validator would need
> information that's essentially equivalent to the content of DT, at
> which point there's no point to the DT at all - and you're left with
> the problem of validating the information that the validator has.
> 

That would be the case if hardware IP only has a single way to be configured.

The industry standard nowadays is picking reusable IP blocks and integrating 
them
together in an SoC. The driver and the binding is common for every platform 
that uses
that block, but the allowed configuration varies according to what the hardware
people uses in a given instance.

> Fundamentally a validator that's useful *cannot* tell the difference
> between a correct tree and one which _could_ be correct for some
> theoretical hardware, but isn't for this particular hardware.
> 

That’s why there’s reason for a nested hierarchy of bindings IMO.

Completeness of validation schemes can be a differentiating factor when
choosing parts for hardware design. They would sure cut down development time.


> -- 
> 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

Regards

— Pantelis

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi David,

> On Oct 10, 2017, at 04:50 , David Gibson  wrote:
> 
> On Mon, Oct 09, 2017 at 06:07:28PM +0300, Pantelis Antoniou wrote:
>> Hi David,
>> 
>>> On Oct 9, 2017, at 03:00 , David Gibson  wrote:
>>> 
>>> On Sun, Oct 08, 2017 at 04:08:03PM -0700, Frank Rowand wrote:
>>>> On 10/07/17 03:23, Pantelis Antoniou wrote:
>>>>> Hi Rob,
>>>>> 
>>>>>> On Oct 6, 2017, at 16:55 , Rob Herring  wrote:
>>>>>> 
>>>>>> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou
>>>>>>  wrote:
>>>>>>> Hi Rob,
>>>> 
>>>> < snip >
>>>> 
>>>>>>> eBPF is portable, can be serialized after compiling in the schema file
>>>>>>> and can be executed in the kernel.
>>>>>> 
>>>>>> Executing in the kernel is a non-goal for me.
>>>> 
>>>> Executing in the kernel is an anti-goal for me.
>>>> 
>>>> We are trying to reduce the device tree footprint inside the kernel,
>>>> not increase it.
>>>> 
>>>> 99.99% of the validation should be possible statically, in the compile
>>>> phase.
>>>> 
>>>> 
>>>>>>> By stripping out all documentation related properties and nodes keeping
>>>>>>> only the compiled filters you can generate a dtb blob that passed to
>>>>>>> kernel can be used for verification of all runtime changes in the
>>>>>>> kernel's live tree. eBPF is enforcing an execution model that is 'safe'
>>>>>>> so we can be sure that no foul play is possible.
>>>> 
>>>> Run time changes can be assumed correct (short of bugs in the overlay
>>>> application code), if the base tree is validated, the overlay is validated,
>>>> and the interface between the live tree and the overlay is a
>>>> connector.
>>> 
>>> In addition, no amount of schema validation can really protect the
>>> kernel from a bad DT.  Even if the schemas can 100% verify that the DT
>>> is "syntactically" correct, which is ambitious, it can't protect
>>> against a DT which is in the right form, but contains information that
>>> is simply wrong for the hardware in question.  That can stuff the
>>> kernel at least as easily as an incorrectly formatted DT.
>>> 
>> 
>> I disagree.
>> 
>> There are multiple levels of validation. For now we’re only talking about
>> binding validation. There can be SoC level validation, board level 
>> validation,
>> revision level validation and finally application specific validation.
>> 
>> Binding validation is making sure properties/nodes follow the binding 
>> document.
>> For instance that for a foo device there’s a mandatory interrupt property.
>> 
>> Simplified
>> 
>> interrupt = ;
>> 
>> Binding validation would ‘catch’ errors like assigning a string or not 
>> having the
>> interrupt property available.
>> 
>> SoC level validation would list the available interrupt number that a given
>> SoC would support for that device.
>> 
>> For example that interrupt can only take the values 10 or 99 in a given SoC.
>> 
>> Board level validation would narrow this down even further to a value of 10 
>> for
>> a given board model.
> 
>> Similar revision level validation would place further restriction on the 
>> allowed
>> configuration.
>> 
>> Finally application specific validation could place restriction based on the 
>> intended
>> application that piece of hardware is used for. For instance devices that 
>> should not
>> exceed a given power budget would have restrictions on the clock frequency 
>> of the processor
>> or bus frequencies etc.
> 
> This doesn't help.  In order to do this, the validator would need
> information that's essentially equivalent to the content of DT, at
> which point there's no point to the DT at all - and you're left with
> the problem of validating the information that the validator has.
> 

That would be the case if hardware IP only has a single way to be configured.

The industry standard nowadays is picking reusable IP blocks and integrating 
them
together in an SoC. The driver and the binding is common for every platform 
that uses
that block, but the allowed configuration varies according to what the hardware
people uses in a given instance.

> Fundamentally a validator that's useful *cannot* tell the difference
> between a correct tree and one which _could_ be correct for some
> theoretical hardware, but isn't for this particular hardware.
> 

That’s why there’s reason for a nested hierarchy of bindings IMO.

Completeness of validation schemes can be a differentiating factor when
choosing parts for hardware design. They would sure cut down development time.


> -- 
> 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

Regards

— Pantelis

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi David,

> On Oct 9, 2017, at 03:00 , David Gibson <da...@gibson.dropbear.id.au> wrote:
> 
> On Sun, Oct 08, 2017 at 04:08:03PM -0700, Frank Rowand wrote:
>> On 10/07/17 03:23, Pantelis Antoniou wrote:
>>> Hi Rob,
>>> 
>>>> On Oct 6, 2017, at 16:55 , Rob Herring <robherri...@gmail.com> wrote:
>>>> 
>>>> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou
>>>> <pantelis.anton...@konsulko.com> wrote:
>>>>> Hi Rob,
>> 
>> < snip >
>> 
>>>>> eBPF is portable, can be serialized after compiling in the schema file
>>>>> and can be executed in the kernel.
>>>> 
>>>> Executing in the kernel is a non-goal for me.
>> 
>> Executing in the kernel is an anti-goal for me.
>> 
>> We are trying to reduce the device tree footprint inside the kernel,
>> not increase it.
>> 
>> 99.99% of the validation should be possible statically, in the compile
>> phase.
>> 
>> 
>>>>> By stripping out all documentation related properties and nodes keeping
>>>>> only the compiled filters you can generate a dtb blob that passed to
>>>>> kernel can be used for verification of all runtime changes in the
>>>>> kernel's live tree. eBPF is enforcing an execution model that is 'safe'
>>>>> so we can be sure that no foul play is possible.
>> 
>> Run time changes can be assumed correct (short of bugs in the overlay
>> application code), if the base tree is validated, the overlay is validated,
>> and the interface between the live tree and the overlay is a
>> connector.
> 
> In addition, no amount of schema validation can really protect the
> kernel from a bad DT.  Even if the schemas can 100% verify that the DT
> is "syntactically" correct, which is ambitious, it can't protect
> against a DT which is in the right form, but contains information that
> is simply wrong for the hardware in question.  That can stuff the
> kernel at least as easily as an incorrectly formatted DT.
> 

I disagree.

There are multiple levels of validation. For now we’re only talking about
binding validation. There can be SoC level validation, board level validation,
revision level validation and finally application specific validation.

Binding validation is making sure properties/nodes follow the binding document.
For instance that for a foo device there’s a mandatory interrupt property.

Simplified

interrupt = ;

Binding validation would ‘catch’ errors like assigning a string or not having 
the
interrupt property available.

SoC level validation would list the available interrupt number that a given
SoC would support for that device.

For example that interrupt can only take the values 10 or 99 in a given SoC.

Board level validation would narrow this down even further to a value of 10 for
a given board model.

Similar revision level validation would place further restriction on the allowed
configuration.

Finally application specific validation could place restriction based on the 
intended
application that piece of hardware is used for. For instance devices that 
should not
exceed a given power budget would have restrictions on the clock frequency of 
the processor
or bus frequencies etc.

> -- 
> 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

Regards

— Pantelis

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi David,

> On Oct 9, 2017, at 03:00 , David Gibson  wrote:
> 
> On Sun, Oct 08, 2017 at 04:08:03PM -0700, Frank Rowand wrote:
>> On 10/07/17 03:23, Pantelis Antoniou wrote:
>>> Hi Rob,
>>> 
>>>> On Oct 6, 2017, at 16:55 , Rob Herring  wrote:
>>>> 
>>>> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou
>>>>  wrote:
>>>>> Hi Rob,
>> 
>> < snip >
>> 
>>>>> eBPF is portable, can be serialized after compiling in the schema file
>>>>> and can be executed in the kernel.
>>>> 
>>>> Executing in the kernel is a non-goal for me.
>> 
>> Executing in the kernel is an anti-goal for me.
>> 
>> We are trying to reduce the device tree footprint inside the kernel,
>> not increase it.
>> 
>> 99.99% of the validation should be possible statically, in the compile
>> phase.
>> 
>> 
>>>>> By stripping out all documentation related properties and nodes keeping
>>>>> only the compiled filters you can generate a dtb blob that passed to
>>>>> kernel can be used for verification of all runtime changes in the
>>>>> kernel's live tree. eBPF is enforcing an execution model that is 'safe'
>>>>> so we can be sure that no foul play is possible.
>> 
>> Run time changes can be assumed correct (short of bugs in the overlay
>> application code), if the base tree is validated, the overlay is validated,
>> and the interface between the live tree and the overlay is a
>> connector.
> 
> In addition, no amount of schema validation can really protect the
> kernel from a bad DT.  Even if the schemas can 100% verify that the DT
> is "syntactically" correct, which is ambitious, it can't protect
> against a DT which is in the right form, but contains information that
> is simply wrong for the hardware in question.  That can stuff the
> kernel at least as easily as an incorrectly formatted DT.
> 

I disagree.

There are multiple levels of validation. For now we’re only talking about
binding validation. There can be SoC level validation, board level validation,
revision level validation and finally application specific validation.

Binding validation is making sure properties/nodes follow the binding document.
For instance that for a foo device there’s a mandatory interrupt property.

Simplified

interrupt = ;

Binding validation would ‘catch’ errors like assigning a string or not having 
the
interrupt property available.

SoC level validation would list the available interrupt number that a given
SoC would support for that device.

For example that interrupt can only take the values 10 or 99 in a given SoC.

Board level validation would narrow this down even further to a value of 10 for
a given board model.

Similar revision level validation would place further restriction on the allowed
configuration.

Finally application specific validation could place restriction based on the 
intended
application that piece of hardware is used for. For instance devices that 
should not
exceed a given power budget would have restrictions on the clock frequency of 
the processor
or bus frequencies etc.

> -- 
> 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

Regards

— Pantelis

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Frank,

> On Oct 9, 2017, at 02:08 , Frank Rowand <frowand.l...@gmail.com> wrote:
> 
> On 10/07/17 03:23, Pantelis Antoniou wrote:
>> Hi Rob,
>> 
>>> On Oct 6, 2017, at 16:55 , Rob Herring <robherri...@gmail.com> wrote:
>>> 
>>> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou
>>> <pantelis.anton...@konsulko.com> wrote:
>>>> Hi Rob,
> 
> < snip >
> 
>>>> eBPF is portable, can be serialized after compiling in the schema file
>>>> and can be executed in the kernel.
>>> 
>>> Executing in the kernel is a non-goal for me.
> 
> Executing in the kernel is an anti-goal for me.
> 
> We are trying to reduce the device tree footprint inside the kernel,
> not increase it.
> 
> 99.99% of the validation should be possible statically, in the compile
> phase.
> 

That’s not possible when you dynamically alter the tree at runtime.

> 
>>>> By stripping out all documentation related properties and nodes keeping
>>>> only the compiled filters you can generate a dtb blob that passed to
>>>> kernel can be used for verification of all runtime changes in the
>>>> kernel's live tree. eBPF is enforcing an execution model that is 'safe'
>>>> so we can be sure that no foul play is possible.
> 
> Run time changes can be assumed correct (short of bugs in the overlay
> application code), if the base tree is validated, the overlay is validated,
> and the interface between the live tree and the overlay is a connector.
> 

You can validate the base tree statically but not the overlays.

In fact a large percentage of overlay usage simply modifies a status property
to turn on or off a device. There is nothing to validate in such case.

The portable connector is still a long ways off and I haven’t seen anything that
could handle something trickier that a few GPIOs and I2C or SPI busses.

My goal is something that works covering all the cases without any surprising
gotchas.

> 
>>> Humm, if you wanted to ensure dtb's are safe, I'd think that we just
>>> sign them like you would for the kernel or modules.
>>> 
>> 
>> That’s a problem when deploying; the runtime validation is for making sure
>> developers don’t get bogged down chasing problems when working on their
>> own platforms/drivers.
>> 
>> We have absolutely zero checks for stopping badly configured DT blobs
>> hanging the kernel. With runtime validation a bug that might take a few
>> days to figure out can be cut down to a few minutes.
> 
> Same reply as above.
> 
> 
>>>> That means that you can a) run it at boot-time, verifying the dtb blob
>>>> passed by the bootloader for errors (potentially disabling devices
>>>> that their nodes fail) and b) run it when applying overlays to reject
>>>> any that result in an invalid tree.
>>> 
>>> Let's get verification at build time working first, then we can worry
>>> about something like this.
> 
> < snip >
> 

Right, let’s get build verification working first.

> -Frank

Regards

— Pantelis

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Frank,

> On Oct 9, 2017, at 02:08 , Frank Rowand  wrote:
> 
> On 10/07/17 03:23, Pantelis Antoniou wrote:
>> Hi Rob,
>> 
>>> On Oct 6, 2017, at 16:55 , Rob Herring  wrote:
>>> 
>>> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou
>>>  wrote:
>>>> Hi Rob,
> 
> < snip >
> 
>>>> eBPF is portable, can be serialized after compiling in the schema file
>>>> and can be executed in the kernel.
>>> 
>>> Executing in the kernel is a non-goal for me.
> 
> Executing in the kernel is an anti-goal for me.
> 
> We are trying to reduce the device tree footprint inside the kernel,
> not increase it.
> 
> 99.99% of the validation should be possible statically, in the compile
> phase.
> 

That’s not possible when you dynamically alter the tree at runtime.

> 
>>>> By stripping out all documentation related properties and nodes keeping
>>>> only the compiled filters you can generate a dtb blob that passed to
>>>> kernel can be used for verification of all runtime changes in the
>>>> kernel's live tree. eBPF is enforcing an execution model that is 'safe'
>>>> so we can be sure that no foul play is possible.
> 
> Run time changes can be assumed correct (short of bugs in the overlay
> application code), if the base tree is validated, the overlay is validated,
> and the interface between the live tree and the overlay is a connector.
> 

You can validate the base tree statically but not the overlays.

In fact a large percentage of overlay usage simply modifies a status property
to turn on or off a device. There is nothing to validate in such case.

The portable connector is still a long ways off and I haven’t seen anything that
could handle something trickier that a few GPIOs and I2C or SPI busses.

My goal is something that works covering all the cases without any surprising
gotchas.

> 
>>> Humm, if you wanted to ensure dtb's are safe, I'd think that we just
>>> sign them like you would for the kernel or modules.
>>> 
>> 
>> That’s a problem when deploying; the runtime validation is for making sure
>> developers don’t get bogged down chasing problems when working on their
>> own platforms/drivers.
>> 
>> We have absolutely zero checks for stopping badly configured DT blobs
>> hanging the kernel. With runtime validation a bug that might take a few
>> days to figure out can be cut down to a few minutes.
> 
> Same reply as above.
> 
> 
>>>> That means that you can a) run it at boot-time, verifying the dtb blob
>>>> passed by the bootloader for errors (potentially disabling devices
>>>> that their nodes fail) and b) run it when applying overlays to reject
>>>> any that result in an invalid tree.
>>> 
>>> Let's get verification at build time working first, then we can worry
>>> about something like this.
> 
> < snip >
> 

Right, let’s get build verification working first.

> -Frank

Regards

— Pantelis

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Rob,

> On Oct 6, 2017, at 16:55 , Rob Herring <robherri...@gmail.com> wrote:
> 
> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
>> Hi Rob,
>> 
>> On Tue, 2017-10-03 at 12:13 -0500, Rob Herring wrote:
>>> On Tue, Oct 3, 2017 at 9:13 AM, Pantelis Antoniou
>>> <pantelis.anton...@konsulko.com> wrote:
>>>> Hi Rob,
>>>> 
>>>> On Tue, 2017-10-03 at 08:18 -0500, Rob Herring wrote:
>>>>> On Mon, Oct 2, 2017 at 2:46 PM, Pantelis Antoniou
>>>>> <pantelis.anton...@konsulko.com> wrote:
>>>>>> Hi Rob,
>>>>>> 
>>>>>> On Sun, 2017-10-01 at 17:00 -0500, Rob Herring wrote:
>>>>>>> On Thu, Sep 28, 2017 at 2:58 PM, Pantelis Antoniou
>>>>>>> <pantelis.anton...@konsulko.com> wrote:
>>>>>>>> Hello again,
>>>>>>>> 
>>>>>>>> Significant progress has been made on yamldt and is now capable of
>>>>>>>> not only generating yaml from DTS source but also compiling DTS sources
>>>>>>>> and being almost fully compatible with DTC.
>>>>>>> 
>>>>>>> Can you quantify "almost"?
>>>>>>> 
>>>>>>>> Compiling the kernel's DTBs using yamldt is as simple as using a
>>>>>>>> DTC=yamldt.
>>>>>>> 
>>>>>>> Good.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Error reporting is accurate and validation against a YAML based schema
>>>>>>>> works as well. In a short while I will begin posting patches with
>>>>>>>> fixes on bindings and DTS files in the kernel.
>>>>>>> 
>>>>>>> What I would like to see is the schema format posted for review.
>>>>>>> 
>>>>>> 
>>>>>> I'm including the skeleton.yaml binding which is the template for
>>>>>> the bindings and a board-example.yaml binding for a top level binding.
>>>>>> 
>>>>>>> I would also like to see the bindings for top-level compatible strings
>>>>>>> (aka boards) as an example. That's something that's simple enough that
>>>>>>> I'd think we could agree on a format and start moving towards defining
>>>>>>> board bindings that way.
>>>>>>> 
>>>>>> 
>>>>>> Note there is some line wrapping I'm including a link
>>>>>> to the github repo of the files:
>>>>>> 
>>>>>> 
>>>>>> The skeleton.yaml
>>>>>> 
>>>>>> https://raw.githubusercontent.com/pantoniou/yamldt/master/validate/bindings/skeleton.yaml
>>>>>> 
>>>>>> %YAML 1.1
>>>>>> ---
>>>>>> # The name of the binding is first
>>>>>> # The anchor is put there for use by others
>>>>>> skeleton: 
>>>>> 
>>>>> This and "id" seem redundant.
>>>>> 
>>>> 
>>>> Indeed.
>>> 
>>> One other thing, "skeleton" is a bit weird as a key. It can't be
>>> validated. All the other keys are standard words. I could write
>>> "skeloton" by mistake and I guess I'd only find the mistake when
>>> something inherits it. That's somewhat true with id, but we can at
>>> least check "id" is present and that it's value is unique among all
>>> other id values.
>>> 
>> 
>> We can keep id and check that it matches the name of the enclosing node.
>> That way you can be sure that there's no error.
>> 
>> But it's a bit weird cause this is similar to declaring a function name
>> with a typo. You won't find out until you use it.
>> 
>>>> 
>>>>>>  version: 1
>>>>>> 
>>>>>>  id: skel-device
>>>>>> 
>>>>>>  title: >
>>>>>>Skeleton Device
>>>>>> 
>>>>>>  maintainer:
>>>>>>name: Skeleton Person <s...@kernel.org>
>>>>>> 
>>>>>>  description: >
>>>>>>The Skeleton Device binding represents the SK11 device produced by
>>>>>>the Skeleton Corporation. The binding can also support compat

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Rob,

> On Oct 6, 2017, at 16:55 , Rob Herring  wrote:
> 
> On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou
>  wrote:
>> Hi Rob,
>> 
>> On Tue, 2017-10-03 at 12:13 -0500, Rob Herring wrote:
>>> On Tue, Oct 3, 2017 at 9:13 AM, Pantelis Antoniou
>>>  wrote:
>>>> Hi Rob,
>>>> 
>>>> On Tue, 2017-10-03 at 08:18 -0500, Rob Herring wrote:
>>>>> On Mon, Oct 2, 2017 at 2:46 PM, Pantelis Antoniou
>>>>>  wrote:
>>>>>> Hi Rob,
>>>>>> 
>>>>>> On Sun, 2017-10-01 at 17:00 -0500, Rob Herring wrote:
>>>>>>> On Thu, Sep 28, 2017 at 2:58 PM, Pantelis Antoniou
>>>>>>>  wrote:
>>>>>>>> Hello again,
>>>>>>>> 
>>>>>>>> Significant progress has been made on yamldt and is now capable of
>>>>>>>> not only generating yaml from DTS source but also compiling DTS sources
>>>>>>>> and being almost fully compatible with DTC.
>>>>>>> 
>>>>>>> Can you quantify "almost"?
>>>>>>> 
>>>>>>>> Compiling the kernel's DTBs using yamldt is as simple as using a
>>>>>>>> DTC=yamldt.
>>>>>>> 
>>>>>>> Good.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Error reporting is accurate and validation against a YAML based schema
>>>>>>>> works as well. In a short while I will begin posting patches with
>>>>>>>> fixes on bindings and DTS files in the kernel.
>>>>>>> 
>>>>>>> What I would like to see is the schema format posted for review.
>>>>>>> 
>>>>>> 
>>>>>> I'm including the skeleton.yaml binding which is the template for
>>>>>> the bindings and a board-example.yaml binding for a top level binding.
>>>>>> 
>>>>>>> I would also like to see the bindings for top-level compatible strings
>>>>>>> (aka boards) as an example. That's something that's simple enough that
>>>>>>> I'd think we could agree on a format and start moving towards defining
>>>>>>> board bindings that way.
>>>>>>> 
>>>>>> 
>>>>>> Note there is some line wrapping I'm including a link
>>>>>> to the github repo of the files:
>>>>>> 
>>>>>> 
>>>>>> The skeleton.yaml
>>>>>> 
>>>>>> https://raw.githubusercontent.com/pantoniou/yamldt/master/validate/bindings/skeleton.yaml
>>>>>> 
>>>>>> %YAML 1.1
>>>>>> ---
>>>>>> # The name of the binding is first
>>>>>> # The anchor is put there for use by others
>>>>>> skeleton: 
>>>>> 
>>>>> This and "id" seem redundant.
>>>>> 
>>>> 
>>>> Indeed.
>>> 
>>> One other thing, "skeleton" is a bit weird as a key. It can't be
>>> validated. All the other keys are standard words. I could write
>>> "skeloton" by mistake and I guess I'd only find the mistake when
>>> something inherits it. That's somewhat true with id, but we can at
>>> least check "id" is present and that it's value is unique among all
>>> other id values.
>>> 
>> 
>> We can keep id and check that it matches the name of the enclosing node.
>> That way you can be sure that there's no error.
>> 
>> But it's a bit weird cause this is similar to declaring a function name
>> with a typo. You won't find out until you use it.
>> 
>>>> 
>>>>>>  version: 1
>>>>>> 
>>>>>>  id: skel-device
>>>>>> 
>>>>>>  title: >
>>>>>>Skeleton Device
>>>>>> 
>>>>>>  maintainer:
>>>>>>name: Skeleton Person 
>>>>>> 
>>>>>>  description: >
>>>>>>The Skeleton Device binding represents the SK11 device produced by
>>>>>>the Skeleton Corporation. The binding can also support compatible
>>>>>>clones made by second source vendors.
>>>>>> 
>>>>>>  # The class is an optional property that declares this
>>>>>

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Rob,

On Tue, 2017-10-03 at 12:13 -0500, Rob Herring wrote:
> On Tue, Oct 3, 2017 at 9:13 AM, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
> > Hi Rob,
> >
> > On Tue, 2017-10-03 at 08:18 -0500, Rob Herring wrote:
> >> On Mon, Oct 2, 2017 at 2:46 PM, Pantelis Antoniou
> >> <pantelis.anton...@konsulko.com> wrote:
> >> > Hi Rob,
> >> >
> >> > On Sun, 2017-10-01 at 17:00 -0500, Rob Herring wrote:
> >> >> On Thu, Sep 28, 2017 at 2:58 PM, Pantelis Antoniou
> >> >> <pantelis.anton...@konsulko.com> wrote:
> >> >> > Hello again,
> >> >> >
> >> >> > Significant progress has been made on yamldt and is now capable of
> >> >> > not only generating yaml from DTS source but also compiling DTS 
> >> >> > sources
> >> >> > and being almost fully compatible with DTC.
> >> >>
> >> >> Can you quantify "almost"?
> >> >>
> >> >> > Compiling the kernel's DTBs using yamldt is as simple as using a
> >> >> > DTC=yamldt.
> >> >>
> >> >> Good.
> >> >>
> >> >> >
> >> >> > Error reporting is accurate and validation against a YAML based schema
> >> >> > works as well. In a short while I will begin posting patches with
> >> >> > fixes on bindings and DTS files in the kernel.
> >> >>
> >> >> What I would like to see is the schema format posted for review.
> >> >>
> >> >
> >> > I'm including the skeleton.yaml binding which is the template for
> >> > the bindings and a board-example.yaml binding for a top level binding.
> >> >
> >> >> I would also like to see the bindings for top-level compatible strings
> >> >> (aka boards) as an example. That's something that's simple enough that
> >> >> I'd think we could agree on a format and start moving towards defining
> >> >> board bindings that way.
> >> >>
> >> >
> >> > Note there is some line wrapping I'm including a link
> >> > to the github repo of the files:
> >> >
> >> >
> >> > The skeleton.yaml
> >> >
> >> > https://raw.githubusercontent.com/pantoniou/yamldt/master/validate/bindings/skeleton.yaml
> >> >
> >> > %YAML 1.1
> >> > ---
> >> > # The name of the binding is first
> >> > # The anchor is put there for use by others
> >> > skeleton: 
> >>
> >> This and "id" seem redundant.
> >>
> >
> > Indeed.
> 
> One other thing, "skeleton" is a bit weird as a key. It can't be
> validated. All the other keys are standard words. I could write
> "skeloton" by mistake and I guess I'd only find the mistake when
> something inherits it. That's somewhat true with id, but we can at
> least check "id" is present and that it's value is unique among all
> other id values.
> 

We can keep id and check that it matches the name of the enclosing node.
That way you can be sure that there's no error.

But it's a bit weird cause this is similar to declaring a function name
with a typo. You won't find out until you use it.

> >
> >> >   version: 1
> >> >
> >> >   id: skel-device
> >> >
> >> >   title: >
> >> > Skeleton Device
> >> >
> >> >   maintainer:
> >> > name: Skeleton Person <s...@kernel.org>
> >> >
> >> >   description: >
> >> > The Skeleton Device binding represents the SK11 device produced by
> >> > the Skeleton Corporation. The binding can also support compatible
> >> > clones made by second source vendors.
> >> >
> >> >   # The class is an optional property that declares this
> >> >   # binding as part of a larger set
> >> >   # Multiple definitions are possible
> >> >   class: [ device, spi-device ]
> >> >
> >> >   # This binding inherits property characteristics from the generic
> >> >   # spi-slave binding
> >> >   # Note that the notation is standard yaml reference
> >> >   inherits: *spi-slave
> >> >
> >> >   # virtual bindings do not generate checkers
> >> >   virtual: true
> >>
> >> virtual is an overloaded term.
&

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Rob,

On Tue, 2017-10-03 at 12:13 -0500, Rob Herring wrote:
> On Tue, Oct 3, 2017 at 9:13 AM, Pantelis Antoniou
>  wrote:
> > Hi Rob,
> >
> > On Tue, 2017-10-03 at 08:18 -0500, Rob Herring wrote:
> >> On Mon, Oct 2, 2017 at 2:46 PM, Pantelis Antoniou
> >>  wrote:
> >> > Hi Rob,
> >> >
> >> > On Sun, 2017-10-01 at 17:00 -0500, Rob Herring wrote:
> >> >> On Thu, Sep 28, 2017 at 2:58 PM, Pantelis Antoniou
> >> >>  wrote:
> >> >> > Hello again,
> >> >> >
> >> >> > Significant progress has been made on yamldt and is now capable of
> >> >> > not only generating yaml from DTS source but also compiling DTS 
> >> >> > sources
> >> >> > and being almost fully compatible with DTC.
> >> >>
> >> >> Can you quantify "almost"?
> >> >>
> >> >> > Compiling the kernel's DTBs using yamldt is as simple as using a
> >> >> > DTC=yamldt.
> >> >>
> >> >> Good.
> >> >>
> >> >> >
> >> >> > Error reporting is accurate and validation against a YAML based schema
> >> >> > works as well. In a short while I will begin posting patches with
> >> >> > fixes on bindings and DTS files in the kernel.
> >> >>
> >> >> What I would like to see is the schema format posted for review.
> >> >>
> >> >
> >> > I'm including the skeleton.yaml binding which is the template for
> >> > the bindings and a board-example.yaml binding for a top level binding.
> >> >
> >> >> I would also like to see the bindings for top-level compatible strings
> >> >> (aka boards) as an example. That's something that's simple enough that
> >> >> I'd think we could agree on a format and start moving towards defining
> >> >> board bindings that way.
> >> >>
> >> >
> >> > Note there is some line wrapping I'm including a link
> >> > to the github repo of the files:
> >> >
> >> >
> >> > The skeleton.yaml
> >> >
> >> > https://raw.githubusercontent.com/pantoniou/yamldt/master/validate/bindings/skeleton.yaml
> >> >
> >> > %YAML 1.1
> >> > ---
> >> > # The name of the binding is first
> >> > # The anchor is put there for use by others
> >> > skeleton: 
> >>
> >> This and "id" seem redundant.
> >>
> >
> > Indeed.
> 
> One other thing, "skeleton" is a bit weird as a key. It can't be
> validated. All the other keys are standard words. I could write
> "skeloton" by mistake and I guess I'd only find the mistake when
> something inherits it. That's somewhat true with id, but we can at
> least check "id" is present and that it's value is unique among all
> other id values.
> 

We can keep id and check that it matches the name of the enclosing node.
That way you can be sure that there's no error.

But it's a bit weird cause this is similar to declaring a function name
with a typo. You won't find out until you use it.

> >
> >> >   version: 1
> >> >
> >> >   id: skel-device
> >> >
> >> >   title: >
> >> > Skeleton Device
> >> >
> >> >   maintainer:
> >> > name: Skeleton Person 
> >> >
> >> >   description: >
> >> > The Skeleton Device binding represents the SK11 device produced by
> >> > the Skeleton Corporation. The binding can also support compatible
> >> > clones made by second source vendors.
> >> >
> >> >   # The class is an optional property that declares this
> >> >   # binding as part of a larger set
> >> >   # Multiple definitions are possible
> >> >   class: [ device, spi-device ]
> >> >
> >> >   # This binding inherits property characteristics from the generic
> >> >   # spi-slave binding
> >> >   # Note that the notation is standard yaml reference
> >> >   inherits: *spi-slave
> >> >
> >> >   # virtual bindings do not generate checkers
> >> >   virtual: true
> >>
> >> virtual is an overloaded term.
> >>
> >
> > OK, what term should I use that this binding should not be instantiated
> > as a checker, only be used by other bindings

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Rob,

On Tue, 2017-10-03 at 08:18 -0500, Rob Herring wrote:
> On Mon, Oct 2, 2017 at 2:46 PM, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
> > Hi Rob,
> >
> > On Sun, 2017-10-01 at 17:00 -0500, Rob Herring wrote:
> >> On Thu, Sep 28, 2017 at 2:58 PM, Pantelis Antoniou
> >> <pantelis.anton...@konsulko.com> wrote:
> >> > Hello again,
> >> >
> >> > Significant progress has been made on yamldt and is now capable of
> >> > not only generating yaml from DTS source but also compiling DTS sources
> >> > and being almost fully compatible with DTC.
> >>
> >> Can you quantify "almost"?
> >>
> >> > Compiling the kernel's DTBs using yamldt is as simple as using a
> >> > DTC=yamldt.
> >>
> >> Good.
> >>
> >> >
> >> > Error reporting is accurate and validation against a YAML based schema
> >> > works as well. In a short while I will begin posting patches with
> >> > fixes on bindings and DTS files in the kernel.
> >>
> >> What I would like to see is the schema format posted for review.
> >>
> >
> > I'm including the skeleton.yaml binding which is the template for
> > the bindings and a board-example.yaml binding for a top level binding.
> >
> >> I would also like to see the bindings for top-level compatible strings
> >> (aka boards) as an example. That's something that's simple enough that
> >> I'd think we could agree on a format and start moving towards defining
> >> board bindings that way.
> >>
> >
> > Note there is some line wrapping I'm including a link
> > to the github repo of the files:
> >
> >
> > The skeleton.yaml
> >
> > https://raw.githubusercontent.com/pantoniou/yamldt/master/validate/bindings/skeleton.yaml
> >
> > %YAML 1.1
> > ---
> > # The name of the binding is first
> > # The anchor is put there for use by others
> > skeleton: 
> 
> This and "id" seem redundant.
> 

Indeed.

> >   version: 1
> >
> >   id: skel-device
> >
> >   title: >
> > Skeleton Device
> >
> >   maintainer:
> > name: Skeleton Person <s...@kernel.org>
> >
> >   description: >
> > The Skeleton Device binding represents the SK11 device produced by
> > the Skeleton Corporation. The binding can also support compatible
> > clones made by second source vendors.
> >
> >   # The class is an optional property that declares this
> >   # binding as part of a larger set
> >   # Multiple definitions are possible
> >   class: [ device, spi-device ]
> >
> >   # This binding inherits property characteristics from the generic
> >   # spi-slave binding
> >   # Note that the notation is standard yaml reference
> >   inherits: *spi-slave
> >
> >   # virtual bindings do not generate checkers
> >   virtual: true
> 
> virtual is an overloaded term.
> 

OK, what term should I use that this binding should not be instantiated
as a checker, only be used by other bindings when inherited?

> >
> >   # each property is defined by each name
> >   properties:
> >
> > # The compatible property is a reserved name. The type is always
> > "string"
> > # and should not be repeated device binding.
> > compatible:
> >   category: required# required property
> >   type: strseq  # is a sequence of strings
> >
> >   description: >
> > FX11 is a clone of the original SK11 device
> >
> >   # v is always the name of the value of the property
> >   # np is passed to the checker and is the current
> >   # node pointer. We can access properties and call
> >   # methods that operate on them.
> >   # There can be multiple constraints, just put them
> >   # into a sequence.
> >   # Note that the BASE("skel,sk11") form from the previous
> >   # binding will have to be reworked.
> >   constraint: |
> > anystreq(v, "skel,sk11") ||
> > anystreq(v, "faux,fx11")
> 
> Constraints and logic ops were certainly not decided in the last
> attempt and I think will be the hardest part to define. I see you are
> using eBPF in the checker. Is that where anystreq comes from?
> 

Yes. The ebpf environment declares a number of methods that are executed
outside the ebpf sandbox. Check out

https://raw.githubusercontent.com/pantoniou/yaml

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Rob,

On Tue, 2017-10-03 at 08:18 -0500, Rob Herring wrote:
> On Mon, Oct 2, 2017 at 2:46 PM, Pantelis Antoniou
>  wrote:
> > Hi Rob,
> >
> > On Sun, 2017-10-01 at 17:00 -0500, Rob Herring wrote:
> >> On Thu, Sep 28, 2017 at 2:58 PM, Pantelis Antoniou
> >>  wrote:
> >> > Hello again,
> >> >
> >> > Significant progress has been made on yamldt and is now capable of
> >> > not only generating yaml from DTS source but also compiling DTS sources
> >> > and being almost fully compatible with DTC.
> >>
> >> Can you quantify "almost"?
> >>
> >> > Compiling the kernel's DTBs using yamldt is as simple as using a
> >> > DTC=yamldt.
> >>
> >> Good.
> >>
> >> >
> >> > Error reporting is accurate and validation against a YAML based schema
> >> > works as well. In a short while I will begin posting patches with
> >> > fixes on bindings and DTS files in the kernel.
> >>
> >> What I would like to see is the schema format posted for review.
> >>
> >
> > I'm including the skeleton.yaml binding which is the template for
> > the bindings and a board-example.yaml binding for a top level binding.
> >
> >> I would also like to see the bindings for top-level compatible strings
> >> (aka boards) as an example. That's something that's simple enough that
> >> I'd think we could agree on a format and start moving towards defining
> >> board bindings that way.
> >>
> >
> > Note there is some line wrapping I'm including a link
> > to the github repo of the files:
> >
> >
> > The skeleton.yaml
> >
> > https://raw.githubusercontent.com/pantoniou/yamldt/master/validate/bindings/skeleton.yaml
> >
> > %YAML 1.1
> > ---
> > # The name of the binding is first
> > # The anchor is put there for use by others
> > skeleton: 
> 
> This and "id" seem redundant.
> 

Indeed.

> >   version: 1
> >
> >   id: skel-device
> >
> >   title: >
> > Skeleton Device
> >
> >   maintainer:
> > name: Skeleton Person 
> >
> >   description: >
> > The Skeleton Device binding represents the SK11 device produced by
> > the Skeleton Corporation. The binding can also support compatible
> > clones made by second source vendors.
> >
> >   # The class is an optional property that declares this
> >   # binding as part of a larger set
> >   # Multiple definitions are possible
> >   class: [ device, spi-device ]
> >
> >   # This binding inherits property characteristics from the generic
> >   # spi-slave binding
> >   # Note that the notation is standard yaml reference
> >   inherits: *spi-slave
> >
> >   # virtual bindings do not generate checkers
> >   virtual: true
> 
> virtual is an overloaded term.
> 

OK, what term should I use that this binding should not be instantiated
as a checker, only be used by other bindings when inherited?

> >
> >   # each property is defined by each name
> >   properties:
> >
> > # The compatible property is a reserved name. The type is always
> > "string"
> > # and should not be repeated device binding.
> > compatible:
> >   category: required# required property
> >   type: strseq  # is a sequence of strings
> >
> >   description: >
> > FX11 is a clone of the original SK11 device
> >
> >   # v is always the name of the value of the property
> >   # np is passed to the checker and is the current
> >   # node pointer. We can access properties and call
> >   # methods that operate on them.
> >   # There can be multiple constraints, just put them
> >   # into a sequence.
> >   # Note that the BASE("skel,sk11") form from the previous
> >   # binding will have to be reworked.
> >   constraint: |
> > anystreq(v, "skel,sk11") ||
> > anystreq(v, "faux,fx11")
> 
> Constraints and logic ops were certainly not decided in the last
> attempt and I think will be the hardest part to define. I see you are
> using eBPF in the checker. Is that where anystreq comes from?
> 

Yes. The ebpf environment declares a number of methods that are executed
outside the ebpf sandbox. Check out

https://raw.githubusercontent.com/pantoniou/yamldt/master/validate/schema/codegen.yaml
https://github.com/pantoniou/yamldt/blob/master/ebpf_dt.c

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Geert,

On Tue, 2017-10-03 at 09:17 +0200, Geert Uytterhoeven wrote:
> Hi Pantelis,
> 
> On Mon, Oct 2, 2017 at 9:46 PM, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
> > # Note that the YAML example must be validated against this binding
> > # to be an accepted entry
> 
> Indeed ;-)
> 
> >   yaml: |
> > sk11@0:
> >   compatible: "skel,sk11"
> >   reg: 0
> >   sip-max-frequency: 100
> 
> s/sip-max-frequency/spi-max-frequency/
> 

Heh, obviously the auto-check of binding examples is not working yet :)

> 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

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Geert,

On Tue, 2017-10-03 at 09:17 +0200, Geert Uytterhoeven wrote:
> Hi Pantelis,
> 
> On Mon, Oct 2, 2017 at 9:46 PM, Pantelis Antoniou
>  wrote:
> > # Note that the YAML example must be validated against this binding
> > # to be an accepted entry
> 
> Indeed ;-)
> 
> >   yaml: |
> > sk11@0:
> >   compatible: "skel,sk11"
> >   reg: 0
> >   sip-max-frequency: 100
> 
> s/sip-max-frequency/spi-max-frequency/
> 

Heh, obviously the auto-check of binding examples is not working yet :)

> 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

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Rob,

On Sun, 2017-10-01 at 17:00 -0500, Rob Herring wrote:
> On Thu, Sep 28, 2017 at 2:58 PM, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
> > Hello again,
> >
> > Significant progress has been made on yamldt and is now capable of
> > not only generating yaml from DTS source but also compiling DTS sources
> > and being almost fully compatible with DTC.
> 
> Can you quantify "almost"?
> 
> > Compiling the kernel's DTBs using yamldt is as simple as using a
> > DTC=yamldt.
> 
> Good.
> 
> >
> > Error reporting is accurate and validation against a YAML based schema
> > works as well. In a short while I will begin posting patches with
> > fixes on bindings and DTS files in the kernel.
> 
> What I would like to see is the schema format posted for review.
> 

I'm including the skeleton.yaml binding which is the template for
the bindings and a board-example.yaml binding for a top level binding.

> I would also like to see the bindings for top-level compatible strings
> (aka boards) as an example. That's something that's simple enough that
> I'd think we could agree on a format and start moving towards defining
> board bindings that way.
> 

Note there is some line wrapping I'm including a link
to the github repo of the files:


The skeleton.yaml 

https://raw.githubusercontent.com/pantoniou/yamldt/master/validate/bindings/skeleton.yaml

%YAML 1.1
---
# The name of the binding is first
# The anchor is put there for use by others
skeleton: 

  version: 1

  id: skel-device

  title: >
Skeleton Device

  maintainer:
name: Skeleton Person <s...@kernel.org>

  description: >
The Skeleton Device binding represents the SK11 device produced by
the Skeleton Corporation. The binding can also support compatible
clones made by second source vendors.

  # The class is an optional property that declares this
  # binding as part of a larger set
  # Multiple definitions are possible
  class: [ device, spi-device ]

  # This binding inherits property characteristics from the generic
  # spi-slave binding
  # Note that the notation is standard yaml reference
  inherits: *spi-slave

  # virtual bindings do not generate checkers
  virtual: true

  # each property is defined by each name
  properties:

# The compatible property is a reserved name. The type is always
"string"
# and should not be repeated device binding.
compatible:
  category: required# required property
  type: strseq  # is a sequence of strings

  description: >
FX11 is a clone of the original SK11 device

  # v is always the name of the value of the property
  # np is passed to the checker and is the current
  # node pointer. We can access properties and call
  # methods that operate on them.
  # There can be multiple constraints, just put them
  # into a sequence.
  # Note that the BASE("skel,sk11") form from the previous
  # binding will have to be reworked.
  constraint: |
anystreq(v, "skel,sk11") ||
anystreq(v, "faux,fx11")

# The reg property is a reserved name. The type is always "int" and
# should not be repeated in a device binding. Constraints are
defined
# only in the context of the parent node's address, size, and ranges
# cells. The description is inherited from the spi-slave binding.
# Note that if inheriting from a base binding this declaration may
# be omitted.
reg:
  category: required# required property
  type: intseq  # is a sequence of integers

# spi-max-frequency needs the device-specific constraint to be
supplied
spi-max-frequency:
  # this constraint is dependent on the compatible property
  # property containing "skel,sk11"
  constraint: |
v <= anystreq(get_strseq(np, "compatible"), "skel,sk11") ?
1000 : 100

# This property overrides the generic binding description with
# a device specific description in order to mention the chip's
# h/w cfg strapping pins.
spi-cs-high:
  description: >
Set if skeleton device configuration pins are set for chip
select polarity high

# Device specific properties don't inherit characteristic from a
generic
# binding so category, type, constraint, and description must be
specified
# if needed.
skel,deprecated1:
  # note that the category may be declare more than one option
  category: [ deprecated, optional ]
  type: int
  constraint: |
v >= 10 && v <= 20
  description: >
First of two deprecated properties.

# There are no constraints for properties of empty type
skel,deprecated2:
  category: deprecated
  typ

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hi Rob,

On Sun, 2017-10-01 at 17:00 -0500, Rob Herring wrote:
> On Thu, Sep 28, 2017 at 2:58 PM, Pantelis Antoniou
>  wrote:
> > Hello again,
> >
> > Significant progress has been made on yamldt and is now capable of
> > not only generating yaml from DTS source but also compiling DTS sources
> > and being almost fully compatible with DTC.
> 
> Can you quantify "almost"?
> 
> > Compiling the kernel's DTBs using yamldt is as simple as using a
> > DTC=yamldt.
> 
> Good.
> 
> >
> > Error reporting is accurate and validation against a YAML based schema
> > works as well. In a short while I will begin posting patches with
> > fixes on bindings and DTS files in the kernel.
> 
> What I would like to see is the schema format posted for review.
> 

I'm including the skeleton.yaml binding which is the template for
the bindings and a board-example.yaml binding for a top level binding.

> I would also like to see the bindings for top-level compatible strings
> (aka boards) as an example. That's something that's simple enough that
> I'd think we could agree on a format and start moving towards defining
> board bindings that way.
> 

Note there is some line wrapping I'm including a link
to the github repo of the files:


The skeleton.yaml 

https://raw.githubusercontent.com/pantoniou/yamldt/master/validate/bindings/skeleton.yaml

%YAML 1.1
---
# The name of the binding is first
# The anchor is put there for use by others
skeleton: 

  version: 1

  id: skel-device

  title: >
Skeleton Device

  maintainer:
name: Skeleton Person 

  description: >
The Skeleton Device binding represents the SK11 device produced by
the Skeleton Corporation. The binding can also support compatible
clones made by second source vendors.

  # The class is an optional property that declares this
  # binding as part of a larger set
  # Multiple definitions are possible
  class: [ device, spi-device ]

  # This binding inherits property characteristics from the generic
  # spi-slave binding
  # Note that the notation is standard yaml reference
  inherits: *spi-slave

  # virtual bindings do not generate checkers
  virtual: true

  # each property is defined by each name
  properties:

# The compatible property is a reserved name. The type is always
"string"
# and should not be repeated device binding.
compatible:
  category: required# required property
  type: strseq  # is a sequence of strings

  description: >
FX11 is a clone of the original SK11 device

  # v is always the name of the value of the property
  # np is passed to the checker and is the current
  # node pointer. We can access properties and call
  # methods that operate on them.
  # There can be multiple constraints, just put them
  # into a sequence.
  # Note that the BASE("skel,sk11") form from the previous
  # binding will have to be reworked.
  constraint: |
anystreq(v, "skel,sk11") ||
anystreq(v, "faux,fx11")

# The reg property is a reserved name. The type is always "int" and
# should not be repeated in a device binding. Constraints are
defined
# only in the context of the parent node's address, size, and ranges
# cells. The description is inherited from the spi-slave binding.
# Note that if inheriting from a base binding this declaration may
# be omitted.
reg:
  category: required# required property
  type: intseq  # is a sequence of integers

# spi-max-frequency needs the device-specific constraint to be
supplied
spi-max-frequency:
  # this constraint is dependent on the compatible property
  # property containing "skel,sk11"
  constraint: |
v <= anystreq(get_strseq(np, "compatible"), "skel,sk11") ?
1000 : 100

# This property overrides the generic binding description with
# a device specific description in order to mention the chip's
# h/w cfg strapping pins.
spi-cs-high:
  description: >
Set if skeleton device configuration pins are set for chip
select polarity high

# Device specific properties don't inherit characteristic from a
generic
# binding so category, type, constraint, and description must be
specified
# if needed.
skel,deprecated1:
  # note that the category may be declare more than one option
  category: [ deprecated, optional ]
  type: int
  constraint: |
v >= 10 && v <= 20
  description: >
First of two deprecated properties.

# There are no constraints for properties of empty type
skel,deprecated2:
  category: deprecated
  type: empty
  description: >
Second of two deprecated 

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

> On Oct 2, 2017, at 01:00 , Rob Herring <robherri...@gmail.com> wrote:
> 
> On Thu, Sep 28, 2017 at 2:58 PM, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
>> Hello again,
>> 
>> Significant progress has been made on yamldt and is now capable of
>> not only generating yaml from DTS source but also compiling DTS sources
>> and being almost fully compatible with DTC.
> 
> Can you quantify "almost”?

The —sort option and /include-bin/ doesn’t work yet.

It’s a day or so to add them but there are no kernel dtb files that rely on 
them.

> 

>> Compiling the kernel's DTBs using yamldt is as simple as using a
>> DTC=yamldt.
> 
> Good.
> 
>> 
>> Error reporting is accurate and validation against a YAML based schema
>> works as well. In a short while I will begin posting patches with
>> fixes on bindings and DTS files in the kernel.
> 
> What I would like to see is the schema format posted for review.
> 

It is based on your binding schema you’ve posted but tweaked slightly to
be parseable by the YAML subset that matches the DTS style.

In particular bare sequences do not map to DT at all, so:

- name: foo

is changed to
name: foo

And so on.

> I would also like to see the bindings for top-level compatible strings
> (aka boards) as an example. That's something that's simple enough that
> I'd think we could agree on a format and start moving towards defining
> board bindings that way.
> 

I’ll see what I can do.


> Rob

Regards

— Pantelis

Re: [RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

> On Oct 2, 2017, at 01:00 , Rob Herring  wrote:
> 
> On Thu, Sep 28, 2017 at 2:58 PM, Pantelis Antoniou
>  wrote:
>> Hello again,
>> 
>> Significant progress has been made on yamldt and is now capable of
>> not only generating yaml from DTS source but also compiling DTS sources
>> and being almost fully compatible with DTC.
> 
> Can you quantify "almost”?

The —sort option and /include-bin/ doesn’t work yet.

It’s a day or so to add them but there are no kernel dtb files that rely on 
them.

> 

>> Compiling the kernel's DTBs using yamldt is as simple as using a
>> DTC=yamldt.
> 
> Good.
> 
>> 
>> Error reporting is accurate and validation against a YAML based schema
>> works as well. In a short while I will begin posting patches with
>> fixes on bindings and DTS files in the kernel.
> 
> What I would like to see is the schema format posted for review.
> 

It is based on your binding schema you’ve posted but tweaked slightly to
be parseable by the YAML subset that matches the DTS style.

In particular bare sequences do not map to DT at all, so:

- name: foo

is changed to
name: foo

And so on.

> I would also like to see the bindings for top-level compatible strings
> (aka boards) as an example. That's something that's simple enough that
> I'd think we could agree on a format and start moving towards defining
> board bindings that way.
> 

I’ll see what I can do.


> Rob

Regards

— Pantelis

[RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hello again,

Significant progress has been made on yamldt and is now capable of
not only generating yaml from DTS source but also compiling DTS sources
and being almost fully compatible with DTC.

Compiling the kernel's DTBs using yamldt is as simple as using a
DTC=yamldt.

Error reporting is accurate and validation against a YAML based schema
works as well. In a short while I will begin posting patches with
fixes on bindings and DTS files in the kernel.

Please try it on your platform and report if you encounter any problems.

https://github.com/pantoniou/yamldt

I am eagerly awaiting for your comments.

Regards

-- Pantelis

[RFC] yamldt v0.5, now a DTS compiler too

[Pantelis Antoniou]

Hello again,

Significant progress has been made on yamldt and is now capable of
not only generating yaml from DTS source but also compiling DTS sources
and being almost fully compatible with DTC.

Compiling the kernel's DTBs using yamldt is as simple as using a
DTC=yamldt.

Error reporting is accurate and validation against a YAML based schema
works as well. In a short while I will begin posting patches with
fixes on bindings and DTS files in the kernel.

Please try it on your platform and report if you encounter any problems.

https://github.com/pantoniou/yamldt

I am eagerly awaiting for your comments.

Regards

-- Pantelis

Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files

[Pantelis Antoniou]

Hi Frank,

> On Aug 16, 2017, at 02:57 , Frank Rowand <frowand.l...@gmail.com> wrote:
> 
> On 08/15/17 15:36, Rob Herring wrote:
>> On Tue, Aug 15, 2017 at 4:15 PM, Tom Rini <tr...@konsulko.com> wrote:
>>> With support for stacked overlays being part of libfdt it is now
>>> possible and likely that overlays which require __symbols__ will be
>>> applied to the dtb files generated by the kernel.  This is done by
>>> passing -@ to dtc.  This does increase the filesize (and resident memory
>>> usage) based on the number of __symbol__ entries added to match the
>>> contents of the dts.
>>> 
>>> Cc: Rob Herring <robh...@kernel.org>
>>> Cc: Frank Rowand <frowand.l...@gmail.com>
>>> Cc: Masahiro Yamada <yamada.masah...@socionext.com>
>>> Cc: Michal Marek <mma...@suse.com>
>>> Cc: Pantelis Antoniou <pantelis.anton...@konsulko.com>
>>> Cc: devicet...@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>> CC: linux-kbu...@vger.kernel.org
>>> Signed-off-by: Tom Rini <tr...@konsulko.com>
>>> ---
>>> In order for a dtb file to be useful with all types of overlays, it
>>> needs to be generated with the -@ flag passed to dtc so that __symbols__
>>> are generated.  This however is not free, and increases the resulting
>>> dtb file by up to approximately 50% today.  In the current worst case
>>> this is moving from 88KiB to 133KiB.  In talking with Frank about this,
>> 
>> Plus some amount for the unflattened tree in memory, too.
>> 
>>> he outlined 3 possible ways (with the 4th option of something else
>>> entirely).
>>> 
>>> 1. Make passing -@ to dtc be dependent upon some CONFIG symbol.
>>> 2. In the kernel, if the kernel does not have overlay support, discard
>>> the __symbols__ information that we've been passed.
>>> 3. Have the bootloader pass in, or not, __symbols__ information.
>>> 
>>> This patch is an attempt to implement something between the 3rd option
>>> and a different, 4th option.  Frank was thinking that we might introduce
>>> a new symbol to control generation of __symbol__ information for option
>>> 1.  I think this gets the usage backwards and will lead to confusion
>>> among users and developers.
>>> 
>>> My proposal is that we do not want __symbols__ existence to be dependent
>>> on some part of the kernel configuration for a number of reasons.
>>> First, this is out of step with the rest of how dtbs are created today
>>> and more importantly, thought about.  Today, all dtb content is
>>> independent of CONFIG options.  If you build a dtb from a given kernel
>>> tree, everyone will agree on the result.  This is part of the "contract"
>>> on passing old kernels and new dtb files even.
>> 
>> Agree completely. I don't even like that building dtbs depends on the ARCH.
>> 
>> However, option 2 may still be useful. There's no point exposing what
>> can't be used. Furthermore, exposing __symbols__ in /proc/device-tree
>> at all may be a bad idea. We should consider if it should always be
>> hidden. That would also allow storing the __symbols__ data however we
>> want internally (i.e. with less memory usage).
> 
> Yes.  I would prefer to treat the __symbols__ node as an internal
> representation of information used by the device tree subsystem.
> It is not hardware description.
> 
> 

This is correct. This is internal workaround against a serialization format
omission.

>> The complication is
>> always kexec which I haven't thought about too much here.
> 
> That should not be an issue, because the device tree is exposed to kexec
> via /sys/firmware/fdt instead of /sys/firmware/devicetree/base (which
> is what /proc/device-tree links to), according to
> Documentation/ABI/testing/sysfs-firmware-ofw.  So the __symbols__
> node will be exposed to kexec.
> 

Which will have to be recreated if we throw away __symbols__ when converting
to our internal representation of labels.

> 
>> Also, perhaps we need finer grain control of __symbols__ generation.
>> We really don't want userspace to be able to modify anything in the DT
>> at any point in time. That's a big can of worms and we don't want to
>> start there. The problem is labels are widely used just for
>> convenience and weren't part of the ABI. With overlays that changes,
>> so we either need to restrict labels usage or define another way. It
>> could be as simple as defining some prefix for label names for labels
>> to export.
> 

Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files

[Pantelis Antoniou]

Hi Frank,

> On Aug 16, 2017, at 02:57 , Frank Rowand  wrote:
> 
> On 08/15/17 15:36, Rob Herring wrote:
>> On Tue, Aug 15, 2017 at 4:15 PM, Tom Rini  wrote:
>>> With support for stacked overlays being part of libfdt it is now
>>> possible and likely that overlays which require __symbols__ will be
>>> applied to the dtb files generated by the kernel.  This is done by
>>> passing -@ to dtc.  This does increase the filesize (and resident memory
>>> usage) based on the number of __symbol__ entries added to match the
>>> contents of the dts.
>>> 
>>> Cc: Rob Herring 
>>> Cc: Frank Rowand 
>>> Cc: Masahiro Yamada 
>>> Cc: Michal Marek 
>>> Cc: Pantelis Antoniou 
>>> Cc: devicet...@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>> CC: linux-kbu...@vger.kernel.org
>>> Signed-off-by: Tom Rini 
>>> ---
>>> In order for a dtb file to be useful with all types of overlays, it
>>> needs to be generated with the -@ flag passed to dtc so that __symbols__
>>> are generated.  This however is not free, and increases the resulting
>>> dtb file by up to approximately 50% today.  In the current worst case
>>> this is moving from 88KiB to 133KiB.  In talking with Frank about this,
>> 
>> Plus some amount for the unflattened tree in memory, too.
>> 
>>> he outlined 3 possible ways (with the 4th option of something else
>>> entirely).
>>> 
>>> 1. Make passing -@ to dtc be dependent upon some CONFIG symbol.
>>> 2. In the kernel, if the kernel does not have overlay support, discard
>>> the __symbols__ information that we've been passed.
>>> 3. Have the bootloader pass in, or not, __symbols__ information.
>>> 
>>> This patch is an attempt to implement something between the 3rd option
>>> and a different, 4th option.  Frank was thinking that we might introduce
>>> a new symbol to control generation of __symbol__ information for option
>>> 1.  I think this gets the usage backwards and will lead to confusion
>>> among users and developers.
>>> 
>>> My proposal is that we do not want __symbols__ existence to be dependent
>>> on some part of the kernel configuration for a number of reasons.
>>> First, this is out of step with the rest of how dtbs are created today
>>> and more importantly, thought about.  Today, all dtb content is
>>> independent of CONFIG options.  If you build a dtb from a given kernel
>>> tree, everyone will agree on the result.  This is part of the "contract"
>>> on passing old kernels and new dtb files even.
>> 
>> Agree completely. I don't even like that building dtbs depends on the ARCH.
>> 
>> However, option 2 may still be useful. There's no point exposing what
>> can't be used. Furthermore, exposing __symbols__ in /proc/device-tree
>> at all may be a bad idea. We should consider if it should always be
>> hidden. That would also allow storing the __symbols__ data however we
>> want internally (i.e. with less memory usage).
> 
> Yes.  I would prefer to treat the __symbols__ node as an internal
> representation of information used by the device tree subsystem.
> It is not hardware description.
> 
> 

This is correct. This is internal workaround against a serialization format
omission.

>> The complication is
>> always kexec which I haven't thought about too much here.
> 
> That should not be an issue, because the device tree is exposed to kexec
> via /sys/firmware/fdt instead of /sys/firmware/devicetree/base (which
> is what /proc/device-tree links to), according to
> Documentation/ABI/testing/sysfs-firmware-ofw.  So the __symbols__
> node will be exposed to kexec.
> 

Which will have to be recreated if we throw away __symbols__ when converting
to our internal representation of labels.

> 
>> Also, perhaps we need finer grain control of __symbols__ generation.
>> We really don't want userspace to be able to modify anything in the DT
>> at any point in time. That's a big can of worms and we don't want to
>> start there. The problem is labels are widely used just for
>> convenience and weren't part of the ABI. With overlays that changes,
>> so we either need to restrict labels usage or define another way. It
>> could be as simple as defining some prefix for label names for labels
>> to export.
> 
> Agreed.  We could also restrict labels in connector nodes to be visible.
> 

I would disagree. This is only being considered because runtime device tree
consistency checks currently is minimal (i.e. non existent). When we have
a prop

Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files

[Pantelis Antoniou]

Hi Tom,

Sorry for taking a little bit of time to reply to this (vacation time).

> On Aug 16, 2017, at 00:15 , Tom Rini <tr...@konsulko.com> wrote:
> 
> With support for stacked overlays being part of libfdt it is now
> possible and likely that overlays which require __symbols__ will be
> applied to the dtb files generated by the kernel.  This is done by
> passing -@ to dtc.  This does increase the filesize (and resident memory
> usage) based on the number of __symbol__ entries added to match the
> contents of the dts.
> 
> Cc: Rob Herring <robh...@kernel.org>
> Cc: Frank Rowand <frowand.l...@gmail.com>
> Cc: Masahiro Yamada <yamada.masah...@socionext.com>
> Cc: Michal Marek <mma...@suse.com>
> Cc: Pantelis Antoniou <pantelis.anton...@konsulko.com>
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> CC: linux-kbu...@vger.kernel.org
> Signed-off-by: Tom Rini <tr...@konsulko.com>
> ---
> In order for a dtb file to be useful with all types of overlays, it
> needs to be generated with the -@ flag passed to dtc so that __symbols__
> are generated.  This however is not free, and increases the resulting
> dtb file by up to approximately 50% today.  In the current worst case
> this is moving from 88KiB to 133KiB.  In talking with Frank about this,
> he outlined 3 possible ways (with the 4th option of something else
> entirely).
> 
> 1. Make passing -@ to dtc be dependent upon some CONFIG symbol.
> 2. In the kernel, if the kernel does not have overlay support, discard
> the __symbols__ information that we've been passed.
> 3. Have the bootloader pass in, or not, __symbols__ information.
> 
> This patch is an attempt to implement something between the 3rd option
> and a different, 4th option.  Frank was thinking that we might introduce
> a new symbol to control generation of __symbol__ information for option
> 1.  I think this gets the usage backwards and will lead to confusion
> among users and developers.
> 
> My proposal is that we do not want __symbols__ existence to be dependent
> on some part of the kernel configuration for a number of reasons.
> First, this is out of step with the rest of how dtbs are created today
> and more importantly, thought about.  Today, all dtb content is
> independent of CONFIG options.  If you build a dtb from a given kernel
> tree, everyone will agree on the result.  This is part of the "contract"
> on passing old kernels and new dtb files even.
> 
> Second, I think this is out of step with how a lot of overlay usage will
> occur.  My thinking is that with maximally useful overlays being
> available in mainline, lots of use-cases that we have today that result
> in a number of DTS files being included can become just overlays.  This
> is true in terms of not only evaluation kits but also when these systems
> are turned into custom hardware.  This is even more true for SoM based
> systems where a physical widget would be a SoM + carrier overlay +
> custom parts overlay.  These cases are going to be resolved with
> overlays being applied outside of the kernel.
> 

FWIW here are some thoughts of mine on this subject.

First, the whole business with the __symbols__ (& the fixup nodes) is meant
to be used as a method to pass along symbol information, inband with the DTB
in such a way as it would require absolutely no changes to booloaders and
the kernel unflattening methods with the downside of the increased memory
consumption.

That said, there’s no reason to keep the __symbols__ node as part of the
in kernel device tree structure after loading. In fact operations would be
much easier if that would be the case. That would go hand in hand with the
a previously posted patch that turns phandle lookups into hash/idr lookups.

I would think that whether overlays would be supported could be a board level
option, but I would hate for overlay support to be dependent on a kernel config
option. Yes, this is contradictory, I know :(. The problem is that if you don’t
have symbols generated at compile time of the kernel DTB you’re SOL loading an
overlay later. I was thinking of a patch that would allow ‘patching in’ the
symbols of an kernel at runtime, when that would be required (using a kernel
module containing that symbol information).

Finally Tom is absolutely correct; the way that system design for EVM+SoM is
done leads naturally to thinking in ‘overlay’ terms. So instead of the all
the different DTBs for different variants of boards we could have the .DTSIs
compiled as overlays and then the final DTB reconstructed at boot time (whether
by the bootloader or the kernel).

Regards

— Pantelis


> Signed-off-by: Tom Rini <tr...@konsulko.com>
> ---
> drivers/of/unittest-data/Makefile | 5 -
> scripts/Makefile.lib  | 3 +++

Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files

[Pantelis Antoniou]

Hi Tom,

Sorry for taking a little bit of time to reply to this (vacation time).

> On Aug 16, 2017, at 00:15 , Tom Rini  wrote:
> 
> With support for stacked overlays being part of libfdt it is now
> possible and likely that overlays which require __symbols__ will be
> applied to the dtb files generated by the kernel.  This is done by
> passing -@ to dtc.  This does increase the filesize (and resident memory
> usage) based on the number of __symbol__ entries added to match the
> contents of the dts.
> 
> Cc: Rob Herring 
> Cc: Frank Rowand 
> Cc: Masahiro Yamada 
> Cc: Michal Marek 
> Cc: Pantelis Antoniou 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> CC: linux-kbu...@vger.kernel.org
> Signed-off-by: Tom Rini 
> ---
> In order for a dtb file to be useful with all types of overlays, it
> needs to be generated with the -@ flag passed to dtc so that __symbols__
> are generated.  This however is not free, and increases the resulting
> dtb file by up to approximately 50% today.  In the current worst case
> this is moving from 88KiB to 133KiB.  In talking with Frank about this,
> he outlined 3 possible ways (with the 4th option of something else
> entirely).
> 
> 1. Make passing -@ to dtc be dependent upon some CONFIG symbol.
> 2. In the kernel, if the kernel does not have overlay support, discard
> the __symbols__ information that we've been passed.
> 3. Have the bootloader pass in, or not, __symbols__ information.
> 
> This patch is an attempt to implement something between the 3rd option
> and a different, 4th option.  Frank was thinking that we might introduce
> a new symbol to control generation of __symbol__ information for option
> 1.  I think this gets the usage backwards and will lead to confusion
> among users and developers.
> 
> My proposal is that we do not want __symbols__ existence to be dependent
> on some part of the kernel configuration for a number of reasons.
> First, this is out of step with the rest of how dtbs are created today
> and more importantly, thought about.  Today, all dtb content is
> independent of CONFIG options.  If you build a dtb from a given kernel
> tree, everyone will agree on the result.  This is part of the "contract"
> on passing old kernels and new dtb files even.
> 
> Second, I think this is out of step with how a lot of overlay usage will
> occur.  My thinking is that with maximally useful overlays being
> available in mainline, lots of use-cases that we have today that result
> in a number of DTS files being included can become just overlays.  This
> is true in terms of not only evaluation kits but also when these systems
> are turned into custom hardware.  This is even more true for SoM based
> systems where a physical widget would be a SoM + carrier overlay +
> custom parts overlay.  These cases are going to be resolved with
> overlays being applied outside of the kernel.
> 

FWIW here are some thoughts of mine on this subject.

First, the whole business with the __symbols__ (& the fixup nodes) is meant
to be used as a method to pass along symbol information, inband with the DTB
in such a way as it would require absolutely no changes to booloaders and
the kernel unflattening methods with the downside of the increased memory
consumption.

That said, there’s no reason to keep the __symbols__ node as part of the
in kernel device tree structure after loading. In fact operations would be
much easier if that would be the case. That would go hand in hand with the
a previously posted patch that turns phandle lookups into hash/idr lookups.

I would think that whether overlays would be supported could be a board level
option, but I would hate for overlay support to be dependent on a kernel config
option. Yes, this is contradictory, I know :(. The problem is that if you don’t
have symbols generated at compile time of the kernel DTB you’re SOL loading an
overlay later. I was thinking of a patch that would allow ‘patching in’ the
symbols of an kernel at runtime, when that would be required (using a kernel
module containing that symbol information).

Finally Tom is absolutely correct; the way that system design for EVM+SoM is
done leads naturally to thinking in ‘overlay’ terms. So instead of the all
the different DTBs for different variants of boards we could have the .DTSIs
compiled as overlays and then the final DTB reconstructed at boot time (whether
by the bootloader or the kernel).

Regards

— Pantelis


> Signed-off-by: Tom Rini 
> ---
> drivers/of/unittest-data/Makefile | 5 -
> scripts/Makefile.lib  | 3 +++
> 2 files changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/of/unittest-data/Makefile 
> b/drivers/of/unittest-data/Makefile
> index 6e00a9c69e58..70731cfe8900 100644
> --- a/drivers/of/unitt

Re: [PATCH] external references for device tree overlays

[Pantelis Antoniou]

Hi Stefani,

On Tue, 2017-06-06 at 21:17 +0200, Stefani Seibold wrote:
> Hi Pantelis,
> 
> thanks for the suggestion. This feature is not very well documented. I
> tried this on my rasp1 running 4.12.0-rc3 and it doesn't work. My
> source is:
> 
> // rapsi example
> /dts-v1/;
> /plugin/;
> 
> / {
> compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> 
> fragment@0 {
> target-path = "/soc/i2s@7e203000";
> __overlay__ {
> #address-cells = <0x0001>;
> #size-cells = <0x0001>;
> test = "test";
> timer = <&{/soc/timer@7e003}>;
> };
> };
> };
> 
> 
> The resulting overlay is (decompiled with fdtdump):
> 
> /dts-v1/;
> // magic: 0xd00dfeed
> // totalsize: 0x19a (410)
> // off_dt_struct: 0x38
> // off_dt_strings:0x148
> // off_mem_rsvmap:0x28
> // version:   17
> // last_comp_version: 16
> // boot_cpuid_phys:   0x0
> // size_dt_strings:   0x52
> // size_dt_struct:0x110
> 
> / {
> compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> fragment@0 {
> target-path = "/soc/i2s@7e203000";
> __overlay__ {
> #address-cells = <0x0001>;
> #size-cells = <0x0001>;
> test = "test";
> timer = <0xdeadbeef>;
> };
> };
> __fixups__ {
> /soc/timer@7e003 = "/fragment@0/__overlay__:timer:0";
> };
> };
> 
> But this will not apply:
> 
> OF: resolver: overlay phandle fixup failed: -22
> create_overlay: Failed to resolve tree
> 
> 

Yes, it will not work as it is; my point is that you don't need the
magic __*__ node.

You will need to modify the overlay application code to live insert a
phandle (if it doesn't exist) when it encounters a /path fixup.

> Anyway, the reason for my patch is that i can reference to nodes which
> lacks a phandle. The phandle will be created on the fly and also
> destroyed when the overlay is unloaded.
> 
> I have a real use case for this patch:
> 
> I have a BIOS on some ARM64 servers which provides broken device tree.
> It also lacks some devices in this tree which needs references to other
> devices which lacks a phandle.
> 
> Since the BIOSes are closed source i need a way to work arround this
> problem without patching all the drivers involved to this devices.
> 
> Hope this helps to understand the reason for this patch.
> 

FWIW your problem seems like something that would happen on the field.
We can berate the vendor of not providing the correct device tree, but
in the end workarounds for broken vendor things are common in the
kernel.

Regards

-- Pantelis

> - Stefani
> 
> Am Montag, den 05.06.2017, 21:43 +0300 schrieb Pantelis Antoniou:
> > Hi Stefani,
> > 
> > On Mon, 2017-06-05 at 14:59 +0200, Stefani Seibold wrote:
> > > From: Stefani Seibold <stef...@seibold.net>
> > > 
> > > This patch enables external references for symbols which are not
> > > exported by the current device tree. For example
> > > 
> > > // RASPI example (only for testing)
> > > /dts-v1/;
> > > /plugin/;
> > > 
> > > / {
> > > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > > 
> > > fragment@0 {
> > > target-path = "/soc/i2s@7e203000";
> > > __overlay__ {
> > > #address-cells = <0x0001>;
> > > #size-cells = <0x0001>;
> > > test = "test";
> > > timer = <>;
> > > };
> > > };
> > > 
> > > __external_symbols__ {
> > > timer = "/soc/timer@7e003000";
> > > };
> > > };
> > > 
> > 
> > I understand the problem. I am just not fond of the
> > __external_symbols__
> > solution.
> > 
> > There's a facility in the DT source language that allows to declare
> > pathspec labels.
> > 
> > The 'timer = <>;' statement could be rewritten as 
> > 'timer = <&{/soc/timer@7e003}>;'
> > 
> > Internally you can 'catch' that this refers to a symbol in the base
> > tree
> > and then do the same symbol insertion as the patch you've submitted.
> > 
> > The benefit to the above is that you don't introduce manually edited
> > speci

Re: [PATCH] external references for device tree overlays

[Pantelis Antoniou]

Hi Stefani,

On Tue, 2017-06-06 at 21:17 +0200, Stefani Seibold wrote:
> Hi Pantelis,
> 
> thanks for the suggestion. This feature is not very well documented. I
> tried this on my rasp1 running 4.12.0-rc3 and it doesn't work. My
> source is:
> 
> // rapsi example
> /dts-v1/;
> /plugin/;
> 
> / {
> compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> 
> fragment@0 {
> target-path = "/soc/i2s@7e203000";
> __overlay__ {
> #address-cells = <0x0001>;
> #size-cells = <0x0001>;
> test = "test";
> timer = <&{/soc/timer@7e003}>;
> };
> };
> };
> 
> 
> The resulting overlay is (decompiled with fdtdump):
> 
> /dts-v1/;
> // magic: 0xd00dfeed
> // totalsize: 0x19a (410)
> // off_dt_struct: 0x38
> // off_dt_strings:0x148
> // off_mem_rsvmap:0x28
> // version:   17
> // last_comp_version: 16
> // boot_cpuid_phys:   0x0
> // size_dt_strings:   0x52
> // size_dt_struct:0x110
> 
> / {
> compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> fragment@0 {
> target-path = "/soc/i2s@7e203000";
> __overlay__ {
> #address-cells = <0x0001>;
> #size-cells = <0x0001>;
> test = "test";
> timer = <0xdeadbeef>;
> };
> };
> __fixups__ {
> /soc/timer@7e003 = "/fragment@0/__overlay__:timer:0";
> };
> };
> 
> But this will not apply:
> 
> OF: resolver: overlay phandle fixup failed: -22
> create_overlay: Failed to resolve tree
> 
> 

Yes, it will not work as it is; my point is that you don't need the
magic __*__ node.

You will need to modify the overlay application code to live insert a
phandle (if it doesn't exist) when it encounters a /path fixup.

> Anyway, the reason for my patch is that i can reference to nodes which
> lacks a phandle. The phandle will be created on the fly and also
> destroyed when the overlay is unloaded.
> 
> I have a real use case for this patch:
> 
> I have a BIOS on some ARM64 servers which provides broken device tree.
> It also lacks some devices in this tree which needs references to other
> devices which lacks a phandle.
> 
> Since the BIOSes are closed source i need a way to work arround this
> problem without patching all the drivers involved to this devices.
> 
> Hope this helps to understand the reason for this patch.
> 

FWIW your problem seems like something that would happen on the field.
We can berate the vendor of not providing the correct device tree, but
in the end workarounds for broken vendor things are common in the
kernel.

Regards

-- Pantelis

> - Stefani
> 
> Am Montag, den 05.06.2017, 21:43 +0300 schrieb Pantelis Antoniou:
> > Hi Stefani,
> > 
> > On Mon, 2017-06-05 at 14:59 +0200, Stefani Seibold wrote:
> > > From: Stefani Seibold 
> > > 
> > > This patch enables external references for symbols which are not
> > > exported by the current device tree. For example
> > > 
> > > // RASPI example (only for testing)
> > > /dts-v1/;
> > > /plugin/;
> > > 
> > > / {
> > > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > > 
> > > fragment@0 {
> > > target-path = "/soc/i2s@7e203000";
> > > __overlay__ {
> > > #address-cells = <0x0001>;
> > > #size-cells = <0x0001>;
> > > test = "test";
> > > timer = <>;
> > > };
> > > };
> > > 
> > > __external_symbols__ {
> > > timer = "/soc/timer@7e003000";
> > > };
> > > };
> > > 
> > 
> > I understand the problem. I am just not fond of the
> > __external_symbols__
> > solution.
> > 
> > There's a facility in the DT source language that allows to declare
> > pathspec labels.
> > 
> > The 'timer = <>;' statement could be rewritten as 
> > 'timer = <&{/soc/timer@7e003}>;'
> > 
> > Internally you can 'catch' that this refers to a symbol in the base
> > tree
> > and then do the same symbol insertion as the patch you've submitted.
> > 
> > The benefit to the above is that you don't introduce manually edited
> > special nodes.
> > 
> &

Re: [PATCH] external references for device tree overlays

[Pantelis Antoniou]

Hi Stefani,

On Mon, 2017-06-05 at 14:59 +0200, Stefani Seibold wrote:
> From: Stefani Seibold 
> 
> This patch enables external references for symbols which are not
> exported by the current device tree. For example
> 
> // RASPI example (only for testing)
> /dts-v1/;
> /plugin/;
> 
> / {
> compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> 
> fragment@0 {
> target-path = "/soc/i2s@7e203000";
> __overlay__ {
> #address-cells = <0x0001>;
> #size-cells = <0x0001>;
> test = "test";
> timer = <>;
> };
> };
> 
> __external_symbols__ {
> timer = "/soc/timer@7e003000";
> };
> };
> 

I understand the problem. I am just not fond of the __external_symbols__
solution.

There's a facility in the DT source language that allows to declare
pathspec labels.

The 'timer = <>;' statement could be rewritten as 
'timer = <&{/soc/timer@7e003}>;'

Internally you can 'catch' that this refers to a symbol in the base tree
and then do the same symbol insertion as the patch you've submitted.

The benefit to the above is that you don't introduce manually edited
special nodes.

Regards

-- Pantelis

> The "timer" symbol is not exported by the RASPI device tree, because it is
> missing in the __symbols__ section of the device tree.
> 
> In case of the RASPI device tree this could be simple fixed by modifing
> the device tree source, but when the device tree is provided by a closed
> source BIOS this kind of missing symbol could not be fixed.
> 
> An additional benefit is to override a (possible broken) symbol exported
> by the currect live device tree.
> 
> The patch is based and tested on linux 4.12-rc3.
> 
> Signed-off-by: Stefani Seibold 
> Signed-off-by: Stefani Seibold 
> ---
>  drivers/of/overlay.c  | 19 +++
>  drivers/of/resolver.c | 27 ++-
>  2 files changed, 41 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index 7827786718d8..de6516ea0fcd 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -50,6 +50,7 @@ struct of_overlay {
>   int id;
>   struct list_head node;
>   int count;
> + struct device_node *tree;
>   struct of_overlay_info *ovinfo_tab;
>   struct of_changeset cset;
>  };
> @@ -422,6 +423,8 @@ int of_overlay_create(struct device_node *tree)
>   /* add to the tail of the overlay list */
>   list_add_tail(>node, _list);
>  
> + ov->tree = tree;
> +
>   of_overlay_notify(ov, OF_OVERLAY_POST_APPLY);
>  
>   mutex_unlock(_mutex);
> @@ -524,6 +527,7 @@ int of_overlay_destroy(int id)
>  {
>   struct of_overlay *ov;
>   int err;
> + phandle phandle;
>  
>   mutex_lock(_mutex);
>  
> @@ -540,6 +544,8 @@ int of_overlay_destroy(int id)
>   goto out;
>   }
>  
> + phandle = ov->tree->phandle;
> +
>   of_overlay_notify(ov, OF_OVERLAY_PRE_REMOVE);
>   list_del(>node);
>   __of_changeset_revert(>cset);
> @@ -549,6 +555,19 @@ int of_overlay_destroy(int id)
>   of_changeset_destroy(>cset);
>   kfree(ov);
>  
> + if (phandle) {
> + struct device_node *node;
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(_lock, flags);
> + for_each_of_allnodes(node) {
> + if (node->phandle >= phandle)
> + node->phandle = 0;
> + }
> + raw_spin_unlock_irqrestore(_lock, flags);
> + }
> +
> +
>   err = 0;
>  
>  out:
> diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
> index 771f4844c781..31b5f32c9b27 100644
> --- a/drivers/of/resolver.c
> +++ b/drivers/of/resolver.c
> @@ -286,13 +286,14 @@ static int adjust_local_phandle_references(struct 
> device_node *local_fixups,
>  int of_resolve_phandles(struct device_node *overlay)
>  {
>   struct device_node *child, *local_fixups, *refnode;
> - struct device_node *tree_symbols, *overlay_fixups;
> + struct device_node *tree_symbols, *ext_symbols, *overlay_fixups;
>   struct property *prop;
>   const char *refpath;
>   phandle phandle, phandle_delta;
>   int err;
>  
>   tree_symbols = NULL;
> + ext_symbols = NULL;
>  
>   if (!overlay) {
>   pr_err("null overlay\n");
> @@ -321,6 +322,9 @@ int of_resolve_phandles(struct device_node *overlay)
>   for_each_child_of_node(overlay, child) {
>   if (!of_node_cmp(child->name, "__fixups__"))
>   overlay_fixups = child;
> + else
> + if (!of_node_cmp(child->name, "__external_symbols__"))
> + ext_symbols = child;
>   }
>  
>   if (!overlay_fixups) {
> @@ -329,20 +333,30 @@ int of_resolve_phandles(struct device_node *overlay)
>   }
>  
>   tree_symbols = 

Re: [PATCH] external references for device tree overlays

[Pantelis Antoniou]

Hi Stefani,

On Mon, 2017-06-05 at 14:59 +0200, Stefani Seibold wrote:
> From: Stefani Seibold 
> 
> This patch enables external references for symbols which are not
> exported by the current device tree. For example
> 
> // RASPI example (only for testing)
> /dts-v1/;
> /plugin/;
> 
> / {
> compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> 
> fragment@0 {
> target-path = "/soc/i2s@7e203000";
> __overlay__ {
> #address-cells = <0x0001>;
> #size-cells = <0x0001>;
> test = "test";
> timer = <>;
> };
> };
> 
> __external_symbols__ {
> timer = "/soc/timer@7e003000";
> };
> };
> 

I understand the problem. I am just not fond of the __external_symbols__
solution.

There's a facility in the DT source language that allows to declare
pathspec labels.

The 'timer = <>;' statement could be rewritten as 
'timer = <&{/soc/timer@7e003}>;'

Internally you can 'catch' that this refers to a symbol in the base tree
and then do the same symbol insertion as the patch you've submitted.

The benefit to the above is that you don't introduce manually edited
special nodes.

Regards

-- Pantelis

> The "timer" symbol is not exported by the RASPI device tree, because it is
> missing in the __symbols__ section of the device tree.
> 
> In case of the RASPI device tree this could be simple fixed by modifing
> the device tree source, but when the device tree is provided by a closed
> source BIOS this kind of missing symbol could not be fixed.
> 
> An additional benefit is to override a (possible broken) symbol exported
> by the currect live device tree.
> 
> The patch is based and tested on linux 4.12-rc3.
> 
> Signed-off-by: Stefani Seibold 
> Signed-off-by: Stefani Seibold 
> ---
>  drivers/of/overlay.c  | 19 +++
>  drivers/of/resolver.c | 27 ++-
>  2 files changed, 41 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index 7827786718d8..de6516ea0fcd 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -50,6 +50,7 @@ struct of_overlay {
>   int id;
>   struct list_head node;
>   int count;
> + struct device_node *tree;
>   struct of_overlay_info *ovinfo_tab;
>   struct of_changeset cset;
>  };
> @@ -422,6 +423,8 @@ int of_overlay_create(struct device_node *tree)
>   /* add to the tail of the overlay list */
>   list_add_tail(>node, _list);
>  
> + ov->tree = tree;
> +
>   of_overlay_notify(ov, OF_OVERLAY_POST_APPLY);
>  
>   mutex_unlock(_mutex);
> @@ -524,6 +527,7 @@ int of_overlay_destroy(int id)
>  {
>   struct of_overlay *ov;
>   int err;
> + phandle phandle;
>  
>   mutex_lock(_mutex);
>  
> @@ -540,6 +544,8 @@ int of_overlay_destroy(int id)
>   goto out;
>   }
>  
> + phandle = ov->tree->phandle;
> +
>   of_overlay_notify(ov, OF_OVERLAY_PRE_REMOVE);
>   list_del(>node);
>   __of_changeset_revert(>cset);
> @@ -549,6 +555,19 @@ int of_overlay_destroy(int id)
>   of_changeset_destroy(>cset);
>   kfree(ov);
>  
> + if (phandle) {
> + struct device_node *node;
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(_lock, flags);
> + for_each_of_allnodes(node) {
> + if (node->phandle >= phandle)
> + node->phandle = 0;
> + }
> + raw_spin_unlock_irqrestore(_lock, flags);
> + }
> +
> +
>   err = 0;
>  
>  out:
> diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
> index 771f4844c781..31b5f32c9b27 100644
> --- a/drivers/of/resolver.c
> +++ b/drivers/of/resolver.c
> @@ -286,13 +286,14 @@ static int adjust_local_phandle_references(struct 
> device_node *local_fixups,
>  int of_resolve_phandles(struct device_node *overlay)
>  {
>   struct device_node *child, *local_fixups, *refnode;
> - struct device_node *tree_symbols, *overlay_fixups;
> + struct device_node *tree_symbols, *ext_symbols, *overlay_fixups;
>   struct property *prop;
>   const char *refpath;
>   phandle phandle, phandle_delta;
>   int err;
>  
>   tree_symbols = NULL;
> + ext_symbols = NULL;
>  
>   if (!overlay) {
>   pr_err("null overlay\n");
> @@ -321,6 +322,9 @@ int of_resolve_phandles(struct device_node *overlay)
>   for_each_child_of_node(overlay, child) {
>   if (!of_node_cmp(child->name, "__fixups__"))
>   overlay_fixups = child;
> + else
> + if (!of_node_cmp(child->name, "__external_symbols__"))
> + ext_symbols = child;
>   }
>  
>   if (!overlay_fixups) {
> @@ -329,20 +333,30 @@ int of_resolve_phandles(struct device_node *overlay)
>   }
>  
>   tree_symbols = of_find_node_by_path("/__symbols__");
> - if (!tree_symbols) {
> - pr_err("no symbols in 

Re: [PATCH 0/4 v2] of/overlay: sysfs based ABI for dt overlays

[Pantelis Antoniou]

Hi Frank, Heinrich,

> On Dec 22, 2016, at 21:00 , Frank Rowand <frowand.l...@gmail.com> wrote:
> 
> Hi Heinrich,
> 
> On 12/20/16 11:04, Heinrich Schuchardt wrote:
>> Currently the kernel only supplies an internal API for creating
>> and destroying device tree overlays.
>> 
>> For some boards vendor specific kernel modules exist for
>> managing device tree overlays but they have not been
>> upstreamed or upstreaming stalled.
>> https://lkml.org/lkml/2015/6/12/624
>> https://lkml.org/lkml/2013/1/7/366
>> 
>> This patch series provides a sysfs based ABI for creation and
>> destruction of dt overlays in /sys/firmware/devicetree/overlays.
>> 
>> The following files are provided:
>> 
>> load:   This is a write only file.
>>A string written to it is interpreted as the path to a
>>flattened device tree overlay file. It is used to create
>>and apply the contained overlays.
>> 
>> loaded: This is a read only file.
>>It provides the count of loaded overlays as a decimal
>>number.
>> 
>> unload: This is a write only file.
>>If a positive number n is wrtten to this file the n
>>most recent overlays are destroyed.
>>If a negative number is written to this file all
>>overlays are destroyed.
> 
> This patch series follows a _somewhat_ similar approach to what
> was first proposed two years ago, and does not address the
> issues that were brought up at that time.  See:
> 
>  From: Pantelis Antoniou <pantelis.anton...@konsulko.com>
>  Date: Wed,  3 Dec 2014 13:23:28 +0200
>  Subject: [PATCH] OF: DT-Overlay configfs interface (v3)
> 
> But just responding directly to the two year old issues would not
> be a productive approach, since there has been a lot of subsequent
> discussion on how to load overlays (you point to two of the many
> threads above).  The latest discussions are based on the concept
> of describing the overlay attachment points as connectors.
> 
> Please join in pushing the connectors discussion along to make
> sure that it meets your needs.
> 

I think it would be best if we focus on getting the configfs based loader
to work. It is pretty similar to what Heinrich is proposing.

> -Frank
> 

Regards

— Pantelis

> 
>> 
>> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
>> 
>> version 2:
>>  change sysfs path to
>>  /sys/firmware/devicetree/overlays
>> 
>>  Fix errors indicated by kbuild robot:
>>  Add missing inline attribute to of_overlay_count
>>  in patch 1.
>>  Add 'select CONFIG_OF_EARLY_FLATTREE' to Kconfig
>>  in patch 2.
>> 
>>  Change unit test cases to check new functions
>>  of_overlay_count and of_overlay_destroy_last.
>> 
>> Heinrich Schuchardt (4):
>>  of/overlay: add API function to count and pop last
>>  of/overlay: sysfs based ABI for dt overlays
>>  of/overlay: documentation for sysfs ABI 
>>  of/overlay: test count and destroy_last
>> 
>> .../ABI/testing/sysfs-firmware-devicetree-overlays |  24 +++ 
>> Documentation/devicetree/overlay-notes.txt |   7 +-
>> drivers/of/Kconfig |  15 ++
>> drivers/of/Makefile|   2 + 
>> drivers/of/base.c  |   1 + 
>> drivers/of/ov_sysfs.c  | 223 
>> +
>> drivers/of/overlay.c   |  50 +
>> drivers/of/unittest.c  |  15 +-
>> include/linux/of.h |  12 ++
>> 9 files changed, 346 insertions(+), 3 deletions(-)
>> create mode 100644 
>> Documentation/ABI/testing/sysfs-firmware-devicetree-overlays
>> create mode 100644 drivers/of/ov_sysfs.c

Re: [PATCH 0/4 v2] of/overlay: sysfs based ABI for dt overlays

[Pantelis Antoniou]

Hi Frank, Heinrich,

> On Dec 22, 2016, at 21:00 , Frank Rowand  wrote:
> 
> Hi Heinrich,
> 
> On 12/20/16 11:04, Heinrich Schuchardt wrote:
>> Currently the kernel only supplies an internal API for creating
>> and destroying device tree overlays.
>> 
>> For some boards vendor specific kernel modules exist for
>> managing device tree overlays but they have not been
>> upstreamed or upstreaming stalled.
>> https://lkml.org/lkml/2015/6/12/624
>> https://lkml.org/lkml/2013/1/7/366
>> 
>> This patch series provides a sysfs based ABI for creation and
>> destruction of dt overlays in /sys/firmware/devicetree/overlays.
>> 
>> The following files are provided:
>> 
>> load:   This is a write only file.
>>A string written to it is interpreted as the path to a
>>flattened device tree overlay file. It is used to create
>>and apply the contained overlays.
>> 
>> loaded: This is a read only file.
>>It provides the count of loaded overlays as a decimal
>>number.
>> 
>> unload: This is a write only file.
>>If a positive number n is wrtten to this file the n
>>most recent overlays are destroyed.
>>If a negative number is written to this file all
>>overlays are destroyed.
> 
> This patch series follows a _somewhat_ similar approach to what
> was first proposed two years ago, and does not address the
> issues that were brought up at that time.  See:
> 
>  From: Pantelis Antoniou 
>  Date: Wed,  3 Dec 2014 13:23:28 +0200
>  Subject: [PATCH] OF: DT-Overlay configfs interface (v3)
> 
> But just responding directly to the two year old issues would not
> be a productive approach, since there has been a lot of subsequent
> discussion on how to load overlays (you point to two of the many
> threads above).  The latest discussions are based on the concept
> of describing the overlay attachment points as connectors.
> 
> Please join in pushing the connectors discussion along to make
> sure that it meets your needs.
> 

I think it would be best if we focus on getting the configfs based loader
to work. It is pretty similar to what Heinrich is proposing.

> -Frank
> 

Regards

— Pantelis

> 
>> 
>> Signed-off-by: Heinrich Schuchardt 
>> 
>> version 2:
>>  change sysfs path to
>>  /sys/firmware/devicetree/overlays
>> 
>>  Fix errors indicated by kbuild robot:
>>  Add missing inline attribute to of_overlay_count
>>  in patch 1.
>>  Add 'select CONFIG_OF_EARLY_FLATTREE' to Kconfig
>>  in patch 2.
>> 
>>  Change unit test cases to check new functions
>>  of_overlay_count and of_overlay_destroy_last.
>> 
>> Heinrich Schuchardt (4):
>>  of/overlay: add API function to count and pop last
>>  of/overlay: sysfs based ABI for dt overlays
>>  of/overlay: documentation for sysfs ABI 
>>  of/overlay: test count and destroy_last
>> 
>> .../ABI/testing/sysfs-firmware-devicetree-overlays |  24 +++ 
>> Documentation/devicetree/overlay-notes.txt |   7 +-
>> drivers/of/Kconfig |  15 ++
>> drivers/of/Makefile|   2 + 
>> drivers/of/base.c  |   1 + 
>> drivers/of/ov_sysfs.c  | 223 
>> +
>> drivers/of/overlay.c   |  50 +
>> drivers/of/unittest.c  |  15 +-
>> include/linux/of.h |  12 ++
>> 9 files changed, 346 insertions(+), 3 deletions(-)
>> create mode 100644 
>> Documentation/ABI/testing/sysfs-firmware-devicetree-overlays
>> create mode 100644 drivers/of/ov_sysfs.c

Re: [PATCH 1/3] of: Support parsing phandle argument lists through a nexus node

[Pantelis Antoniou]

Hi Stephen,

> On Nov 24, 2016, at 12:25 , Stephen Boyd <stephen.b...@linaro.org> wrote:
> 
> Platforms like 96boards have a standardized connector/expansion
> slot that exposes signals like GPIOs to expansion boards in an
> SoC agnostic way. We'd like the DT overlays for the expansion
> boards to be written once without knowledge of the SoC on the
> other side of the connector. This avoids the unscalable
> combinatorial explosion of a different DT overlay for each
> expansion board and SoC pair.
> 
> We need a way to describe the GPIOs routed through the connector
> in an SoC agnostic way. Let's introduce nexus property parsing
> into the OF core to do this. This is largely based on the
> interrupt nexus support we already have. This allows us to remap
> a phandle list in a consumer node (e.g. reset-gpios) through a
> connector in a generic way (e.g. via gpio-map). Do this in a
> generic routine so that we can remap any sort of variable length
> phandle list.
> 
> Taking GPIOs as an example, the connector would be a GPIO nexus,
> supporting the remapping of a GPIO specifier space to multiple
> GPIO providers on the SoC. DT would look as shown below, where
> 'soc_gpio1' and 'soc_gpio2' are inside the SoC, 'connector' is an
> expansion port where boards can be plugged in, and
> 'expansion_device' is a device on the expansion board.
> 
>   soc {
>   soc_gpio1: gpio-controller1 {
>   #gpio-cells = <2>;
>   };
> 
>   soc_gpio2: gpio-controller2 {
>   #gpio-cells = <2>;
>   };
>   };
> 
>   connector: connector {
>   #gpio-cells = <2>;
>   gpio-map = <0 GPIO_ACTIVE_LOW _gpio1 1 GPIO_ACTIVE_LOW>,
>  <1 GPIO_ACTIVE_LOW _gpio2 4 GPIO_ACTIVE_LOW>,
>  <2 GPIO_ACTIVE_LOW _gpio1 3 GPIO_ACTIVE_LOW>,
>  <3 GPIO_ACTIVE_LOW _gpio2 2 GPIO_ACTIVE_LOW>;
>   gpio-map-mask = <0xf 0x1>;
>   };
> 
>   expansion_device {
>   reset-gpios = < 2 GPIO_ACTIVE_LOW>;
>   };
> 
> The GPIO core would use of_parse_phandle_with_args_map() instead
> of of_parse_phandle_with_args() and arrive at the same type of
> result, a phandle and argument list. The difference is that the
> phandle and arguments will be remapped through the nexus node to
> the underlying SoC GPIO controller node. In the example above,
> we would remap 'reset-gpios' from < 2 GPIO_ACTIVE_LOW>
> to <_gpio1 3 GPIO_ACTIVE_LOW>.
> 

Very good. My only point would be to elaborate a little bit on the
documentation part about how there might be different #list-cells values
pointed at, and how the lookup is performed in steps.

> Cc: Pantelis Antoniou <pantelis.anton...@konsulko.com>
> Cc: Linus Walleij <linus.wall...@linaro.org>
> Cc: Mark Brown <broo...@kernel.org>
> Signed-off-by: Stephen Boyd <stephen.b...@linaro.org>
> ---
> drivers/of/base.c  | 146 +
> include/linux/of.h |  14 +
> 2 files changed, 160 insertions(+)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d687e6de24a0..693b73f33675 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1772,6 +1772,152 @@ int of_parse_phandle_with_args(const struct 
> device_node *np, const char *list_na
> EXPORT_SYMBOL(of_parse_phandle_with_args);
> 
> /**
> + * of_parse_phandle_with_args_map() - Find a node pointed by phandle in a 
> list and remap it
> + * @np:  pointer to a device tree node containing a list
> + * @list_name:   property name that contains a list
> + * @cells_name:  property name that specifies phandles' arguments count
> + * @index:   index of a phandle to parse out
> + * @out_args:optional pointer to output arguments structure (will be 
> filled)
> + *
> + * This function is useful to parse lists of phandles and their arguments.
> + * Returns 0 on success and fills out_args, on error returns appropriate
> + * errno value.
> + *
> + * Caller is responsible to call of_node_put() on the returned out_args->np
> + * pointer.
> + *
> + * Example:
> + *
> + * phandle1: node1 {
> + *   #list-cells = <2>;
> + * }
> + *
> + * phandle2: node2 {
> + *   #list-cells = <1>;
> + * }
> + *
> + * phandle3: node3 {
> + *   #list-cells = <1>;
> + *   list-map = <0  3>,
> + *  <1  2>,
> + *  <2  5 1>;
> + *   list-map-mask = <0x3>;
> + * };
> + *
> + * node4 {
> + *  

Re: [PATCH 1/3] of: Support parsing phandle argument lists through a nexus node

[Pantelis Antoniou]

Hi Stephen,

> On Nov 24, 2016, at 12:25 , Stephen Boyd  wrote:
> 
> Platforms like 96boards have a standardized connector/expansion
> slot that exposes signals like GPIOs to expansion boards in an
> SoC agnostic way. We'd like the DT overlays for the expansion
> boards to be written once without knowledge of the SoC on the
> other side of the connector. This avoids the unscalable
> combinatorial explosion of a different DT overlay for each
> expansion board and SoC pair.
> 
> We need a way to describe the GPIOs routed through the connector
> in an SoC agnostic way. Let's introduce nexus property parsing
> into the OF core to do this. This is largely based on the
> interrupt nexus support we already have. This allows us to remap
> a phandle list in a consumer node (e.g. reset-gpios) through a
> connector in a generic way (e.g. via gpio-map). Do this in a
> generic routine so that we can remap any sort of variable length
> phandle list.
> 
> Taking GPIOs as an example, the connector would be a GPIO nexus,
> supporting the remapping of a GPIO specifier space to multiple
> GPIO providers on the SoC. DT would look as shown below, where
> 'soc_gpio1' and 'soc_gpio2' are inside the SoC, 'connector' is an
> expansion port where boards can be plugged in, and
> 'expansion_device' is a device on the expansion board.
> 
>   soc {
>   soc_gpio1: gpio-controller1 {
>   #gpio-cells = <2>;
>   };
> 
>   soc_gpio2: gpio-controller2 {
>   #gpio-cells = <2>;
>   };
>   };
> 
>   connector: connector {
>   #gpio-cells = <2>;
>   gpio-map = <0 GPIO_ACTIVE_LOW _gpio1 1 GPIO_ACTIVE_LOW>,
>  <1 GPIO_ACTIVE_LOW _gpio2 4 GPIO_ACTIVE_LOW>,
>  <2 GPIO_ACTIVE_LOW _gpio1 3 GPIO_ACTIVE_LOW>,
>  <3 GPIO_ACTIVE_LOW _gpio2 2 GPIO_ACTIVE_LOW>;
>   gpio-map-mask = <0xf 0x1>;
>   };
> 
>   expansion_device {
>   reset-gpios = < 2 GPIO_ACTIVE_LOW>;
>   };
> 
> The GPIO core would use of_parse_phandle_with_args_map() instead
> of of_parse_phandle_with_args() and arrive at the same type of
> result, a phandle and argument list. The difference is that the
> phandle and arguments will be remapped through the nexus node to
> the underlying SoC GPIO controller node. In the example above,
> we would remap 'reset-gpios' from < 2 GPIO_ACTIVE_LOW>
> to <_gpio1 3 GPIO_ACTIVE_LOW>.
> 

Very good. My only point would be to elaborate a little bit on the
documentation part about how there might be different #list-cells values
pointed at, and how the lookup is performed in steps.

> Cc: Pantelis Antoniou 
> Cc: Linus Walleij 
> Cc: Mark Brown 
> Signed-off-by: Stephen Boyd 
> ---
> drivers/of/base.c  | 146 +
> include/linux/of.h |  14 +
> 2 files changed, 160 insertions(+)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d687e6de24a0..693b73f33675 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1772,6 +1772,152 @@ int of_parse_phandle_with_args(const struct 
> device_node *np, const char *list_na
> EXPORT_SYMBOL(of_parse_phandle_with_args);
> 
> /**
> + * of_parse_phandle_with_args_map() - Find a node pointed by phandle in a 
> list and remap it
> + * @np:  pointer to a device tree node containing a list
> + * @list_name:   property name that contains a list
> + * @cells_name:  property name that specifies phandles' arguments count
> + * @index:   index of a phandle to parse out
> + * @out_args:optional pointer to output arguments structure (will be 
> filled)
> + *
> + * This function is useful to parse lists of phandles and their arguments.
> + * Returns 0 on success and fills out_args, on error returns appropriate
> + * errno value.
> + *
> + * Caller is responsible to call of_node_put() on the returned out_args->np
> + * pointer.
> + *
> + * Example:
> + *
> + * phandle1: node1 {
> + *   #list-cells = <2>;
> + * }
> + *
> + * phandle2: node2 {
> + *   #list-cells = <1>;
> + * }
> + *
> + * phandle3: node3 {
> + *   #list-cells = <1>;
> + *   list-map = <0  3>,
> + *  <1  2>,
> + *  <2  5 1>;
> + *   list-map-mask = <0x3>;
> + * };
> + *
> + * node4 {
> + *   list = < 1 2  0>;
> + * }
> + *
> + * To get a device_node of the `node2' node you may call this:
> + * of_parse_phandle_with_args(node4, "list", "#list-ce

Re: [PATCH 0/2] OF phandle nexus support + GPIO nexus

[Pantelis Antoniou]

Hi Stephen,

> On Nov 24, 2016, at 12:25 , Stephen Boyd  wrote:
> 
> This is one small chunk of work related to DT overlays for expansion
> boards. It would be good to have a way to expose #-cells types of
> providers through a connector in a standard way. So we introduce a way
> to make "nexus" nodes for these types of properties to remap the consumer
> number space to the other side of the connector's number space. It's
> basically a copy of the interrupt nexus implementation, but without
> the address space matching design and interrupt-parent walking.
> 
> The first patch implements a generic method to do this, and the second patch
> adds a unit test for it. The third patch is more of an example than anything
> else. It shows how we would modify frameworks to use the new API.
> 

Excellent. It was about time this happened.

> Stephen Boyd (3):
>  of: Support parsing phandle argument lists through a nexus node
>  of: unittest: Add phandle remapping test
>  gpio: Support gpio nexus dt bindings
> 
> drivers/gpio/gpiolib-of.c   |   5 +-
> drivers/of/base.c   | 146 
> drivers/of/unittest-data/testcases.dts  |  11 +++
> drivers/of/unittest-data/tests-phandle.dtsi |  24 +
> drivers/of/unittest.c   | 124 +++
> include/linux/of.h  |  14 +++
> 6 files changed, 322 insertions(+), 2 deletions(-)
> 
> -- 
> 2.10.0.297.gf6727b0
> 

Comments inline…

Regards

— Pantelis

Re: [PATCH 0/2] OF phandle nexus support + GPIO nexus

[Pantelis Antoniou]

Hi Stephen,

> On Nov 24, 2016, at 12:25 , Stephen Boyd  wrote:
> 
> This is one small chunk of work related to DT overlays for expansion
> boards. It would be good to have a way to expose #-cells types of
> providers through a connector in a standard way. So we introduce a way
> to make "nexus" nodes for these types of properties to remap the consumer
> number space to the other side of the connector's number space. It's
> basically a copy of the interrupt nexus implementation, but without
> the address space matching design and interrupt-parent walking.
> 
> The first patch implements a generic method to do this, and the second patch
> adds a unit test for it. The third patch is more of an example than anything
> else. It shows how we would modify frameworks to use the new API.
> 

Excellent. It was about time this happened.

> Stephen Boyd (3):
>  of: Support parsing phandle argument lists through a nexus node
>  of: unittest: Add phandle remapping test
>  gpio: Support gpio nexus dt bindings
> 
> drivers/gpio/gpiolib-of.c   |   5 +-
> drivers/of/base.c   | 146 
> drivers/of/unittest-data/testcases.dts  |  11 +++
> drivers/of/unittest-data/tests-phandle.dtsi |  24 +
> drivers/of/unittest.c   | 124 +++
> include/linux/of.h  |  14 +++
> 6 files changed, 322 insertions(+), 2 deletions(-)
> 
> -- 
> 2.10.0.297.gf6727b0
> 

Comments inline…

Regards

— Pantelis

Re: [RFC PATCH 1/5] of: introduce the overlay manager

[Pantelis Antoniou]

Hi Antoine,

> On Oct 26, 2016, at 17:57 , Antoine Tenart 
>  wrote:
> 
> The overlay manager is an in-kernel library helping to handle dt overlay
> loading when using capes.
> 

Code related comments

> Signed-off-by: Antoine Tenart 
> ---
> drivers/of/Kconfig   |   2 +
> drivers/of/Makefile  |   1 +
> drivers/of/overlay-manager/Kconfig   |   6 +
> drivers/of/overlay-manager/Makefile  |   1 +
> drivers/of/overlay-manager/overlay-manager.c | 199 +++
> include/linux/overlay-manager.h  |  38 +
> 6 files changed, 247 insertions(+)
> create mode 100644 drivers/of/overlay-manager/Kconfig
> create mode 100644 drivers/of/overlay-manager/Makefile
> create mode 100644 drivers/of/overlay-manager/overlay-manager.c
> create mode 100644 include/linux/overlay-manager.h
> 
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index bc07ad30c9bf..e57aeaf0bf4f 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -116,4 +116,6 @@ config OF_OVERLAY
> config OF_NUMA
>   bool
> 
> +source "drivers/of/overlay-manager/Kconfig"
> +
> endif # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index d7efd9d458aa..d738fd41271f 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_OF_OVERLAY) += overlay.o
> obj-$(CONFIG_OF_NUMA) += of_numa.o
> 
> obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> +obj-y += overlay-manager/
> diff --git a/drivers/of/overlay-manager/Kconfig 
> b/drivers/of/overlay-manager/Kconfig
> new file mode 100644
> index ..eeb76054dcb8
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Kconfig
> @@ -0,0 +1,6 @@
> +config OF_OVERLAY_MGR
> + bool "Device Tree Overlay Manager"
> + depends on OF_OVERLAY
> + help
> +   Enable the overlay manager to handle automatic overlay loading when
> +   devices are detected.
> diff --git a/drivers/of/overlay-manager/Makefile 
> b/drivers/of/overlay-manager/Makefile
> new file mode 100644
> index ..86d2b53950e7
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_OF_OVERLAY_MGR) += overlay-manager.o
> diff --git a/drivers/of/overlay-manager/overlay-manager.c 
> b/drivers/of/overlay-manager/overlay-manager.c
> new file mode 100644
> index ..a725d7e24d38
> --- /dev/null
> +++ b/drivers/of/overlay-manager/overlay-manager.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 - Antoine Tenart 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct overlay_mgr_overlay {
> + struct list_head list;
> + char *name;
> +};
> +
> +LIST_HEAD(overlay_mgr_overlays);
> +LIST_HEAD(overlay_mgr_formats);
> +DEFINE_SPINLOCK(overlay_mgr_lock);
> +DEFINE_SPINLOCK(overlay_mgr_format_lock);
> +

Is there a reason for using spinlocks here? OF uses a mutex for
locking since we don’t expect OF manipulation occurring in a
non schedulable context.

> +/*
> + * overlay_mgr_register_format()
> + *
> + * Adds a new format candidate to the list of supported formats. The 
> registered
> + * formats are used to parse the headers stored on the dips.
> + */
> +int overlay_mgr_register_format(struct overlay_mgr_format *candidate)
> +{
> + struct overlay_mgr_format *format;
> + int err = 0;
> +
> + spin_lock(_mgr_format_lock);
> +
> + /* Check if the format is already registered */
> + list_for_each_entry(format, _mgr_formats, list) {
> + if (!strcpy(format->name, candidate->name)) {
> + err = -EEXIST;
> + goto err;
> + }
> + }
> +
> + list_add_tail(>list, _mgr_formats);
> +
> +err:
> + spin_unlock(_mgr_format_lock);
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_register_format);
> +
> +/*
> + * overlay_mgr_parse()
> + *
> + * Parse raw data with registered format parsers. Fills the candidate string 
> if
> + * one parser understood the raw data format.
> + */
> +int overlay_mgr_parse(struct device *dev, void *data, char ***candidates,
> +   unsigned *n)
> +{

The two argument format is not very readable. Perhaps use a structure instead?

> + struct list_head *pos, *tmp;
> + struct overlay_mgr_format *format;
> +
> + list_for_each_safe(pos, tmp, _mgr_formats) {
> + format = list_entry(pos, struct overlay_mgr_format, list);
> +
> + format->parse(dev, data, candidates, n);
> + if (n > 0)
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_parse);
> 

Re: [RFC PATCH 1/5] of: introduce the overlay manager

[Pantelis Antoniou]

Hi Antoine,

> On Oct 26, 2016, at 17:57 , Antoine Tenart 
>  wrote:
> 
> The overlay manager is an in-kernel library helping to handle dt overlay
> loading when using capes.
> 

Code related comments

> Signed-off-by: Antoine Tenart 
> ---
> drivers/of/Kconfig   |   2 +
> drivers/of/Makefile  |   1 +
> drivers/of/overlay-manager/Kconfig   |   6 +
> drivers/of/overlay-manager/Makefile  |   1 +
> drivers/of/overlay-manager/overlay-manager.c | 199 +++
> include/linux/overlay-manager.h  |  38 +
> 6 files changed, 247 insertions(+)
> create mode 100644 drivers/of/overlay-manager/Kconfig
> create mode 100644 drivers/of/overlay-manager/Makefile
> create mode 100644 drivers/of/overlay-manager/overlay-manager.c
> create mode 100644 include/linux/overlay-manager.h
> 
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index bc07ad30c9bf..e57aeaf0bf4f 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -116,4 +116,6 @@ config OF_OVERLAY
> config OF_NUMA
>   bool
> 
> +source "drivers/of/overlay-manager/Kconfig"
> +
> endif # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index d7efd9d458aa..d738fd41271f 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_OF_OVERLAY) += overlay.o
> obj-$(CONFIG_OF_NUMA) += of_numa.o
> 
> obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> +obj-y += overlay-manager/
> diff --git a/drivers/of/overlay-manager/Kconfig 
> b/drivers/of/overlay-manager/Kconfig
> new file mode 100644
> index ..eeb76054dcb8
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Kconfig
> @@ -0,0 +1,6 @@
> +config OF_OVERLAY_MGR
> + bool "Device Tree Overlay Manager"
> + depends on OF_OVERLAY
> + help
> +   Enable the overlay manager to handle automatic overlay loading when
> +   devices are detected.
> diff --git a/drivers/of/overlay-manager/Makefile 
> b/drivers/of/overlay-manager/Makefile
> new file mode 100644
> index ..86d2b53950e7
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_OF_OVERLAY_MGR) += overlay-manager.o
> diff --git a/drivers/of/overlay-manager/overlay-manager.c 
> b/drivers/of/overlay-manager/overlay-manager.c
> new file mode 100644
> index ..a725d7e24d38
> --- /dev/null
> +++ b/drivers/of/overlay-manager/overlay-manager.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 - Antoine Tenart 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct overlay_mgr_overlay {
> + struct list_head list;
> + char *name;
> +};
> +
> +LIST_HEAD(overlay_mgr_overlays);
> +LIST_HEAD(overlay_mgr_formats);
> +DEFINE_SPINLOCK(overlay_mgr_lock);
> +DEFINE_SPINLOCK(overlay_mgr_format_lock);
> +

Is there a reason for using spinlocks here? OF uses a mutex for
locking since we don’t expect OF manipulation occurring in a
non schedulable context.

> +/*
> + * overlay_mgr_register_format()
> + *
> + * Adds a new format candidate to the list of supported formats. The 
> registered
> + * formats are used to parse the headers stored on the dips.
> + */
> +int overlay_mgr_register_format(struct overlay_mgr_format *candidate)
> +{
> + struct overlay_mgr_format *format;
> + int err = 0;
> +
> + spin_lock(_mgr_format_lock);
> +
> + /* Check if the format is already registered */
> + list_for_each_entry(format, _mgr_formats, list) {
> + if (!strcpy(format->name, candidate->name)) {
> + err = -EEXIST;
> + goto err;
> + }
> + }
> +
> + list_add_tail(>list, _mgr_formats);
> +
> +err:
> + spin_unlock(_mgr_format_lock);
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_register_format);
> +
> +/*
> + * overlay_mgr_parse()
> + *
> + * Parse raw data with registered format parsers. Fills the candidate string 
> if
> + * one parser understood the raw data format.
> + */
> +int overlay_mgr_parse(struct device *dev, void *data, char ***candidates,
> +   unsigned *n)
> +{

The two argument format is not very readable. Perhaps use a structure instead?

> + struct list_head *pos, *tmp;
> + struct overlay_mgr_format *format;
> +
> + list_for_each_safe(pos, tmp, _mgr_formats) {
> + format = list_entry(pos, struct overlay_mgr_format, list);
> +
> + format->parse(dev, data, candidates, n);
> + if (n > 0)
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_parse);
> +
> +static int overlay_mgr_check_overlay(struct device_node *node)
> +{
> + struct property *p;
> +  

Re: [RFC PATCH 1/5] of: introduce the overlay manager

[Pantelis Antoniou]

Hi Antoine,

> On Oct 26, 2016, at 17:57 , Antoine Tenart 
>  wrote:
> 
> The overlay manager is an in-kernel library helping to handle dt overlay
> loading when using capes.
> 

All in all a nice idea. Comments inline.

> Signed-off-by: Antoine Tenart 
> ---
> drivers/of/Kconfig   |   2 +
> drivers/of/Makefile  |   1 +
> drivers/of/overlay-manager/Kconfig   |   6 +
> drivers/of/overlay-manager/Makefile  |   1 +
> drivers/of/overlay-manager/overlay-manager.c | 199 +++
> include/linux/overlay-manager.h  |  38 +
> 6 files changed, 247 insertions(+)
> create mode 100644 drivers/of/overlay-manager/Kconfig
> create mode 100644 drivers/of/overlay-manager/Makefile
> create mode 100644 drivers/of/overlay-manager/overlay-manager.c
> create mode 100644 include/linux/overlay-manager.h
> 
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index bc07ad30c9bf..e57aeaf0bf4f 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -116,4 +116,6 @@ config OF_OVERLAY
> config OF_NUMA
>   bool
> 
> +source "drivers/of/overlay-manager/Kconfig"
> +
> endif # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index d7efd9d458aa..d738fd41271f 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_OF_OVERLAY) += overlay.o
> obj-$(CONFIG_OF_NUMA) += of_numa.o
> 
> obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> +obj-y += overlay-manager/
> diff --git a/drivers/of/overlay-manager/Kconfig 
> b/drivers/of/overlay-manager/Kconfig
> new file mode 100644
> index ..eeb76054dcb8
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Kconfig
> @@ -0,0 +1,6 @@
> +config OF_OVERLAY_MGR
> + bool "Device Tree Overlay Manager"
> + depends on OF_OVERLAY
> + help
> +   Enable the overlay manager to handle automatic overlay loading when
> +   devices are detected.
> diff --git a/drivers/of/overlay-manager/Makefile 
> b/drivers/of/overlay-manager/Makefile
> new file mode 100644
> index ..86d2b53950e7
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_OF_OVERLAY_MGR) += overlay-manager.o
> diff --git a/drivers/of/overlay-manager/overlay-manager.c 
> b/drivers/of/overlay-manager/overlay-manager.c
> new file mode 100644
> index ..a725d7e24d38
> --- /dev/null
> +++ b/drivers/of/overlay-manager/overlay-manager.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 - Antoine Tenart 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct overlay_mgr_overlay {
> + struct list_head list;
> + char *name;
> +};
> +
> +LIST_HEAD(overlay_mgr_overlays);
> +LIST_HEAD(overlay_mgr_formats);
> +DEFINE_SPINLOCK(overlay_mgr_lock);
> +DEFINE_SPINLOCK(overlay_mgr_format_lock);
> +
> +/*
> + * overlay_mgr_register_format()
> + *
> + * Adds a new format candidate to the list of supported formats. The 
> registered
> + * formats are used to parse the headers stored on the dips.
> + */
> +int overlay_mgr_register_format(struct overlay_mgr_format *candidate)
> +{
> + struct overlay_mgr_format *format;
> + int err = 0;
> +
> + spin_lock(_mgr_format_lock);
> +
> + /* Check if the format is already registered */
> + list_for_each_entry(format, _mgr_formats, list) {
> + if (!strcpy(format->name, candidate->name)) {
> + err = -EEXIST;
> + goto err;
> + }
> + }
> +
> + list_add_tail(>list, _mgr_formats);
> +
> +err:
> + spin_unlock(_mgr_format_lock);
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_register_format);
> +
> +/*
> + * overlay_mgr_parse()
> + *
> + * Parse raw data with registered format parsers. Fills the candidate string 
> if
> + * one parser understood the raw data format.
> + */
> +int overlay_mgr_parse(struct device *dev, void *data, char ***candidates,
> +   unsigned *n)
> +{
> + struct list_head *pos, *tmp;
> + struct overlay_mgr_format *format;
> +
> + list_for_each_safe(pos, tmp, _mgr_formats) {
> + format = list_entry(pos, struct overlay_mgr_format, list);
> +
> + format->parse(dev, data, candidates, n);
> + if (n > 0)
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_parse);
> +
> +static int overlay_mgr_check_overlay(struct device_node *node)
> +{
> + struct property *p;
> + const char *str = NULL;
> +
> + p = of_find_property(node, "compatible", NULL);
> + if (!p)
> +   

Re: [RFC PATCH 1/5] of: introduce the overlay manager

[Pantelis Antoniou]

Hi Antoine,

> On Oct 26, 2016, at 17:57 , Antoine Tenart 
>  wrote:
> 
> The overlay manager is an in-kernel library helping to handle dt overlay
> loading when using capes.
> 

All in all a nice idea. Comments inline.

> Signed-off-by: Antoine Tenart 
> ---
> drivers/of/Kconfig   |   2 +
> drivers/of/Makefile  |   1 +
> drivers/of/overlay-manager/Kconfig   |   6 +
> drivers/of/overlay-manager/Makefile  |   1 +
> drivers/of/overlay-manager/overlay-manager.c | 199 +++
> include/linux/overlay-manager.h  |  38 +
> 6 files changed, 247 insertions(+)
> create mode 100644 drivers/of/overlay-manager/Kconfig
> create mode 100644 drivers/of/overlay-manager/Makefile
> create mode 100644 drivers/of/overlay-manager/overlay-manager.c
> create mode 100644 include/linux/overlay-manager.h
> 
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index bc07ad30c9bf..e57aeaf0bf4f 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -116,4 +116,6 @@ config OF_OVERLAY
> config OF_NUMA
>   bool
> 
> +source "drivers/of/overlay-manager/Kconfig"
> +
> endif # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index d7efd9d458aa..d738fd41271f 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_OF_OVERLAY) += overlay.o
> obj-$(CONFIG_OF_NUMA) += of_numa.o
> 
> obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> +obj-y += overlay-manager/
> diff --git a/drivers/of/overlay-manager/Kconfig 
> b/drivers/of/overlay-manager/Kconfig
> new file mode 100644
> index ..eeb76054dcb8
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Kconfig
> @@ -0,0 +1,6 @@
> +config OF_OVERLAY_MGR
> + bool "Device Tree Overlay Manager"
> + depends on OF_OVERLAY
> + help
> +   Enable the overlay manager to handle automatic overlay loading when
> +   devices are detected.
> diff --git a/drivers/of/overlay-manager/Makefile 
> b/drivers/of/overlay-manager/Makefile
> new file mode 100644
> index ..86d2b53950e7
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_OF_OVERLAY_MGR) += overlay-manager.o
> diff --git a/drivers/of/overlay-manager/overlay-manager.c 
> b/drivers/of/overlay-manager/overlay-manager.c
> new file mode 100644
> index ..a725d7e24d38
> --- /dev/null
> +++ b/drivers/of/overlay-manager/overlay-manager.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 - Antoine Tenart 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct overlay_mgr_overlay {
> + struct list_head list;
> + char *name;
> +};
> +
> +LIST_HEAD(overlay_mgr_overlays);
> +LIST_HEAD(overlay_mgr_formats);
> +DEFINE_SPINLOCK(overlay_mgr_lock);
> +DEFINE_SPINLOCK(overlay_mgr_format_lock);
> +
> +/*
> + * overlay_mgr_register_format()
> + *
> + * Adds a new format candidate to the list of supported formats. The 
> registered
> + * formats are used to parse the headers stored on the dips.
> + */
> +int overlay_mgr_register_format(struct overlay_mgr_format *candidate)
> +{
> + struct overlay_mgr_format *format;
> + int err = 0;
> +
> + spin_lock(_mgr_format_lock);
> +
> + /* Check if the format is already registered */
> + list_for_each_entry(format, _mgr_formats, list) {
> + if (!strcpy(format->name, candidate->name)) {
> + err = -EEXIST;
> + goto err;
> + }
> + }
> +
> + list_add_tail(>list, _mgr_formats);
> +
> +err:
> + spin_unlock(_mgr_format_lock);
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_register_format);
> +
> +/*
> + * overlay_mgr_parse()
> + *
> + * Parse raw data with registered format parsers. Fills the candidate string 
> if
> + * one parser understood the raw data format.
> + */
> +int overlay_mgr_parse(struct device *dev, void *data, char ***candidates,
> +   unsigned *n)
> +{
> + struct list_head *pos, *tmp;
> + struct overlay_mgr_format *format;
> +
> + list_for_each_safe(pos, tmp, _mgr_formats) {
> + format = list_entry(pos, struct overlay_mgr_format, list);
> +
> + format->parse(dev, data, candidates, n);
> + if (n > 0)
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_parse);
> +
> +static int overlay_mgr_check_overlay(struct device_node *node)
> +{
> + struct property *p;
> + const char *str = NULL;
> +
> + p = of_find_property(node, "compatible", NULL);
> + if (!p)
> + return -EINVAL;
> +
> + do {
> + str = of_prop_next_string(p, str);
> +

Re: [RFC PATCH 13/13] of: Remove unused variable overlay_symbols

[Pantelis Antoniou]

Hi Frank,


> On Oct 25, 2016, at 23:59 , frowand.l...@gmail.com wrote:
> 
> From: Frank Rowand 
> 
> This unused variable is a reminder that symbols in overlays are
> not available to subsequent overlays.  If such a feature is
> desired then there are several ways it could be implemented.
> 

Please don’t apply that. There’s a patch that actually imports
the symbol table from overlays that subsequent operations
work.

Please see:

https://patchwork.kernel.org/patch/9104701/

> Signed-off-by: Frank Rowand 
> ---
> drivers/of/resolver.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
> index 3f7cf569c7ea..b48d16200ccd 100644
> --- a/drivers/of/resolver.c
> +++ b/drivers/of/resolver.c
> @@ -272,7 +272,7 @@ static int adjust_local_phandle_references(struct 
> device_node *local_fixups,
> int of_resolve_phandles(struct device_node *overlay)
> {
>   struct device_node *child, *local_fixups, *refnode;
> - struct device_node *tree_symbols, *overlay_symbols, *overlay_fixups;
> + struct device_node *tree_symbols, *overlay_fixups;
>   struct property *prop;
>   const char *refpath;
>   phandle phandle, phandle_delta;
> @@ -302,12 +302,9 @@ int of_resolve_phandles(struct device_node *overlay)
>   if (err)
>   goto err_out;
> 
> - overlay_symbols = NULL;
>   overlay_fixups = NULL;
> 
>   for_each_child_of_node(overlay, child) {
> - if (!of_node_cmp(child->name, "__symbols__"))
> - overlay_symbols = child;
>   if (!of_node_cmp(child->name, "__fixups__"))
>   overlay_fixups = child;
>   }
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Regards

— Pantelis

Re: [RFC PATCH 13/13] of: Remove unused variable overlay_symbols

[Pantelis Antoniou]

Hi Frank,


> On Oct 25, 2016, at 23:59 , frowand.l...@gmail.com wrote:
> 
> From: Frank Rowand 
> 
> This unused variable is a reminder that symbols in overlays are
> not available to subsequent overlays.  If such a feature is
> desired then there are several ways it could be implemented.
> 

Please don’t apply that. There’s a patch that actually imports
the symbol table from overlays that subsequent operations
work.

Please see:

https://patchwork.kernel.org/patch/9104701/

> Signed-off-by: Frank Rowand 
> ---
> drivers/of/resolver.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
> index 3f7cf569c7ea..b48d16200ccd 100644
> --- a/drivers/of/resolver.c
> +++ b/drivers/of/resolver.c
> @@ -272,7 +272,7 @@ static int adjust_local_phandle_references(struct 
> device_node *local_fixups,
> int of_resolve_phandles(struct device_node *overlay)
> {
>   struct device_node *child, *local_fixups, *refnode;
> - struct device_node *tree_symbols, *overlay_symbols, *overlay_fixups;
> + struct device_node *tree_symbols, *overlay_fixups;
>   struct property *prop;
>   const char *refpath;
>   phandle phandle, phandle_delta;
> @@ -302,12 +302,9 @@ int of_resolve_phandles(struct device_node *overlay)
>   if (err)
>   goto err_out;
> 
> - overlay_symbols = NULL;
>   overlay_fixups = NULL;
> 
>   for_each_child_of_node(overlay, child) {
> - if (!of_node_cmp(child->name, "__symbols__"))
> - overlay_symbols = child;
>   if (!of_node_cmp(child->name, "__fixups__"))
>   overlay_fixups = child;
>   }
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Regards

— Pantelis

Re: [RFC PATCH 00/13] of: Make drivers/of/resolver.c more readable

[Pantelis Antoniou]

Hi Frank,

> On Oct 26, 2016, at 00:02 , Frank Rowand  wrote:
> 
> On 10/25/16 13:58, frowand.l...@gmail.com wrote:
>> From: Frank Rowand 
>> 
>> drivers/of/resolve.c is a bit difficult to read.  Clean it up so
>> that review of future overlay related patches will be easier.
> 
> < snip >
> 
> Hi Pantelis,
> 
> Can you test this patch series on some real hardware?
> 

Sure, I’ll give it whirl today. Been swamped after ELCE but now
I have a little bit of time.

> Thanks,
> 
> Frank

Regards

— Pantelis

Re: [RFC PATCH 00/13] of: Make drivers/of/resolver.c more readable

[Pantelis Antoniou]

Hi Frank,

> On Oct 26, 2016, at 00:02 , Frank Rowand  wrote:
> 
> On 10/25/16 13:58, frowand.l...@gmail.com wrote:
>> From: Frank Rowand 
>> 
>> drivers/of/resolve.c is a bit difficult to read.  Clean it up so
>> that review of future overlay related patches will be easier.
> 
> < snip >
> 
> Hi Pantelis,
> 
> Can you test this patch series on some real hardware?
> 

Sure, I’ll give it whirl today. Been swamped after ELCE but now
I have a little bit of time.

> Thanks,
> 
> Frank

Regards

— Pantelis

Re: [RFC PATCH 02/13] of: Remove excessive printks to reduce clutter

[Pantelis Antoniou]

Hi Rob, Frank,

> On Oct 27, 2016, at 15:21 , Rob Herring  wrote:
> 
> On Tue, Oct 25, 2016 at 3:58 PM,   wrote:
>> From: Frank Rowand 
> 
> Maybe some should be debug?
> 

Yes, please do not get rid of them completely.
Leave them at least as debug level so that if there’s a problem
there’s a way to figure out why something happened.

>> Signed-off-by: Frank Rowand 
>> ---
>> drivers/of/resolver.c | 28 
>> 1 file changed, 28 deletions(-)
>> 
>> diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
>> index 4ff0220d7aa2..93a7ca0bf98c 100644
>> --- a/drivers/of/resolver.c
>> +++ b/drivers/of/resolver.c
>> @@ -116,8 +116,6 @@ static int __of_adjust_phandle_ref(struct device_node 
>> *node,
>> 
>>propval = kmalloc(rprop->length, GFP_KERNEL);
>>if (!propval) {
>> -   pr_err("%s: Could not copy value of '%s'\n",
>> -   __func__, rprop->name);
>>return -ENOMEM;
>>}
> 
> I would remove the brackets in this patch rather than separately.
> 
>>memcpy(propval, rprop->value, rprop->length);


Regards

— Pantelis

Re: [RFC PATCH 02/13] of: Remove excessive printks to reduce clutter

[Pantelis Antoniou]

Hi Rob, Frank,

> On Oct 27, 2016, at 15:21 , Rob Herring  wrote:
> 
> On Tue, Oct 25, 2016 at 3:58 PM,   wrote:
>> From: Frank Rowand 
> 
> Maybe some should be debug?
> 

Yes, please do not get rid of them completely.
Leave them at least as debug level so that if there’s a problem
there’s a way to figure out why something happened.

>> Signed-off-by: Frank Rowand 
>> ---
>> drivers/of/resolver.c | 28 
>> 1 file changed, 28 deletions(-)
>> 
>> diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
>> index 4ff0220d7aa2..93a7ca0bf98c 100644
>> --- a/drivers/of/resolver.c
>> +++ b/drivers/of/resolver.c
>> @@ -116,8 +116,6 @@ static int __of_adjust_phandle_ref(struct device_node 
>> *node,
>> 
>>propval = kmalloc(rprop->length, GFP_KERNEL);
>>if (!propval) {
>> -   pr_err("%s: Could not copy value of '%s'\n",
>> -   __func__, rprop->name);
>>return -ENOMEM;
>>}
> 
> I would remove the brackets in this patch rather than separately.
> 
>>memcpy(propval, rprop->value, rprop->length);


Regards

— Pantelis

Re: [PATCH 00/10] Introduce Juniper PTXPMB CPLD driver

[Pantelis Antoniou]

Hi Linus,

> On Oct 20, 2016, at 16:42 , Linus Walleij <linus.wall...@linaro.org> wrote:
> 
> On Fri, Oct 7, 2016 at 5:17 PM, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
> 
>> Add Juniper's PTXPMB FPGA CPLD driver. Those FPGAs
>> are present in Juniper's PTX series of routers.
>> 
>> The MFD driver provices watchdog/i2c/gpio/mtd devices.
> 
> Since it's quite a bunch of patches to quite a bunch of controllers
> I think it's best if you get the MFD parts ready and merged through
> Lee first for v4.10, then we can add the subdrivers on top, maybe
> in v4.11, or on top of an immutable branch from Lee once he is
> happy with the core if the MFD core is finished quickly.
> 

Will do.

> I will review all the GPIO stuff though so you can revise these
> patches too :)
> 

Goodie :)

> Yours,
> Linus Walleij

Regards

— Pantelis

Re: [PATCH 00/10] Introduce Juniper PTXPMB CPLD driver

[Pantelis Antoniou]

Hi Linus,

> On Oct 20, 2016, at 16:42 , Linus Walleij  wrote:
> 
> On Fri, Oct 7, 2016 at 5:17 PM, Pantelis Antoniou
>  wrote:
> 
>> Add Juniper's PTXPMB FPGA CPLD driver. Those FPGAs
>> are present in Juniper's PTX series of routers.
>> 
>> The MFD driver provices watchdog/i2c/gpio/mtd devices.
> 
> Since it's quite a bunch of patches to quite a bunch of controllers
> I think it's best if you get the MFD parts ready and merged through
> Lee first for v4.10, then we can add the subdrivers on top, maybe
> in v4.11, or on top of an immutable branch from Lee once he is
> happy with the core if the MFD core is finished quickly.
> 

Will do.

> I will review all the GPIO stuff though so you can revise these
> patches too :)
> 

Goodie :)

> Yours,
> Linus Walleij

Regards

— Pantelis

Re: [PATCH] spi: mark device nodes only in case of successful instantiation

[Pantelis Antoniou]

Hi Ralf,

> On Oct 16, 2016, at 12:55 , Ralf Ramsauer  wrote:
> 
> Hi Geert,
> 
> On 10/16/2016 10:49 AM, Geert Uytterhoeven wrote:
>> Hi Ralf,
>> 
>> (Cc i2c)
>> 
>> On Fri, Oct 14, 2016 at 9:31 PM, Ralf Ramsauer
>>  wrote:
>>> Instantiated SPI device nodes are marked with OF_POPULATE. This was
>>> introduced in bd6c164. On unloading, loaded device nodes will of course
>>> be unmarked. The problem are nodes the fail during initialisation: If a
>>> node failed during registration, it won't be unloaded and hence never be
>>> unmarked again.
>>> 
>>> So if a SPI driver module is unloaded and reloaded, it will skip nodes
>>> that failed before.
>>> 
>>> Skip device nodes that are already populated and mark them only in case
>>> of success.
>>> 
>>> Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
>>> Signed-off-by: Ralf Ramsauer 
>>> Cc: Geert Uytterhoeven 
>>> ---
>>> Hi,
>>> 
>>> imagine the following situation: you loaded a spi driver as module, but
>>> it fails to instantiate, because of some reasons (e.g. some resources,
>>> like gpios, might be in use in userspace).
>>> 
>>> When reloading the driver, _all_ nodes, including previously failed
>>> ones, should be probed again. This is not the case at the moment.
>>> Current behaviour only re-registers nodes that were previously
>>> successfully loaded.
>>> 
>>> This small patches fixes this behaviour. I stumbled over this while
>>> working on a spi driver.
>> 
>> Thanks for your patch!
>> 
>>> drivers/spi/spi.c | 7 +--
>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
>>> index 200ca22..f96a04e 100644
>>> --- a/drivers/spi/spi.c
>>> +++ b/drivers/spi/spi.c
>>> @@ -1604,12 +1604,15 @@ static void of_register_spi_devices(struct 
>>> spi_master *master)
>>>return;
>>> 
>>>for_each_available_child_of_node(master->dev.of_node, nc) {
>>> -   if (of_node_test_and_set_flag(nc, OF_POPULATED))
>>> +   if (of_node_check_flag(nc, OF_POPULATED))
>>>continue;
>>>spi = of_register_spi_device(master, nc);
>>> -   if (IS_ERR(spi))
>>> +   if (IS_ERR(spi)) {
>>>dev_warn(>dev, "Failed to create SPI device 
>>> for %s\n",
>>>nc->full_name);
>>> +   continue;
>>> +   }
>>> +   of_node_set_flag(nc, OF_POPULATED);
>> 
>> I think it's safer to keep the atomic test-and-set, but clear the flag on
>> failure, cfr. of_platform_device_create_pdata() and of_amba_device_create().
> Ack, no prob. Let me change this in the next version.
>> 
>> Shouldn't of_spi_notify() be fixed, too?
> Right, that's almost the same path.
>> 
>> The same issue exists for i2c in of_i2c_register_devices() and 
>> of_i2c_notify(),
>> which is what I had used as an example.
> Good old c ;-)
> I'll fix and test that tomorrow and come back with two patches, as it
> touches different subsystems.
> 

Thanks for this. This is a very rare case that’s easy to slip through.
It is good to be consistent :)

> Best
>  Ralf
>> 

Regards

— Pantelis

>> 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
>> 
> 
> 
> -- 
> Ralf Ramsauer
> GPG: 0x8F10049B

Re: [PATCH] spi: mark device nodes only in case of successful instantiation

[Pantelis Antoniou]

Hi Ralf,

> On Oct 16, 2016, at 12:55 , Ralf Ramsauer  wrote:
> 
> Hi Geert,
> 
> On 10/16/2016 10:49 AM, Geert Uytterhoeven wrote:
>> Hi Ralf,
>> 
>> (Cc i2c)
>> 
>> On Fri, Oct 14, 2016 at 9:31 PM, Ralf Ramsauer
>>  wrote:
>>> Instantiated SPI device nodes are marked with OF_POPULATE. This was
>>> introduced in bd6c164. On unloading, loaded device nodes will of course
>>> be unmarked. The problem are nodes the fail during initialisation: If a
>>> node failed during registration, it won't be unloaded and hence never be
>>> unmarked again.
>>> 
>>> So if a SPI driver module is unloaded and reloaded, it will skip nodes
>>> that failed before.
>>> 
>>> Skip device nodes that are already populated and mark them only in case
>>> of success.
>>> 
>>> Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
>>> Signed-off-by: Ralf Ramsauer 
>>> Cc: Geert Uytterhoeven 
>>> ---
>>> Hi,
>>> 
>>> imagine the following situation: you loaded a spi driver as module, but
>>> it fails to instantiate, because of some reasons (e.g. some resources,
>>> like gpios, might be in use in userspace).
>>> 
>>> When reloading the driver, _all_ nodes, including previously failed
>>> ones, should be probed again. This is not the case at the moment.
>>> Current behaviour only re-registers nodes that were previously
>>> successfully loaded.
>>> 
>>> This small patches fixes this behaviour. I stumbled over this while
>>> working on a spi driver.
>> 
>> Thanks for your patch!
>> 
>>> drivers/spi/spi.c | 7 +--
>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
>>> index 200ca22..f96a04e 100644
>>> --- a/drivers/spi/spi.c
>>> +++ b/drivers/spi/spi.c
>>> @@ -1604,12 +1604,15 @@ static void of_register_spi_devices(struct 
>>> spi_master *master)
>>>return;
>>> 
>>>for_each_available_child_of_node(master->dev.of_node, nc) {
>>> -   if (of_node_test_and_set_flag(nc, OF_POPULATED))
>>> +   if (of_node_check_flag(nc, OF_POPULATED))
>>>continue;
>>>spi = of_register_spi_device(master, nc);
>>> -   if (IS_ERR(spi))
>>> +   if (IS_ERR(spi)) {
>>>dev_warn(>dev, "Failed to create SPI device 
>>> for %s\n",
>>>nc->full_name);
>>> +   continue;
>>> +   }
>>> +   of_node_set_flag(nc, OF_POPULATED);
>> 
>> I think it's safer to keep the atomic test-and-set, but clear the flag on
>> failure, cfr. of_platform_device_create_pdata() and of_amba_device_create().
> Ack, no prob. Let me change this in the next version.
>> 
>> Shouldn't of_spi_notify() be fixed, too?
> Right, that's almost the same path.
>> 
>> The same issue exists for i2c in of_i2c_register_devices() and 
>> of_i2c_notify(),
>> which is what I had used as an example.
> Good old c ;-)
> I'll fix and test that tomorrow and come back with two patches, as it
> touches different subsystems.
> 

Thanks for this. This is a very rare case that’s easy to slip through.
It is good to be consistent :)

> Best
>  Ralf
>> 

Regards

— Pantelis

>> 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
>> 
> 
> 
> -- 
> Ralf Ramsauer
> GPG: 0x8F10049B

Re: [PATCH v2 2/2] i2c: mark device nodes only in case of successful instantiation

[Pantelis Antoniou]

Hi Ralf,

> On Oct 17, 2016, at 16:59 , Ralf Ramsauer <r...@ramses-pyramidenbau.de> wrote:
> 
> Instantiated I2C device nodes are marked with OF_POPULATE. This was
> introduced in 4f001fd. On unloading, loaded device nodes will of course
> be unmarked. The problem are nodes that fail during initialisation: If a
> node fails, it won't be unloaded and hence not be unmarked.
> 
> If a I2C driver module is unloaded and reloaded, it will skip nodes that
> failed before.
> 
> Skip device nodes that are already populated and mark them only in case
> of success.
> 
> Note that the same issue exists for SPI.
> 
> Fixes: 4f001fd ("i2c: Mark instantiated device nodes with OF_POPULATE")
> Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
> ---
> drivers/i2c/i2c-core.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 5ab6721..1704fc8 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -1681,6 +1681,7 @@ static struct i2c_client *of_i2c_register_device(struct 
> i2c_adapter *adap,
> static void of_i2c_register_devices(struct i2c_adapter *adap)
> {
>   struct device_node *bus, *node;
> + struct i2c_client *client;
> 
>   /* Only register child devices if the adapter has a node pointer set */
>   if (!adap->dev.of_node)
> @@ -1695,7 +1696,14 @@ static void of_i2c_register_devices(struct i2c_adapter 
> *adap)
>   for_each_available_child_of_node(bus, node) {
>   if (of_node_test_and_set_flag(node, OF_POPULATED))
>   continue;
> - of_i2c_register_device(adap, node);
> +
> + client = of_i2c_register_device(adap, node);
> + if (IS_ERR(client)) {
> + dev_warn(>dev,
> +  "Failed to create I2C device for %s\n",
> +  node->full_name);
> + of_node_clear_flag(node, OF_POPULATED);
> + }
>   }
> 
>   of_node_put(bus);
> @@ -2299,6 +2307,7 @@ static int of_i2c_notify(struct notifier_block *nb, 
> unsigned long action,
>   if (IS_ERR(client)) {
>   dev_err(>dev, "failed to create client for 
> '%s'\n",
>rd->dn->full_name);
> +     of_node_clear_flag(rd->dn, OF_POPULATED);
>   return notifier_from_errno(PTR_ERR(client));
>   }
>   break;
> -- 
> 2.10.1
> 

Thanks for this

Acked-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>

Re: [PATCH v2 2/2] i2c: mark device nodes only in case of successful instantiation

[Pantelis Antoniou]

Hi Ralf,

> On Oct 17, 2016, at 16:59 , Ralf Ramsauer  wrote:
> 
> Instantiated I2C device nodes are marked with OF_POPULATE. This was
> introduced in 4f001fd. On unloading, loaded device nodes will of course
> be unmarked. The problem are nodes that fail during initialisation: If a
> node fails, it won't be unloaded and hence not be unmarked.
> 
> If a I2C driver module is unloaded and reloaded, it will skip nodes that
> failed before.
> 
> Skip device nodes that are already populated and mark them only in case
> of success.
> 
> Note that the same issue exists for SPI.
> 
> Fixes: 4f001fd ("i2c: Mark instantiated device nodes with OF_POPULATE")
> Signed-off-by: Ralf Ramsauer 
> ---
> drivers/i2c/i2c-core.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 5ab6721..1704fc8 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -1681,6 +1681,7 @@ static struct i2c_client *of_i2c_register_device(struct 
> i2c_adapter *adap,
> static void of_i2c_register_devices(struct i2c_adapter *adap)
> {
>   struct device_node *bus, *node;
> + struct i2c_client *client;
> 
>   /* Only register child devices if the adapter has a node pointer set */
>   if (!adap->dev.of_node)
> @@ -1695,7 +1696,14 @@ static void of_i2c_register_devices(struct i2c_adapter 
> *adap)
>   for_each_available_child_of_node(bus, node) {
>   if (of_node_test_and_set_flag(node, OF_POPULATED))
>   continue;
> - of_i2c_register_device(adap, node);
> +
> + client = of_i2c_register_device(adap, node);
> + if (IS_ERR(client)) {
> + dev_warn(>dev,
> +  "Failed to create I2C device for %s\n",
> +  node->full_name);
> + of_node_clear_flag(node, OF_POPULATED);
> + }
>   }
> 
>   of_node_put(bus);
> @@ -2299,6 +2307,7 @@ static int of_i2c_notify(struct notifier_block *nb, 
> unsigned long action,
>   if (IS_ERR(client)) {
>   dev_err(>dev, "failed to create client for 
> '%s'\n",
>rd->dn->full_name);
> +     of_node_clear_flag(rd->dn, OF_POPULATED);
>   return notifier_from_errno(PTR_ERR(client));
>   }
>   break;
> -- 
> 2.10.1
> 

Thanks for this

Acked-by: Pantelis Antoniou 

Re: [PATCH v2 1/2] spi: mark device nodes only in case of successful instantiation

[Pantelis Antoniou]

Hi Ralf,

> On Oct 17, 2016, at 16:59 , Ralf Ramsauer <r...@ramses-pyramidenbau.de> wrote:
> 
> Instantiated SPI device nodes are marked with OF_POPULATE. This was
> introduced in bd6c164. On unloading, loaded device nodes will of course
> be unmarked. The problem are nodes that fail during initialisation: If a
> node fails, it won't be unloaded and hence not be unmarked.
> 
> If a SPI driver module is unloaded and reloaded, it will skip nodes that
> failed before.
> 
> Skip device nodes that are already populated and mark them only in case
> of success.
> 
> Note that the same issue exists for I2C.
> 
> Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
> Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
> ---
> drivers/spi/spi.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 5787b72..838783c 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1618,9 +1618,11 @@ static void of_register_spi_devices(struct spi_master 
> *master)
>   if (of_node_test_and_set_flag(nc, OF_POPULATED))
>   continue;
>   spi = of_register_spi_device(master, nc);
> - if (IS_ERR(spi))
> + if (IS_ERR(spi)) {
>   dev_warn(>dev, "Failed to create SPI device for 
> %s\n",
>   nc->full_name);
> + of_node_clear_flag(nc, OF_POPULATED);
> + }
>   }
> }
> #else
> @@ -3131,6 +3133,7 @@ static int of_spi_notify(struct notifier_block *nb, 
> unsigned long action,
>   if (IS_ERR(spi)) {
>   pr_err("%s: failed to create for '%s'\n",
>   __func__, rd->dn->full_name);
> + of_node_clear_flag(rd->dn, OF_POPULATED);
>   return notifier_from_errno(PTR_ERR(spi));
>   }
>   break;
> -- 
> 2.10.1
> 

Thanks for this.

Acked-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>

Re: [PATCH v2 1/2] spi: mark device nodes only in case of successful instantiation

[Pantelis Antoniou]

Hi Ralf,

> On Oct 17, 2016, at 16:59 , Ralf Ramsauer  wrote:
> 
> Instantiated SPI device nodes are marked with OF_POPULATE. This was
> introduced in bd6c164. On unloading, loaded device nodes will of course
> be unmarked. The problem are nodes that fail during initialisation: If a
> node fails, it won't be unloaded and hence not be unmarked.
> 
> If a SPI driver module is unloaded and reloaded, it will skip nodes that
> failed before.
> 
> Skip device nodes that are already populated and mark them only in case
> of success.
> 
> Note that the same issue exists for I2C.
> 
> Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
> Signed-off-by: Ralf Ramsauer 
> ---
> drivers/spi/spi.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 5787b72..838783c 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1618,9 +1618,11 @@ static void of_register_spi_devices(struct spi_master 
> *master)
>   if (of_node_test_and_set_flag(nc, OF_POPULATED))
>   continue;
>   spi = of_register_spi_device(master, nc);
> - if (IS_ERR(spi))
> + if (IS_ERR(spi)) {
>   dev_warn(>dev, "Failed to create SPI device for 
> %s\n",
>   nc->full_name);
> + of_node_clear_flag(nc, OF_POPULATED);
> + }
>   }
> }
> #else
> @@ -3131,6 +3133,7 @@ static int of_spi_notify(struct notifier_block *nb, 
> unsigned long action,
>   if (IS_ERR(spi)) {
>   pr_err("%s: failed to create for '%s'\n",
>   __func__, rd->dn->full_name);
> + of_node_clear_flag(rd->dn, OF_POPULATED);
>   return notifier_from_errno(PTR_ERR(spi));
>   }
>   break;
> -- 
> 2.10.1
> 

Thanks for this.

Acked-by: Pantelis Antoniou 

Re: [PATCH v2 0/2] spi, i2c: mark device nodes only in case of successful instantiation

[Pantelis Antoniou]

Hi Ralf,

> On Oct 17, 2016, at 16:59 , Ralf Ramsauer <r...@ramses-pyramidenbau.de> wrote:
> 
> Hi,
> 
> this one fixes initialisation of I2C/SPI nodes.  Upon failure during
> intialisation, nodes were erroneously populated and never unmarked.
> 
> This lead to the problem that re-loaded drivers will never probe those devices
> again and can easily be fixed by clearing the OF_POPULATE flag when the node
> doesn't successfully initialise.
> 
> For the discussion of v1, see
> https://lkml.org/lkml/2016/10/14/483
> 
>  Ralf
> 
> changes since v1:
>  - also fix I2C core driver
>  - keep the atomic test-and-set, as Geert suggested
> 
> Ralf Ramsauer (2):
>  spi: mark device nodes only in case of successful instantiation
>  i2c: mark device nodes only in case of successful instantiation
> 
> drivers/i2c/i2c-core.c | 11 ++-
> drivers/spi/spi.c  |  5 -
> 2 files changed, 14 insertions(+), 2 deletions(-)
> 
> -- 
> 2.10.1
> 

Thanks for catching this.

Acked-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>

Re: [PATCH v2 0/2] spi, i2c: mark device nodes only in case of successful instantiation

[Pantelis Antoniou]

Hi Ralf,

> On Oct 17, 2016, at 16:59 , Ralf Ramsauer  wrote:
> 
> Hi,
> 
> this one fixes initialisation of I2C/SPI nodes.  Upon failure during
> intialisation, nodes were erroneously populated and never unmarked.
> 
> This lead to the problem that re-loaded drivers will never probe those devices
> again and can easily be fixed by clearing the OF_POPULATE flag when the node
> doesn't successfully initialise.
> 
> For the discussion of v1, see
> https://lkml.org/lkml/2016/10/14/483
> 
>  Ralf
> 
> changes since v1:
>  - also fix I2C core driver
>  - keep the atomic test-and-set, as Geert suggested
> 
> Ralf Ramsauer (2):
>  spi: mark device nodes only in case of successful instantiation
>  i2c: mark device nodes only in case of successful instantiation
> 
> drivers/i2c/i2c-core.c | 11 ++-
> drivers/spi/spi.c  |  5 -
> 2 files changed, 14 insertions(+), 2 deletions(-)
> 
> -- 
> 2.10.1
> 

Thanks for catching this.

Acked-by: Pantelis Antoniou 

Re: [PATCH 10/10] hwmon: i2cs-fan: Add hwmon dts binding documentation

[Pantelis Antoniou]

> On Oct 10, 2016, at 23:29 , Rob Herring <r...@kernel.org> wrote:
> 
> On Fri, Oct 07, 2016 at 06:21:09PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev <gvl...@juniper.net>
>> 
>> Adds the I2CS Fan Tray hwmon device tree node documentation.
>> 
>> Signed-off-by: Georgi Vlaev <gvl...@juniper.net>
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
>> ---
>> Documentation/devicetree/bindings/hwmon/i2cs-fan.txt | 19 +++
>> 1 file changed, 19 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/hwmon/i2cs-fan.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/hwmon/i2cs-fan.txt 
>> b/Documentation/devicetree/bindings/hwmon/i2cs-fan.txt
>> new file mode 100644
>> index 000..4ef880c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/i2cs-fan.txt
>> @@ -0,0 +1,19 @@
>> +Hwmon driver for Juniper fan trays on I2CS Slave FPGA
> 
> This is a h/w description, not a driver.
> 
>> +
>> +Required properties:
>> +
>> +- compatible: "i2cs-fan-hwmon"
> 
> I doubt any fan control h/w has "hwmon" in the name.
> 
>> +
>> +Optional properties:
>> +
>> +- num-fans: fans per tray (default 14)
>> +
>> +- tach-factor: TACH count scaling factor (default 120)
> 
> vendor prefixes needed.
> 
>> +
>> +Example:
>> +
>> +fan-hwmon {
>> +compatible = "jnx,i2cs-fan-hwmon";
>> +num-fans = <6>;
>> +tach-factor = <33>;
>> +};
>> -- 
>> 1.9.1

OK on all three.

Re: [PATCH 10/10] hwmon: i2cs-fan: Add hwmon dts binding documentation

[Pantelis Antoniou]

> On Oct 10, 2016, at 23:29 , Rob Herring  wrote:
> 
> On Fri, Oct 07, 2016 at 06:21:09PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev 
>> 
>> Adds the I2CS Fan Tray hwmon device tree node documentation.
>> 
>> Signed-off-by: Georgi Vlaev 
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou 
>> ---
>> Documentation/devicetree/bindings/hwmon/i2cs-fan.txt | 19 +++
>> 1 file changed, 19 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/hwmon/i2cs-fan.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/hwmon/i2cs-fan.txt 
>> b/Documentation/devicetree/bindings/hwmon/i2cs-fan.txt
>> new file mode 100644
>> index 000..4ef880c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/i2cs-fan.txt
>> @@ -0,0 +1,19 @@
>> +Hwmon driver for Juniper fan trays on I2CS Slave FPGA
> 
> This is a h/w description, not a driver.
> 
>> +
>> +Required properties:
>> +
>> +- compatible: "i2cs-fan-hwmon"
> 
> I doubt any fan control h/w has "hwmon" in the name.
> 
>> +
>> +Optional properties:
>> +
>> +- num-fans: fans per tray (default 14)
>> +
>> +- tach-factor: TACH count scaling factor (default 120)
> 
> vendor prefixes needed.
> 
>> +
>> +Example:
>> +
>> +fan-hwmon {
>> +compatible = "jnx,i2cs-fan-hwmon";
>> +num-fans = <6>;
>> +tach-factor = <33>;
>> +};
>> -- 
>> 1.9.1

OK on all three.

Re: [PATCH 4/4] gpio: ptxpmb-ext-cpld: Document bindings of PTXPMB extended CPLD

[Pantelis Antoniou]

Hi Rob,

> On Oct 10, 2016, at 23:19 , Rob Herring <r...@kernel.org> wrote:
> 
> On Fri, Oct 07, 2016 at 06:19:34PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev <gvl...@juniper.net>
>> 
>> Add device tree bindings document for the GPIO driver of
>> Juniper's PTXPMB extended CPLD.
>> 
>> Signed-off-by: Georgi Vlaev <gvl...@juniper.net>
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
>> ---
>> .../bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt | 36 
>> ++
>> 1 file changed, 36 insertions(+)
>> create mode 100644 
>> Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt
>> 
>> diff --git 
>> a/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt 
>> b/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt
>> new file mode 100644
>> index 000..87f01b9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt
>> @@ -0,0 +1,36 @@
>> +Juniper PTXPMB extended CPLD GPIO block
>> +
>> +Required properties:
>> +
>> +- compatible:
>> +Must be "jnx,gpio-ptxpmb-ext-cpld"
> 
> Generally, '-gpio' would be last.
> 

OK.


>> +
>> +- #gpio-cells:
>> +Should be <2>.  The first cell is the pin number (within the 
>> controller's
>> +pin space), and the second is used for the following flags:
>> +bit[0]: direction (0 = out, 1 = in)
>> +bit[1]: init high
>> +bit[2]: active low
> 
> Same comment as all the other gpio bindings...
> 
>> +
>> +- gpio-controller:
>> +Specifies that the node is a GPIO controller.
>> +
>> +- interrupt-controller:
>> +Specifies that the node is an interrupt controller.
>> +
>> +Optional properties:
>> +
>> +- reg:
>> +Address and length of the register set for the device. Usually supplied
>> +by the parent MFD device.
> 
> Make it required.
> 

Hmm, the current driver supplies that range via platform data (it’s an mfd 
driver).
What’s the take on mixing those?

>> +
>> +
>> +Example:
>> +
>> +gpio_ext_cpld: cpld-ext-gpio {
>> +compatible = "jnx,gpio-ptxpmb-ext-cpld";
>> +#gpio-cells = <2>;
>> +#interrupt-cells = <2>;
>> +gpio-controller;
>> +interrupt-controller;
>> +};
>> -- 
>> 1.9.1

Re: [PATCH 02/10] mfd: dt-bindings: Add bindings for the Juniper I2CS MFD

[Pantelis Antoniou]

Hi Rob,

> On Oct 10, 2016, at 23:23 , Rob Herring <r...@kernel.org> wrote:
> 
> On Fri, Oct 07, 2016 at 06:21:01PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev <gvl...@juniper.net>
>> 
>> Add device tree bindings for the Juniper I2CS MFD driver.
>> 
>> Signed-off-by: Georgi Vlaev <gvl...@juniper.net>
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
>> ---
>> Documentation/devicetree/bindings/mfd/jnx-i2cs.txt | 68 
>> ++
>> 1 file changed, 68 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/jnx-i2cs.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/mfd/jnx-i2cs.txt 
>> b/Documentation/devicetree/bindings/mfd/jnx-i2cs.txt
>> new file mode 100644
>> index 000..0ec103b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/jnx-i2cs.txt
>> @@ -0,0 +1,68 @@
>> +Device-Tree bindings for Juniper Networks I2CS FPGA MFD
>> +
>> +Required properties:
>> +- compatible - Must be one of:
>> +"jnx,i2cs-rcb"  (Routing Engine or Control Board FRUs)
>> +"jnx,i2cs-fpc"  (Flexible Port Concentrator FRUs)
>> +"jnx,i2cs-sib"  (Switching Interface Board FRUs)
>> +"jnx,i2cs-fan"  (Fan Tray FRUs)
>> +
>> +Optional properties:
>> +
>> +Depending on the FRU, the I2CS MFD has varied group of sub-devices:
>> +
>> +Device   Description
>> +--   ---
>> +jnx,i2cs-gpio   : Virtual gpio mapping driver
>> +jnx,i2cs-fan-hwmon  : hwmon driver for fan trays
>> +jnx,i2c-mux-i2cs: I2C Mux driver for FPC FRUs
>> +jnx,leds-i2cs   : Led driver
>> +
>> +All these optional nodes are described in their respective binding
>> +documents.
>> +
>> +Example node:
>> +
>> +i2cs@54 {
>> +compatible = "jnx,i2cs-fpc";
>> +reg = <0x54>;
>> +#address-cells = <0>;
>> +#size-cells = <0>;
>> +
>> +fpc2_mux {
> 
> Generic node names please.
> 

OK.

> mux { 
> 
>> +compatible = "jnx,i2c-mux-i2cs";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +fpc2i2c0: i2c@0 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +reg = <0>;
>> +};
>> +};
>> +
>> +fpc2_gpiomap: gpio-jnx-i2cs {
> 
> gpio@54 {
> 
OK

>> +compatible = "jnx,gpio-i2cs";
>> +reg = <0x54>;
>> +#gpio-cells = <2>;
>> +gpio-controller;
>> +interrupt-controller;
>> +
>> +/*
>> + * Map bits [0-3] of reg 0x21 as gpio inputs, bits [4-7]
>> + * as gpio outputs
>> + */
>> +i2c-gpio-map = <0x21 0x0f>;
>> +};
>> +
>> +leds-jnx-i2cs {
> 
> leds {
> 

OK.

>> +compatible = "jnx,leds-i2cs";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +sib8-active {
>> +reg = <0>;
>> +linux,default-trigger = "sib8-active";
>> +};
>> +};
>> +};
>> -- 
>> 1.9.1

Re: [PATCH 4/4] gpio: ptxpmb-ext-cpld: Document bindings of PTXPMB extended CPLD

[Pantelis Antoniou]

Hi Rob,

> On Oct 10, 2016, at 23:19 , Rob Herring  wrote:
> 
> On Fri, Oct 07, 2016 at 06:19:34PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev 
>> 
>> Add device tree bindings document for the GPIO driver of
>> Juniper's PTXPMB extended CPLD.
>> 
>> Signed-off-by: Georgi Vlaev 
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou 
>> ---
>> .../bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt | 36 
>> ++
>> 1 file changed, 36 insertions(+)
>> create mode 100644 
>> Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt
>> 
>> diff --git 
>> a/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt 
>> b/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt
>> new file mode 100644
>> index 000..87f01b9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/jnx,gpio-ptxpmb-ext-cpld.txt
>> @@ -0,0 +1,36 @@
>> +Juniper PTXPMB extended CPLD GPIO block
>> +
>> +Required properties:
>> +
>> +- compatible:
>> +Must be "jnx,gpio-ptxpmb-ext-cpld"
> 
> Generally, '-gpio' would be last.
> 

OK.


>> +
>> +- #gpio-cells:
>> +Should be <2>.  The first cell is the pin number (within the 
>> controller's
>> +pin space), and the second is used for the following flags:
>> +bit[0]: direction (0 = out, 1 = in)
>> +bit[1]: init high
>> +bit[2]: active low
> 
> Same comment as all the other gpio bindings...
> 
>> +
>> +- gpio-controller:
>> +Specifies that the node is a GPIO controller.
>> +
>> +- interrupt-controller:
>> +Specifies that the node is an interrupt controller.
>> +
>> +Optional properties:
>> +
>> +- reg:
>> +Address and length of the register set for the device. Usually supplied
>> +by the parent MFD device.
> 
> Make it required.
> 

Hmm, the current driver supplies that range via platform data (it’s an mfd 
driver).
What’s the take on mixing those?

>> +
>> +
>> +Example:
>> +
>> +gpio_ext_cpld: cpld-ext-gpio {
>> +compatible = "jnx,gpio-ptxpmb-ext-cpld";
>> +#gpio-cells = <2>;
>> +#interrupt-cells = <2>;
>> +gpio-controller;
>> +interrupt-controller;
>> +};
>> -- 
>> 1.9.1

Re: [PATCH 02/10] mfd: dt-bindings: Add bindings for the Juniper I2CS MFD

[Pantelis Antoniou]

Hi Rob,

> On Oct 10, 2016, at 23:23 , Rob Herring  wrote:
> 
> On Fri, Oct 07, 2016 at 06:21:01PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev 
>> 
>> Add device tree bindings for the Juniper I2CS MFD driver.
>> 
>> Signed-off-by: Georgi Vlaev 
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou 
>> ---
>> Documentation/devicetree/bindings/mfd/jnx-i2cs.txt | 68 
>> ++
>> 1 file changed, 68 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/jnx-i2cs.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/mfd/jnx-i2cs.txt 
>> b/Documentation/devicetree/bindings/mfd/jnx-i2cs.txt
>> new file mode 100644
>> index 000..0ec103b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/jnx-i2cs.txt
>> @@ -0,0 +1,68 @@
>> +Device-Tree bindings for Juniper Networks I2CS FPGA MFD
>> +
>> +Required properties:
>> +- compatible - Must be one of:
>> +"jnx,i2cs-rcb"  (Routing Engine or Control Board FRUs)
>> +"jnx,i2cs-fpc"  (Flexible Port Concentrator FRUs)
>> +"jnx,i2cs-sib"  (Switching Interface Board FRUs)
>> +"jnx,i2cs-fan"  (Fan Tray FRUs)
>> +
>> +Optional properties:
>> +
>> +Depending on the FRU, the I2CS MFD has varied group of sub-devices:
>> +
>> +Device   Description
>> +--   ---
>> +jnx,i2cs-gpio   : Virtual gpio mapping driver
>> +jnx,i2cs-fan-hwmon  : hwmon driver for fan trays
>> +jnx,i2c-mux-i2cs: I2C Mux driver for FPC FRUs
>> +jnx,leds-i2cs   : Led driver
>> +
>> +All these optional nodes are described in their respective binding
>> +documents.
>> +
>> +Example node:
>> +
>> +i2cs@54 {
>> +compatible = "jnx,i2cs-fpc";
>> +reg = <0x54>;
>> +#address-cells = <0>;
>> +#size-cells = <0>;
>> +
>> +fpc2_mux {
> 
> Generic node names please.
> 

OK.

> mux { 
> 
>> +compatible = "jnx,i2c-mux-i2cs";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +fpc2i2c0: i2c@0 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +reg = <0>;
>> +};
>> +};
>> +
>> +fpc2_gpiomap: gpio-jnx-i2cs {
> 
> gpio@54 {
> 
OK

>> +compatible = "jnx,gpio-i2cs";
>> +reg = <0x54>;
>> +#gpio-cells = <2>;
>> +gpio-controller;
>> +interrupt-controller;
>> +
>> +/*
>> + * Map bits [0-3] of reg 0x21 as gpio inputs, bits [4-7]
>> + * as gpio outputs
>> + */
>> +i2c-gpio-map = <0x21 0x0f>;
>> +};
>> +
>> +leds-jnx-i2cs {
> 
> leds {
> 

OK.

>> +compatible = "jnx,leds-i2cs";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +sib8-active {
>> +reg = <0>;
>> +linux,default-trigger = "sib8-active";
>> +};
>> +};
>> +};
>> -- 
>> 1.9.1

Re: [PATCH 04/10] i2c: i2c-mux-i2cs: Add device tree bindings

[Pantelis Antoniou]

Hi Rob,

> On Oct 10, 2016, at 18:48 , Peter Rosin <p...@axentia.se> wrote:
> 
> On 2016-10-07 17:21, Pantelis Antoniou wrote:
>> From: Georgi Vlaev <gvl...@juniper.net>
>> 
>> Add binding document for the i2c mux driver of Juniper's I2CS FPGA.
>> 
>> Signed-off-by: Georgi Vlaev <gvl...@juniper.net>
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
>> ---
>> .../devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt   | 27 
>> ++
>> 1 file changed, 27 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt 
>> b/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt
>> new file mode 100644
>> index 000..03d917f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt
>> @@ -0,0 +1,27 @@
>> +* Juniper I2C Mux on I2CS
>> +
>> +I2C mux driver for switching the RE access to the FPC i2c bus.
>> +Compatible with the FPC variant of the I2CS.
>> +
>> +Required properties:
>> +
>> +  - compatible: "jnx,i2cs-mux-i2cs".
> 
> jnx,i2c-mux-i2cs
> 

OK.

>> +
>> +The following required properties are defined externally:
>> +
>> +  - Standard I2C mux properties. See i2c-mux.txt in this directory.
> 
> To accommodate changes pending for 4.9, change "mux" to "gate" in
> this line…
> 

OK, interesting.


>> +  - I2C child bus nodes. See i2c-mux.txt in this directory.
> 
> This line is wrong since the child nodes themselves are optional in
> i2c-gate.txt (and i2c-mux.txt). I guess you can just drop it since
> the child nodes are mentioned in i2c-gate.txt (and i2c-mux.txt).
> 

OK then.

>> +
>> +Example:
>> +
>> +fpc0_mux {
>> +compatible = "jnx,i2c-mux-i2cs";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
> 
> ...drop these two...
> 
>> +
>> +fpc0i2c0: i2c@0 {
> 
> ...change i2c@0 to i2c-gate...
> 
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +reg = <0>;
> 
> ...and drop reg.
> 
> Cheers,
> Peter
> 

OK on all.

>> +};
>> +};

Re: [PATCH 04/10] i2c: i2c-mux-i2cs: Add device tree bindings

[Pantelis Antoniou]

Hi Rob,

> On Oct 10, 2016, at 18:48 , Peter Rosin  wrote:
> 
> On 2016-10-07 17:21, Pantelis Antoniou wrote:
>> From: Georgi Vlaev 
>> 
>> Add binding document for the i2c mux driver of Juniper's I2CS FPGA.
>> 
>> Signed-off-by: Georgi Vlaev 
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou 
>> ---
>> .../devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt   | 27 
>> ++
>> 1 file changed, 27 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt 
>> b/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt
>> new file mode 100644
>> index 000..03d917f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/i2c/jnx,i2c-mux-i2cs.txt
>> @@ -0,0 +1,27 @@
>> +* Juniper I2C Mux on I2CS
>> +
>> +I2C mux driver for switching the RE access to the FPC i2c bus.
>> +Compatible with the FPC variant of the I2CS.
>> +
>> +Required properties:
>> +
>> +  - compatible: "jnx,i2cs-mux-i2cs".
> 
> jnx,i2c-mux-i2cs
> 

OK.

>> +
>> +The following required properties are defined externally:
>> +
>> +  - Standard I2C mux properties. See i2c-mux.txt in this directory.
> 
> To accommodate changes pending for 4.9, change "mux" to "gate" in
> this line…
> 

OK, interesting.


>> +  - I2C child bus nodes. See i2c-mux.txt in this directory.
> 
> This line is wrong since the child nodes themselves are optional in
> i2c-gate.txt (and i2c-mux.txt). I guess you can just drop it since
> the child nodes are mentioned in i2c-gate.txt (and i2c-mux.txt).
> 

OK then.

>> +
>> +Example:
>> +
>> +fpc0_mux {
>> +compatible = "jnx,i2c-mux-i2cs";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
> 
> ...drop these two...
> 
>> +
>> +fpc0i2c0: i2c@0 {
> 
> ...change i2c@0 to i2c-gate...
> 
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +reg = <0>;
> 
> ...and drop reg.
> 
> Cheers,
> Peter
> 

OK on all.

>> +};
>> +};

Re: [PATCH 2/4] mfd: ptxpmb-ext-cpld: Add documentation for PTXPMB extended CPLD

[Pantelis Antoniou]

Hi Rob,

> On Oct 10, 2016, at 23:10 , Rob Herring <r...@kernel.org> wrote:
> 
> On Fri, Oct 07, 2016 at 06:19:32PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev <gvl...@juniper.net>
>> 
>> Add DT bindings document for the PTXPMB extended CPLD device.
>> 
>> Signed-off-by: Georgi Vlaev <gvl...@juniper.net>
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
>> ---
>> .../bindings/mfd/jnx-ptxpmb-ext-cpld.txt   | 35 
>> ++
>> 1 file changed, 35 insertions(+)
>> create mode 100644 
>> Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt 
>> b/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt
>> new file mode 100644
>> index 000..098a548a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt
>> @@ -0,0 +1,35 @@
>> +* Device tree bindings for Juniper's PTXPMB Extended CPLD FPGA MFD driver
>> +
>> +The device supports a gpio block which is described in the
>> +jnx-gpio-ptxpmb-ext-cpld document.
>> +
>> +Required properties:
>> +
>> +- compatible:   "jnx,ptxpmb-ext-cpld"
>> +
>> +- reg:  contains offset/length value for device state 
>> control
>> +registers space.
>> +
>> +Optional properties:
>> +
>> +- interrupts:   The interrupt line(s) the /IRQ signal(s) for 
>> the device is
>> +connected to.
>> +
>> +- interrupt-parent: The parent interrupt controller.
>> +
>> +Example:
>> +
>> +ext-cpld@1,0 {
>> +compatible = "jnx,ptxpmb-ext-cpld";
>> +reg = <0x1 0 0x1000>;
> 
> What's the bus type here? Unit address is probably wrong.
> 

localbus on a gpmc memory controller.

>> +interrupt-parent = <>;
>> +interrupts = <7 2>, <8 2>;
>> +
>> +gpio_ext_cpld: cpld-ext-gpio {
>> +compatible = "jnx,gpio-ptxpmb-ext-cpld";
>> +#gpio-cells = <2>;
>> +#interrupt-cells = <2>;
>> +gpio-controller;
>> +interrupt-controller;
>> +};
>> +};
>> -- 
>> 1.9.1

Re: [PATCH 2/4] mfd: ptxpmb-ext-cpld: Add documentation for PTXPMB extended CPLD

[Pantelis Antoniou]

Hi Rob,

> On Oct 10, 2016, at 23:10 , Rob Herring  wrote:
> 
> On Fri, Oct 07, 2016 at 06:19:32PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev 
>> 
>> Add DT bindings document for the PTXPMB extended CPLD device.
>> 
>> Signed-off-by: Georgi Vlaev 
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou 
>> ---
>> .../bindings/mfd/jnx-ptxpmb-ext-cpld.txt   | 35 
>> ++
>> 1 file changed, 35 insertions(+)
>> create mode 100644 
>> Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt 
>> b/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt
>> new file mode 100644
>> index 000..098a548a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/jnx-ptxpmb-ext-cpld.txt
>> @@ -0,0 +1,35 @@
>> +* Device tree bindings for Juniper's PTXPMB Extended CPLD FPGA MFD driver
>> +
>> +The device supports a gpio block which is described in the
>> +jnx-gpio-ptxpmb-ext-cpld document.
>> +
>> +Required properties:
>> +
>> +- compatible:   "jnx,ptxpmb-ext-cpld"
>> +
>> +- reg:  contains offset/length value for device state 
>> control
>> +registers space.
>> +
>> +Optional properties:
>> +
>> +- interrupts:   The interrupt line(s) the /IRQ signal(s) for 
>> the device is
>> +connected to.
>> +
>> +- interrupt-parent: The parent interrupt controller.
>> +
>> +Example:
>> +
>> +ext-cpld@1,0 {
>> +compatible = "jnx,ptxpmb-ext-cpld";
>> +reg = <0x1 0 0x1000>;
> 
> What's the bus type here? Unit address is probably wrong.
> 

localbus on a gpmc memory controller.

>> +interrupt-parent = <>;
>> +interrupts = <7 2>, <8 2>;
>> +
>> +gpio_ext_cpld: cpld-ext-gpio {
>> +compatible = "jnx,gpio-ptxpmb-ext-cpld";
>> +#gpio-cells = <2>;
>> +#interrupt-cells = <2>;
>> +gpio-controller;
>> +interrupt-controller;
>> +};
>> +};
>> -- 
>> 1.9.1

Re: [PATCH 08/10] mtd: flash-sam: Bindings for Juniper's SAM FPGA flash

[Pantelis Antoniou]

Hi Rob,

> On Oct 10, 2016, at 23:07 , Rob Herring <r...@kernel.org> wrote:
> 
> gOn Fri, Oct 07, 2016 at 06:18:36PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev <gvl...@juniper.net>
>> 
>> Add binding document for Junipers Flash IP block present
>> in the SAM FPGA on PTX series of routers.
>> 
>> Signed-off-by: Georgi Vlaev <gvl...@juniper.net>
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
>> ---
>> .../devicetree/bindings/mtd/flash-sam.txt  | 31 
>> ++
>> 1 file changed, 31 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/flash-sam.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/mtd/flash-sam.txt 
>> b/Documentation/devicetree/bindings/mtd/flash-sam.txt
>> new file mode 100644
>> index 000..bdf1d78
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/flash-sam.txt
>> @@ -0,0 +1,31 @@
>> +Flash device on a Juniper SAM FPGA
>> +
>> +These flash chips are found in the PTX series of Juniper routers.
>> +
>> +They are regular CFI compatible (Intel or AMD extended) flash chips with
>> +some special write protect/VPP bits that can be controlled by the machine's
>> +system controller.
> 
> And where's the description of the sys ctrlr?
> 

The system controller is Juniper IP. We’ll have to ask around about
specifics, and it’s pretty uninspiring stuff.

>> +
>> +Required properties:
>> +- compatible : must be "jnx,flash-sam"
>> +
>> +Optional properties:
>> +- reg : memory address for the flash chip, note that this is not
>> +required since usually the device is a subdevice of the SAM MFD
>> +driver which fills in the register fields.
>> +
>> +For the rest of the properties, see mtd-physmap.txt.
>> +
>> +The device tree may optionally contain sub-nodes describing partitions of 
>> the
>> +address space. See partition.txt for more detail.
>> +
>> +Example:
>> +
>> +flash_sam {
>> +compatible = "jnx,flash-sam";
>> +partition@0 {
> 
> This should have a heirarchy of a controller node, a flash child node, 
> partitions child node, and partition child nodes.
> 

OK.

>> +reg = <0x0 0x40>;
>> +label = "pic0-golden";
>> +read-only;
>> +};
>> +};
>> -- 
>> 1.9.1

Re: [PATCH 08/10] mtd: flash-sam: Bindings for Juniper's SAM FPGA flash

[Pantelis Antoniou]

Hi Rob,

> On Oct 10, 2016, at 23:07 , Rob Herring  wrote:
> 
> gOn Fri, Oct 07, 2016 at 06:18:36PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev 
>> 
>> Add binding document for Junipers Flash IP block present
>> in the SAM FPGA on PTX series of routers.
>> 
>> Signed-off-by: Georgi Vlaev 
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou 
>> ---
>> .../devicetree/bindings/mtd/flash-sam.txt  | 31 
>> ++
>> 1 file changed, 31 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/flash-sam.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/mtd/flash-sam.txt 
>> b/Documentation/devicetree/bindings/mtd/flash-sam.txt
>> new file mode 100644
>> index 000..bdf1d78
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/flash-sam.txt
>> @@ -0,0 +1,31 @@
>> +Flash device on a Juniper SAM FPGA
>> +
>> +These flash chips are found in the PTX series of Juniper routers.
>> +
>> +They are regular CFI compatible (Intel or AMD extended) flash chips with
>> +some special write protect/VPP bits that can be controlled by the machine's
>> +system controller.
> 
> And where's the description of the sys ctrlr?
> 

The system controller is Juniper IP. We’ll have to ask around about
specifics, and it’s pretty uninspiring stuff.

>> +
>> +Required properties:
>> +- compatible : must be "jnx,flash-sam"
>> +
>> +Optional properties:
>> +- reg : memory address for the flash chip, note that this is not
>> +required since usually the device is a subdevice of the SAM MFD
>> +driver which fills in the register fields.
>> +
>> +For the rest of the properties, see mtd-physmap.txt.
>> +
>> +The device tree may optionally contain sub-nodes describing partitions of 
>> the
>> +address space. See partition.txt for more detail.
>> +
>> +Example:
>> +
>> +flash_sam {
>> +compatible = "jnx,flash-sam";
>> +partition@0 {
> 
> This should have a heirarchy of a controller node, a flash child node, 
> partitions child node, and partition child nodes.
> 

OK.

>> +reg = <0x0 0x40>;
>> +label = "pic0-golden";
>> +read-only;
>> +};
>> +};
>> -- 
>> 1.9.1

Re: [PATCH 06/10] gpio: sam: Document bindings of SAM FPGA GPIO block

[Pantelis Antoniou]

Hi Rob,

> On Oct 10, 2016, at 23:03 , Rob Herring <r...@kernel.org> wrote:
> 
> On Fri, Oct 07, 2016 at 06:18:34PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev <gvl...@juniper.net>
>> 
>> Add device tree bindings document for the GPIO driver of
>> Juniper's SAM FPGA.
>> 
>> Signed-off-by: Georgi Vlaev <gvl...@juniper.net>
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
>> ---
>> .../devicetree/bindings/gpio/jnx,gpio-sam.txt  | 110 
>> +
>> 1 file changed, 110 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt 
>> b/Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt
>> new file mode 100644
>> index 000..514c350
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt
>> @@ -0,0 +1,110 @@
>> +Juniper SAM FPGA GPIO block
>> +
>> +The controller's registers are organized as sets of eight 32-bit
>> +registers with each set controlling a bank of up to 32 pins.  A single
>> +interrupt is shared for all of the banks handled by the controller.
>> +
>> +Required properties:
>> +
>> +- compatible:
>> +Must be "jnx,gpio-sam"
>> +
>> +- #gpio-cells:
>> +Should be <2>.  The first cell is the pin number (within the 
>> controller's
>> +pin space), and the second is used for the following flags:
>> +bit[0]: direction (0 = out, 1 = in)
>> +bit[1]: init high
>> +bit[2]: active low
>> +bit[3]: open drain
>> +bit[4]: open drain
> 
> Use and/or add to standard flags.
> 

OK.

>> +
>> +- gpio-controller:
>> +Specifies that the node is a GPIO controller.
>> +
>> +Optional properties:
>> +
>> +- reg:
>> +This driver is part of the SAM FPGA MFD driver, so the
>> +address range is supplied by that driver. However you can
>> +override using this property.
>> +
>> +- gpio-base:
>> +Base of the GPIO pins of this instance. If not present use system 
>> allocated.
> 
> This probably needs to go.
> 

OK.

>> +
>> +- gpio-count:
> 
> ngpios instead.
> 

OK.

>> +Number of GPIO pins of this instance. If not present read the number 
>> from
>> +the one configured in the FPGA data. Maximum number is 512.
>> +
>> +- #interrupt-cells:
>> +Should be <2>.  The first cell is the GPIO number, the second should 
>> specify
>> +flags.  The following subset of flags is supported:
>> +- bits[16,4:0] trigger type and level flags
>> +bit  0: rising edge interrupt
>> +bit  1: falling edge interrupt
>> +bit  2: active high interrupt
>> +bit  3: active low interrupt
>> +bit  4: enable debounce
>> +bit 16: signal is active low
> 
> What does this mean?
> 

I will reword.

>> +See also 
>> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>> +
>> +- gpio-interrupts:
>> +A number of triples that define the mapping of interrupt groupsb to a 
>> range of
>> +pins. The first cell defines the interrupt group, the second is the 
>> start of
>> +the pin range and the third the number of pins in the range.
> 
> Needs a vendor prefix.
> 

OK.

>> +
>> +- gpio-exports:
>> +A subnode containing the list of pins that will be exported to 
>> user-space.
> 
> DT doesn't know about userspace. Drop this.
> 

OK, the export bit should go. 

>> +Each subnode contains:
>> +Required properties:
>> +- pin: The gpio to be exported and the relevant flags.
>> +Optional properties:
>> +- label: The label to use for export; if not supplied use the node 
>> name.
>> +
>> +Example:
>> +
>> +gpio20: gpio-sam {
>> +compatible = "jnx,gpio-sam";
>> +gpio-controller;
>> +interrupt-controller;
>> +/* 1st cell: gpio pin
>> + * 2nd cell: flags (bit mask)
>> + * bit  0: rising edge interrupt
>> + * bit  1: falling edge interrupt
>> + * bit  2: active high interrupt
>> + * bit  3: active low interrupt
>> + * bit  4: enable debounce
>> + * bit 16: signal is active low
>> + */
>> +#interrupt-cells = <2>;
>> +#gpio-cells = <2>;
>> +gpio-c

Re: [PATCH 06/10] gpio: sam: Document bindings of SAM FPGA GPIO block

[Pantelis Antoniou]

Hi Rob,

> On Oct 10, 2016, at 23:03 , Rob Herring  wrote:
> 
> On Fri, Oct 07, 2016 at 06:18:34PM +0300, Pantelis Antoniou wrote:
>> From: Georgi Vlaev 
>> 
>> Add device tree bindings document for the GPIO driver of
>> Juniper's SAM FPGA.
>> 
>> Signed-off-by: Georgi Vlaev 
>> [Ported from Juniper kernel]
>> Signed-off-by: Pantelis Antoniou 
>> ---
>> .../devicetree/bindings/gpio/jnx,gpio-sam.txt  | 110 
>> +
>> 1 file changed, 110 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt 
>> b/Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt
>> new file mode 100644
>> index 000..514c350
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/jnx,gpio-sam.txt
>> @@ -0,0 +1,110 @@
>> +Juniper SAM FPGA GPIO block
>> +
>> +The controller's registers are organized as sets of eight 32-bit
>> +registers with each set controlling a bank of up to 32 pins.  A single
>> +interrupt is shared for all of the banks handled by the controller.
>> +
>> +Required properties:
>> +
>> +- compatible:
>> +Must be "jnx,gpio-sam"
>> +
>> +- #gpio-cells:
>> +Should be <2>.  The first cell is the pin number (within the 
>> controller's
>> +pin space), and the second is used for the following flags:
>> +bit[0]: direction (0 = out, 1 = in)
>> +bit[1]: init high
>> +bit[2]: active low
>> +bit[3]: open drain
>> +bit[4]: open drain
> 
> Use and/or add to standard flags.
> 

OK.

>> +
>> +- gpio-controller:
>> +Specifies that the node is a GPIO controller.
>> +
>> +Optional properties:
>> +
>> +- reg:
>> +This driver is part of the SAM FPGA MFD driver, so the
>> +address range is supplied by that driver. However you can
>> +override using this property.
>> +
>> +- gpio-base:
>> +Base of the GPIO pins of this instance. If not present use system 
>> allocated.
> 
> This probably needs to go.
> 

OK.

>> +
>> +- gpio-count:
> 
> ngpios instead.
> 

OK.

>> +Number of GPIO pins of this instance. If not present read the number 
>> from
>> +the one configured in the FPGA data. Maximum number is 512.
>> +
>> +- #interrupt-cells:
>> +Should be <2>.  The first cell is the GPIO number, the second should 
>> specify
>> +flags.  The following subset of flags is supported:
>> +- bits[16,4:0] trigger type and level flags
>> +bit  0: rising edge interrupt
>> +bit  1: falling edge interrupt
>> +bit  2: active high interrupt
>> +bit  3: active low interrupt
>> +bit  4: enable debounce
>> +bit 16: signal is active low
> 
> What does this mean?
> 

I will reword.

>> +See also 
>> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>> +
>> +- gpio-interrupts:
>> +A number of triples that define the mapping of interrupt groupsb to a 
>> range of
>> +pins. The first cell defines the interrupt group, the second is the 
>> start of
>> +the pin range and the third the number of pins in the range.
> 
> Needs a vendor prefix.
> 

OK.

>> +
>> +- gpio-exports:
>> +A subnode containing the list of pins that will be exported to 
>> user-space.
> 
> DT doesn't know about userspace. Drop this.
> 

OK, the export bit should go. 

>> +Each subnode contains:
>> +Required properties:
>> +- pin: The gpio to be exported and the relevant flags.
>> +Optional properties:
>> +- label: The label to use for export; if not supplied use the node 
>> name.
>> +
>> +Example:
>> +
>> +gpio20: gpio-sam {
>> +compatible = "jnx,gpio-sam";
>> +gpio-controller;
>> +interrupt-controller;
>> +/* 1st cell: gpio pin
>> + * 2nd cell: flags (bit mask)
>> + * bit  0: rising edge interrupt
>> + * bit  1: falling edge interrupt
>> + * bit  2: active high interrupt
>> + * bit  3: active low interrupt
>> + * bit  4: enable debounce
>> + * bit 16: signal is active low
>> + */
>> +#interrupt-cells = <2>;
>> +#gpio-cells = <2>;
>> +gpio-count = <340>;
>> +/* 1st cell: gpio interrupt status bit
>> + * 2nd cell: 1st pin
>> + * 3rd cell: #

Re: [RFC 0/2] Juniper DT based connector driver

[Pantelis Antoniou]

Hi Rob,

> On Oct 8, 2016, at 19:10 , Rob Herring <robh...@kernel.org> wrote:
> 
> On Fri, Oct 7, 2016 at 10:16 AM, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
>> Introduce a Juniper PTX router series DT overlay based
>> connector driver.
>> 
>> This is submitted as an RFC since some OF infrastructure
>> patches (like changeset helpers etc) are not yet mainlined.
> 
> Because you haven't sent them out again. There were only minor issues.
> Someone else said recently they were going to refresh them, but I
> haven't seen them.
> 

Yes, they will go out right after ELCE.

> Rob

Regards

— Pantelis

Re: [RFC 0/2] Juniper DT based connector driver

[Pantelis Antoniou]

Hi Rob,

> On Oct 8, 2016, at 19:10 , Rob Herring  wrote:
> 
> On Fri, Oct 7, 2016 at 10:16 AM, Pantelis Antoniou
>  wrote:
>> Introduce a Juniper PTX router series DT overlay based
>> connector driver.
>> 
>> This is submitted as an RFC since some OF infrastructure
>> patches (like changeset helpers etc) are not yet mainlined.
> 
> Because you haven't sent them out again. There were only minor issues.
> Someone else said recently they were going to refresh them, but I
> haven't seen them.
> 

Yes, they will go out right after ELCE.

> Rob

Regards

— Pantelis

Re: [RFC 1/2] staging: jnx: Add Juniper connector driver

[Pantelis Antoniou]

Hi Joe,

> On Oct 7, 2016, at 19:25 , Joe Perches <j...@perches.com> wrote:
> 
> On Fri, 2016-10-07 at 18:16 +0300, Pantelis Antoniou wrote:
>> diff --git a/drivers/staging/jnx/jnx-connector.c 
>> b/drivers/staging/jnx/jnx-connector.c
> []
>> +struct jnx_conn_data {
>> +struct device *dev; /* parent (platform) device */
>> +const char *name[NUM_OVERLAYS]; /* overlay file names */
>> +bool enabled;   /* true if can handle interrupts */
>> +bool poweron;   /* true if assumed to be powered on */
> 
> maybe use pahole and remove some of the wasteful padding
> 

Yes, good idea; this structure sorta grew organically.

>> +int attention_button;   /* attention button gpio pin */
>> +bool have_attention_button; /* true if attention button exists */
>> +unsigned long attention_button_holdtime;/* button hold time, jiffies */
>> +bool attention_ignore;  /* true if handled by user space */
>> +int power_enable;   /* power enable gpio pin */
>> +bool auto_enable;   /* true if board should auto-enable */
>> +struct jnx_i2c_power_seq pon;   /* power-on sequence */
> []
>> +u32 gpio_flags;
>> +u16 assembly_id;
>> +int slot;   /* slot number */
>> +int type;   /* card type */
>> +bool static_assembly_id;/* true if assembly_id is static */
>> +bool assembly_id_valid; /* true if assembly_id is valid */
>> +int adapter;/* parent i2c adapter number */
> []
>> +struct mutex mutex; /* mutex to protect state changes */
>> +bool synchronous;   /* true if state changes are ok */
>> +struct mutex fdt_mutex; /* mutex to protect fdt accesses */
> []
>> +bool standby_to_master; /* standby:master_ev processing */
>> +};
> []
>> +/*
>> + * jnx_conn_insert_ideeprom()
>> + *   Inserts ideeprom with a parent from OF prop
>> + */
>> +static int jnx_conn_insert_ideeprom(struct jnx_conn_data *data,
>> +struct i2c_adapter *adap,
>> +struct device_node *node,
>> +struct i2c_board_info *info)
>> +{
>> +struct device *dev = data->dev;
>> +struct i2c_adapter *parent = NULL;
>> +struct i2c_client *client;
>> +struct device_node *anode;
>> +struct at24_platform_data at24_pdata = {
>> +.byte_len = 256,
>> +.page_size = 4,
>> +.setup = jnx_conn_at24_callback,
>> +.context = data,
>> +};
>> +
>> +info->platform_data = _pdata;
> 
> Assigning a temporary address through a pointer argument?
> Isn't there a better way?
> 

Yeah, it is weird; it works but its risky.

I’ll change it.

>> +/*
>> + * jnx_conn_verify_overlay()
>> + *
>> + * Verify if overlay is compatible with this board/slot
>> + */
>> +static int jnx_conn_verify_overlay(struct jnx_conn_data *data,
>> +   struct device_node *np)
>> +{
> []
>> +ret = of_property_read_u32(np, "type", );
>> +if (ret) {
>> +dev_err(dev, "Missing type property\n");
>> +return ret;
>> +}
>> +if (var != data->type) {
>> +dev_err(dev, "Wrong type: Expected %d, got %d\n",
>> +data->type, var);
>> +return -EINVAL;
>> +}
>> +
>> +/*
>> + * 'assembly-ids' property must exist, and one of its entries must match
>> + * the card assembly id
>> + */
>> +assembly_ids = of_get_property(np, "assembly-ids", );
>> +if (!assembly_ids || size < sizeof(u32)) {
>> +dev_err(dev, "Bad assembly-ids property\n");
>> +return -EINVAL;
>> +}
>> +ret = -EINVAL;
>> +for (i = 0; i < size / sizeof(u32); i++) {
>> +if (be32_to_cpu(assembly_ids[i]) == data->assembly_id) {
>> +ret = 0;
>> +break;
>> +}
>> +}
>> +if (ret) {
>> +dev_err(dev, "Assembly ID 0x%x not supported by overlay\n",
>> +data->assembly_id);
>> +return ret;
>> +}
> 
> Given all the direct returns above here, perhaps
> 
>   for (i = 0; i < size / sizeof(u32); i++) {
>   if (be32_to_cpu(assembly_ids[i]) == data->assembly_id)
>   return 0;
>   }
> 

It does look better.

>   dev_err(...);
>   return -EINVAL;
> 
> 


Regards

— Pantelis

Re: [RFC 1/2] staging: jnx: Add Juniper connector driver

[Pantelis Antoniou]

Hi Joe,

> On Oct 7, 2016, at 19:25 , Joe Perches  wrote:
> 
> On Fri, 2016-10-07 at 18:16 +0300, Pantelis Antoniou wrote:
>> diff --git a/drivers/staging/jnx/jnx-connector.c 
>> b/drivers/staging/jnx/jnx-connector.c
> []
>> +struct jnx_conn_data {
>> +struct device *dev; /* parent (platform) device */
>> +const char *name[NUM_OVERLAYS]; /* overlay file names */
>> +bool enabled;   /* true if can handle interrupts */
>> +bool poweron;   /* true if assumed to be powered on */
> 
> maybe use pahole and remove some of the wasteful padding
> 

Yes, good idea; this structure sorta grew organically.

>> +int attention_button;   /* attention button gpio pin */
>> +bool have_attention_button; /* true if attention button exists */
>> +unsigned long attention_button_holdtime;/* button hold time, jiffies */
>> +bool attention_ignore;  /* true if handled by user space */
>> +int power_enable;   /* power enable gpio pin */
>> +bool auto_enable;   /* true if board should auto-enable */
>> +struct jnx_i2c_power_seq pon;   /* power-on sequence */
> []
>> +u32 gpio_flags;
>> +u16 assembly_id;
>> +int slot;   /* slot number */
>> +int type;   /* card type */
>> +bool static_assembly_id;/* true if assembly_id is static */
>> +bool assembly_id_valid; /* true if assembly_id is valid */
>> +int adapter;/* parent i2c adapter number */
> []
>> +struct mutex mutex; /* mutex to protect state changes */
>> +bool synchronous;   /* true if state changes are ok */
>> +struct mutex fdt_mutex; /* mutex to protect fdt accesses */
> []
>> +bool standby_to_master; /* standby:master_ev processing */
>> +};
> []
>> +/*
>> + * jnx_conn_insert_ideeprom()
>> + *   Inserts ideeprom with a parent from OF prop
>> + */
>> +static int jnx_conn_insert_ideeprom(struct jnx_conn_data *data,
>> +struct i2c_adapter *adap,
>> +struct device_node *node,
>> +struct i2c_board_info *info)
>> +{
>> +struct device *dev = data->dev;
>> +struct i2c_adapter *parent = NULL;
>> +struct i2c_client *client;
>> +struct device_node *anode;
>> +struct at24_platform_data at24_pdata = {
>> +.byte_len = 256,
>> +.page_size = 4,
>> +.setup = jnx_conn_at24_callback,
>> +.context = data,
>> +};
>> +
>> +info->platform_data = _pdata;
> 
> Assigning a temporary address through a pointer argument?
> Isn't there a better way?
> 

Yeah, it is weird; it works but its risky.

I’ll change it.

>> +/*
>> + * jnx_conn_verify_overlay()
>> + *
>> + * Verify if overlay is compatible with this board/slot
>> + */
>> +static int jnx_conn_verify_overlay(struct jnx_conn_data *data,
>> +   struct device_node *np)
>> +{
> []
>> +ret = of_property_read_u32(np, "type", );
>> +if (ret) {
>> +dev_err(dev, "Missing type property\n");
>> +return ret;
>> +}
>> +if (var != data->type) {
>> +dev_err(dev, "Wrong type: Expected %d, got %d\n",
>> +data->type, var);
>> +return -EINVAL;
>> +}
>> +
>> +/*
>> + * 'assembly-ids' property must exist, and one of its entries must match
>> + * the card assembly id
>> + */
>> +assembly_ids = of_get_property(np, "assembly-ids", );
>> +if (!assembly_ids || size < sizeof(u32)) {
>> +dev_err(dev, "Bad assembly-ids property\n");
>> +return -EINVAL;
>> +}
>> +ret = -EINVAL;
>> +for (i = 0; i < size / sizeof(u32); i++) {
>> +if (be32_to_cpu(assembly_ids[i]) == data->assembly_id) {
>> +ret = 0;
>> +break;
>> +}
>> +}
>> +if (ret) {
>> +dev_err(dev, "Assembly ID 0x%x not supported by overlay\n",
>> +data->assembly_id);
>> +return ret;
>> +}
> 
> Given all the direct returns above here, perhaps
> 
>   for (i = 0; i < size / sizeof(u32); i++) {
>   if (be32_to_cpu(assembly_ids[i]) == data->assembly_id)
>   return 0;
>   }
> 

It does look better.

>   dev_err(...);
>   return -EINVAL;
> 
> 


Regards

— Pantelis

Re: [PATCH 0/6] Introduce Juniper CBC FPGA

[Pantelis Antoniou]

Hi Greg,

> On Oct 7, 2016, at 18:39 , Greg Kroah-Hartman <gre...@linuxfoundation.org> 
> wrote:
> 
> On Fri, Oct 07, 2016 at 06:20:08PM +0300, Pantelis Antoniou wrote:
>> Add Juniper's PTX1K CBC FPGA driver. Those FPGAs
>> are present in Juniper's PTX series of routers.
>> 
>> The MFD driver provices a gpio device and a special
>> driver for Juniper's board infrastucture.
>> The FPGA infrastucture driver is providing an interface
>> for user-space handling of the FPGA in those platforms.
>> 
>> There are full device tree binding documents for the
>> master mfd driver and for the slave driver.
>> 
>> This patchset is against mainline as of today: v4.8-9431-g3477d16
>> and is dependent on the "Juniper prerequisites" and
>> "Juniper infrastructure" patchsets sent earlier.
>> 
>> Georgi Vlaev (5):
>>  mfd: Add support for the PTX1K CBC FPGA
>>  gpio: Add support for PTX1K CBC FPGA spare GPIOs
>>  gpio: gpio-cbc: Document bindings of CBC FPGA GPIO block
>>  gpio: cbc-presence: Add CBC presence detect as GPIO driver
>>  gpio: gpio-cbc-presense: Document bindings of CBC FPGA presence
>> 
>> Tom Kavanagh (1):
>>  staging: jnx: CBD-FPGA infrastructure
>> 
>> .../bindings/gpio/jnx,gpio-cbc-presense.txt|  31 +
>> .../devicetree/bindings/gpio/jnx,gpio-cbc.txt  |  30 +
>> drivers/gpio/Kconfig   |  23 +
>> drivers/gpio/Makefile  |   2 +
>> drivers/gpio/gpio-cbc-presence.c   | 460 ++
>> drivers/gpio/gpio-cbc.c| 236 +
>> drivers/mfd/Kconfig|  16 +
>> drivers/mfd/Makefile   |   1 +
>> drivers/mfd/cbc-core.c | 971 
>> +
>> drivers/staging/jnx/Kconfig|  34 +
>> drivers/staging/jnx/Makefile   |   5 +
>> drivers/staging/jnx/jnx-cbc-ptx1k.c| 242 +
>> drivers/staging/jnx/jnx-cbd-fpga-common.c  | 332 +++
>> drivers/staging/jnx/jnx-cbd-fpga-common.h  |  27 +
>> drivers/staging/jnx/jnx-cbd-fpga-core.c| 540 
>> drivers/staging/jnx/jnx-cbd-fpga-core.h|  68 ++
>> drivers/staging/jnx/jnx-cbd-fpga-platdata.h|  51 ++
>> drivers/staging/jnx/jnx-cbd-fpga-ptx1k.c   | 134 +++
>> drivers/staging/jnx/jnx-cbd-fpga-ptx21k.c  | 143 +++
>> drivers/staging/jnx/jnx-cbd-fpga-ptx3k.c   | 111 +++
>> drivers/staging/jnx/jnx-cbd-fpga-ptx5k.c   | 107 +++
>> include/linux/mfd/cbc-core.h   | 181 
>> 22 files changed, 3745 insertions(+)
> 
> Please don't mix driver submissions like this.  Staging stuff needs to
> go to the staging maintainer, gpio to that one, mfd to that one, and so
> on.
> 
> there's almost nothing anyone can do with this series as-is, sorry.
> 
> please split it up.
> 

Now I’m confused, this is a typical MFD submission:

https://lwn.net/Articles/587032/

Looks like it’s normal for a single patchset against multiple subsystems.

Do we have a definitive form for this?

> thanks,
> 
> greg k-h

Regards

— Pantelis

Re: [PATCH 0/6] Introduce Juniper CBC FPGA

[Pantelis Antoniou]

Hi Greg,

> On Oct 7, 2016, at 18:39 , Greg Kroah-Hartman  
> wrote:
> 
> On Fri, Oct 07, 2016 at 06:20:08PM +0300, Pantelis Antoniou wrote:
>> Add Juniper's PTX1K CBC FPGA driver. Those FPGAs
>> are present in Juniper's PTX series of routers.
>> 
>> The MFD driver provices a gpio device and a special
>> driver for Juniper's board infrastucture.
>> The FPGA infrastucture driver is providing an interface
>> for user-space handling of the FPGA in those platforms.
>> 
>> There are full device tree binding documents for the
>> master mfd driver and for the slave driver.
>> 
>> This patchset is against mainline as of today: v4.8-9431-g3477d16
>> and is dependent on the "Juniper prerequisites" and
>> "Juniper infrastructure" patchsets sent earlier.
>> 
>> Georgi Vlaev (5):
>>  mfd: Add support for the PTX1K CBC FPGA
>>  gpio: Add support for PTX1K CBC FPGA spare GPIOs
>>  gpio: gpio-cbc: Document bindings of CBC FPGA GPIO block
>>  gpio: cbc-presence: Add CBC presence detect as GPIO driver
>>  gpio: gpio-cbc-presense: Document bindings of CBC FPGA presence
>> 
>> Tom Kavanagh (1):
>>  staging: jnx: CBD-FPGA infrastructure
>> 
>> .../bindings/gpio/jnx,gpio-cbc-presense.txt|  31 +
>> .../devicetree/bindings/gpio/jnx,gpio-cbc.txt  |  30 +
>> drivers/gpio/Kconfig   |  23 +
>> drivers/gpio/Makefile  |   2 +
>> drivers/gpio/gpio-cbc-presence.c   | 460 ++
>> drivers/gpio/gpio-cbc.c| 236 +
>> drivers/mfd/Kconfig|  16 +
>> drivers/mfd/Makefile   |   1 +
>> drivers/mfd/cbc-core.c | 971 
>> +
>> drivers/staging/jnx/Kconfig|  34 +
>> drivers/staging/jnx/Makefile   |   5 +
>> drivers/staging/jnx/jnx-cbc-ptx1k.c| 242 +
>> drivers/staging/jnx/jnx-cbd-fpga-common.c  | 332 +++
>> drivers/staging/jnx/jnx-cbd-fpga-common.h  |  27 +
>> drivers/staging/jnx/jnx-cbd-fpga-core.c| 540 
>> drivers/staging/jnx/jnx-cbd-fpga-core.h|  68 ++
>> drivers/staging/jnx/jnx-cbd-fpga-platdata.h|  51 ++
>> drivers/staging/jnx/jnx-cbd-fpga-ptx1k.c   | 134 +++
>> drivers/staging/jnx/jnx-cbd-fpga-ptx21k.c  | 143 +++
>> drivers/staging/jnx/jnx-cbd-fpga-ptx3k.c   | 111 +++
>> drivers/staging/jnx/jnx-cbd-fpga-ptx5k.c   | 107 +++
>> include/linux/mfd/cbc-core.h   | 181 
>> 22 files changed, 3745 insertions(+)
> 
> Please don't mix driver submissions like this.  Staging stuff needs to
> go to the staging maintainer, gpio to that one, mfd to that one, and so
> on.
> 
> there's almost nothing anyone can do with this series as-is, sorry.
> 
> please split it up.
> 

Now I’m confused, this is a typical MFD submission:

https://lwn.net/Articles/587032/

Looks like it’s normal for a single patchset against multiple subsystems.

Do we have a definitive form for this?

> thanks,
> 
> greg k-h

Regards

— Pantelis

[PATCH 09/10] net: phy: Add MDIO driver for Juniper's SAM FPGA

[Pantelis Antoniou]

From: Georgi Vlaev <gvl...@juniper.net>

Add driver for the MDIO IP block present in Juniper's
SAM FPGA.

This driver supports only Clause 45 of the 802.3 spec.

Note that due to the fact that there are no drivers for
Broadcom/Avago retimers on 10/40Ge path that are controlled
from the MDIO interface there is a method to have direct
access to registers via a debugfs interface.

Signed-off-by: Georgi Vlaev <gvl...@juniper.net>
[Ported from Juniper kernel]
Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 drivers/net/phy/Kconfig|   8 +
 drivers/net/phy/Makefile   |   1 +
 drivers/net/phy/mdio-sam.c | 564 +
 3 files changed, 573 insertions(+)
 create mode 100644 drivers/net/phy/mdio-sam.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 5078a0d..7d7f265 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -122,6 +122,14 @@ config MDIO_OCTEON
  buses. It is required by the Octeon and ThunderX ethernet device
  drivers on some systems.
 
+config MDIO_SAM
+   tristate "Juniper Networks SAM FPGA MDIO controller"
+   depends on MFD_JUNIPER_SAM
+   help
+ This module provides a driver for the Juniper Network SAM FPGA MDIO
+ buses. This hardware can be found in the Gladiator PIC SAM FPGA. This
+ driver is client of the sam-core MFD driver.
+
 config MDIO_SUN4I
tristate "Allwinner sun4i MDIO interface support"
depends on ARCH_SUNXI
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e58667d..c7631cf 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_MDIO_GPIO)   += mdio-gpio.o
 obj-$(CONFIG_MDIO_HISI_FEMAC)  += mdio-hisi-femac.o
 obj-$(CONFIG_MDIO_MOXART)  += mdio-moxart.o
 obj-$(CONFIG_MDIO_OCTEON)  += mdio-octeon.o
+obj-$(CONFIG_MDIO_SAM) += mdio-sam.o
 obj-$(CONFIG_MDIO_SUN4I)   += mdio-sun4i.o
 obj-$(CONFIG_MDIO_THUNDER) += mdio-thunder.o
 obj-$(CONFIG_MDIO_XGENE)   += mdio-xgene.o
diff --git a/drivers/net/phy/mdio-sam.c b/drivers/net/phy/mdio-sam.c
new file mode 100644
index 000..73cefa1
--- /dev/null
+++ b/drivers/net/phy/mdio-sam.c
@@ -0,0 +1,564 @@
+/*
+ * Juniper Networks SAM FPGA MDIO driver.
+ *
+ * Copyright (c) 2015, Juniper Networks
+ * Author: Georgi Vlaev <gvl...@juniper.net>
+ *
+ * The MDIO bus driver supports GPQAM, GPCAM, GPQ28 FPGAs found
+ * on Juniper's 10/40/100GE Gladiator PIC cards. Only Clause 45
+ * access is currently available natively.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_DEBUG_FS
+#include 
+#include 
+#include 
+#endif
+
+#define MDIO_CMD1  0x /* Command Table 1 */
+#define MDIO_CMD2  0x0800 /* Command Table 2 */
+#define MDIO_RESULT0x1000 /* Result Table (RO) */
+#define MDIO_PRI_CMD1  0x1800 /* Priority Command Table 1 */
+#define MDIO_PRI_CMD2  0x2000 /* Priority Command Table 1 */
+#define MDIO_PRI_RESULT0x2800 /* Priority Result Table (RO) */
+#define MDIO_TBL_CMD   0x3000 /* Table Command Register (WO) */
+#define MDIO_STATUS0x3008 /* Master Status (RO) */
+#define MDIO_STATUS_INT0x3010 /* Master Status Interrupt Mask (W1C) */
+
+/* MDIO_TBL_CMD */
+#define TBL_CMD_REG_ABORT  BIT(31) /* Regular Table ABORT */
+#define TBL_CMD_REG_GO BIT(30) /* Regular Table GO */
+#define TBL_CMD_PRI_ABORT  BIT(29) /* Priority Table Abort */
+#define TBL_CMD_PRI_GO BIT(28) /* Priority Table GO */
+#define TBL_CMD_SOFT_RESET BIT(27) /* Soft Reset */
+
+/* MDIO_STATUS */
+#define STAT_REG_RDY   BIT(31) /* READY for Programming Regular Table */
+#define STAT_REG_DONE  BIT(30) /* DONE SUCCESSFULLY WITH REGULAR TABLE */
+#define STAT_PRI_RDY   BIT(29) /* READY for Programming Priority Table */
+#define STAT_PRI_DONE  BIT(28) /* DONE SUCCESSFULLY WITH PRIORITY TABLE */
+#define STAT_REG_ERR   BIT(27) /* DONE WITH ERRORS for Regular Table */
+#define STAT_PRI_ERR   BIT(26) /* DONE WITH ERRORS for Priority Table */
+#define STAT_REG_PROG_ERR  BIT(25) /* Programming Err for Regular Table */
+#define STAT_PRI_PROG_ERR  BIT(24) /* Programming Err for Priority Table */
+
+/* MDIO_CMD2, MDIO_PRI_CMD2 */
+#define CMD2_ENABLEBIT(17)
+#define CMD2_READ  BIT(16)
+
+/* MDIO_RESULT, MDIO_PRI_RESULT */
+#define RES_SUCCESSBIT(17)
+#define RES_ERROR  BIT(16)
+
+#defi

[PATCH 03/10] i2c: Juniper SAM I2C driver

[Pantelis Antoniou]

From: Maryam Seraj <mse...@juniper.net>

Introduce SAM I2C driver for the I2C interfaces on the Juniper
SAM FPGA.

Signed-off-by: Maryam Seraj <mse...@juniper.net>
Signed-off-by: Debjit Ghosh <dgh...@juniper.net>
Signed-off-by: Georgi Vlaev <gvl...@juniper.net>
Signed-off-by: Guenter Roeck <gro...@juniper.net>
Signed-off-by: Rajat Jain <rajatj...@juniper.net>
[Ported from Juniper kernel]
Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 drivers/i2c/busses/Kconfig   |  11 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-sam.c | 942 +++
 3 files changed, 954 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-sam.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 5c3993b..eeac4b2 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -833,6 +833,17 @@ config I2C_SH7760
  This driver can also be built as a module.  If so, the module
  will be called i2c-sh7760.
 
+config I2C_SAM
+   tristate "Juniper SAM FPGA I2C Controller"
+   select I2C_MUX
+   depends on MFD_JUNIPER_SAM || MFD_JUNIPER_CBC
+   help
+ This driver supports the I2C interfaces on the Juniper SAM FPGA
+ which is present on the relevant Juniper platforms.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-sam.
+
 config I2C_SH_MOBILE
tristate "SuperH Mobile I2C Controller"
depends on HAS_DMA
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 37f2819..b99b229 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_I2C_QUP) += i2c-qup.o
 obj-$(CONFIG_I2C_RIIC) += i2c-riic.o
 obj-$(CONFIG_I2C_RK3X) += i2c-rk3x.o
 obj-$(CONFIG_I2C_S3C2410)  += i2c-s3c2410.o
+obj-$(CONFIG_I2C_SAM)  += i2c-sam.o
 obj-$(CONFIG_I2C_SH7760)   += i2c-sh7760.o
 obj-$(CONFIG_I2C_SH_MOBILE)+= i2c-sh_mobile.o
 obj-$(CONFIG_I2C_SIMTEC)   += i2c-simtec.o
diff --git a/drivers/i2c/busses/i2c-sam.c b/drivers/i2c/busses/i2c-sam.c
new file mode 100644
index 000..1ec930a
--- /dev/null
+++ b/drivers/i2c/busses/i2c-sam.c
@@ -0,0 +1,942 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SAM_DEB1(dev, fmt, args...) do { \
+   if (sam_debug >= 1) \
+   dev_err(dev, fmt, ## args); \
+   } while (0)
+#define SAM_DEB2(dev, fmt, args...) do { \
+   if (sam_debug >= 2) \
+   dev_err(dev, fmt, ## args); \
+   } while (0)
+#define SAM_DEB3(dev, fmt, args...) do { \
+   if (sam_debug >= 3) \
+   dev_err(dev, fmt, ## args); } \
+   while (0)
+
+static int sam_debug;
+
+#define DRIVER_DESC"SAM FPGA I2C Driver"
+#define DRIVER_VERSION "0.2"
+#define DRIVER_AUTHOR  "Maryam Seraj <mse...@juniper.net>"
+
+#define SAM_FPGA_MODULE_NAME   "i2c-sam"
+
+#define SAM_I2C_MUX_MAX_CHAN   8
+
+#define SAM_I2C_DEV_ADDR_MASK  0x7f
+#define SAM_I2C_TBL_ENTRY_CMDS_NUM 2
+
+#define SAM_I2C_CMD_TABLE_SZ   256
+
+#define SAM_I2C_STS_DONE   (1 << 0)
+#define SAM_I2C_STS_PRIO_DONE  (1 << 1)
+#define SAM_I2C_STS_RUNNING(1 << 2)
+#define SAM_I2C_STS_PRIO_RUNNING   (1 << 3)
+#define SAM_I2C_STS_ERR(1 << 4)
+#define SAM_I2C_STS_PRIO_ERR   (1 << 5)
+#define SAM_I2C_STS_RDY(1 << 6)
+#define SAM_I2C_STS_TR_TIMEOUT (1 << 7)
+#define SAM_I2C_STS_CMD_TIMEOUT(1 << 8)
+#define SAM_I2C_STS_CMD_TABLE_TIMEOUT  (1 << 9)
+
+#define SAM_I2C_STS_CLEAR_MASK (SAM_I2C_STS_DONE \
+| SAM_I2C_STS_PRIO_DONE \
+| SAM_I2C_STS_TR_TIMEOUT \
+| SAM_I2C_STS_CMD_TIMEOUT \
+| SAM_I2C_STS_CMD_TABLE_TIMEOUT \
+| SAM_I2C_STS_ERR \
+| SAM_I2C_STS_PRIO_ERR)
+#define SAM_I2C_STS_CLEAR(x)   (((x) & ~0x3fb3) | SAM_I2C_STS_CLEAR_MASK)
+
+#define SAM_I2C_STS_TIMEOUT(SAM_I2C_STS_TR_TIMEOUT \
+| SAM_I2C_STS_CMD_TIMEOUT \
+| SAM_I2C_STS_CMD_TABLE_TIMEOUT)
+
+#define SAM_I2C_DONE(s)((s) & (SAM_I2C_STS_DONE | 
SAM_I2C_STS_ERR \
+   | SAM_I2C_STS_TIMEOUT))
+
+#define SAM_I2C_CTRL_RESET (1 << 0)
+#define SAM_I2C_CTRL_GO(1 << 1)
+#define SAM_I2C_CTRL_

[PATCH 1/6] mfd: Add support for the PTX1K CBC FPGA

[Pantelis Antoniou]

From: Georgi Vlaev <gvl...@juniper.net>

The CBC intergrates CB and SAM on single FPGA. This is a PCI MFD driver
and provides support for the following functions as subdrivers:

* SAM I2C accelerator
* SAM MTD flash
* CBC spare GPIOs
* CBC JNX infrastructure

Signed-off-by: Georgi Vlaev <gvl...@juniper.net>
Signed-off-by: Guenter Roeck <gro...@juniper.net>
Signed-off-by: Rajat Jain <rajatj...@juniper.net>
[Ported from Juniper kernel]
Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 drivers/mfd/Kconfig  |  16 +
 drivers/mfd/Makefile |   1 +
 drivers/mfd/cbc-core.c   | 971 +++
 include/linux/mfd/cbc-core.h | 181 
 4 files changed, 1169 insertions(+)
 create mode 100644 drivers/mfd/cbc-core.c
 create mode 100644 include/linux/mfd/cbc-core.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 7e1fa14..6107f7a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1384,6 +1384,22 @@ config MFD_JUNIPER_EXT_CPLD
  called "ptxpmb-ext-cpld"
 
 
+config MFD_JUNIPER_CBC
+   tristate "Juniper PTX1K CBC FPGA"
+   depends on JNX_PTX1K_RCB
+   default y if JNX_PTX1K_RCB
+   select MFD_CORE
+   select MTD
+   select MTD_SAM_FLASH
+   select I2C_SAM
+   select GPIO_CBC_PRESENCE if JNX_CONNECTOR
+   help
+ Select this to enable the CBC FPGA multi-function kernel driver.
+ This FPGA is present on the PTX1K RCB Juniper platform.
+
+ This driver can be built as a module. If built as a module it will be
+ called "cbc-core"
+
 config MFD_TWL4030_AUDIO
bool "TI TWL4030 Audio"
depends on TWL4030_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index da94482..0ea6dc6 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -151,6 +151,7 @@ obj-$(CONFIG_AB8500_GPADC)  += ab8500-gpadc.o
 obj-$(CONFIG_MFD_JUNIPER_CPLD) += ptxpmb-cpld-core.o
 obj-$(CONFIG_MFD_JUNIPER_SAM)  += sam-core.o
 obj-$(CONFIG_MFD_JUNIPER_EXT_CPLD) += ptxpmb-ext-cpld-core.o
+obj-$(CONFIG_MFD_JUNIPER_CBC)  += cbc-core.o
 obj-$(CONFIG_MFD_DB8500_PRCMU) += db8500-prcmu.o
 # ab8500-core need to come after db8500-prcmu (which provides the channel)
 obj-$(CONFIG_AB8500_CORE)  += ab8500-core.o ab8500-sysctrl.o
diff --git a/drivers/mfd/cbc-core.c b/drivers/mfd/cbc-core.c
new file mode 100644
index 000..1e6c95b
--- /dev/null
+++ b/drivers/mfd/cbc-core.c
@@ -0,0 +1,971 @@
+/*
+ * drivers/mfd/cbc-core.c
+ *
+ * Copyright (c) 2014, Juniper Networks
+ * Author: Georgi Vlaev <gvl...@juniper.net>
+ * Based on: sam-core.c
+ *
+ * The CBC FPGA intergrates the PTX1K CB and some functions of
+ * the SAM FPGA on single device. We're reusing the SAM I2C,
+ * MTD flash drivers. The JNX CB logic is implemented in
+ * drivers/jnx/jnx-cbc-ptx1k.c and drivers/jnx/jnx-cbd-fpga-ptx1k.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_DEBUG_FS
+#include 
+#include 
+#endif
+
+enum {
+   CBC_CELL_SAM_I2C,   /* SAM I2C accelerator */
+   CBC_CELL_SAM_MTD,   /* SAM EPCS64 config flash */
+   CBC_CELL_GPIO,  /* CBC spare GPIO */
+   CBC_CELL_JNX_CBD,   /* CBC CB JNX driver */
+   CBC_CELL_GPIO_PRS,  /* CBC presence as GPIO (CH_PRS) */
+   CBC_CELL_GPIO_PRS_OTHER,/* CBC presence ss GPIO (OTHER_CH_PRS) */
+   CBC_CELL_GPIO_PRS_SIB,  /* CBC presence as GPIO (CH_PRS_SIB) */
+   CBC_NUM_MFD_CELLS
+};
+
+#define CBC_IRQ_NR 31
+#define CBC_RES_NR 2 /* iomem, irq */
+#define CBC_RES_NR_NOIRQ   1 /* iomem */
+
+struct cbc_fpga_data {
+   void __iomem *membase;
+   struct pci_dev *pdev;
+   u32 fpga_rev;   /* CBC revision */
+   u32 fpga_date;  /* CBC revision date */
+   int i2c_mstr_count; /* CBC/I2C SAM master count */
+   struct irq_domain *irq_domain;
+   u32 int_src; /* interrupt src reg (MSI, legacy) */
+   u32 int_en; /* interrupt en reg (MSI, legacy) */
+   spinlock_t irq_lock;
+   struct mfd_cell mfd_cells[CBC_NUM_MFD_CELLS];
+   struct resource mfd_i2c_resources[CBC_RES_NR];
+   struct resource mfd_mtd_resources[CBC_RES_NR_NOIRQ];
+   struct resource mfd_gpio_resources[CBC_RES_NR_NOIRQ];
+   struct resource mfd_jnx_resources[CBC_RES_NR_NOIRQ];
+   struct resource mfd_gpio_prs_resources[CBC_RES_NR_NOIRQ];
+#ifdef CONFIG_DEBUG_FS
+   struct dentry *cbc_debugfs_dir;
+   u32 debug_address; /* any register offsset */
+   struct debugfs_regset32 *regset; /* all regs */
+   u32 test_int_cnt; /* TEST_I

[PATCH 09/10] net: phy: Add MDIO driver for Juniper's SAM FPGA

[Pantelis Antoniou]

From: Georgi Vlaev 

Add driver for the MDIO IP block present in Juniper's
SAM FPGA.

This driver supports only Clause 45 of the 802.3 spec.

Note that due to the fact that there are no drivers for
Broadcom/Avago retimers on 10/40Ge path that are controlled
from the MDIO interface there is a method to have direct
access to registers via a debugfs interface.

Signed-off-by: Georgi Vlaev 
[Ported from Juniper kernel]
Signed-off-by: Pantelis Antoniou 
---
 drivers/net/phy/Kconfig|   8 +
 drivers/net/phy/Makefile   |   1 +
 drivers/net/phy/mdio-sam.c | 564 +
 3 files changed, 573 insertions(+)
 create mode 100644 drivers/net/phy/mdio-sam.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 5078a0d..7d7f265 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -122,6 +122,14 @@ config MDIO_OCTEON
  buses. It is required by the Octeon and ThunderX ethernet device
  drivers on some systems.
 
+config MDIO_SAM
+   tristate "Juniper Networks SAM FPGA MDIO controller"
+   depends on MFD_JUNIPER_SAM
+   help
+ This module provides a driver for the Juniper Network SAM FPGA MDIO
+ buses. This hardware can be found in the Gladiator PIC SAM FPGA. This
+ driver is client of the sam-core MFD driver.
+
 config MDIO_SUN4I
tristate "Allwinner sun4i MDIO interface support"
depends on ARCH_SUNXI
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e58667d..c7631cf 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_MDIO_GPIO)   += mdio-gpio.o
 obj-$(CONFIG_MDIO_HISI_FEMAC)  += mdio-hisi-femac.o
 obj-$(CONFIG_MDIO_MOXART)  += mdio-moxart.o
 obj-$(CONFIG_MDIO_OCTEON)  += mdio-octeon.o
+obj-$(CONFIG_MDIO_SAM) += mdio-sam.o
 obj-$(CONFIG_MDIO_SUN4I)   += mdio-sun4i.o
 obj-$(CONFIG_MDIO_THUNDER) += mdio-thunder.o
 obj-$(CONFIG_MDIO_XGENE)   += mdio-xgene.o
diff --git a/drivers/net/phy/mdio-sam.c b/drivers/net/phy/mdio-sam.c
new file mode 100644
index 000..73cefa1
--- /dev/null
+++ b/drivers/net/phy/mdio-sam.c
@@ -0,0 +1,564 @@
+/*
+ * Juniper Networks SAM FPGA MDIO driver.
+ *
+ * Copyright (c) 2015, Juniper Networks
+ * Author: Georgi Vlaev 
+ *
+ * The MDIO bus driver supports GPQAM, GPCAM, GPQ28 FPGAs found
+ * on Juniper's 10/40/100GE Gladiator PIC cards. Only Clause 45
+ * access is currently available natively.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_DEBUG_FS
+#include 
+#include 
+#include 
+#endif
+
+#define MDIO_CMD1  0x /* Command Table 1 */
+#define MDIO_CMD2  0x0800 /* Command Table 2 */
+#define MDIO_RESULT0x1000 /* Result Table (RO) */
+#define MDIO_PRI_CMD1  0x1800 /* Priority Command Table 1 */
+#define MDIO_PRI_CMD2  0x2000 /* Priority Command Table 1 */
+#define MDIO_PRI_RESULT0x2800 /* Priority Result Table (RO) */
+#define MDIO_TBL_CMD   0x3000 /* Table Command Register (WO) */
+#define MDIO_STATUS0x3008 /* Master Status (RO) */
+#define MDIO_STATUS_INT0x3010 /* Master Status Interrupt Mask (W1C) */
+
+/* MDIO_TBL_CMD */
+#define TBL_CMD_REG_ABORT  BIT(31) /* Regular Table ABORT */
+#define TBL_CMD_REG_GO BIT(30) /* Regular Table GO */
+#define TBL_CMD_PRI_ABORT  BIT(29) /* Priority Table Abort */
+#define TBL_CMD_PRI_GO BIT(28) /* Priority Table GO */
+#define TBL_CMD_SOFT_RESET BIT(27) /* Soft Reset */
+
+/* MDIO_STATUS */
+#define STAT_REG_RDY   BIT(31) /* READY for Programming Regular Table */
+#define STAT_REG_DONE  BIT(30) /* DONE SUCCESSFULLY WITH REGULAR TABLE */
+#define STAT_PRI_RDY   BIT(29) /* READY for Programming Priority Table */
+#define STAT_PRI_DONE  BIT(28) /* DONE SUCCESSFULLY WITH PRIORITY TABLE */
+#define STAT_REG_ERR   BIT(27) /* DONE WITH ERRORS for Regular Table */
+#define STAT_PRI_ERR   BIT(26) /* DONE WITH ERRORS for Priority Table */
+#define STAT_REG_PROG_ERR  BIT(25) /* Programming Err for Regular Table */
+#define STAT_PRI_PROG_ERR  BIT(24) /* Programming Err for Priority Table */
+
+/* MDIO_CMD2, MDIO_PRI_CMD2 */
+#define CMD2_ENABLEBIT(17)
+#define CMD2_READ  BIT(16)
+
+/* MDIO_RESULT, MDIO_PRI_RESULT */
+#define RES_SUCCESSBIT(17)
+#define RES_ERROR  BIT(16)
+
+#define MDIO_RDY_TMO   30 /* in msec */
+
+struct mdio_sam_data {
+   void __iomem *base;
+#ifdef CONFIG_DEBUG_FS
+ 

[PATCH 03/10] i2c: Juniper SAM I2C driver

[Pantelis Antoniou]

From: Maryam Seraj 

Introduce SAM I2C driver for the I2C interfaces on the Juniper
SAM FPGA.

Signed-off-by: Maryam Seraj 
Signed-off-by: Debjit Ghosh 
Signed-off-by: Georgi Vlaev 
Signed-off-by: Guenter Roeck 
Signed-off-by: Rajat Jain 
[Ported from Juniper kernel]
Signed-off-by: Pantelis Antoniou 
---
 drivers/i2c/busses/Kconfig   |  11 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-sam.c | 942 +++
 3 files changed, 954 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-sam.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 5c3993b..eeac4b2 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -833,6 +833,17 @@ config I2C_SH7760
  This driver can also be built as a module.  If so, the module
  will be called i2c-sh7760.
 
+config I2C_SAM
+   tristate "Juniper SAM FPGA I2C Controller"
+   select I2C_MUX
+   depends on MFD_JUNIPER_SAM || MFD_JUNIPER_CBC
+   help
+ This driver supports the I2C interfaces on the Juniper SAM FPGA
+ which is present on the relevant Juniper platforms.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-sam.
+
 config I2C_SH_MOBILE
tristate "SuperH Mobile I2C Controller"
depends on HAS_DMA
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 37f2819..b99b229 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_I2C_QUP) += i2c-qup.o
 obj-$(CONFIG_I2C_RIIC) += i2c-riic.o
 obj-$(CONFIG_I2C_RK3X) += i2c-rk3x.o
 obj-$(CONFIG_I2C_S3C2410)  += i2c-s3c2410.o
+obj-$(CONFIG_I2C_SAM)  += i2c-sam.o
 obj-$(CONFIG_I2C_SH7760)   += i2c-sh7760.o
 obj-$(CONFIG_I2C_SH_MOBILE)+= i2c-sh_mobile.o
 obj-$(CONFIG_I2C_SIMTEC)   += i2c-simtec.o
diff --git a/drivers/i2c/busses/i2c-sam.c b/drivers/i2c/busses/i2c-sam.c
new file mode 100644
index 000..1ec930a
--- /dev/null
+++ b/drivers/i2c/busses/i2c-sam.c
@@ -0,0 +1,942 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SAM_DEB1(dev, fmt, args...) do { \
+   if (sam_debug >= 1) \
+   dev_err(dev, fmt, ## args); \
+   } while (0)
+#define SAM_DEB2(dev, fmt, args...) do { \
+   if (sam_debug >= 2) \
+   dev_err(dev, fmt, ## args); \
+   } while (0)
+#define SAM_DEB3(dev, fmt, args...) do { \
+   if (sam_debug >= 3) \
+   dev_err(dev, fmt, ## args); } \
+   while (0)
+
+static int sam_debug;
+
+#define DRIVER_DESC"SAM FPGA I2C Driver"
+#define DRIVER_VERSION "0.2"
+#define DRIVER_AUTHOR  "Maryam Seraj "
+
+#define SAM_FPGA_MODULE_NAME   "i2c-sam"
+
+#define SAM_I2C_MUX_MAX_CHAN   8
+
+#define SAM_I2C_DEV_ADDR_MASK  0x7f
+#define SAM_I2C_TBL_ENTRY_CMDS_NUM 2
+
+#define SAM_I2C_CMD_TABLE_SZ   256
+
+#define SAM_I2C_STS_DONE   (1 << 0)
+#define SAM_I2C_STS_PRIO_DONE  (1 << 1)
+#define SAM_I2C_STS_RUNNING(1 << 2)
+#define SAM_I2C_STS_PRIO_RUNNING   (1 << 3)
+#define SAM_I2C_STS_ERR(1 << 4)
+#define SAM_I2C_STS_PRIO_ERR   (1 << 5)
+#define SAM_I2C_STS_RDY(1 << 6)
+#define SAM_I2C_STS_TR_TIMEOUT (1 << 7)
+#define SAM_I2C_STS_CMD_TIMEOUT(1 << 8)
+#define SAM_I2C_STS_CMD_TABLE_TIMEOUT  (1 << 9)
+
+#define SAM_I2C_STS_CLEAR_MASK (SAM_I2C_STS_DONE \
+| SAM_I2C_STS_PRIO_DONE \
+| SAM_I2C_STS_TR_TIMEOUT \
+| SAM_I2C_STS_CMD_TIMEOUT \
+| SAM_I2C_STS_CMD_TABLE_TIMEOUT \
+| SAM_I2C_STS_ERR \
+| SAM_I2C_STS_PRIO_ERR)
+#define SAM_I2C_STS_CLEAR(x)   (((x) & ~0x3fb3) | SAM_I2C_STS_CLEAR_MASK)
+
+#define SAM_I2C_STS_TIMEOUT(SAM_I2C_STS_TR_TIMEOUT \
+| SAM_I2C_STS_CMD_TIMEOUT \
+| SAM_I2C_STS_CMD_TABLE_TIMEOUT)
+
+#define SAM_I2C_DONE(s)((s) & (SAM_I2C_STS_DONE | 
SAM_I2C_STS_ERR \
+   | SAM_I2C_STS_TIMEOUT))
+
+#define SAM_I2C_CTRL_RESET (1 << 0)
+#define SAM_I2C_CTRL_GO(1 << 1)
+#define SAM_I2C_CTRL_PRIO_GO   (1 << 2)
+#define SAM_I2C_CTRL_ABORT (1 << 3)
+#define SAM_I2C_CTRL_PRIO_ABORT(1 << 4)
+
+/* Priority ctrl & status bits are offset +1 from the regular

[PATCH 1/6] mfd: Add support for the PTX1K CBC FPGA

[Pantelis Antoniou]

From: Georgi Vlaev 

The CBC intergrates CB and SAM on single FPGA. This is a PCI MFD driver
and provides support for the following functions as subdrivers:

* SAM I2C accelerator
* SAM MTD flash
* CBC spare GPIOs
* CBC JNX infrastructure

Signed-off-by: Georgi Vlaev 
Signed-off-by: Guenter Roeck 
Signed-off-by: Rajat Jain 
[Ported from Juniper kernel]
Signed-off-by: Pantelis Antoniou 
---
 drivers/mfd/Kconfig  |  16 +
 drivers/mfd/Makefile |   1 +
 drivers/mfd/cbc-core.c   | 971 +++
 include/linux/mfd/cbc-core.h | 181 
 4 files changed, 1169 insertions(+)
 create mode 100644 drivers/mfd/cbc-core.c
 create mode 100644 include/linux/mfd/cbc-core.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 7e1fa14..6107f7a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1384,6 +1384,22 @@ config MFD_JUNIPER_EXT_CPLD
  called "ptxpmb-ext-cpld"
 
 
+config MFD_JUNIPER_CBC
+   tristate "Juniper PTX1K CBC FPGA"
+   depends on JNX_PTX1K_RCB
+   default y if JNX_PTX1K_RCB
+   select MFD_CORE
+   select MTD
+   select MTD_SAM_FLASH
+   select I2C_SAM
+   select GPIO_CBC_PRESENCE if JNX_CONNECTOR
+   help
+ Select this to enable the CBC FPGA multi-function kernel driver.
+ This FPGA is present on the PTX1K RCB Juniper platform.
+
+ This driver can be built as a module. If built as a module it will be
+ called "cbc-core"
+
 config MFD_TWL4030_AUDIO
bool "TI TWL4030 Audio"
depends on TWL4030_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index da94482..0ea6dc6 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -151,6 +151,7 @@ obj-$(CONFIG_AB8500_GPADC)  += ab8500-gpadc.o
 obj-$(CONFIG_MFD_JUNIPER_CPLD) += ptxpmb-cpld-core.o
 obj-$(CONFIG_MFD_JUNIPER_SAM)  += sam-core.o
 obj-$(CONFIG_MFD_JUNIPER_EXT_CPLD) += ptxpmb-ext-cpld-core.o
+obj-$(CONFIG_MFD_JUNIPER_CBC)  += cbc-core.o
 obj-$(CONFIG_MFD_DB8500_PRCMU) += db8500-prcmu.o
 # ab8500-core need to come after db8500-prcmu (which provides the channel)
 obj-$(CONFIG_AB8500_CORE)  += ab8500-core.o ab8500-sysctrl.o
diff --git a/drivers/mfd/cbc-core.c b/drivers/mfd/cbc-core.c
new file mode 100644
index 000..1e6c95b
--- /dev/null
+++ b/drivers/mfd/cbc-core.c
@@ -0,0 +1,971 @@
+/*
+ * drivers/mfd/cbc-core.c
+ *
+ * Copyright (c) 2014, Juniper Networks
+ * Author: Georgi Vlaev 
+ * Based on: sam-core.c
+ *
+ * The CBC FPGA intergrates the PTX1K CB and some functions of
+ * the SAM FPGA on single device. We're reusing the SAM I2C,
+ * MTD flash drivers. The JNX CB logic is implemented in
+ * drivers/jnx/jnx-cbc-ptx1k.c and drivers/jnx/jnx-cbd-fpga-ptx1k.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_DEBUG_FS
+#include 
+#include 
+#endif
+
+enum {
+   CBC_CELL_SAM_I2C,   /* SAM I2C accelerator */
+   CBC_CELL_SAM_MTD,   /* SAM EPCS64 config flash */
+   CBC_CELL_GPIO,  /* CBC spare GPIO */
+   CBC_CELL_JNX_CBD,   /* CBC CB JNX driver */
+   CBC_CELL_GPIO_PRS,  /* CBC presence as GPIO (CH_PRS) */
+   CBC_CELL_GPIO_PRS_OTHER,/* CBC presence ss GPIO (OTHER_CH_PRS) */
+   CBC_CELL_GPIO_PRS_SIB,  /* CBC presence as GPIO (CH_PRS_SIB) */
+   CBC_NUM_MFD_CELLS
+};
+
+#define CBC_IRQ_NR 31
+#define CBC_RES_NR 2 /* iomem, irq */
+#define CBC_RES_NR_NOIRQ   1 /* iomem */
+
+struct cbc_fpga_data {
+   void __iomem *membase;
+   struct pci_dev *pdev;
+   u32 fpga_rev;   /* CBC revision */
+   u32 fpga_date;  /* CBC revision date */
+   int i2c_mstr_count; /* CBC/I2C SAM master count */
+   struct irq_domain *irq_domain;
+   u32 int_src; /* interrupt src reg (MSI, legacy) */
+   u32 int_en; /* interrupt en reg (MSI, legacy) */
+   spinlock_t irq_lock;
+   struct mfd_cell mfd_cells[CBC_NUM_MFD_CELLS];
+   struct resource mfd_i2c_resources[CBC_RES_NR];
+   struct resource mfd_mtd_resources[CBC_RES_NR_NOIRQ];
+   struct resource mfd_gpio_resources[CBC_RES_NR_NOIRQ];
+   struct resource mfd_jnx_resources[CBC_RES_NR_NOIRQ];
+   struct resource mfd_gpio_prs_resources[CBC_RES_NR_NOIRQ];
+#ifdef CONFIG_DEBUG_FS
+   struct dentry *cbc_debugfs_dir;
+   u32 debug_address; /* any register offsset */
+   struct debugfs_regset32 *regset; /* all regs */
+   u32 test_int_cnt; /* TEST_INT counter */
+   u32 i2c_accel_cnt; /* INT_I2C_ACCEL cnt */
+   u32 i2c_accel_empty_cnt; /* INT_I2C_ACCEL cnt && !CBC_STATUS_IRQ_EN */
+#endif
+};
+
+/*

[PATCH 1/2] staging: jnx: Juniper subsystem & board core APIs

[Pantelis Antoniou]

From: Tom Kavanagh <tkavan...@juniper.net>

The Juniper System Infrastructure subsystem creates platform devices
for the platform, chassis and cards and provides sysfs attributes for
these devices.

Each board contains I2C ID EEPROMs which contain information about the
chassis, platform, type and assembly IDs.

All Juniper local boards that run Linux contain a CBD (Control Board)
FPGA that provides I2C interfaces (among other things) that the other
boards use to connect their ID EEPROMs to.

A set of APIs for boards/modules is provided. These APIs provide:

- The ability to "listen" for the addition/deletion of any new board
  and schedule work to be done upon notification.
- The query of mastership in the dual failover environment these
  platform operate in.
- Registering boards and chassis.

A user-space API is provided by sysfs device files and it is described
in the relevant ABI documentation file.

Signed-off-by: Georgi Vlaev <gvl...@juniper.net>
Signed-off-by: Guenter Roeck <gro...@juniper.net>
Signed-off-by: Mohammad Kamil <mka...@juniper.net>
Signed-off-by: Rajat Jain <rajatj...@juniper.net>
Signed-off-by: Tom Kavanagh <tkavan...@juniper.net>
Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
[Ported from Juniper kernel]
Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 Documentation/ABI/testing/sysfs-platform-jnx | 170 +++
 drivers/staging/Kconfig  |   2 +
 drivers/staging/Makefile |   1 +
 drivers/staging/jnx/Kconfig  |  24 +
 drivers/staging/jnx/Makefile |   5 +
 drivers/staging/jnx/jnx-board-core.c | 247 ++
 drivers/staging/jnx/jnx-subsys-private.h |  35 ++
 drivers/staging/jnx/jnx-subsys.c | 655 +++
 include/linux/jnx/jnx-board-core.h   |  41 ++
 include/linux/jnx/jnx-subsys.h   |  94 
 10 files changed, 1274 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-jnx
 create mode 100644 drivers/staging/jnx/Kconfig
 create mode 100644 drivers/staging/jnx/Makefile
 create mode 100644 drivers/staging/jnx/jnx-board-core.c
 create mode 100644 drivers/staging/jnx/jnx-subsys-private.h
 create mode 100644 drivers/staging/jnx/jnx-subsys.c
 create mode 100644 include/linux/jnx/jnx-board-core.h
 create mode 100644 include/linux/jnx/jnx-subsys.h

diff --git a/Documentation/ABI/testing/sysfs-platform-jnx 
b/Documentation/ABI/testing/sysfs-platform-jnx
new file mode 100644
index 000..9bc7adc
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-jnx
@@ -0,0 +1,170 @@
+What:  /sys/devices/platform/jnx/chassis/platform
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev <gvl...@juniper.net>
+Description:
+   Read only numeric platform ID of the Juniper platform we're
+   running on. Valid platforms IDs are:
+   SANGRIA 85
+   HENDRICKS   156
+   POLARIS 171
+   OMEGA   181
+
+What:  /sys/devices/platform/jnx/chassis/chassis_no
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev <gvl...@juniper.net>
+Description:
+   Read only chassis number.
+
+What:  /sys/devices/platform/jnx/chassis/multichassis
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev <gvl...@juniper.net>
+Description:
+   Read only multichassis status
+   1 if we're on a multichassis system
+   0 otherwise
+
+What:  /sys/devices/platform/jnx/chassis/master
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev <gvl...@juniper.net>
+Description:
+   Read only numeric ID of the master slot.
+
+What:  /sys/devices/platform/jnx/chassis/mastership
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev <gvl...@juniper.net>
+Description:
+   Read for returning non zero if current RE is master
+   Write for relinquishing mastership to other RE
+
+What:  /sys/devices/platform/jnx/chassis/mastership_alive
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev <gvl...@juniper.net>
+Description:
+   Write to update the mastership watchdog alive.
+   The watchdog period is CBD FPGA specific.
+
+What:  /sys/devices/platform/jnx/chassis/mastership_alive_cnt
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev <gvl...@juniper.net>
+Description:
+   Read to return the mastership count number
+   Write to set the mastership count number
+
+What:  /sys/devices/platform/jnx/card/foo[n]
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev &

[PATCH 1/2] staging: jnx: Juniper subsystem & board core APIs

[Pantelis Antoniou]

From: Tom Kavanagh 

The Juniper System Infrastructure subsystem creates platform devices
for the platform, chassis and cards and provides sysfs attributes for
these devices.

Each board contains I2C ID EEPROMs which contain information about the
chassis, platform, type and assembly IDs.

All Juniper local boards that run Linux contain a CBD (Control Board)
FPGA that provides I2C interfaces (among other things) that the other
boards use to connect their ID EEPROMs to.

A set of APIs for boards/modules is provided. These APIs provide:

- The ability to "listen" for the addition/deletion of any new board
  and schedule work to be done upon notification.
- The query of mastership in the dual failover environment these
  platform operate in.
- Registering boards and chassis.

A user-space API is provided by sysfs device files and it is described
in the relevant ABI documentation file.

Signed-off-by: Georgi Vlaev 
Signed-off-by: Guenter Roeck 
Signed-off-by: Mohammad Kamil 
Signed-off-by: Rajat Jain 
Signed-off-by: Tom Kavanagh 
Signed-off-by: Pantelis Antoniou 
[Ported from Juniper kernel]
Signed-off-by: Pantelis Antoniou 
---
 Documentation/ABI/testing/sysfs-platform-jnx | 170 +++
 drivers/staging/Kconfig  |   2 +
 drivers/staging/Makefile |   1 +
 drivers/staging/jnx/Kconfig  |  24 +
 drivers/staging/jnx/Makefile |   5 +
 drivers/staging/jnx/jnx-board-core.c | 247 ++
 drivers/staging/jnx/jnx-subsys-private.h |  35 ++
 drivers/staging/jnx/jnx-subsys.c | 655 +++
 include/linux/jnx/jnx-board-core.h   |  41 ++
 include/linux/jnx/jnx-subsys.h   |  94 
 10 files changed, 1274 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-jnx
 create mode 100644 drivers/staging/jnx/Kconfig
 create mode 100644 drivers/staging/jnx/Makefile
 create mode 100644 drivers/staging/jnx/jnx-board-core.c
 create mode 100644 drivers/staging/jnx/jnx-subsys-private.h
 create mode 100644 drivers/staging/jnx/jnx-subsys.c
 create mode 100644 include/linux/jnx/jnx-board-core.h
 create mode 100644 include/linux/jnx/jnx-subsys.h

diff --git a/Documentation/ABI/testing/sysfs-platform-jnx 
b/Documentation/ABI/testing/sysfs-platform-jnx
new file mode 100644
index 000..9bc7adc
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-jnx
@@ -0,0 +1,170 @@
+What:  /sys/devices/platform/jnx/chassis/platform
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev 
+Description:
+   Read only numeric platform ID of the Juniper platform we're
+   running on. Valid platforms IDs are:
+   SANGRIA 85
+   HENDRICKS   156
+   POLARIS 171
+   OMEGA   181
+
+What:  /sys/devices/platform/jnx/chassis/chassis_no
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev 
+Description:
+   Read only chassis number.
+
+What:  /sys/devices/platform/jnx/chassis/multichassis
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev 
+Description:
+   Read only multichassis status
+   1 if we're on a multichassis system
+   0 otherwise
+
+What:  /sys/devices/platform/jnx/chassis/master
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev 
+Description:
+   Read only numeric ID of the master slot.
+
+What:  /sys/devices/platform/jnx/chassis/mastership
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev 
+Description:
+   Read for returning non zero if current RE is master
+   Write for relinquishing mastership to other RE
+
+What:  /sys/devices/platform/jnx/chassis/mastership_alive
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev 
+Description:
+   Write to update the mastership watchdog alive.
+   The watchdog period is CBD FPGA specific.
+
+What:  /sys/devices/platform/jnx/chassis/mastership_alive_cnt
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev 
+Description:
+   Read to return the mastership count number
+   Write to set the mastership count number
+
+What:  /sys/devices/platform/jnx/card/foo[n]
+Date:  Sep 2016
+KernelVersion: 4.8.0-rc7
+Contact:   Georgi Vlaev 
+Description:
+   Symbolic link of the jnx board with the given type
+   foo with an option index number. For instance the
+   first two fan type cards would link like this:
+
+   /sys/devices/platform/jnx/card/fan0 -> ../jnx-09cc.0
+   /sys/devices/platform/jnx/card/fan1 -> ../jnx-09cc.1
+
+What:  /sys/devices/platform/jnx/jnx-.N/id
+Date:  

[PATCH 3/4] gpio: ptxpmb-ext-cpld: Add driver for Juniper's PTXPMB extended CPLD

[Pantelis Antoniou]

From: Guenter Roeck <gro...@juniper.net>

This IP block is present in the PTXPMB extended CPLD present on
Junipers PTX series of routers and provides SIB connector status pins
as GPIO pins for use with other drivers.

Signed-off-by: Guenter Roeck <gro...@juniper.net>
Signed-off-by: JawaharBalaji Thirumalaisamy <jawah...@juniper.net>
[Ported from Juniper kernel]
Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 drivers/gpio/Kconfig|  11 +
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-ptxpmb-ext-cpld.c | 430 
 3 files changed, 442 insertions(+)
 create mode 100644 drivers/gpio/gpio-ptxpmb-ext-cpld.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c25dbe9..281029b 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -371,6 +371,17 @@ config GPIO_PTXPMB_CPLD
  This driver can also be built as a module.  If so, the module
  will be called gpio-ptxpmb-cpld.
 
+config GPIO_PTXPMB_EXT_CPLD
+   tristate "PTXPMB Extended CPLD GPIO"
+   depends on MFD_JUNIPER_EXT_CPLD
+   default y if MFD_JUNIPER_EXT_CPLD
+   help
+ This driver exports various bits on the Juniper Control Board
+ Extended CPLD as GPIO pins to userspace.
+
+ This driver can also be built as a module.  If so, the module
+ will be called gpio-ptxpmb-ext-cpld.
+
 config GPIO_PXA
bool "PXA GPIO support"
depends on ARCH_PXA || ARCH_MMP
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 6691d8c..ec890c7 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_GPIO_PCH)+= gpio-pch.o
 obj-$(CONFIG_GPIO_PISOSR)  += gpio-pisosr.o
 obj-$(CONFIG_GPIO_PL061)   += gpio-pl061.o
 obj-$(CONFIG_GPIO_PTXPMB_CPLD) += gpio-ptxpmb-cpld.o
+obj-$(CONFIG_GPIO_PTXPMB_EXT_CPLD) += gpio-ptxpmb-ext-cpld.o
 obj-$(CONFIG_GPIO_PXA) += gpio-pxa.o
 obj-$(CONFIG_GPIO_RC5T583) += gpio-rc5t583.o
 obj-$(CONFIG_GPIO_RDC321X) += gpio-rdc321x.o
diff --git a/drivers/gpio/gpio-ptxpmb-ext-cpld.c 
b/drivers/gpio/gpio-ptxpmb-ext-cpld.c
new file mode 100644
index 000..0152f0b
--- /dev/null
+++ b/drivers/gpio/gpio-ptxpmb-ext-cpld.c
@@ -0,0 +1,430 @@
+/*
+ * Copyright (C) 2012 Juniper networks
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define EXT_CPLD_NGPIO 32  /*  0..15: SIB presence bits*/
+   /* 16..31: SIB interrupt status */
+
+/**
+ * struct ext_cpld_gpio - GPIO private data structure.
+ * @base: PCI base address of Memory mapped I/O register.
+ * @dev: Pointer to device structure.
+ * @gpio: Data for GPIO infrastructure.
+ */
+struct ext_cpld_gpio {
+   void __iomem *base;
+   struct device *dev;
+   struct gpio_chip gpio;
+   struct mutex irq_lock;
+   struct mutex work_lock;
+   struct irq_domain *domain;
+   int irq;
+   u8 irq_type[EXT_CPLD_NGPIO];
+   u16 sib_presence_cache;
+   u16 sib_presence_irq_enabled;
+   u16 sib_irq_status_cache;
+   u16 sib_irq_enabled;
+   struct delayed_work work;
+};
+
+static int ext_cpld_gpio_get(struct gpio_chip *gpio, unsigned int nr)
+{
+   struct ext_cpld_gpio *chip = container_of(gpio,
+ struct ext_cpld_gpio, gpio);
+   struct pmb_boot_cpld_ext *cpld = chip->base;
+   u16 *addr = nr < 16 ? >sib_presence : >sib_irq_status;
+   u16 val;
+
+   val = ioread16(addr);
+   if (nr < 16)
+   chip->sib_presence_cache = val;
+   else
+   chip->sib_irq_status_cache = val;
+
+   return !!(val & (1 << (nr & 15)));
+}
+
+static int ext_cpld_gpio_direction_input(struct gpio_chip *gpio,
+unsigned int nr)
+{
+   /* all pins are input pins */
+   return 0;
+}
+
+static int ext_cpld_gpio_to_irq(struct gpio_chip *gpio, unsigned int offset)
+{
+   struct ext_cpld_gpio *chip = container_of(gpio,
+ struct ext_cpld_gpio, gpio);
+
+   return irq_create_mapping(chip->domain, offset);
+}
+
+static void ext_cpld_irq_mask(struct irq_data *data)
+{
+   struct ext_cpld_gpio *chip = irq_data_get_irq_chip_data(data);
+  

[PATCH 3/4] gpio: ptxpmb-ext-cpld: Add driver for Juniper's PTXPMB extended CPLD

[Pantelis Antoniou]

From: Guenter Roeck 

This IP block is present in the PTXPMB extended CPLD present on
Junipers PTX series of routers and provides SIB connector status pins
as GPIO pins for use with other drivers.

Signed-off-by: Guenter Roeck 
Signed-off-by: JawaharBalaji Thirumalaisamy 
[Ported from Juniper kernel]
Signed-off-by: Pantelis Antoniou 
---
 drivers/gpio/Kconfig|  11 +
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-ptxpmb-ext-cpld.c | 430 
 3 files changed, 442 insertions(+)
 create mode 100644 drivers/gpio/gpio-ptxpmb-ext-cpld.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c25dbe9..281029b 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -371,6 +371,17 @@ config GPIO_PTXPMB_CPLD
  This driver can also be built as a module.  If so, the module
  will be called gpio-ptxpmb-cpld.
 
+config GPIO_PTXPMB_EXT_CPLD
+   tristate "PTXPMB Extended CPLD GPIO"
+   depends on MFD_JUNIPER_EXT_CPLD
+   default y if MFD_JUNIPER_EXT_CPLD
+   help
+ This driver exports various bits on the Juniper Control Board
+ Extended CPLD as GPIO pins to userspace.
+
+ This driver can also be built as a module.  If so, the module
+ will be called gpio-ptxpmb-ext-cpld.
+
 config GPIO_PXA
bool "PXA GPIO support"
depends on ARCH_PXA || ARCH_MMP
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 6691d8c..ec890c7 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_GPIO_PCH)+= gpio-pch.o
 obj-$(CONFIG_GPIO_PISOSR)  += gpio-pisosr.o
 obj-$(CONFIG_GPIO_PL061)   += gpio-pl061.o
 obj-$(CONFIG_GPIO_PTXPMB_CPLD) += gpio-ptxpmb-cpld.o
+obj-$(CONFIG_GPIO_PTXPMB_EXT_CPLD) += gpio-ptxpmb-ext-cpld.o
 obj-$(CONFIG_GPIO_PXA) += gpio-pxa.o
 obj-$(CONFIG_GPIO_RC5T583) += gpio-rc5t583.o
 obj-$(CONFIG_GPIO_RDC321X) += gpio-rdc321x.o
diff --git a/drivers/gpio/gpio-ptxpmb-ext-cpld.c 
b/drivers/gpio/gpio-ptxpmb-ext-cpld.c
new file mode 100644
index 000..0152f0b
--- /dev/null
+++ b/drivers/gpio/gpio-ptxpmb-ext-cpld.c
@@ -0,0 +1,430 @@
+/*
+ * Copyright (C) 2012 Juniper networks
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define EXT_CPLD_NGPIO 32  /*  0..15: SIB presence bits*/
+   /* 16..31: SIB interrupt status */
+
+/**
+ * struct ext_cpld_gpio - GPIO private data structure.
+ * @base: PCI base address of Memory mapped I/O register.
+ * @dev: Pointer to device structure.
+ * @gpio: Data for GPIO infrastructure.
+ */
+struct ext_cpld_gpio {
+   void __iomem *base;
+   struct device *dev;
+   struct gpio_chip gpio;
+   struct mutex irq_lock;
+   struct mutex work_lock;
+   struct irq_domain *domain;
+   int irq;
+   u8 irq_type[EXT_CPLD_NGPIO];
+   u16 sib_presence_cache;
+   u16 sib_presence_irq_enabled;
+   u16 sib_irq_status_cache;
+   u16 sib_irq_enabled;
+   struct delayed_work work;
+};
+
+static int ext_cpld_gpio_get(struct gpio_chip *gpio, unsigned int nr)
+{
+   struct ext_cpld_gpio *chip = container_of(gpio,
+ struct ext_cpld_gpio, gpio);
+   struct pmb_boot_cpld_ext *cpld = chip->base;
+   u16 *addr = nr < 16 ? >sib_presence : >sib_irq_status;
+   u16 val;
+
+   val = ioread16(addr);
+   if (nr < 16)
+   chip->sib_presence_cache = val;
+   else
+   chip->sib_irq_status_cache = val;
+
+   return !!(val & (1 << (nr & 15)));
+}
+
+static int ext_cpld_gpio_direction_input(struct gpio_chip *gpio,
+unsigned int nr)
+{
+   /* all pins are input pins */
+   return 0;
+}
+
+static int ext_cpld_gpio_to_irq(struct gpio_chip *gpio, unsigned int offset)
+{
+   struct ext_cpld_gpio *chip = container_of(gpio,
+ struct ext_cpld_gpio, gpio);
+
+   return irq_create_mapping(chip->domain, offset);
+}
+
+static void ext_cpld_irq_mask(struct irq_data *data)
+{
+   struct ext_cpld_gpio *chip = irq_data_get_irq_chip_data(data);
+   struct pmb_boot_cpld_ext *cpld = chip->base;
+   u16 *addr = data->hwirq < 16 ?
+   >sib_presence_irq_en : >sib_irq_

[PATCH 0/6] Introduce Juniper CBC FPGA

[Pantelis Antoniou]

Add Juniper's PTX1K CBC FPGA driver. Those FPGAs
are present in Juniper's PTX series of routers.

The MFD driver provices a gpio device and a special
driver for Juniper's board infrastucture.
The FPGA infrastucture driver is providing an interface
for user-space handling of the FPGA in those platforms.

There are full device tree binding documents for the
master mfd driver and for the slave driver.

This patchset is against mainline as of today: v4.8-9431-g3477d16
and is dependent on the "Juniper prerequisites" and
"Juniper infrastructure" patchsets sent earlier.

Georgi Vlaev (5):
  mfd: Add support for the PTX1K CBC FPGA
  gpio: Add support for PTX1K CBC FPGA spare GPIOs
  gpio: gpio-cbc: Document bindings of CBC FPGA GPIO block
  gpio: cbc-presence: Add CBC presence detect as GPIO driver
  gpio: gpio-cbc-presense: Document bindings of CBC FPGA presence

Tom Kavanagh (1):
  staging: jnx: CBD-FPGA infrastructure

 .../bindings/gpio/jnx,gpio-cbc-presense.txt|  31 +
 .../devicetree/bindings/gpio/jnx,gpio-cbc.txt  |  30 +
 drivers/gpio/Kconfig   |  23 +
 drivers/gpio/Makefile  |   2 +
 drivers/gpio/gpio-cbc-presence.c   | 460 ++
 drivers/gpio/gpio-cbc.c| 236 +
 drivers/mfd/Kconfig|  16 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/cbc-core.c | 971 +
 drivers/staging/jnx/Kconfig|  34 +
 drivers/staging/jnx/Makefile   |   5 +
 drivers/staging/jnx/jnx-cbc-ptx1k.c| 242 +
 drivers/staging/jnx/jnx-cbd-fpga-common.c  | 332 +++
 drivers/staging/jnx/jnx-cbd-fpga-common.h  |  27 +
 drivers/staging/jnx/jnx-cbd-fpga-core.c| 540 
 drivers/staging/jnx/jnx-cbd-fpga-core.h|  68 ++
 drivers/staging/jnx/jnx-cbd-fpga-platdata.h|  51 ++
 drivers/staging/jnx/jnx-cbd-fpga-ptx1k.c   | 134 +++
 drivers/staging/jnx/jnx-cbd-fpga-ptx21k.c  | 143 +++
 drivers/staging/jnx/jnx-cbd-fpga-ptx3k.c   | 111 +++
 drivers/staging/jnx/jnx-cbd-fpga-ptx5k.c   | 107 +++
 include/linux/mfd/cbc-core.h   | 181 
 22 files changed, 3745 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpio/jnx,gpio-cbc-presense.txt
 create mode 100644 Documentation/devicetree/bindings/gpio/jnx,gpio-cbc.txt
 create mode 100644 drivers/gpio/gpio-cbc-presence.c
 create mode 100644 drivers/gpio/gpio-cbc.c
 create mode 100644 drivers/mfd/cbc-core.c
 create mode 100644 drivers/staging/jnx/jnx-cbc-ptx1k.c
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-common.c
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-common.h
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-core.c
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-core.h
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-platdata.h
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-ptx1k.c
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-ptx21k.c
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-ptx3k.c
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-ptx5k.c
 create mode 100644 include/linux/mfd/cbc-core.h

-- 
1.9.1

[PATCH 0/6] Introduce Juniper CBC FPGA

[Pantelis Antoniou]

Add Juniper's PTX1K CBC FPGA driver. Those FPGAs
are present in Juniper's PTX series of routers.

The MFD driver provices a gpio device and a special
driver for Juniper's board infrastucture.
The FPGA infrastucture driver is providing an interface
for user-space handling of the FPGA in those platforms.

There are full device tree binding documents for the
master mfd driver and for the slave driver.

This patchset is against mainline as of today: v4.8-9431-g3477d16
and is dependent on the "Juniper prerequisites" and
"Juniper infrastructure" patchsets sent earlier.

Georgi Vlaev (5):
  mfd: Add support for the PTX1K CBC FPGA
  gpio: Add support for PTX1K CBC FPGA spare GPIOs
  gpio: gpio-cbc: Document bindings of CBC FPGA GPIO block
  gpio: cbc-presence: Add CBC presence detect as GPIO driver
  gpio: gpio-cbc-presense: Document bindings of CBC FPGA presence

Tom Kavanagh (1):
  staging: jnx: CBD-FPGA infrastructure

 .../bindings/gpio/jnx,gpio-cbc-presense.txt|  31 +
 .../devicetree/bindings/gpio/jnx,gpio-cbc.txt  |  30 +
 drivers/gpio/Kconfig   |  23 +
 drivers/gpio/Makefile  |   2 +
 drivers/gpio/gpio-cbc-presence.c   | 460 ++
 drivers/gpio/gpio-cbc.c| 236 +
 drivers/mfd/Kconfig|  16 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/cbc-core.c | 971 +
 drivers/staging/jnx/Kconfig|  34 +
 drivers/staging/jnx/Makefile   |   5 +
 drivers/staging/jnx/jnx-cbc-ptx1k.c| 242 +
 drivers/staging/jnx/jnx-cbd-fpga-common.c  | 332 +++
 drivers/staging/jnx/jnx-cbd-fpga-common.h  |  27 +
 drivers/staging/jnx/jnx-cbd-fpga-core.c| 540 
 drivers/staging/jnx/jnx-cbd-fpga-core.h|  68 ++
 drivers/staging/jnx/jnx-cbd-fpga-platdata.h|  51 ++
 drivers/staging/jnx/jnx-cbd-fpga-ptx1k.c   | 134 +++
 drivers/staging/jnx/jnx-cbd-fpga-ptx21k.c  | 143 +++
 drivers/staging/jnx/jnx-cbd-fpga-ptx3k.c   | 111 +++
 drivers/staging/jnx/jnx-cbd-fpga-ptx5k.c   | 107 +++
 include/linux/mfd/cbc-core.h   | 181 
 22 files changed, 3745 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpio/jnx,gpio-cbc-presense.txt
 create mode 100644 Documentation/devicetree/bindings/gpio/jnx,gpio-cbc.txt
 create mode 100644 drivers/gpio/gpio-cbc-presence.c
 create mode 100644 drivers/gpio/gpio-cbc.c
 create mode 100644 drivers/mfd/cbc-core.c
 create mode 100644 drivers/staging/jnx/jnx-cbc-ptx1k.c
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-common.c
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-common.h
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-core.c
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-core.h
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-platdata.h
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-ptx1k.c
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-ptx21k.c
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-ptx3k.c
 create mode 100644 drivers/staging/jnx/jnx-cbd-fpga-ptx5k.c
 create mode 100644 include/linux/mfd/cbc-core.h

-- 
1.9.1