mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Greg KH <greg@kroah.com>
Cc: Andrew Morton <akpm@zip.com.au>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Type-checking for pci layer
Date: Wed, 3 Nov 2004 23:14:40 +0100	[thread overview]
Message-ID: <20041103221440.GG1574@elf.ucw.cz> (raw)
In-Reply-To: <20041103215130.GA30621@kroah.com>

Hi!

> > This adds type-checking to PCI layer. u32 has been replaced with
> > defines, so it is no longer easy to confuse it with system suspend
> > level. Patrick included it in his power tree, but I guess direct
> > merging to you (Andrew) is faster/easier way to go? Please apply,
> > 
> > 								Pavel
> > 
> > Acked-by: Greg KH <greg@kroah.com>
> 
> Woah, I've never acked this patch.  Let me push it through my pci trees,
> or if Pat's already taken it, I'll get it from him through that path.

Did I misunderstandd email exchange? [I have full version with all
headers, too...]. [I hope I sent same patch as last time... Hmm, only
files were transposed]

Or did you just say that you agree with Patrick, nothing about
original patch?


From: Pavel Machek <pavel@ucw.cz>
To: Greg KH <greg@kroah.com>,
	Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: [linux-pm] Typechecking for pci layer

--===============94806148714041028==
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi!

Does this look like a way to go? I created special type for pci power
state, because otherwise it is too tempting to pass system power level
(or something completely unrelated :) to pci_ functions.

I'm not sure if PCI_D3cold should be included like
this. pci_enable_wake at least ignores it...

								Pavel

--- clean/drivers/pci/pci.c	2004-10-01 00:30:16.000000000 +0200
+++ linux/drivers/pci/pci.c	2004-10-25 23:24:37.000000000 +0200
@@ -242,7 +242,7 @@
  */
 
 int
-pci_set_power_state(struct pci_dev *dev, int state)
+pci_set_power_state(struct pci_dev *dev, pci_power_t state)
 {
 	int pm;
 	u16 pmcsr;
@@ -422,7 +422,7 @@
  * 0 if operation is successful.
  * 
  */
-int pci_enable_wake(struct pci_dev *dev, u32 state, int enable)
+int pci_enable_wake(struct pci_dev *dev, pci_power_t state, int enable)
 {
 	int pm;
 	u16 value;
--- clean/include/linux/pci.h	2004-10-01 00:30:30.000000000 +0200
+++ linux/include/linux/pci.h	2004-10-25 23:25:41.000000000 +0200
@@ -480,6 +480,14 @@
 #define DEVICE_COUNT_COMPATIBLE	4
 #define DEVICE_COUNT_RESOURCE	12
 
+typedef int __bitwise pci_power_t;
+
+#define PCI_D0	((pci_power_t __force) 0)
+#define PCI_D1	((pci_power_t __force) 1)
+#define PCI_D2	((pci_power_t __force) 2)
+#define PCI_D3hot	((pci_power_t __force) 3)
+#define PCI_D3cold	((pci_power_t __force) 4)
+
 /*
  * The pci_dev structure is used to describe PCI devices.
  */
@@ -508,7 +516,7 @@
 					   this if your device has broken DMA
 					   or supports 64-bit transfers.  */
 
-	u32             current_state;  /* Current operating state. In ACPI-speak,
+	pci_power_t     current_state;  /* Current operating state. In ACPI-speak,
 					   this is D0-D3, D0 being fully functional,
 					   and D3 being off. */
 
@@ -645,7 +653,7 @@
 	struct pci_dynids dynids;
 };
 
-#define	to_pci_driver(drv) container_of(drv,struct pci_driver, driver)
+#define	to_pci_driver(drv) container_of(drv, struct pci_driver, driver)
 
 /**
  * PCI_DEVICE - macro used to describe a specific pci device
@@ -781,8 +789,8 @@
 /* Power management related routines */
 int pci_save_state(struct pci_dev *dev, u32 *buffer);
 int pci_restore_state(struct pci_dev *dev, u32 *buffer);
-int pci_set_power_state(struct pci_dev *dev, int state);
-int pci_enable_wake(struct pci_dev *dev, u32 state, int enable);
+int pci_set_power_state(struct pci_dev *dev, pci_power_t state);
+int pci_enable_wake(struct pci_dev *dev, pci_power_t state, int enable);
 
 /* Helper functions for low-level code (drivers/pci/setup-[bus,res].c) */
 void pci_bus_assign_resources(struct pci_bus *bus);

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

From: Patrick Mochel <mochel@digitalimplant.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Greg KH <greg@kroah.com>,
	Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: Re: [linux-pm] Typechecking for pci layer

On Tue, 26 Oct 2004, Pavel Machek wrote:

> Hi!
>
> Does this look like a way to go? I created special type for pci power
> state, because otherwise it is too tempting to pass system power level
> (or something completely unrelated :) to pci_ functions.
>
> I'm not sure if PCI_D3cold should be included like
> this. pci_enable_wake at least ignores it...

It's not a real state that devices can enter; IIRC it just describes the
state devices are in when the system is initially turned on. I don't know
why some drivers use it, but it doesn't seem right. (It's been a while
since I read the spec, though, so I could be wrong.)

If Greg ACKs it, I'll add it to my tree and push it upwards.


	Pat

From: Greg KH <greg@kroah.com>
To: Patrick Mochel <mochel@digitalimplant.org>
Cc: Pavel Machek <pavel@ucw.cz>,
	Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: Re: [linux-pm] Typechecking for pci layer

On Thu, Oct 28, 2004 at 08:43:55AM -0700, Patrick Mochel wrote:
> 
> On Tue, 26 Oct 2004, Pavel Machek wrote:
> 
> > Hi!
> >
> > Does this look like a way to go? I created special type for pci power
> > state, because otherwise it is too tempting to pass system power level
> > (or something completely unrelated :) to pci_ functions.
> >
> > I'm not sure if PCI_D3cold should be included like
> > this. pci_enable_wake at least ignores it...
> 
> It's not a real state that devices can enter; IIRC it just describes the
> state devices are in when the system is initially turned on. I don't know
> why some drivers use it, but it doesn't seem right. (It's been a while
> since I read the spec, though, so I could be wrong.)
> 
> If Greg ACKs it, I'll add it to my tree and push it upwards.

ACK.

heh, reminds me of bill the cat...

greg k-h


-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

  reply	other threads:[~2004-11-03 22:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-03 21:47 Pavel Machek
2004-11-03 21:51 ` Greg KH
2004-11-03 22:14   ` Pavel Machek [this message]
2004-11-03 22:21     ` Greg KH
2004-11-03 22:48       ` Pavel Machek
2004-11-03 23:11         ` Andrew Morton

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=20041103221440.GG1574@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=akpm@zip.com.au \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®