Re: [PATCH v6 3/4] of: overlay: add per overlay sysfs attributes

Hi Rob,

On Oct 22, 2015, at 00:52 , Rob Herring [off-list ref] wrote:

On Wed, Oct 21, 2015 at 2:37 PM, Pantelis Antoniou
[off-list ref] wrote:

quoted

Hi Rob,

quoted

On Oct 21, 2015, at 00:54 , Rob Herring [off-list ref] wrote:

On Tue, Oct 20, 2015 at 4:11 PM, Pantelis Antoniou
[off-list ref] wrote:

quoted

Hi Rob,

quoted

On Oct 21, 2015, at 00:04 , Rob Herring [off-list ref] wrote:

On Tue, Oct 20, 2015 at 2:13 PM, Pantelis Antoniou
[off-list ref] wrote:

quoted

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

[...]

quoted

quoted

quoted

@@ -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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html