[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqL8+4HCrSFQf5oi1PdE0mQveL9OFPFPfVGT+xm-JeMO2g@mail.gmail.com>
Date: Thu, 5 Nov 2015 13:52:31 -0600
From: Rob Herring <robherring2@...il.com>
To: Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc: Frank Rowand <frowand.list@...il.com>,
Matt Porter <mporter@...sulko.com>,
Koen Kooi <koen@...inion.thruhere.net>,
Guenter Roeck <linux@...ck-us.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>
Subject: Re: [PATCH v6 3/4] of: overlay: add per overlay sysfs attributes
On Thu, Oct 22, 2015 at 11:15 AM, Pantelis Antoniou
<pantelis.antoniou@...sulko.com> wrote:
> Hi Rob,
>
>> On Oct 22, 2015, at 00:52 , Rob Herring <robherring2@...il.com> wrote:
>>
>> On Wed, Oct 21, 2015 at 2:37 PM, Pantelis Antoniou
>> <pantelis.antoniou@...sulko.com> wrote:
>>> Hi Rob,
>>>
>>>> On Oct 21, 2015, at 00:54 , Rob Herring <robherring2@...il.com> wrote:
>>>>
>>>> On Tue, Oct 20, 2015 at 4:11 PM, Pantelis Antoniou
>>>> <pantelis.antoniou@...sulko.com> wrote:
>>>>> Hi Rob,
>>>>>
>>>>>> On Oct 21, 2015, at 00:04 , Rob Herring <robherring2@...il.com> wrote:
>>>>>>
>>>>>> On Tue, Oct 20, 2015 at 2:13 PM, Pantelis Antoniou
>>>>>> <pantelis.antoniou@...sulko.com> 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.
But you are exposing fragments as there is a directory for each one.
Overlays are just logical collections of fragments. You could go as
far to say overlays don't need to be exposed at all and only fragments
need to be (not that we should). We already have overlays and nodes as
kobjs, so I don't think fragments as kobjs breaks the mental model.
> TBH a link attribute is indeed better than a path attribute, but marginally so.
> It’s not worth the trouble IMO.
It is just an ABI we have to support forever...
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists