Hi Rob, > On Jun 15, 2015, at 16:42 , Rob Herring <robherring2@xxxxxxxxx> wrote: > > On Mon, Jun 15, 2015 at 8:26 AM, Pantelis Antoniou > <pantelis.antoniou@xxxxxxxxxxxx> wrote: >> Hi Rob, >> >>> On Jun 15, 2015, at 16:24 , Rob Herring <robherring2@xxxxxxxxx> wrote: >>> >>> On Fri, Jun 12, 2015 at 2:38 PM, Pantelis Antoniou >>> <pantelis.antoniou@xxxxxxxxxxxx> wrote: >>>> Documentation ABI entry for overlays sysfs entries. >>>> >>>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> >>>> --- >>>> .../ABI/testing/sysfs-firmware-devicetree-overlays | 35 ++++++++++++++++++++++ >>>> 1 file changed, 35 insertions(+) >>>> create mode 100644 Documentation/ABI/testing/sysfs-firmware-devicetree-overlays >>>> >>>> diff --git a/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays b/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays >>>> new file mode 100644 >>>> index 0000000..be2d28b >>>> --- /dev/null >>>> +++ b/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays >>>> @@ -0,0 +1,35 @@ > > [...] > >>>> + >>>> + targets: A file containing the list of targets of each overlay >>>> + with each line containing a target. >>> >>> We have OF nodes in sysfs now. Would it be more useful if we created >>> links to the target nodes instead of having a list of names? >>> >> >> Probably, this interface is merely informational; things get complicated by >> the fact that there can be more than one target in each overlay. > > Right, you would need 'targetN' or perhaps '<node name>' (with a '.N' > for duplicates) as the link names. > > If it is informational, then perhaps debugfs should be used instead? > I’d rather not pull in debugfs here. It’s informational, but not only for debugging. I’ll see what I can do with the targets. > What else if anything do you envision adding here? > As far as generic infrastructure properties, I hope nothing else. However I do intend to use the kobj directory to make the overlay users ‘hang’ properties relevant to their use. For instance the beaglebone capemanager could put there the compatible and the resource declaration properties. But that’s going to come later. > Rob > — Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html