Hi Rob, > On Oct 22, 2015, at 00:52 , Rob Herring <robherring2@xxxxxxxxx> wrote: > > On Wed, Oct 21, 2015 at 2:37 PM, Pantelis Antoniou > <pantelis.antoniou@xxxxxxxxxxxx> wrote: >> Hi Rob, >> >>> On Oct 21, 2015, at 00:54 , Rob Herring <robherring2@xxxxxxxxx> wrote: >>> >>> On Tue, Oct 20, 2015 at 4:11 PM, Pantelis Antoniou >>> <pantelis.antoniou@xxxxxxxxxxxx> wrote: >>>> Hi Rob, >>>> >>>>> On Oct 21, 2015, at 00:04 , Rob Herring <robherring2@xxxxxxxxx> wrote: >>>>> >>>>> On Tue, Oct 20, 2015 at 2:13 PM, Pantelis Antoniou >>>>> <pantelis.antoniou@xxxxxxxxxxxx> wrote: >>>>>> * A per overlay can_remove sysfs attribute that reports whether >>>>>> the overlay can be removed or not due to another overlapping overlay. >>>>>> >>>>>> * A target sysfs attribute listing the target of each fragment, >>>>>> in a group named after the name of the fragment. >>> >>> [...] >>> >>>>>> @@ -255,6 +278,17 @@ err_fail: >>>>>> return -EINVAL; >>>>>> } >>>>>> >>>>>> +static ssize_t target_show(struct kobject *kobj, >>>>>> + struct fragment_attribute *fattr, char *buf) >>>>>> +{ >>>>>> + struct of_overlay_info *ovinfo = fattr->ovinfo; >>>>>> + >>>>>> + return snprintf(buf, PAGE_SIZE, "%s\n", >>>>>> + of_node_full_name(ovinfo->target)); >>>>> >>>>> This can be a link to the node itself, can't it? >>>>> >>>> >>>> Yes. Do you want it like this? >>> >>> Yes, hence the suggestion. Unless you see some reason why not. >>> >> >> Nope, can’t be done. The sysfs API only allows linking one kobj to another. >> The kobj is the overlay but the target is in the fragment attribute group. > > Can't we make the fragments kobj's as well? > We could, but it break the mental model of what a kobj should represent. An overlay is an object which can be address, a fragment is never directly exposed. TBH a link attribute is indeed better than a path attribute, but marginally so. It’s not worth the trouble IMO. > 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