Messages in this thread | | | Date | Sat, 26 Jan 2008 20:17:17 +0100 | From | Sam Ravnborg <> | Subject | Re: [Patch] Shut up warnings from files under drivers/ |
| |
On Sat, Jan 26, 2008 at 04:55:58AM -0500, Jeff Garzik wrote: > WANG Cong wrote: > >diff --git a/drivers/video/kyro/fbdev.c b/drivers/video/kyro/fbdev.c > >index acb9370..437ebd0 100644 > >--- a/drivers/video/kyro/fbdev.c > >+++ b/drivers/video/kyro/fbdev.c > >@@ -90,7 +90,9 @@ static int nomtrr __devinitdata = 0; > > > > /* PCI driver prototypes */ > > static int kyrofb_probe(struct pci_dev *pdev, const struct pci_device_id > > *ent); > >+#if defined(MODULE) || defined(CONFIG_HOTPLUG) > > static void kyrofb_remove(struct pci_dev *pdev); > >+#endif > > > > static struct fb_videomode kyro_modedb[] __devinitdata = { > > { > >@@ -754,6 +756,7 @@ out_unmap: > > return -EINVAL; > > } > > > >+#if defined(MODULE) || defined(CONFIG_HOTPLUG) > > static void __devexit kyrofb_remove(struct pci_dev *pdev) > > { > > struct fb_info *info = pci_get_drvdata(pdev); > >@@ -783,6 +786,7 @@ static void __devexit kyrofb_remove(struct pci_dev > >*pdev) > > pci_set_drvdata(pdev, NULL); > > framebuffer_release(info); > > } > >+#endif > > > Quite strange -- due to __devexit_p() and the __devexit marker, ifdefs > should not be needed. > > I would look into why that isn't working as designed in these cases...
I checked up on the synclink.c warning. We have the following code:
static void synclink_remove_one (struct pci_dev *dev);
...
static struct pci_driver synclink_pci_driver = { .remove = __devexit_p(synclink_remove_one), };
...
static void __devexit synclink_remove_one (struct pci_dev *dev) { }
And I double checked the preprocessed source to check that we applied the __attribute__((__used__)) to the function.
Investigating a bit more I realized that gcc looses the __used__ attribution due to the prototype. So there are two correct fixes: a) move the function up so we do not need the forward declaration b) add a __devexit to the forward decalration too.
I strongly prefer the first version and this is the correct fix for these cases.
Do we have a gcc bug here - I did not see a definitive answer in gcc docs?
Sam
| |