- 31 Oct, 2011 40 commits
-
-
Paul Gortmaker authored
We are cleaning up the omnipresent module.h stuff, so people who really use it need to call it out explicitly. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
This 2nd batch of implicit module.h users only appeared when we removed the unnecessary module.h from include/linux/miscdevice.h [The 1st batch is already present in Greg's staging tree.] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
These files are using moduleparam infrastructure and were getting that via the implicit module.h presence that we are phasing out. So they'll need to include moduleparam.h explicitly in advance. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
Lots of drivers have in the past expected the presence of basic things like THIS_MODULE and EXPORT_SYMBOL. With the header cleanup, they wont have these. Call out the include explicitly. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
Or we will get things like this when we remove the implicit path: drivers/ssb/embedded.c:32: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' drivers/ssb/driver_chipcommon.c:432: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' drivers/ssb/driver_chipcommon_pmu.c:607: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' drivers/ssb/pcihost_wrapper.c:120: error: ‘THIS_MODULE’ undeclared (first use in this function) drivers/ssb/driver_pcicore.c:721: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’ drivers/ssb/driver_gige.c:249: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
The header cleanup means that module.h is no longer simply everywhere. So real modules need to actively include it. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
Once the implicit use of module.h is prevented, these files will fail to find the stat.h header content. Fix up the implicit usage expectations in advance of the cleanup. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
These two basic defines were everywhere, simply because module.h was also everywhere. But we are cleaning up the latter. So make the exporters actually call out their need for the include. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
We are cleaning up the implicit presence of module.h; these guys are some of the people who just assume it will be there. Call it out explitly for those that really need it. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
These macros are in <linux/export.h> and will no longer be implicitly everywhere anymore. Fix it up in advance. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
With the pending module.h cleanup, these files will fail to compile, unless they explicitly call out the include of this file. [omap-usb-host addition courtesy of Anand Gadiyar <gadiyar@ti.com>] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
So that we don't get build failures once the implicit module.h presence is removed. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
Fix in advance, or we will get things like this: drivers/bcma/core.c:20: warning: data definition has no type or storage class drivers/bcma/core.c:20: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' drivers/bcma/core.c:20: warning: parameter names (without types) in function declaration Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
This will ensure that it continues to build once we remove the implicit module.h presence from everywhere later on. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
To fix what used to be the implicit presence of the macros EXPORT_SYMBOL and THIS_MODULE, via module.h being everywhere. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
It doesn't need the full module.h but it was getting moduleparam.h from the fact that module.h was everywhere. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
Give these files export.h so that they can reliably get the EXPORT_SYMBOL and THIS_MODULE macros in the future, once module.h isn't implicitly everywhere. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
So that they have access to EXPORT_SYMBOL variants and THIS_MODULE. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
This is exporting symbols and will fail to build once we remove the implicit presence of module.h Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Randy Dunlap authored
sfi_acpi.c needs to include linux/sysfs.h for data types. drivers/sfi/sfi_core.h:66: error: field 'attr' has incomplete type drivers/sfi/sfi_acpi.c:179: warning: 'struct kobject' declared inside parameter list drivers/sfi/sfi_acpi.c:179: warning: its scope is only this definition or declaration, which is probably not what you want drivers/sfi/sfi_acpi.c:182: warning: type defaults to 'int' in declaration of '__mptr' drivers/sfi/sfi_acpi.c:182: warning: initialization from incompatible pointer type Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
Upon the trial removal of the implicit presence of module.h, lots of files showed up that were getting the sub-includes by default without calling them out. Fix them in advance. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
The module.h header is no longer going to be implicitly present everywhere. So real modular users need to call out its use explicitly in advance. [v2: add new users reported by Randy Dunlap <rdunlap@xenotime.net>] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
For files that were getting these macros via the implicit presence of module.h being everywhere. With contributions from Stephen Rothwell <sfr@canb.auug.org.au>. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
This file really needs the full module.h header file present, but was just getting it implicitly before. Fix it up in advance so we avoid build failures once the cleanup commit is present. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
This is a full module, with module_init() and module_exit() and so it needs module.h called out for inclusion. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
We will need this to avoid build failures pending a future implicit module.h presence cleanup. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
These files really need the full module.h header file present, but were just getting it implicitly before. Fix it up in advance so we avoid build failures once the cleanup commit is present. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
This file really needs the full module.h header file present, but was just getting it implicitly before. Fix it up in advance so we avoid build failures once the cleanup commit is present. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
This is another group of drivers that simply assumed that module.h was everywhere. But it won't be once we clean up its presence from device.h Call out the real users of it in advance. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
A pending cleanup will mean that module.h won't be implicitly everywhere anymore. Make sure the modular drivers in clocksource are actually calling out for <module.h> explicitly in advance. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
These two macros were in module.h but now module.h is no longer sprayed across every source file imaginable, so the users need to expicitly call out their use of them. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Stephen Rothwell authored
To fix: drivers/media/rc/ir-raw.c: In function 'init_decoders': drivers/media/rc/ir-raw.c:354:2: error: implicit declaration of function 'request_module' Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
In preparation of the module.h usage cleanup, call out the export.h to avoid build failures when that happens. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
A pending cleanup will mean that module.h won't be implicitly everywhere anymore. Make sure the modular drivers in the leds dir are actually calling out for <module.h> explicitly in advance. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
In preparation of the module.h usage cleanup, call out the header that we need to get EXPORT_SYMBOL variants and THIS_MODULE into scope. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
So that we don't get build failures once the implicit module.h presence is terminated. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
This file needs the full module.h header and up to now was just implicitly capitalizing on it being present already. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
-