From: Jonas Bonn <jonas@southpole.se> Date: 2008-02-20 12:55:15
The PCI_DEVICE_TABLE patch I sent earlier doesn't necessarily make much sense by itself... here is a set of patches that apply this macro, in turn moving a lot of this data into __devinitconst which is discardable in certain situations. Hopefully the benefit of this approach is a bit clearer now.
drivers/net/3c59x.c | 2 +-
drivers/net/amd8111e.c | 2 +-
drivers/net/arcnet/com20020-pci.c | 2 +-
drivers/net/defxx.c | 2 +-
drivers/net/hamachi.c | 2 +-
drivers/net/niu.c | 2 +-
drivers/net/pasemi_mac.c | 2 +-
drivers/net/sk98lin/skge.c | 2 +-
drivers/net/skfp/skfddi.c | 2 +-
drivers/net/starfire.c | 2 +-
drivers/net/sunhme.c | 2 +-
drivers/net/tlan.c | 2 +-
drivers/net/wan/dscc4.c | 2 +-
drivers/net/wan/lmc/lmc_main.c | 2 +-
include/linux/pci.h | 9 +++++++++
15 files changed, 23 insertions(+), 14 deletions(-)
From: Jonas Bonn <jonas@southpole.se> Date: 2008-02-20 12:55:42
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 <jonas@southpole.se>
---
include/linux/pci.h | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
From: Sam Ravnborg <hidden> Date: 2008-02-20 13:17:25
On Wed, Feb 20, 2008 at 01:53:36PM +0100, Jonas Bonn wrote:
The PCI_DEVICE_TABLE patch I sent earlier doesn't necessarily make
much sense by itself... here is a set of patches that apply
this macro, in turn moving a lot of this data into __devinitconst
which is discardable in certain situations.
Hopefully the benefit of this approach is a bit clearer now.
[shorter lines please..]
Can you please confirm that this does not break powerpc (64 bit)
as they have troubles with the constification..
Sam
From: Jonas Bonn <jonas@southpole.se> Date: 2008-02-20 13:27:34
Sam Ravnborg wrote:
On Wed, Feb 20, 2008 at 01:53:36PM +0100, Jonas Bonn wrote:
quoted
The PCI_DEVICE_TABLE patch I sent earlier doesn't necessarily make
much sense by itself... here is a set of patches that apply
this macro, in turn moving a lot of this data into __devinitconst
which is discardable in certain situations.
Hopefully the benefit of this approach is a bit clearer now.
[shorter lines please..]
Sorry...
Can you please confirm that this does not break powerpc (64 bit)
as they have troubles with the constification..
I do not have access to any PowerPC machine... Olof Johansson built the
tree I posted earlier on PowerPC; there's nothing really new here except
the wrapping of the definition in a macro.
But of course, it would great if someone could confirm this...
From: Sam Ravnborg <hidden> Date: 2008-02-20 13:55:46
On Wed, Feb 20, 2008 at 02:27:19PM +0100, Jonas Bonn wrote:
Sam Ravnborg wrote:
quoted
On Wed, Feb 20, 2008 at 01:53:36PM +0100, Jonas Bonn wrote:
quoted
The PCI_DEVICE_TABLE patch I sent earlier doesn't necessarily make
much sense by itself... here is a set of patches that apply
this macro, in turn moving a lot of this data into __devinitconst
which is discardable in certain situations.
Hopefully the benefit of this approach is a bit clearer now.
[shorter lines please..]
Sorry...
quoted
Can you please confirm that this does not break powerpc (64 bit)
as they have troubles with the constification..
I do not have access to any PowerPC machine... Olof Johansson built the
tree I posted earlier on PowerPC; there's nothing really new here except
the wrapping of the definition in a macro.
And you added const and a specific section.
Exactly what could break on PowerPC.
To do the build break check is easy.
Google for "crosstool" and build your own powerpc toolchain.
Andrew has something precompiled somewhere but I lost the link.
Sam
From: Jonas Bonn <jonas@southpole.se> Date: 2008-02-20 14:03:43
Sam Ravnborg wrote:
On Wed, Feb 20, 2008 at 02:27:19PM +0100, Jonas Bonn wrote:
quoted
Sam Ravnborg wrote:
quoted
On Wed, Feb 20, 2008 at 01:53:36PM +0100, Jonas Bonn wrote:
quoted
The PCI_DEVICE_TABLE patch I sent earlier doesn't necessarily make
much sense by itself... here is a set of patches that apply
this macro, in turn moving a lot of this data into __devinitconst
which is discardable in certain situations.
Hopefully the benefit of this approach is a bit clearer now.
[shorter lines please..]
Sorry...
quoted
Can you please confirm that this does not break powerpc (64 bit)
as they have troubles with the constification..
I do not have access to any PowerPC machine... Olof Johansson built the
tree I posted earlier on PowerPC; there's nothing really new here except
the wrapping of the definition in a macro.
And you added const and a specific section.
No... once the macro is expanded the code is exactly the same as that
which built cleanly on powerpc previously (which Olof, built, I mean)...
nothing new here.
Exactly what could break on PowerPC.
To do the build break check is easy.
Google for "crosstool" and build your own powerpc toolchain.
Thanks... I'll throw together a cross compiler and see what I can do.
/Jonas
Andrew has something precompiled somewhere but I lost the link.
Sam