public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Henrik Rydberg <rydberg@euromail.se>
To: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Jean Delvare <khali@linux-fr.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>
Subject: Re: [lm-sensors] [PATCH 2/8] hwmon: applesmc: Introduce a register lookup table
Date: Thu, 04 Nov 2010 09:20:18 +0100	[thread overview]
Message-ID: <4CD26CC2.7070401@euromail.se> (raw)
In-Reply-To: <20101104042121.GA19231@ericsson.com>

Hi Guenter,

>> @@ -217,14 +235,13 @@ static unsigned int fans_handled;

>>  /* Indicates which temperature sensors set to use. */
>>  static unsigned int applesmc_temperature_set;
>>
>> -static DEFINE_MUTEX(applesmc_lock);
>> -
>>  /*
>>   * Last index written to key_at_index sysfs file, and value to use for all other
>>   * key_at_index_* sysfs files.
>>   */
>>  static unsigned int key_at_index;
>>
>> +
> 
> unnecessary blank line


Ironically, I even tried to get rid out it two times. ;-)

>> +static int applesmc_get_entry_by_index(int index, struct applesmc_entry *entry)
>> +{
> 
> One thing I don't understand about the whole caching scheme - why don't you just
> return (and use) a pointer to the cached entry ? Seems to me that would be much simpler.
> If you want to return error types, you could use ERR_PTR, PTR_ERR, and IS_ERR.


Yes, the return types are important. I can change this, it will reduce the patch
by some lines.

>> +       struct applesmc_entry *cache = &smcreg.entry[index];
>> +       __be32 be;
>> +       int ret;
>> +
>> +       if (cache->valid) {
>> +               memcpy(entry, cache, sizeof(*entry));
>> +               return 0;
>>         }
>> -       key[4] = 0;
>>
>> -       return 0;
>> +       mutex_lock(&smcreg.mutex);


Note to self: it is possible to arrive here with a valid cache. If pointers are
used, exit to avoid incoherent reads.

>> +
>> +       be = cpu_to_be32(index);
>> +       ret = read_smc(APPLESMC_GET_KEY_BY_INDEX_CMD, (u8 *)&be, cache->key, 4);
>> +       if (ret)
>> +               goto out;
>> +       ret = read_smc(APPLESMC_GET_KEY_TYPE_CMD, cache->key, &cache->len, 6);
> 
> This one is a bit odd. cache->len is an u8. You are reading 6 bytes into it.
> I assume this is supposed to fill both cache->len and cache->type in a single operation.


True.


> Not sure if this is a good idea. Seems to depend a lot on the assumption that
> fields are consecutive. Might be safer to read the data into a temporary
> 6 byte buffer and copy it into ->len and ->type afterwards.


Right, there could be alignment problems here. Thanks.

> If that is not acceptable, please add a comment describing what you are doing here
> and why.


It was just about the extra stack space. There will be a natural place for the
buffer once the pointer are used.

>> +       if (ret)
>> +               goto out;
>> +
>> +       cache->type[4] = 0;
> 
> Why read 6 bytes above if you overwrite the last byte anyway ?


Backwards compatibility reasons. The register type names have been used as four
byte strings since the beginning. I do not know is the last value codes
something else - I can make that clearer by reserving a byte in the struct instead.

> 
>> +       cache->valid = 1;


Continued note to self: a switch here is not handled properly.

>> +       memcpy(entry, cache, sizeof(*entry));
>> +
>> +out:
>> +       mutex_unlock(&smcreg.mutex);
>> +       return ret;
>>  }



>> +/*
>> + * applesmc_init_smcreg_try - Try to initialize register cache. Idempotent.
>> + */
>> +static int applesmc_init_smcreg_try(void)
>> +{
>> +       struct applesmc_registers *s = &smcreg;
>> +       int ret;
>> +
>> +       if (s->init_complete)
>> +               return 0;
>> +
>> +       mutex_init(&s->mutex);
>> +
>> +       ret = read_register_count(&s->key_count);
>> +       if (ret)
>> +               return ret;
>> +
>> +       if (!s->entry)
>> +               s->entry = kcalloc(s->key_count, sizeof(*s->entry), GFP_KERNEL);
>> +       if (!s->entry)
>> +               return -ENOMEM;
>> +
>> +       s->init_complete = true;
>> +
>> +       pr_info("key=%d\n", s->key_count);
>> +
>> +       return 0;
>> +}
>> +
>> +/*
>> + * applesmc_init_smcreg - Initialize register cache.
>> + *
>> + * Retries until initialization is successful, or the operation times out.
>> + *
>> + */
>> +static int applesmc_init_smcreg(void)
>> +{
>> +       int ms, ret;
>> +
>> +       for (ms = 0; ms < INIT_TIMEOUT_MSECS; ms += INIT_WAIT_MSECS) {
>> +               ret = applesmc_init_smcreg_try();
>> +               if (!ret)
>> +                       return 0;
>> +               pr_warn("slow init, retrying\n");
>> +               msleep(INIT_WAIT_MSECS);
>> +       }
>> +
>> +       return ret;
>> +}
>> +
>> +static void applesmc_destroy_smcreg(void)
>> +{
>> +       kfree(smcreg.entry);
>> +       smcreg.entry = NULL;
> 
> Do you also have to reset init_complete ?


Yes!

Thanks,
Henrik

  reply	other threads:[~2010-11-04  8:23 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-31  7:50 [PATCH 0/8] hwmon: applesmc: Dynamic configuration rewrite Henrik Rydberg
2010-10-31  7:50 ` [PATCH 1/8] hwmon: applesmc: Relax the severity of device init failure Henrik Rydberg
2010-11-02 16:03   ` [lm-sensors] " Guenter Roeck
2010-11-03 14:45     ` Henrik Rydberg
2010-10-31  7:50 ` [PATCH 2/8] hwmon: applesmc: Introduce a register lookup table Henrik Rydberg
2010-11-04  4:21   ` [lm-sensors] " Guenter Roeck
2010-11-04  8:20     ` Henrik Rydberg [this message]
2010-10-31  7:50 ` [PATCH 3/8] hwmon: applesmc: Dynamic creation of temperature files Henrik Rydberg
2010-11-05  2:23   ` [lm-sensors] " Guenter Roeck
2010-10-31  7:50 ` [PATCH 4/8] hwmon: applesmc: Handle new temperature format Henrik Rydberg
2010-11-05  2:32   ` [lm-sensors] " Guenter Roeck
2010-11-05  2:35   ` Guenter Roeck
2010-11-05  8:34     ` Henrik Rydberg
2010-10-31  7:50 ` [PATCH 5/8] hwmon: applesmc: Extract all features generically Henrik Rydberg
2010-11-05  2:50   ` [lm-sensors] " Guenter Roeck
2010-11-05  8:52     ` Henrik Rydberg
2010-10-31  7:50 ` [PATCH 6/8] hwmon: applesmc: Dynamic creation of fan files Henrik Rydberg
2010-11-05  2:59   ` [lm-sensors] " Guenter Roeck
2010-11-05  8:56     ` Henrik Rydberg
2010-10-31  7:50 ` [PATCH 7/8] hwmon: applesmc: Simplify feature sysfs handling Henrik Rydberg
2010-11-05  3:07   ` [lm-sensors] " Guenter Roeck
2010-10-31  7:50 ` [PATCH 8/8] hwmon: applesmc: Update copyright information Henrik Rydberg
2010-11-05  3:09   ` [lm-sensors] " Guenter Roeck
2010-11-05  9:00     ` Henrik Rydberg
2010-11-05 11:45       ` Guenter Roeck
2010-10-31  8:31 ` [PATCH 0/8] hwmon: applesmc: Dynamic configuration rewrite Joe Perches
2010-10-31  8:44   ` Henrik Rydberg
2010-10-31  8:55     ` Joe Perches
2010-10-31 10:05     ` Jean Delvare
2010-11-03 13:48 ` [lm-sensors] " Guenter Roeck
2010-11-03 14:43   ` Henrik Rydberg

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=4CD26CC2.7070401@euromail.se \
    --to=rydberg@euromail.se \
    --cc=guenter.roeck@ericsson.com \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.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