From: Guenter Roeck <linux@roeck-us.net>
To: Jean Delvare <jdelvare@suse.de>
Cc: Alvaro Gamez Machado <alvaro.gamez@hazent.com>,
linux-hwmon@vger.kernel.org
Subject: Re: [PATCH] hwmon: (lm92) Do not try to detect MAX6635
Date: Thu, 22 Mar 2018 09:30:49 -0700 [thread overview]
Message-ID: <20180322163049.GA25601@roeck-us.net> (raw)
In-Reply-To: <20180322101702.247542e2@endymion>
On Thu, Mar 22, 2018 at 10:17:02AM +0100, Jean Delvare wrote:
> On Wed, 21 Mar 2018 16:04:52 +0100, Alvaro Gamez Machado wrote:
> > Maxim MAX663x family are mostly compatible with LM92, but they lack any
> > identification register. Weakening the detect function would make it prone
> > to false positives, and current one doesn't detect all chips. Therefore,
> > the detect function for max6635 devices is removed in favor of explicit
> > device instatiation.
> >
> > Signed-off-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
> > ---
> > Documentation/hwmon/lm92 | 4 +---
> > drivers/hwmon/lm92.c | 58 ------------------------------------------------
> > 2 files changed, 1 insertion(+), 61 deletions(-)
> >
> > diff --git a/Documentation/hwmon/lm92 b/Documentation/hwmon/lm92
> > index 22f68ad032cf..f2a5adcf4ead 100644
> > --- a/Documentation/hwmon/lm92
> > +++ b/Documentation/hwmon/lm92
> > @@ -12,9 +12,7 @@ Supported chips:
> > Datasheet: http://www.national.com/pf/LM/LM76.html
> > * Maxim MAX6633/MAX6634/MAX6635
> > Prefix: 'lm92'
> > - Addresses scanned: I2C 0x48 - 0x4b
> > - MAX6633 with address in 0x40 - 0x47, 0x4c - 0x4f needs force parameter
> > - and MAX6634 with address in 0x4c - 0x4f needs force parameter
> > + Addresses scanned: none, force parameter needed
> > Datasheet: http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3074
> >
> > Authors:
> > diff --git a/drivers/hwmon/lm92.c b/drivers/hwmon/lm92.c
> > index 2a91974a10bb..18509b5af11e 100644
> > --- a/drivers/hwmon/lm92.c
> > +++ b/drivers/hwmon/lm92.c
> > @@ -259,62 +259,6 @@ static void lm92_init_client(struct i2c_client *client)
> > config & 0xFE);
> > }
> >
> > -/*
> > - * The MAX6635 has no identification register, so we have to use tricks
> > - * to identify it reliably. This is somewhat slow.
> > - * Note that we do NOT rely on the 2 MSB of the configuration register
> > - * always reading 0, as suggested by the datasheet, because it was once
> > - * reported not to be true.
> > - */
> > -static int max6635_check(struct i2c_client *client)
> > -{
> > - u16 temp_low, temp_high, temp_hyst, temp_crit;
> > - u8 conf;
> > - int i;
> > -
> > - /*
> > - * No manufacturer ID register, so a read from this address will
> > - * always return the last read value.
> > - */
> > - temp_low = i2c_smbus_read_word_data(client, LM92_REG_TEMP_LOW);
> > - if (i2c_smbus_read_word_data(client, LM92_REG_MAN_ID) != temp_low)
> > - return 0;
> > - temp_high = i2c_smbus_read_word_data(client, LM92_REG_TEMP_HIGH);
> > - if (i2c_smbus_read_word_data(client, LM92_REG_MAN_ID) != temp_high)
> > - return 0;
> > -
> > - /* Limits are stored as integer values (signed, 9-bit). */
> > - if ((temp_low & 0x7f00) || (temp_high & 0x7f00))
> > - return 0;
> > - temp_hyst = i2c_smbus_read_word_data(client, LM92_REG_TEMP_HYST);
> > - temp_crit = i2c_smbus_read_word_data(client, LM92_REG_TEMP_CRIT);
> > - if ((temp_hyst & 0x7f00) || (temp_crit & 0x7f00))
> > - return 0;
> > -
> > - /*
> > - * Registers addresses were found to cycle over 16-byte boundaries.
> > - * We don't test all registers with all offsets so as to save some
> > - * reads and time, but this should still be sufficient to dismiss
> > - * non-MAX6635 chips.
> > - */
> > - conf = i2c_smbus_read_byte_data(client, LM92_REG_CONFIG);
> > - for (i = 16; i < 96; i *= 2) {
> > - if (temp_hyst != i2c_smbus_read_word_data(client,
> > - LM92_REG_TEMP_HYST + i - 16)
> > - || temp_crit != i2c_smbus_read_word_data(client,
> > - LM92_REG_TEMP_CRIT + i)
> > - || temp_low != i2c_smbus_read_word_data(client,
> > - LM92_REG_TEMP_LOW + i + 16)
> > - || temp_high != i2c_smbus_read_word_data(client,
> > - LM92_REG_TEMP_HIGH + i + 32)
> > - || conf != i2c_smbus_read_byte_data(client,
> > - LM92_REG_CONFIG + i))
> > - return 0;
> > - }
> > -
> > - return 1;
> > -}
> > -
> > static struct attribute *lm92_attrs[] = {
> > &sensor_dev_attr_temp1_input.dev_attr.attr,
> > &sensor_dev_attr_temp1_crit.dev_attr.attr,
> > @@ -348,8 +292,6 @@ static int lm92_detect(struct i2c_client *new_client,
> >
> > if ((config & 0xe0) == 0x00 && man_id == 0x0180)
> > pr_info("lm92: Found National Semiconductor LM92 chip\n");
> > - else if (max6635_check(new_client))
> > - pr_info("lm92: Found Maxim MAX6635 chip\n");
> > else
> > return -ENODEV;
> >
>
> Reviewed-by: Jean Delvare <jdelvare@suse.de>
>
> It would probably make sense to add prefix "max6635" to lm92_id[] so
> that the device can be instantiated by its actual name.
Excellent idea. I took the freedom to add that to the patch.
Thanks,
Guenter
>
> --
> Jean Delvare
> SUSE L3 Support
prev parent reply other threads:[~2018-03-22 16:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 15:04 [PATCH] hwmon: (lm92) Do not try to detect MAX6635 Alvaro Gamez Machado
2018-03-22 1:53 ` Guenter Roeck
2018-03-22 9:17 ` [PATCH] " Jean Delvare
2018-03-22 16:30 ` 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=20180322163049.GA25601@roeck-us.net \
--to=linux@roeck-us.net \
--cc=alvaro.gamez@hazent.com \
--cc=jdelvare@suse.de \
--cc=linux-hwmon@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