From: Pavel Machek <pavel@ucw.cz>
To: Adam Belay <abelay@novell.com>
Cc: Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: Re: [RFC] Power Management API (rev 1)
Date: Wed, 20 Apr 2005 17:59:56 +0200 [thread overview]
Message-ID: <20050420155956.GA3372@elf.ucw.cz> (raw)
In-Reply-To: <1113773748.3451.142.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]
Hi!
> I've made some revisions to my new power management API. I would
> appreciate any suggestions or comments.
> /*
> * pm.h - the Power Management Interface
> *
> */
>
> #ifndef _LINUX_PM_H
> #define _LINUX_PM_H
>
> #ifdef __KERNEL__
>
> #include <linux/config.h>
> #include <linux/list.h>
> #include <asm/atomic.h>
>
> struct device;
>
> struct power_resource;
> struct power_driver;
> struct power_policy;
> struct power_device;
>
>
> /*
> * Global System Power States
> *
> * Reflect the status of the overall system.
> */
>
> struct system_power_state {
> unsigned int state;
We already have int system_state... How is this different?
Please move the defines near here, and preferably add type-checking
for sparse.
> unsigned int flags;
>
> struct list_head state_list;
> };
>
> extern int pm_register_system_state(struct system_power_state *state);
> extern void pm_unregister_system_state(struct system_power_state *state);
>
> extern struct system_power_state *
> pm_get_system_state_data(unsigned int state);
Having "unsigned int state" is asking for trouble.
> /*
> * Power States
> *
> * These are used to define device-specific power states.
> */
>
> struct power_state {
> char * name;
> int available;
>
> unsigned int state;
> unsigned int flags;
Are they same type as system_power_state.state? This should be clear,
and type-checked by sparse. Otherwise people will get it wrong.
> /*
> * Power Devices
> *
> * Power devices are the core building block of a system's power management
> * topology. They may require power resources, but the primary dependency
> * relationships are represented by a tree of "power devices". This tree
> * is based on a power domain (or container) model.
> */
>
> struct power_device {
> char * name;
> struct kobject kobj;
>
> unsigned int state;
> unsigned int min_state;
> unsigned int max_state;
Third "state"... Are they same type? Different?
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2005-04-20 15:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-17 21:35 [RFC] Power Management API (rev 1) Adam Belay
2005-04-20 15:59 ` Pavel Machek [this message]
2005-04-23 7:23 ` Adam Belay
2005-04-26 3:04 ` Nigel Cunningham
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=20050420155956.GA3372@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=abelay@novell.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.