linux-hwmon.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 

      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).