[PATCH 0/5] MIPS: module.h usage cleanup.

[PATCH 0/5] MIPS: module.h usage cleanup.

[Paul Gortmaker]

Hi Ralf,

Not a lot to see here, really.  MIPS had usages of module.h tucked
away in a couple asm files, and that was masking some of the other
implicit users, plus preventing MIPS from getting the full benefit
of not having to feed module.h to cpp 35,000 times.

I've left the two drivers/serial commits separate, in case there
is a desire to have them go in via Greg's trees, but they are a
required dependency for the arch/mips fixes, so I think it makes
sense they stay together with the other changes here.

I will have some arch independent module.h cleanups (in fs and lib)
that will require me to create a module.h tree for 3.4, so I can
carry this there if required.  But this lot is all self-contained
to MIPS and so I'd be fine with (and actually prefer) this going in
via the MIPS tree.  No strong preference - either way, let me know.

Thanks,
Paul.
---

Paul Gortmaker (5):
  serial: MIPS DECstation zs.c driver needs module.h
  serial: MIPS swarm sb1250-duart.c driver needs module.h
  MIPS: fix several implicit uses of export.h/module.h
  MIPS: delete bogus module.h usage in termios.h
  MIPS: dont use module.h just to export symbols in asm/uasm.h

 arch/mips/alchemy/devboards/db1200.c  |    1 +
 arch/mips/cavium-octeon/setup.c       |    1 +
 arch/mips/include/asm/module.h        |    1 +
 arch/mips/include/asm/termios.h       |    2 +-
 arch/mips/include/asm/uasm.h          |    2 +-
 arch/mips/kernel/traps.c              |    1 +
 arch/mips/pmc-sierra/yosemite/setup.c |    1 +
 arch/mips/rb532/devices.c             |    1 +
 arch/mips/sni/setup.c                 |    1 +
 drivers/tty/serial/sb1250-duart.c     |    1 +
 drivers/tty/serial/zs.c               |    1 +
 11 files changed, 11 insertions(+), 2 deletions(-)

-- 
1.7.9.1

[PATCH 1/5] serial: MIPS DECstation zs.c driver needs module.h

[Paul Gortmaker]

This driver is a module and needs module.h, otherwise
it will break when we remove a bogus usage of module.h
from one of the other MIPS headers.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 drivers/tty/serial/zs.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/zs.c b/drivers/tty/serial/zs.c
index b7455b5..73315e3 100644
--- a/drivers/tty/serial/zs.c
+++ b/drivers/tty/serial/zs.c
@@ -57,6 +57,7 @@
 #include <linux/ioport.h>
 #include <linux/irqflags.h>
 #include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/major.h>
 #include <linux/serial.h>
 #include <linux/serial_core.h>
-- 
1.7.9.1

[PATCH 2/5] serial: MIPS swarm sb1250-duart.c driver needs module.h

[Paul Gortmaker]

This driver is a module and needs module.h, otherwise
it will break when we remove a bogus usage of module.h
from one of the other MIPS headers.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 drivers/tty/serial/sb1250-duart.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/sb1250-duart.c b/drivers/tty/serial/sb1250-duart.c
index 0be8a2f..f76b1688 100644
--- a/drivers/tty/serial/sb1250-duart.c
+++ b/drivers/tty/serial/sb1250-duart.c
@@ -31,6 +31,7 @@
 #include <linux/interrupt.h>
 #include <linux/ioport.h>
 #include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/major.h>
 #include <linux/serial.h>
 #include <linux/serial_core.h>
-- 
1.7.9.1

[PATCH 3/5] MIPS: fix several implicit uses of export.h/module.h

[Paul Gortmaker]

These will show up as a build failure once we clean up a
misuse of module.h in the mips termios header.

Uses export.h: (EXPORT_SYMBOL)
   arch/mips/cavium-octeon/setup.c
   arch/mips/pmc-sierra/yosemite/setup.c
   arch/mips/rb532/devices.c
   arch/mips/sni/setup.c

Uses module.h: (symbol_get/put)
   arch/mips/alchemy/devboards/db1200.c

Uses module.h: (print_modules)
   arch/mips/kernel/traps.c

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 arch/mips/alchemy/devboards/db1200.c  |    1 +
 arch/mips/cavium-octeon/setup.c       |    1 +
 arch/mips/kernel/traps.c              |    1 +
 arch/mips/pmc-sierra/yosemite/setup.c |    1 +
 arch/mips/rb532/devices.c             |    1 +
 arch/mips/sni/setup.c                 |    1 +
 6 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/mips/alchemy/devboards/db1200.c b/arch/mips/alchemy/devboards/db1200.c
index a83302b..7dde016 100644
--- a/arch/mips/alchemy/devboards/db1200.c
+++ b/arch/mips/alchemy/devboards/db1200.c
@@ -22,6 +22,7 @@
 #include <linux/gpio.h>
 #include <linux/i2c.h>
 #include <linux/init.h>
+#include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/leds.h>
diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
index 260b273..3a01231 100644
--- a/arch/mips/cavium-octeon/setup.c
+++ b/arch/mips/cavium-octeon/setup.c
@@ -9,6 +9,7 @@
 #include <linux/init.h>
 #include <linux/console.h>
 #include <linux/delay.h>
+#include <linux/export.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/serial.h>
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index cc4a3f1..62cbffd 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -15,6 +15,7 @@
 #include <linux/compiler.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/mm.h>
 #include <linux/sched.h>
 #include <linux/smp.h>
diff --git a/arch/mips/pmc-sierra/yosemite/setup.c b/arch/mips/pmc-sierra/yosemite/setup.c
index 3498ac9..b6472fc 100644
--- a/arch/mips/pmc-sierra/yosemite/setup.c
+++ b/arch/mips/pmc-sierra/yosemite/setup.c
@@ -27,6 +27,7 @@
 #include <linux/bcd.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/export.h>
 #include <linux/types.h>
 #include <linux/mm.h>
 #include <linux/bootmem.h>
diff --git a/arch/mips/rb532/devices.c b/arch/mips/rb532/devices.c
index a969eb8..ea77428 100644
--- a/arch/mips/rb532/devices.c
+++ b/arch/mips/rb532/devices.c
@@ -15,6 +15,7 @@
  *  GNU General Public License for more details.
  */
 #include <linux/kernel.h>
+#include <linux/export.h>
 #include <linux/init.h>
 #include <linux/ctype.h>
 #include <linux/string.h>
diff --git a/arch/mips/sni/setup.c b/arch/mips/sni/setup.c
index d16b462..413f17f 100644
--- a/arch/mips/sni/setup.c
+++ b/arch/mips/sni/setup.c
@@ -10,6 +10,7 @@
  */
 #include <linux/eisa.h>
 #include <linux/init.h>
+#include <linux/export.h>
 #include <linux/console.h>
 #include <linux/fb.h>
 #include <linux/screen_info.h>
-- 
1.7.9.1

[PATCH 4/5] MIPS: delete bogus module.h usage in termios.h

[Paul Gortmaker]

There is no need for this.  Removing it causes a small amount
of fallout (shown below) due to a few implicit header presence
assumptions that are easily fixed.

arch/mips/include/asm/termios.h:103: error: implicit declaration of function 'access_ok'
arch/mips/include/asm/module.h:17: error: expected specifier-qualifier-list before 'Elf64_Addr'

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 arch/mips/include/asm/module.h  |    1 +
 arch/mips/include/asm/termios.h |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/mips/include/asm/module.h b/arch/mips/include/asm/module.h
index 7467d1d..5300080 100644
--- a/arch/mips/include/asm/module.h
+++ b/arch/mips/include/asm/module.h
@@ -2,6 +2,7 @@
 #define _ASM_MODULE_H
 
 #include <linux/list.h>
+#include <linux/elf.h>
 #include <asm/uaccess.h>
 
 struct mod_arch_specific {
diff --git a/arch/mips/include/asm/termios.h b/arch/mips/include/asm/termios.h
index 8f77f77..abdd87a 100644
--- a/arch/mips/include/asm/termios.h
+++ b/arch/mips/include/asm/termios.h
@@ -60,7 +60,7 @@ struct termio {
 };
 
 #ifdef __KERNEL__
-#include <linux/module.h>
+#include <asm/uaccess.h>
 
 /*
  *	intr=^C		quit=^\		erase=del	kill=^U
-- 
1.7.9.1

[PATCH 5/5] MIPS: dont use module.h just to export symbols in asm/uasm.h

[Paul Gortmaker]

Putting module.h into widely used headers just bogs cpp down
with reams of stuff that isn't needed.  Here, we only need
visibility to EXPORT_SYMBOL.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 arch/mips/include/asm/uasm.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/mips/include/asm/uasm.h b/arch/mips/include/asm/uasm.h
index 504d40a..440a21d 100644
--- a/arch/mips/include/asm/uasm.h
+++ b/arch/mips/include/asm/uasm.h
@@ -11,7 +11,7 @@
 #include <linux/types.h>
 
 #ifdef CONFIG_EXPORT_UASM
-#include <linux/module.h>
+#include <linux/export.h>
 #define __uasminit
 #define __uasminitdata
 #define UASM_EXPORT_SYMBOL(sym) EXPORT_SYMBOL(sym)
-- 
1.7.9.1

Re: [PATCH 0/5] MIPS: module.h usage cleanup.

[Ralf Baechle]

On Tue, Feb 28, 2012 at 02:24:43PM -0500, Paul Gortmaker wrote:

> Hi Ralf,
> 
> Not a lot to see here, really.  MIPS had usages of module.h tucked
> away in a couple asm files, and that was masking some of the other
> implicit users, plus preventing MIPS from getting the full benefit
> of not having to feed module.h to cpp 35,000 times.
> 
> I've left the two drivers/serial commits separate, in case there
> is a desire to have them go in via Greg's trees, but they are a
> required dependency for the arch/mips fixes, so I think it makes
> sense they stay together with the other changes here.
> 
> I will have some arch independent module.h cleanups (in fs and lib)
> that will require me to create a module.h tree for 3.4, so I can
> carry this there if required.  But this lot is all self-contained
> to MIPS and so I'd be fine with (and actually prefer) this going in
> via the MIPS tree.  No strong preference - either way, let me know.

Haven't received any comment and the patches are trivial so I'm going
to queue them hopeing that Alan Cox (not on cc ...) doesn't mind ...

  Ralf

Re: [PATCH 0/5] MIPS: module.h usage cleanup.

[Paul Gortmaker]

On 12-03-06 02:08 PM, Ralf Baechle wrote:
> On Tue, Feb 28, 2012 at 02:24:43PM -0500, Paul Gortmaker wrote:
> 
>> Hi Ralf,
>>
>> Not a lot to see here, really.  MIPS had usages of module.h tucked
>> away in a couple asm files, and that was masking some of the other
>> implicit users, plus preventing MIPS from getting the full benefit
>> of not having to feed module.h to cpp 35,000 times.
>>
>> I've left the two drivers/serial commits separate, in case there
>> is a desire to have them go in via Greg's trees, but they are a
>> required dependency for the arch/mips fixes, so I think it makes
>> sense they stay together with the other changes here.
>>
>> I will have some arch independent module.h cleanups (in fs and lib)
>> that will require me to create a module.h tree for 3.4, so I can
>> carry this there if required.  But this lot is all self-contained
>> to MIPS and so I'd be fine with (and actually prefer) this going in
>> via the MIPS tree.  No strong preference - either way, let me know.
> 
> Haven't received any comment and the patches are trivial so I'm going
> to queue them hopeing that Alan Cox (not on cc ...) doesn't mind ...

I stuck them in linux-next for additional sanity testing above the
defconfig builds that I did and nothing caught fire.  I'll back
them out from my for-next branch now that I know you've got them queued
via the mips for-next.

Thanks!
Paul.

> 
>   Ralf

Re: [PATCH 0/5] MIPS: module.h usage cleanup.

[Paul Gortmaker]

On 12-03-06 02:08 PM, Ralf Baechle wrote:
> On Tue, Feb 28, 2012 at 02:24:43PM -0500, Paul Gortmaker wrote:
> 
>> Hi Ralf,
>>
>> Not a lot to see here, really.  MIPS had usages of module.h tucked
>> away in a couple asm files, and that was masking some of the other
>> implicit users, plus preventing MIPS from getting the full benefit
>> of not having to feed module.h to cpp 35,000 times.
>>
>> I've left the two drivers/serial commits separate, in case there
>> is a desire to have them go in via Greg's trees, but they are a
>> required dependency for the arch/mips fixes, so I think it makes
>> sense they stay together with the other changes here.
>>
>> I will have some arch independent module.h cleanups (in fs and lib)
>> that will require me to create a module.h tree for 3.4, so I can
>> carry this there if required.  But this lot is all self-contained
>> to MIPS and so I'd be fine with (and actually prefer) this going in
>> via the MIPS tree.  No strong preference - either way, let me know.
> 
> Haven't received any comment and the patches are trivial so I'm going
> to queue them hopeing that Alan Cox (not on cc ...) doesn't mind ...

I stuck them in linux-next for additional sanity testing above the
defconfig builds that I did and nothing caught fire.  I'll back
them out from my for-next branch now that I know you've got them queued
via the mips for-next.

Thanks!
Paul.

> 
>   Ralf