From: Wei Ni <wni@nvidia.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v3 2/4] hwmon: (lm90) use macro defines for the status bit
Date: Wed, 17 Jul 2013 17:29:32 +0800 [thread overview]
Message-ID: <51E663FC.5050209@nvidia.com> (raw)
In-Reply-To: <20130717102803.6ee36313@endymion.delvare>
On 07/17/2013 04:28 PM, Jean Delvare wrote:
> Hi Wei,
>
> On Wed, 17 Jul 2013 15:03:35 +0800, Wei Ni wrote:
>> On 07/16/2013 12:57 AM, Jean Delvare wrote:
>>> On Fri, 12 Jul 2013 15:48:05 +0800, Wei Ni wrote:
>>>> Add bit defines for the status register.
>>>
>>> Regarding the subject: for me these are constants, not macros. AFAIK
>>> the term "macro" refers to defines with parameters only.
>>
>> How about "Introduce status bits"
>
> I'd say "Define status bits" as this is exactly what you're doing ;-)
> That being said, your patch actually does more than this, as you are
> moving code around and to a separate function. The patch description
> should say that and explain why.
ok, I will update it in my next version.
>
>>>> (...)
>>>> + if ((status & 0x7f) == 0 && (status2 & 0xfe) == 0)
>>>> + return false;
>>>
>>> It's a bit disappointing to not use the freshly introduced constants.
>>> That being said I agree it would make the code hard to read, so you can
>>> leave it as is.
>>
>> Sorry, I forgot it.
>> How about to define:
>> #define LM90_STATUS_MASK 0x7f
>> #define MAX6696_STATUS2_MASK 0xfe
>
> I wouldn't bother. I suspect that this code will have to be reworked
> soon anyway and these constants may no longer be needed then.
Ok, let's leave it as is.
>
>> Or since Guenter is for vacation, I can just leave it as is, and wait
>> him back to talk about below issue.
>
> I do maintain the lm90 driver, so the decision is up to me. Guenter did
> a preliminary review of your patches and I am grateful for that, but I
> do not intend to wait for his return to continue with your patches.
> Otherwise he will have to do the same when he returns and I am gone,
> and this may end up delaying your patches by one kernel version.
I will send out patches soon :)
>
>>>> (...)
>>>> + struct lm90_data *data = i2c_get_clientdata(client);
>>>> + u8 config, alarms;
>>>> +
>>>> + lm90_read_reg(client, LM90_REG_R_STATUS, &alarms);
>>>
>>> You end up reading LM90_REG_R_STATUS, which is not OK. This register
>>> contains self-clearing bits, so there is no guarantee that the second
>>> read will return the same value as the first read. You'll have to come
>>> up with a different approach that reads LM90_REG_R_STATUS only once.
>>
>> Oh, yes, this is a problem, I didn't noticed it.
>> How about to use this:
>> bool lm90_alarms_tripped(*client, *status);
>> bool lm90_alarms2_tripped(*client, *status2);
>> So we can read the status only once and pass it.
>
> This is a good idea but you only need status, not status2, so it can be
> made simpler:
> bool lm90_is_tripped(*client, *status);
> (handling both status and status 2 as you already do.)
Yes this is simpler, but I think in the future we may need to handle the
status2, how to handle it ? Or we can define the status as
bit[0~7]->status and bit[8~15]->status2 .
>
next prev parent reply other threads:[~2013-07-17 9:31 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-12 7:48 [PATCH v3 0/4] Lm90 Enhancements Wei Ni
2013-07-12 7:48 ` [PATCH v3 1/4] hwmon: (lm90) split set&show temp as common codes Wei Ni
2013-07-12 13:26 ` Jean Delvare
2013-07-12 13:50 ` Guenter Roeck
2013-07-12 14:30 ` Jean Delvare
2013-07-12 14:40 ` Guenter Roeck
2013-07-15 6:25 ` Wei Ni
2013-07-15 7:24 ` Jean Delvare
2013-07-15 9:14 ` Wei Ni
2013-07-15 17:52 ` Jean Delvare
2013-07-17 4:26 ` Thierry Reding
2013-07-17 5:14 ` Guenter Roeck
2013-07-17 6:26 ` Wei Ni
2013-07-17 9:11 ` Jean Delvare
2013-07-17 9:54 ` Wei Ni
2013-07-15 6:05 ` Wei Ni
2013-07-15 7:29 ` Jean Delvare
2013-07-12 7:48 ` [PATCH v3 2/4] hwmon: (lm90) use macro defines for the status bit Wei Ni
2013-07-15 16:57 ` Jean Delvare
2013-07-15 17:33 ` Guenter Roeck
2013-10-30 15:33 ` Jean Delvare
2013-10-30 16:11 ` Guenter Roeck
2013-10-30 16:56 ` Guenter Roeck
2013-07-17 7:03 ` Wei Ni
2013-07-17 7:09 ` Wei Ni
2013-07-17 8:28 ` Jean Delvare
2013-07-17 9:29 ` Wei Ni [this message]
2013-07-17 9:46 ` Jean Delvare
2013-07-12 7:48 ` [PATCH v3 3/4] hwmon: (lm90) add support to handle IRQ Wei Ni
2013-07-18 15:58 ` Jean Delvare
2013-07-19 6:41 ` Wei Ni
2013-07-24 7:46 ` Wei Ni
2013-07-24 8:08 ` Jean Delvare
2013-07-27 15:02 ` Jean Delvare
2013-07-29 10:14 ` Wei Ni
2013-07-29 15:58 ` Jean Delvare
2013-07-30 8:18 ` Wei Ni
2013-09-16 12:34 ` Jean Delvare
2013-07-12 7:48 ` [PATCH v3 4/4] hwmon: (lm90) use enums for the indexes of temp8 and temp11 Wei Ni
2013-07-27 15:38 ` Jean Delvare
2013-07-29 11:15 ` Wei Ni
2013-07-29 15:48 ` Jean Delvare
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=51E663FC.5050209@nvidia.com \
--to=wni@nvidia.com \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lm-sensors@lm-sensors.org \
--cc=thierry.reding@gmail.com \
/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).