Skip to contentSkip to conversation

dpt_i2o: fix compiler warning on dptids

PATCH In review Namhyung Kim 2 participants 9 messages Dec 7, 2010 – Dec 8, 2010

Subsystems (2)
SCSI Module support
lore
Share & tools
lore

Namhyung Kim

author
#0 lore raw

PATCH 1/3 dpt_i2o: fix compiler warning on dptids

Annotate dptids as '__used' to fix following warning:

CC drivers/scsi/dpt_i2o.o
drivers/scsi/dpt_i2o.c:183: warning: ‘dptids’ defined but not used

Signed-off-by Namhyung Kim <[email protected]>
Cc Adaptec OEM Raid Solutions <[email protected]>
---
 drivers/scsi/dpt_i2o.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/scsi/dpt_i2o.c +1 -1
index cffcb10..b276077 100644
@@ -180,7 +180,7 @@ static u8 adpt_read_blink_led(adpt_hba* host)
  *============================================================================
  */
 
-static struct pci_device_id dptids[] = {
+static struct pci_device_id dptids[] __used = {
 	{ PCI_DPT_VENDOR_ID, PCI_DPT_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
 	{ PCI_DPT_VENDOR_ID, PCI_DPT_RAPTOR_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
 	{ 0, }
Signature · 1 line
1.7.0.4
author
#1 lore raw

PATCH 2/3 fdomain: fix compiler warning on fdomain_pci_tbl

Annotate fdomain_pci_tbl as '__used' to fix following warning:

CC drivers/scsi/fdomain.o
drivers/scsi/fdomain.c:1775: warning: ‘fdomain_pci_tbl’ defined but not used

Signed-off-by Namhyung Kim <[email protected]>
Cc Rik Faith <[email protected]>
---
 drivers/scsi/fdomain.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/scsi/fdomain.c +1 -1
index 69b7aa5..974c0d9 100644
@@ -1772,7 +1772,7 @@ struct scsi_host_template fdomain_driver_template = {
 #ifndef PCMCIA
 #ifdef CONFIG_PCI
 
-static struct pci_device_id fdomain_pci_tbl[] __devinitdata = {
+static struct pci_device_id fdomain_pci_tbl[] __devinitdata __used = {
 	{ PCI_VENDOR_ID_FD, PCI_DEVICE_ID_FD_36C70,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 	{ }
Signature · 1 line
1.7.0.4
author
#2 lore raw

PATCH 3/3 initio: fix compiler warning on i91u_pci_devices

In reply to Namhyung Kim

Annotate i91u_pci_devices as '__used' to fix following warning:

CC drivers/scsi/initio.o
drivers/scsi/initio.c:131: warning: ‘i91u_pci_devices’ defined but not used

Signed-off-by Namhyung Kim <[email protected]>
---
 drivers/scsi/initio.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/scsi/initio.c +1 -1
index 9627d06..01c54cf 100644
@@ -128,7 +128,7 @@ static int setup_debug = 0;
 static void i91uSCBPost(u8 * pHcb, u8 * pScb);
 
 /* PCI Devices supported by this driver */
-static struct pci_device_id i91u_pci_devices[] = {
+static struct pci_device_id i91u_pci_devices[] __used = {
 	{ PCI_VENDOR_ID_INIT,  I950_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 	{ PCI_VENDOR_ID_INIT,  I940_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
 	{ PCI_VENDOR_ID_INIT,  I935_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
Signature · 1 line
1.7.0.4
#3 lore raw
In reply to Namhyung Kim
Quoted 16 lines · Namhyung Kim

Annotate dptids as '__used' to fix following warning:

CC drivers/scsi/dpt_i2o.o
drivers/scsi/dpt_i2o.c:183: warning: ‘dptids’ defined but not used

Signed-off-by Namhyung Kim <[email protected]>
Cc Adaptec OEM Raid Solutions <[email protected]>
---
 drivers/scsi/dpt_i2o.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/scsi/dpt_i2o.c +0 -0
index cffcb10..b276077 100644

drivers/scsi/dpt_i2o.c static u8 adpt_read_blink_led(adpt_hba* host) · line 186

Quoted 8 lines
drivers/scsi/dpt_i2o.c +1 -1
@@ -180,7 +180,7 @@ static u8 adpt_read_blink_led(adpt_hba* host)
  *============================================================================
  */
 
-static struct pci_device_id dptids[] = {
+static struct pci_device_id dptids[] __used = {
 	{ PCI_DPT_VENDOR_ID, PCI_DPT_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
 	{ PCI_DPT_VENDOR_ID, PCI_DPT_RAPTOR_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
 	{ 0, }

Um so this is definitely used in the MODULE_DEVICE_TABLE just below.

I deduce you have some type of config which causes that to be a nop (say !CONFIG_MODULE)? In which case, surely the correct fix is in module.h?

James

author
#4 lore raw

2010-12-07 (화), 09:57 -0600, James Bottomley:

Quoted 6 lines

Um so this is definitely used in the MODULE_DEVICE_TABLE just below.

I deduce you have some type of config which causes that to be a nop (say !CONFIG_MODULE)? In which case, surely the correct fix is in module.h?

Hi,

MODULE_DEVICE_TABLE expands to nop when !MODULE (not !CONFIG_MODULE) so allyesconfig build always emits the warnings. Possible patch for this would be wraping it up in #ifdefs but when I sent a same patch to Greg KH he didn't want to add more #ifdefs in .c files.

Signature · 2 lines
Regards,
Namhyung Kim
#5 lore raw
Quoted 8 lines · Namhyung Kim

2010-12-07 (화), 09:57 -0600, James Bottomley:

Quoted 6 lines

Um so this is definitely used in the MODULE_DEVICE_TABLE just below.

I deduce you have some type of config which causes that to be a nop (say !CONFIG_MODULE)? In which case, surely the correct fix is in module.h?

Quoted 6 lines

Hi,

MODULE_DEVICE_TABLE expands to nop when !MODULE (not !CONFIG_MODULE) so allyesconfig build always emits the warnings. Possible patch for this would be wraping it up in #ifdefs but when I sent a same patch to Greg KH he didn't want to add more #ifdefs in .c files.

I didn't mean changing any c files. I meant fixing the module include to make the table used even in the !MODULE case. That way we only alter one file instead of a significant proportion of the drivers.

James

---

include/linux/module.h +4 -1
index 7575bbb..d49aa9c 100644
@@ -90,7 +90,10 @@ extern const struct gtype##_id __mod_##gtype##_table		\
 extern struct module __this_module;
 #define THIS_MODULE (&__this_module)
 #else  /* !MODULE */
-#define MODULE_GENERIC_TABLE(gtype,name)
+/* Flag name as used to avoid warnings about the unused device id table */
+#define MODULE_GENERIC_TABLE(gtype,name)			\
+static const struct gtype##_id __mod_##gtype##_table		\
+  __attribute__ ((unused, alias(__stringify(name))))
 #define THIS_MODULE ((struct module *)0)
 #endif
author
#6 lore raw

2010-12-07 (화), 10:30 -0600, James Bottomley:

Quoted 10 lines · Namhyung Kim
Quoted 4 lines

MODULE_DEVICE_TABLE expands to nop when !MODULE (not !CONFIG_MODULE) so allyesconfig build always emits the warnings. Possible patch for this would be wraping it up in #ifdefs but when I sent a same patch to Greg KH he didn't want to add more #ifdefs in .c files.

I didn't mean changing any c files. I meant fixing the module include to make the table used even in the !MODULE case. That way we only alter one file instead of a significant proportion of the drivers.

It would not be a _significant_ proportion because normal drivers may refer the table in their driver struct. :)

Anyway the patch below looks good to me. I'll happily drop my patches if you apply this in your tree.

Thanks.

Quoted 17 lines
include/linux/module.h +4 -1
index 7575bbb..d49aa9c 100644
@@ -90,7 +90,10 @@ extern const struct gtype##_id __mod_##gtype##_table		\
 extern struct module __this_module;
 #define THIS_MODULE (&__this_module)
 #else  /* !MODULE */
-#define MODULE_GENERIC_TABLE(gtype,name)
+/* Flag name as used to avoid warnings about the unused device id table */
+#define MODULE_GENERIC_TABLE(gtype,name)			\
+static const struct gtype##_id __mod_##gtype##_table		\
+  __attribute__ ((unused, alias(__stringify(name))))
 #define THIS_MODULE ((struct module *)0)
 #endif
Signature · 8 lines
Regards,
Namhyung Kim


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
author
#7 lore raw

2010-12-08 (수), 02:24 +0900, Namhyung Kim:

Quoted 12 lines

2010-12-07 (화), 10:30 -0600, James Bottomley:

Quoted 10 lines · Namhyung Kim
Quoted 4 lines

MODULE_DEVICE_TABLE expands to nop when !MODULE (not !CONFIG_MODULE) so allyesconfig build always emits the warnings. Possible patch for this would be wraping it up in #ifdefs but when I sent a same patch to Greg KH he didn't want to add more #ifdefs in .c files.

I didn't mean changing any c files. I meant fixing the module include to make the table used even in the !MODULE case. That way we only alter one file instead of a significant proportion of the drivers.

Quoted 6 lines

It would not be a _significant_ proportion because normal drivers may refer the table in their driver struct. :)

Anyway the patch below looks good to me. I'll happily drop my patches if you apply this in your tree.

Hi,

As akpm told me, using DEFINE_PCI_DEVICE_TABLE could also remove the warnings (probably by making the table const) but it still requires modifying .c files. What do you think?

Signature · 2 lines
Regards,
Namhyung Kim
#8 lore raw
Quoted 20 lines · Namhyung Kim

2010-12-08 (수), 02:24 +0900, Namhyung Kim:

Quoted 12 lines

2010-12-07 (화), 10:30 -0600, James Bottomley:

Quoted 10 lines · Namhyung Kim
Quoted 4 lines

MODULE_DEVICE_TABLE expands to nop when !MODULE (not !CONFIG_MODULE) so allyesconfig build always emits the warnings. Possible patch for this would be wraping it up in #ifdefs but when I sent a same patch to Greg KH he didn't want to add more #ifdefs in .c files.

I didn't mean changing any c files. I meant fixing the module include to make the table used even in the !MODULE case. That way we only alter one file instead of a significant proportion of the drivers.

Quoted 6 lines

It would not be a _significant_ proportion because normal drivers may refer the table in their driver struct. :)

Anyway the patch below looks good to me. I'll happily drop my patches if you apply this in your tree.

Quoted 5 lines

Hi,

As akpm told me, using DEFINE_PCI_DEVICE_TABLE could also remove the warnings (probably by making the table const) but it still requires modifying .c files. What do you think?

The warning only appears in the non-modular case, which is pretty unusual for drivers nowadays, so I think the simplest elimination solution is the best one (i.e. just kill it at source in the header).

James

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html