From: Pavel Machek <pavel@suse.cz>
To: "Eugeny S. Mints" <eugeny.mints@gmail.com>
Cc: linux-pm@lists.osdl.org
Subject: Re: [RFC] PowerOP, PowerOP Core 1/3
Date: Tue, 15 Aug 2006 20:37:57 +0000 [thread overview]
Message-ID: <20060815203756.GI4032@ucw.cz> (raw)
In-Reply-To: <44D7EA4D.1020001@gmail.com>
Hi!
> diff --git a/drivers/Makefile b/drivers/Makefile
> index fc2d744..f8eaf31 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -65,6 +65,7 @@ obj-$(CONFIG_ISDN) += isdn/
> obj-$(CONFIG_EDAC) += edac/
> obj-$(CONFIG_MCA) += mca/
> obj-$(CONFIG_EISA) += eisa/
> +obj-$(CONFIG_POWEROP) += powerop/
Can we make it drivers/power? It is probably suitable for more than
powerop.
> +static int
> +get_point(void *md_opt, const char *pwr_params, va_list args)
> +{
Uhuh... is there a way to use something safer than unchecked va_list
s?
> +int
> +powerop_driver_register(struct powerop_driver *p)
> +{
> + int error = 0;
> +
> + if (! powerop_driver) {
No space between ! and argument...
> +/*
> + * powerop_register_point - add new operating point with a given name to
> + * operating points list. A caller passes power parameters for new operating
> + * points as pairs of name/value and passes only those parameter names the
> + * caller is interested in. PowerOP Core calls powerop driver to initialize
> + * arch dependent part of new operating point and links new named operating
> + * point to the list maintained by PowerOP Core
> + *
> + *
> + * INPUT
> + * id - operating point name
> + * pwr_params - set of (power parameter name, value) pairs
> + *
> + * OUTPUT
> + * none
> + *
> + * RETURN
> + * zero on success, error code otherwise
> + *
> + */
> +int
> +powerop_register_point(const char *id, const char *pwr_params, ...)
> +{
> + int err = 0;
> + struct powerop_point *opt;
> + va_list args;
> +
> + if ((!powerop_initialized) || (id == NULL))
> + return -EINVAL;
> +
> + if ((opt = kmalloc(sizeof(struct powerop_point), GFP_KERNEL)) == NULL)
> + return -ENOMEM;
> +
> + memset(opt, 0, sizeof(struct powerop_point));
kzalloc?
Why do we want one more string parser in kernel?
Pavel
--
Thanks for all the (sleeping) penguins.
next prev parent reply other threads:[~2006-08-15 20:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-08 1:35 [RFC] PowerOP, PowerOP Core 1/3 Eugeny S. Mints
2006-08-15 20:37 ` Pavel Machek [this message]
2006-08-17 22:23 ` Eugeny S. Mints
2006-08-24 8:04 ` 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=20060815203756.GI4032@ucw.cz \
--to=pavel@suse.cz \
--cc=eugeny.mints@gmail.com \
--cc=linux-pm@lists.osdl.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 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.