From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752645AbbJTVPJ (ORCPT ); Tue, 20 Oct 2015 17:15:09 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:36298 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751592AbbJTVPF convert rfc822-to-8bit (ORCPT ); Tue, 20 Oct 2015 17:15:05 -0400 Subject: Re: [PATCH v6 3/4] of: overlay: add per overlay sysfs attributes Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: Pantelis Antoniou In-Reply-To: <20151020210806.GC28724@kroah.com> Date: Wed, 21 Oct 2015 00:15:00 +0300 Cc: Rob Herring , Frank Rowand , Matt Porter , Koen Kooi , Guenter Roeck , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: References: <1445368397-8732-1-git-send-email-pantelis.antoniou@konsulko.com> <1445368397-8732-4-git-send-email-pantelis.antoniou@konsulko.com> <20151020210806.GC28724@kroah.com> To: Greg Kroah-Hartman X-Mailer: Apple Mail (2.2104) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Greg, > On Oct 21, 2015, at 00:08 , Greg Kroah-Hartman wrote: > > On Tue, Oct 20, 2015 at 10:13:16PM +0300, Pantelis Antoniou 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. >> >> Signed-off-by: Pantelis Antoniou >> --- >> drivers/of/overlay.c | 103 +++++++++++++++++++++++++++++++++++++++++++++++++-- >> 1 file changed, 99 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c >> index 067404e..2d51d9e2 100644 >> --- a/drivers/of/overlay.c >> +++ b/drivers/of/overlay.c >> @@ -25,8 +25,23 @@ >> >> #include "of_private.h" >> >> +/* fwd. decl */ >> +struct of_overlay; >> +struct of_overlay_info; >> + >> +/* an attribute for each fragment */ >> +struct fragment_attribute { >> + struct attribute attr; >> + ssize_t (*show)(struct kobject *kobj, struct fragment_attribute *fattr, >> + char *buf); >> + ssize_t (*store)(struct kobject *kobj, struct fragment_attribute *fattr, >> + const char *buf, size_t count); >> + struct of_overlay_info *ovinfo; >> +}; >> + >> /** >> * struct of_overlay_info - Holds a single overlay info >> + * @info: info node that contains the target and overlay >> * @target: target of the overlay operation >> * @overlay: pointer to the overlay contents node >> * >> @@ -34,8 +49,13 @@ >> * records. >> */ >> struct of_overlay_info { >> + struct of_overlay *ov; >> + struct device_node *info; >> struct device_node *target; >> struct device_node *overlay; >> + struct attribute_group attr_group; >> + struct attribute *attrs[2]; > > Why both 2 attributes _and_ an attribute group? Why not put the > attributes in the attribute group? > > And why just one attribute group? Why not an array of them like the > rest of the kernel is used to handle? > Because this makes it easier to add all the attributes for all the fragments in a single sysfs_create_groups() call, once for each overlay, instead of having a call to sysfs_create_group() for each fragment of the overlay. Reusing driver core helpers is good, no? > thanks, > > greg k-h Regards — Pantelis