From: Guenter Roeck <linux@roeck-us.net>
To: Jeremy Gebben <jgebben@sweptlaser.com>
Cc: Jean Delvare <jdelvare@suse.com>,
Jonathan Corbet <corbet@lwn.net>,
linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH resend 1/3] hwmon: (lm85) remove freq_map size hardcodes
Date: Wed, 30 Jan 2019 09:25:10 -0800 [thread overview]
Message-ID: <20190130172510.GB14781@roeck-us.net> (raw)
In-Reply-To: <20190130161447.19946-1-jgebben@sweptlaser.com>
On Wed, Jan 30, 2019 at 09:14:45AM -0700, Jeremy Gebben wrote:
>
> Allow support for chips that support more than 8 frequencies.
> The size still must be a power of two.
>
This is risky. Someone later may not know/remember and
expand the table without maintaining that restriction.
I would suggest to use map_size instead of map_mask.
While that adds some divide operations, none of those are
in a critical path, and the code would be much more robust.
> Signed-off-by: Jeremy Gebben <jgebben@sweptlaser.com>
> ---
> drivers/hwmon/lm85.c | 25 +++++++++++++++----------
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/hwmon/lm85.c b/drivers/hwmon/lm85.c
> index 0a325878e8f5..48f59667a88c 100644
> --- a/drivers/hwmon/lm85.c
> +++ b/drivers/hwmon/lm85.c
> @@ -198,13 +198,13 @@ static int RANGE_TO_REG(long range)
> #define RANGE_FROM_REG(val) lm85_range_map[(val) & 0x0f]
>
> /* These are the PWM frequency encodings */
> -static const int lm85_freq_map[8] = { /* 1 Hz */
> +static const int lm85_freq_map[] = { /* 1 Hz */
> 10, 15, 23, 30, 38, 47, 61, 94
> };
> -static const int adm1027_freq_map[8] = { /* 1 Hz */
> +
> +static const int adm1027_freq_map[] = { /* 1 Hz */
> 11, 15, 22, 29, 35, 44, 59, 88
> };
> -#define FREQ_MAP_LEN 8
>
> static int FREQ_TO_REG(const int *map,
> unsigned int map_size, unsigned long freq)
> @@ -212,9 +212,9 @@ static int FREQ_TO_REG(const int *map,
> return find_closest(freq, map, map_size);
> }
>
> -static int FREQ_FROM_REG(const int *map, u8 reg)
> +static int FREQ_FROM_REG(const int *map, unsigned int map_size, u8 reg)
> {
> - return map[reg & 0x07];
> + return map[reg & (map_size - 1)];
Passing in map_size (calculated as map_mask + 1) just to subtract one
doesn't make sense.
> }
>
> /*
> @@ -296,6 +296,8 @@ struct lm85_data {
> struct i2c_client *client;
> const struct attribute_group *groups[6];
> const int *freq_map;
> + unsigned int freq_map_mask;
> +
> enum chips type;
>
> bool has_vid5; /* true if VID5 is configured for ADT7463 or ADT7468 */
> @@ -514,7 +516,7 @@ static struct lm85_data *lm85_update_device(struct device *dev)
> data->autofan[i].config =
> lm85_read_value(client, LM85_REG_AFAN_CONFIG(i));
> val = lm85_read_value(client, LM85_REG_AFAN_RANGE(i));
> - data->pwm_freq[i] = val & 0x07;
> + data->pwm_freq[i] = val & data->freq_map_mask;
> data->zone[i].range = val >> 4;
> data->autofan[i].min_pwm =
> lm85_read_value(client, LM85_REG_AFAN_MINPWM(i));
> @@ -791,7 +793,8 @@ static ssize_t show_pwm_freq(struct device *dev,
> if (IS_ADT7468_HFPWM(data))
> freq = 22500;
> else
> - freq = FREQ_FROM_REG(data->freq_map, data->pwm_freq[nr]);
> + freq = FREQ_FROM_REG(data->freq_map, data->freq_map_mask + 1,
> + data->pwm_freq[nr]);
>
> return sprintf(buf, "%d\n", freq);
> }
> @@ -820,7 +823,7 @@ static ssize_t set_pwm_freq(struct device *dev,
> lm85_write_value(client, ADT7468_REG_CFG5, data->cfg5);
> } else { /* Low freq. mode */
> data->pwm_freq[nr] = FREQ_TO_REG(data->freq_map,
> - FREQ_MAP_LEN, val);
> + data->freq_map_mask + 1, val);
> lm85_write_value(client, LM85_REG_AFAN_RANGE(nr),
> (data->zone[nr].range << 4)
> | data->pwm_freq[nr]);
> @@ -1196,7 +1199,7 @@ static ssize_t set_temp_auto_temp_min(struct device *dev,
> TEMP_FROM_REG(data->zone[nr].limit));
> lm85_write_value(client, LM85_REG_AFAN_RANGE(nr),
> ((data->zone[nr].range & 0x0f) << 4)
> - | (data->pwm_freq[nr] & 0x07));
> + | data->pwm_freq[nr]);
>
> mutex_unlock(&data->update_lock);
> return count;
> @@ -1232,7 +1235,7 @@ static ssize_t set_temp_auto_temp_max(struct device *dev,
> val - min);
> lm85_write_value(client, LM85_REG_AFAN_RANGE(nr),
> ((data->zone[nr].range & 0x0f) << 4)
> - | (data->pwm_freq[nr] & 0x07));
> + | data->pwm_freq[nr]);
> mutex_unlock(&data->update_lock);
> return count;
> }
> @@ -1569,9 +1572,11 @@ static int lm85_probe(struct i2c_client *client, const struct i2c_device_id *id)
> case emc6d103:
> case emc6d103s:
> data->freq_map = adm1027_freq_map;
> + data->freq_map_mask = ARRAY_SIZE(adm1027_freq_map) - 1;
> break;
> default:
> data->freq_map = lm85_freq_map;
> + data->freq_map_mask = ARRAY_SIZE(lm85_freq_map) - 1;
> }
You'd have to make sure that freq_map_mask is indeed a mask, ie that
ARRAY_SIZE() is a power of two. I would suggest to use freq_map_size
instead.
>
> /* Set the VRM version */
> --
> 2.17.1
>
prev parent reply other threads:[~2019-01-30 17:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-29 21:29 [PATCH 0/3] hwmon: (lm85) add LM96000 high freqency pwm support Jeremy Gebben
2019-01-29 23:38 ` Guenter Roeck
2019-01-30 16:19 ` Jeremy Gebben
2019-01-30 16:14 ` [PATCH resend 1/3] hwmon: (lm85) remove freq_map size hardcodes Jeremy Gebben
2019-01-30 16:14 ` [PATCH resend 2/3] hwmon: (lm85) Document the LM96000 as supported Jeremy Gebben
2019-01-30 16:14 ` [PATCH resend 3/3] hwmon: (lm85) add support for LM96000 high frequencies Jeremy Gebben
2019-01-30 17:25 ` Guenter Roeck [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190130172510.GB14781@roeck-us.net \
--to=linux@roeck-us.net \
--cc=corbet@lwn.net \
--cc=jdelvare@suse.com \
--cc=jgebben@sweptlaser.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).