Re: [Fixed PATCH] hpt366: fix section mismatch warnings
On Sun, Feb 24, 2008 at 03:33:51PM +0100, Bartlomiej Zolnierkiewicz wrote: > On Saturday 23 February 2008, Sam Ravnborg wrote: > > hpt366: fix section mismatch warnings > > > > Fix following warnings: > > WARNING: o-sparc64/vmlinux.o(.data+0x195a38): Section mismatch in reference > > from the variable hpt37x_info.0 to the variable .devinit.data:hpt370 > > WARNING: o-sparc64/vmlinux.o(.data+0x195a40): Section mismatch in reference > > from the variable hpt37x_info.0 to the variable .devinit.data:hpt370a > > WARNING: o-sparc64/vmlinux.o(.data+0x195a48): Section mismatch in reference > > from the variable hpt37x_info.0 to the variable .devinit.data:hpt372 > > WARNING: o-sparc64/vmlinux.o(.data+0x195a50): Section mismatch in reference > > from the variable hpt37x_info.0 to the variable .devinit.data:hpt372n > > > > Replace a static array with a small switch resulting in > > more readable code. > > Mark the pci table __devinitconst. > > > > A lot of variables are const but annotated __devinitdata. > > Annotating them __devinitconst would cause a section type > > conflict error when build for 64 bit powerpc. > > > > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> > > Cc: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> > > Cc: Sergei Shtylyov <[EMAIL PROTECTED]> > > --- > > thanks, applied > > > The first patch I posted caused a section type conflict when > > build for 64 bit powerpc. The actual cause of this is know and unavoidable > > when we start to declare variables const. > > The patch attached is much simpler as the transition from __devinitdata > > to __devinitconst turned out to be bogus. > > Weird, I thought that the main purpose of __devinitconst was to replace > const + __devinitdata? The problem we face is that gcc in some cases mark the destination section READ-ONLY and in other cases not. So if we annotate two variables to go into the same section and gcc only annotate one of them READ-ONLY them we will have a section type conflict. gcc is not consistent across architectures what to mark READ-ONLY and not. And what we saw here was a combination where on x86 the destinatin section were marked equal (READ-ONLY or not READ-ONLY) but on powerpc were marked different. One was marked READ-ONLY the other was not. So when playing with const it is improtant to try out with a 64 bit gcc for powerpc to see if it causes any section type conflict. Note: 32 bit gcc does not have this issue. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fixed PATCH] hpt366: fix section mismatch warnings
On Saturday 23 February 2008, Sam Ravnborg wrote: > hpt366: fix section mismatch warnings > > Fix following warnings: > WARNING: o-sparc64/vmlinux.o(.data+0x195a38): Section mismatch in reference > from the variable hpt37x_info.0 to the variable .devinit.data:hpt370 > WARNING: o-sparc64/vmlinux.o(.data+0x195a40): Section mismatch in reference > from the variable hpt37x_info.0 to the variable .devinit.data:hpt370a > WARNING: o-sparc64/vmlinux.o(.data+0x195a48): Section mismatch in reference > from the variable hpt37x_info.0 to the variable .devinit.data:hpt372 > WARNING: o-sparc64/vmlinux.o(.data+0x195a50): Section mismatch in reference > from the variable hpt37x_info.0 to the variable .devinit.data:hpt372n > > Replace a static array with a small switch resulting in > more readable code. > Mark the pci table __devinitconst. > > A lot of variables are const but annotated __devinitdata. > Annotating them __devinitconst would cause a section type > conflict error when build for 64 bit powerpc. > > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> > Cc: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> > Cc: Sergei Shtylyov <[EMAIL PROTECTED]> > --- thanks, applied > The first patch I posted caused a section type conflict when > build for 64 bit powerpc. The actual cause of this is know and unavoidable > when we start to declare variables const. > The patch attached is much simpler as the transition from __devinitdata > to __devinitconst turned out to be bogus. Weird, I thought that the main purpose of __devinitconst was to replace const + __devinitdata? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fixed PATCH] hpt366: fix section mismatch warnings
On Saturday 23 February 2008, Sam Ravnborg wrote: hpt366: fix section mismatch warnings Fix following warnings: WARNING: o-sparc64/vmlinux.o(.data+0x195a38): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt370 WARNING: o-sparc64/vmlinux.o(.data+0x195a40): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt370a WARNING: o-sparc64/vmlinux.o(.data+0x195a48): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt372 WARNING: o-sparc64/vmlinux.o(.data+0x195a50): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt372n Replace a static array with a small switch resulting in more readable code. Mark the pci table __devinitconst. A lot of variables are const but annotated __devinitdata. Annotating them __devinitconst would cause a section type conflict error when build for 64 bit powerpc. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Cc: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Cc: Sergei Shtylyov [EMAIL PROTECTED] --- thanks, applied The first patch I posted caused a section type conflict when build for 64 bit powerpc. The actual cause of this is know and unavoidable when we start to declare variables const. The patch attached is much simpler as the transition from __devinitdata to __devinitconst turned out to be bogus. Weird, I thought that the main purpose of __devinitconst was to replace const + __devinitdata? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fixed PATCH] hpt366: fix section mismatch warnings
On Sun, Feb 24, 2008 at 03:33:51PM +0100, Bartlomiej Zolnierkiewicz wrote: On Saturday 23 February 2008, Sam Ravnborg wrote: hpt366: fix section mismatch warnings Fix following warnings: WARNING: o-sparc64/vmlinux.o(.data+0x195a38): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt370 WARNING: o-sparc64/vmlinux.o(.data+0x195a40): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt370a WARNING: o-sparc64/vmlinux.o(.data+0x195a48): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt372 WARNING: o-sparc64/vmlinux.o(.data+0x195a50): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt372n Replace a static array with a small switch resulting in more readable code. Mark the pci table __devinitconst. A lot of variables are const but annotated __devinitdata. Annotating them __devinitconst would cause a section type conflict error when build for 64 bit powerpc. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Cc: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Cc: Sergei Shtylyov [EMAIL PROTECTED] --- thanks, applied The first patch I posted caused a section type conflict when build for 64 bit powerpc. The actual cause of this is know and unavoidable when we start to declare variables const. The patch attached is much simpler as the transition from __devinitdata to __devinitconst turned out to be bogus. Weird, I thought that the main purpose of __devinitconst was to replace const + __devinitdata? The problem we face is that gcc in some cases mark the destination section READ-ONLY and in other cases not. So if we annotate two variables to go into the same section and gcc only annotate one of them READ-ONLY them we will have a section type conflict. gcc is not consistent across architectures what to mark READ-ONLY and not. And what we saw here was a combination where on x86 the destinatin section were marked equal (READ-ONLY or not READ-ONLY) but on powerpc were marked different. One was marked READ-ONLY the other was not. So when playing with const it is improtant to try out with a 64 bit gcc for powerpc to see if it causes any section type conflict. Note: 32 bit gcc does not have this issue. Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Fixed PATCH] hpt366: fix section mismatch warnings
hpt366: fix section mismatch warnings
Fix following warnings:
WARNING: o-sparc64/vmlinux.o(.data+0x195a38): Section mismatch in reference
from the variable hpt37x_info.0 to the variable .devinit.data:hpt370
WARNING: o-sparc64/vmlinux.o(.data+0x195a40): Section mismatch in reference
from the variable hpt37x_info.0 to the variable .devinit.data:hpt370a
WARNING: o-sparc64/vmlinux.o(.data+0x195a48): Section mismatch in reference
from the variable hpt37x_info.0 to the variable .devinit.data:hpt372
WARNING: o-sparc64/vmlinux.o(.data+0x195a50): Section mismatch in reference
from the variable hpt37x_info.0 to the variable .devinit.data:hpt372n
Replace a static array with a small switch resulting in
more readable code.
Mark the pci table __devinitconst.
A lot of variables are const but annotated __devinitdata.
Annotating them __devinitconst would cause a section type
conflict error when build for 64 bit powerpc.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Cc: Sergei Shtylyov <[EMAIL PROTECTED]>
---
The first patch I posted caused a section type conflict when
build for 64 bit powerpc. The actual cause of this is know and unavoidable
when we start to declare variables const.
The patch attached is much simpler as the transition from __devinitdata
to __devinitconst turned out to be bogus.
I also took the opportunity to simplify the switch as suggested by
Sergei.
Sam
diff --git a/drivers/ide/pci/hpt366.c b/drivers/ide/pci/hpt366.c
index d0f7bb8..a5eeb6b 100644
--- a/drivers/ide/pci/hpt366.c
+++ b/drivers/ide/pci/hpt366.c
@@ -1570,11 +1570,13 @@ static int __devinit hpt366_init_one(struct pci_dev
*dev, const struct pci_devic
if (rev < 3)
info =
else {
- static const struct hpt_info *hpt37x_info[] =
- { , , , };
-
- info = hpt37x_info[min_t(u8, rev, 6) - 3];
- idx++;
+ switch (min_t(u8, rev, 6)) {
+ case 3: info = break;
+ case 4: info = break;
+ case 5: info = break;
+ case 6: info = break;
+ }
+ idx++;
}
break;
case 1:
@@ -1626,7 +1628,7 @@ static int __devinit hpt366_init_one(struct pci_dev *dev,
const struct pci_devic
return ide_setup_pci_device(dev, );
}
-static const struct pci_device_id hpt366_pci_tbl[] = {
+static const struct pci_device_id hpt366_pci_tbl[] __devinitconst = {
{ PCI_VDEVICE(TTI, PCI_DEVICE_ID_TTI_HPT366), 0 },
{ PCI_VDEVICE(TTI, PCI_DEVICE_ID_TTI_HPT372), 1 },
{ PCI_VDEVICE(TTI, PCI_DEVICE_ID_TTI_HPT302), 2 },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Fixed PATCH] hpt366: fix section mismatch warnings
hpt366: fix section mismatch warnings
Fix following warnings:
WARNING: o-sparc64/vmlinux.o(.data+0x195a38): Section mismatch in reference
from the variable hpt37x_info.0 to the variable .devinit.data:hpt370
WARNING: o-sparc64/vmlinux.o(.data+0x195a40): Section mismatch in reference
from the variable hpt37x_info.0 to the variable .devinit.data:hpt370a
WARNING: o-sparc64/vmlinux.o(.data+0x195a48): Section mismatch in reference
from the variable hpt37x_info.0 to the variable .devinit.data:hpt372
WARNING: o-sparc64/vmlinux.o(.data+0x195a50): Section mismatch in reference
from the variable hpt37x_info.0 to the variable .devinit.data:hpt372n
Replace a static array with a small switch resulting in
more readable code.
Mark the pci table __devinitconst.
A lot of variables are const but annotated __devinitdata.
Annotating them __devinitconst would cause a section type
conflict error when build for 64 bit powerpc.
Signed-off-by: Sam Ravnborg [EMAIL PROTECTED]
Cc: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Cc: Sergei Shtylyov [EMAIL PROTECTED]
---
The first patch I posted caused a section type conflict when
build for 64 bit powerpc. The actual cause of this is know and unavoidable
when we start to declare variables const.
The patch attached is much simpler as the transition from __devinitdata
to __devinitconst turned out to be bogus.
I also took the opportunity to simplify the switch as suggested by
Sergei.
Sam
diff --git a/drivers/ide/pci/hpt366.c b/drivers/ide/pci/hpt366.c
index d0f7bb8..a5eeb6b 100644
--- a/drivers/ide/pci/hpt366.c
+++ b/drivers/ide/pci/hpt366.c
@@ -1570,11 +1570,13 @@ static int __devinit hpt366_init_one(struct pci_dev
*dev, const struct pci_devic
if (rev 3)
info = hpt36x;
else {
- static const struct hpt_info *hpt37x_info[] =
- { hpt370, hpt370a, hpt372, hpt372n };
-
- info = hpt37x_info[min_t(u8, rev, 6) - 3];
- idx++;
+ switch (min_t(u8, rev, 6)) {
+ case 3: info = hpt370; break;
+ case 4: info = hpt370a; break;
+ case 5: info = hpt372; break;
+ case 6: info = hpt372n; break;
+ }
+ idx++;
}
break;
case 1:
@@ -1626,7 +1628,7 @@ static int __devinit hpt366_init_one(struct pci_dev *dev,
const struct pci_devic
return ide_setup_pci_device(dev, d);
}
-static const struct pci_device_id hpt366_pci_tbl[] = {
+static const struct pci_device_id hpt366_pci_tbl[] __devinitconst = {
{ PCI_VDEVICE(TTI, PCI_DEVICE_ID_TTI_HPT366), 0 },
{ PCI_VDEVICE(TTI, PCI_DEVICE_ID_TTI_HPT372), 1 },
{ PCI_VDEVICE(TTI, PCI_DEVICE_ID_TTI_HPT302), 2 },
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
