Re: [PATCH] Add PCI_DEVICE_TABLE macro

2008-02-20 Thread Jeff Garzik
Greg KH wrote: On Mon, Feb 18, 2008 at 08:34:42AM +0100, Jonas Bonn wrote: And again, what does this buy us? Clarity and simplicity, I hope... there are a bunch of definitions scattered about the kernel that omit the __devinitdata modifier despite the documentation stating that it should

Re: [PATCH] Add PCI_DEVICE_TABLE macro

2008-02-20 Thread Greg KH
On Mon, Feb 18, 2008 at 08:34:42AM +0100, Jonas Bonn wrote: >> And again, what does this buy us? > > Clarity and simplicity, I hope... there are a bunch of definitions > scattered about the kernel that omit the __devinitdata modifier despite the > documentation stating that it should always be

[PATCH] Add PCI_DEVICE_TABLE macro

2008-02-20 Thread Jonas Bonn
The definitions of struct pci_device_id arrays should generally follow the same pattern across the entire kernel. This macro defines this array as const and puts it into the __devinitconst section. Signed-off-by: Jonas Bonn <[EMAIL PROTECTED]> --- include/linux/pci.h |9 + 1 files

[PATCH] Add PCI_DEVICE_TABLE macro

2008-02-20 Thread Jonas Bonn
The definitions of struct pci_device_id arrays should generally follow the same pattern across the entire kernel. This macro defines this array as const and puts it into the __devinitconst section. Signed-off-by: Jonas Bonn [EMAIL PROTECTED] --- include/linux/pci.h |9 + 1 files

Re: [PATCH] Add PCI_DEVICE_TABLE macro

2008-02-20 Thread Greg KH
On Mon, Feb 18, 2008 at 08:34:42AM +0100, Jonas Bonn wrote: And again, what does this buy us? Clarity and simplicity, I hope... there are a bunch of definitions scattered about the kernel that omit the __devinitdata modifier despite the documentation stating that it should always be there.

Re: [PATCH] Add PCI_DEVICE_TABLE macro

2008-02-20 Thread Jeff Garzik
Greg KH wrote: On Mon, Feb 18, 2008 at 08:34:42AM +0100, Jonas Bonn wrote: And again, what does this buy us? Clarity and simplicity, I hope... there are a bunch of definitions scattered about the kernel that omit the __devinitdata modifier despite the documentation stating that it should

[PATCH] Add PCI_DEVICE_TABLE macro

2008-02-18 Thread Jonas Bonn
The definitions of struct pci_device_id arrays should generally follow the same pattern across the entire kernel. This macro defines this array as const and puts it into the __devinitconst section. Signed-off-by: Jonas Bonn <[EMAIL PROTECTED]> --- include/linux/pci.h |9 + 1 files

[PATCH] Add PCI_DEVICE_TABLE macro

2008-02-18 Thread Jonas Bonn
The definitions of struct pci_device_id arrays should generally follow the same pattern across the entire kernel. This macro defines this array as const and puts it into the __devinitconst section. Signed-off-by: Jonas Bonn [EMAIL PROTECTED] --- include/linux/pci.h |9 + 1 files

Re: [PATCH] Add PCI_DEVICE_TABLE macro

2008-02-17 Thread Jonas Bonn
And again, what does this buy us? Clarity and simplicity, I hope... there are a bunch of definitions scattered about the kernel that omit the __devinitdata modifier despite the documentation stating that it should always be there. The definition really should have been const, which wasn't

Re: [PATCH] Add PCI_DEVICE_TABLE macro

2008-02-17 Thread Greg KH
On Sun, Feb 17, 2008 at 01:13:24PM +0100, Jonas Bonn wrote: > I'm a bit uncertain whether the definition really should include the > 'static' modifier... for most definitions of these tables this is ok, > but there are a couple of cases where it should not be static, so the > line would need to be

Re: [PATCH] Add PCI_DEVICE_TABLE macro

2008-02-17 Thread Randy Dunlap
On Sun, 17 Feb 2008 13:10:05 +0100 Jonas Bonn wrote: > The definitions of struct pci_device_id arrays should generally follow > the same pattern across the entire kernel. This macro defines this > array as static const and puts it into the __devinitconst section. > > Signed-off-by: Jonas Bonn

Re: [PATCH] Add PCI_DEVICE_TABLE macro

2008-02-17 Thread Jonas Bonn
I'm a bit uncertain whether the definition really should include the 'static' modifier... for most definitions of these tables this is ok, but there are a couple of cases where it should not be static, so the line would need to be open-coded again... /Jonas On Sun, 2008-02-17 at 13:10 +0100,

[PATCH] Add PCI_DEVICE_TABLE macro

2008-02-17 Thread Jonas Bonn
The definitions of struct pci_device_id arrays should generally follow the same pattern across the entire kernel. This macro defines this array as static const and puts it into the __devinitconst section. Signed-off-by: Jonas Bonn <[EMAIL PROTECTED]> --- include/linux/pci.h |8 1

[PATCH] Add PCI_DEVICE_TABLE macro

2008-02-17 Thread Jonas Bonn
The definitions of struct pci_device_id arrays should generally follow the same pattern across the entire kernel. This macro defines this array as static const and puts it into the __devinitconst section. Signed-off-by: Jonas Bonn [EMAIL PROTECTED] --- include/linux/pci.h |8 1

Re: [PATCH] Add PCI_DEVICE_TABLE macro

2008-02-17 Thread Jonas Bonn
I'm a bit uncertain whether the definition really should include the 'static' modifier... for most definitions of these tables this is ok, but there are a couple of cases where it should not be static, so the line would need to be open-coded again... /Jonas On Sun, 2008-02-17 at 13:10 +0100,

Re: [PATCH] Add PCI_DEVICE_TABLE macro

2008-02-17 Thread Randy Dunlap
On Sun, 17 Feb 2008 13:10:05 +0100 Jonas Bonn wrote: The definitions of struct pci_device_id arrays should generally follow the same pattern across the entire kernel. This macro defines this array as static const and puts it into the __devinitconst section. Signed-off-by: Jonas Bonn [EMAIL

Re: [PATCH] Add PCI_DEVICE_TABLE macro

2008-02-17 Thread Greg KH
On Sun, Feb 17, 2008 at 01:13:24PM +0100, Jonas Bonn wrote: I'm a bit uncertain whether the definition really should include the 'static' modifier... for most definitions of these tables this is ok, but there are a couple of cases where it should not be static, so the line would need to be

Re: [PATCH] Add PCI_DEVICE_TABLE macro

2008-02-17 Thread Jonas Bonn
And again, what does this buy us? Clarity and simplicity, I hope... there are a bunch of definitions scattered about the kernel that omit the __devinitdata modifier despite the documentation stating that it should always be there. The definition really should have been const, which wasn't