[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f22c891c38f01af65f7f51176045a66e537ad176.camel@intel.com>
Date: Fri, 1 Dec 2023 17:31:32 +0000
From: "Zhang, Rui" <rui.zhang@...el.com>
To: "linux@...ck-us.net" <linux@...ck-us.net>,
"ashok_raj@...ux.intel.com" <ashok_raj@...ux.intel.com>
CC: "Yu, Fenghua" <fenghua.yu@...el.com>,
"Raj, Ashok" <ashok.raj@...el.com>,
"linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"jdelvare@...e.com" <jdelvare@...e.com>
Subject: Re: [PATCH 2/3] hwmon: (coretemp) Remove unnecessary dependency of
array index
> > > mutex_lock(&tdata->update_lock);
> > > @@ -445,7 +441,6 @@ static int create_core_attrs(struct temp_data
> > > *tdata, struct device *dev,
> > > tdata->sd_attrs[i].dev_attr.attr.name = tdata-
> > > >attr_name[i];
> > > tdata->sd_attrs[i].dev_attr.attr.mode = 0444;
> > > tdata->sd_attrs[i].dev_attr.show = rd_ptr[i];
> > > - tdata->sd_attrs[i].index = attr_no;
> >
> > I was naively thinking if we could nuke that "index". I can see
> > that used
> > in couple macros, but seems like we can lose it?
> >
> > Completely untested.. and uncertain :-)
> >
>
> If you had suggested to replace
> struct sensor_device_attribute sd_attrs[TOTAL_ATTRS];
> with
> struct device_attribute sd_attrs[TOTAL_ATTRS];
> what you suggested may actually be possible and make sense.
Too late for me today.
Let me check if I can convert it to use device_attribute instead
tomorrow.
thanks,
rui
Powered by blists - more mailing lists