From: Richard Purdie <rpurdie@rpsys.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: lenz@cs.wisc.edu, kernel list <linux-kernel@vger.kernel.org>,
Russell King <rmk@arm.linux.org.uk>
Subject: Re: More cleanups for sharpsl_pm.c
Date: Sat, 12 Nov 2005 23:26:43 +0000 [thread overview]
Message-ID: <1131838003.7597.49.camel@localhost.localdomain> (raw)
In-Reply-To: <20051110235614.GA21337@elf.ucw.cz>
On Fri, 2005-11-11 at 00:56 +0100, Pavel Machek wrote:
> sharpsl.c uses macros to hide method calls, in quite a confusing
> way. This just inlines the macros, so it is easy to see what is going
> on.
I'm not totally convinced this makes it easier to read. To me,
CHARGE_ON(); is more readable than sharpsl_pm.machinfo->charge(1);. Yes,
you need to look up what the macro does but the names give a fairly good
idea.
ALso, keeping the macros means when I implement the LED trigger for
charging, I don't have to edit every function in sharpsl_pm but can just
tweak the header and add an extra level of LED functions. Given that,
I'd prefer to leave these as they are for now.
> +/* FIXME:
> + why not simply get_percentage, and base it off that?
> +*/
> if (sharpsl_pm.charge_mode == CHRG_ON) {
> high_thresh = sharpsl_pm.machinfo->status_high_acin;
> low_thresh = sharpsl_pm.machinfo->status_low_acin;
The percentage curves is likely to change in the future and I doubt
anyone would remember to update these values. I'd therefore prefer for
them to be independent of the lookup table.
(The table will change once I get more discharge profiles from users and
can work out a more accurate discharge curve).
Richard
next prev parent reply other threads:[~2005-11-12 23:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-10 23:56 More cleanups for sharpsl_pm.c Pavel Machek
2005-11-12 23:26 ` Richard Purdie [this message]
2005-11-14 22:05 ` Pavel Machek
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=1131838003.7597.49.camel@localhost.localdomain \
--to=rpurdie@rpsys.net \
--cc=lenz@cs.wisc.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rmk@arm.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.