attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work
with const attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
28720 985 12 29717 7415 drivers/net/.../cxgb3/cxgb3_main.o
File size After adding 'const':
text data bss dec hex filename
28848 857 12 29717 7415 drivers/net/.../cxgb3/cxgb3_main.o
Signed-off-by: Arvind Yadav <[email protected]>
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index 0bc6a4f..6a01536 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -793,7 +793,9 @@ static DEVICE_ATTR(name, S_IRUGO | S_IWUSR, show_##name, store_method)
NULL
};
-static struct attribute_group cxgb3_attr_group = {.attrs = cxgb3_attrs };
+static const struct attribute_group cxgb3_attr_group = {
+ .attrs = cxgb3_attrs,
+};
static ssize_t tm_attr_show(struct device *d,
char *buf, int sched)
@@ -880,7 +882,9 @@ static DEVICE_ATTR(name, S_IRUGO | S_IWUSR, show_##name, store_##name)
NULL
};
-static struct attribute_group offload_attr_group = {.attrs = offload_attrs };
+static const struct attribute_group offload_attr_group = {
+ .attrs = offload_attrs,
+};
/*
* Sends an sk_buff to an offload queue driver
--
1.9.1
On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:
> attribute_groups are not supposed to change at runtime. All functions
> working with attribute_groups provided by <linux/sysfs.h> work
> with const attribute_group. So mark the non-const structs as const.
I think it's good you are doing all of these.
Instead of individually sending these patches, could you
please send a patch series for all of these attribute_group
patches with a cover letter at the same time?
That could make it easier for a trivial maintainer to apply
all of these at once and not get some applied and others
ignored or dropped on the floor.
Hi Joe,
On Monday 10 July 2017 10:30 PM, Joe Perches wrote:
> On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:
>> attribute_groups are not supposed to change at runtime. All functions
>> working with attribute_groups provided by <linux/sysfs.h> work
>> with const attribute_group. So mark the non-const structs as const.
> I think it's good you are doing all of these.
>
> Instead of individually sending these patches, could you
> please send a patch series for all of these attribute_group
> patches with a cover letter at the same time?
>
> That could make it easier for a trivial maintainer to apply
> all of these at once and not get some applied and others
> ignored or dropped on the floor.
>
Once again, I will send all of patch together, But I have doubt. If it's
having
different maintainer. Example- 'net:' subsystem is having a different
different
maintainer. So do i need to add all the maintainer in single list. Which
can confuse
what patch is for what maintainer. Please suggest me.
Thanks ,
~arvind
On Tue, 2017-07-11 at 11:11 +0530, Arvind Yadav wrote:
> Hi Joe,
>
>
> On Monday 10 July 2017 10:30 PM, Joe Perches wrote:
> > On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:
> > > attribute_groups are not supposed to change at runtime. All functions
> > > working with attribute_groups provided by <linux/sysfs.h> work
> > > with const attribute_group. So mark the non-const structs as const.
> >
> > I think it's good you are doing all of these.
> >
> > Instead of individually sending these patches, could you
> > please send a patch series for all of these attribute_group
> > patches with a cover letter at the same time?
> >
> > That could make it easier for a trivial maintainer to apply
> > all of these at once and not get some applied and others
> > ignored or dropped on the floor.
> >
>
> Once again, I will send all of patch together, But I have doubt. If it's
> having
> different maintainer. Example- 'net:' subsystem is having a different
> different
> maintainer. So do i need to add all the maintainer in single list. Which
> can confuse
> what patch is for what maintainer. Please suggest me.
Please send individual patches, one per maintainer/subsystem
as a series with a cover letter like:
[PATCH 0/N] treewide: constify attribute_group structures
[PATCH 1/N] chelsio: cxgb3: constify attribute_group
[PATCH 2/N] chelsio: cxgb4: constify attribute_group
...
[PATCH N/N] subsystem: constify attribute_group
Hi Joe,
On Tuesday 11 July 2017 11:17 AM, Joe Perches wrote:
> On Tue, 2017-07-11 at 11:11 +0530, Arvind Yadav wrote:
>> Hi Joe,
>>
>>
>> On Monday 10 July 2017 10:30 PM, Joe Perches wrote:
>>> On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:
>>>> attribute_groups are not supposed to change at runtime. All functions
>>>> working with attribute_groups provided by <linux/sysfs.h> work
>>>> with const attribute_group. So mark the non-const structs as const.
>>> I think it's good you are doing all of these.
>>>
>>> Instead of individually sending these patches, could you
>>> please send a patch series for all of these attribute_group
>>> patches with a cover letter at the same time?
>>>
>>> That could make it easier for a trivial maintainer to apply
>>> all of these at once and not get some applied and others
>>> ignored or dropped on the floor.
>>>
>> Once again, I will send all of patch together, But I have doubt. If it's
>> having
>> different maintainer. Example- 'net:' subsystem is having a different
>> different
>> maintainer. So do i need to add all the maintainer in single list. Which
>> can confuse
>> what patch is for what maintainer. Please suggest me.
> Please send individual patches, one per maintainer/subsystem
> as a series with a cover letter like:
>
> [PATCH 0/N] treewide: constify attribute_group structures
> [PATCH 1/N] chelsio: cxgb3: constify attribute_group
> [PATCH 2/N] chelsio: cxgb4: constify attribute_group
> ...
> [PATCH N/N] subsystem: constify attribute_group
>
Thank you, I will follow as per your suggestion.
Regards,
~arvind