[PATCH] tile: add init.h to usb.c to avoid compile failure

[PATCH] tile: add init.h to usb.c to avoid compile failure

[Paul Gortmaker]

Pending header cleanups will reveal this file is using the
init.h content implicitly with the following fail:

arch/tile/kernel/usb.c:69:1: warning: data definition has no type or storage class [enabled by default]
arch/tile/kernel/usb.c:69:1: error: type defaults to 'int' in declaration of 'arch_initcall'
arch/tile/kernel/usb.c:69:1: warning: parameter names (without types) in function declaration [enabled by default]
arch/tile/kernel/usb.c:62:19: warning: 'tilegx_usb_init' defined but not used

Explicitly add init.h to get arch_initcall and avoid this.

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---

[adding this to the header move series of commits; see
 https://lkml.kernel.org/r/1433276168-21550-1-git-send-email-paul.gortmaker@windriver.com
 for original series posting. ]

 arch/tile/kernel/usb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/tile/kernel/usb.c b/arch/tile/kernel/usb.c
index 5af8debc6a71..f0da5a237e94 100644
--- a/arch/tile/kernel/usb.c
+++ b/arch/tile/kernel/usb.c
@@ -21,6 +21,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/platform_device.h>
 #include <linux/usb/tilegx.h>
+#include <linux/init.h>
 #include <linux/types.h>
 
 static u64 ehci_dmamask = DMA_BIT_MASK(32);
-- 
2.2.1

Re: [PATCH] tile: add init.h to usb.c to avoid compile failure

[Chris Metcalf]

On 06/05/2015 10:36 AM, Paul Gortmaker wrote:
> Pending header cleanups will reveal this file is using the
> init.h content implicitly with the following fail:
>
> arch/tile/kernel/usb.c:69:1: warning: data definition has no type or storage class [enabled by default]
> arch/tile/kernel/usb.c:69:1: error: type defaults to 'int' in declaration of 'arch_initcall'
> arch/tile/kernel/usb.c:69:1: warning: parameter names (without types) in function declaration [enabled by default]
> arch/tile/kernel/usb.c:62:19: warning: 'tilegx_usb_init' defined but not used
>
> Explicitly add init.h to get arch_initcall and avoid this.
>
> Reported-by: kbuild test robot<fengguang.wu@intel.com>
> Cc: Chris Metcalf<cmetcalf@ezchip.com>
> Signed-off-by: Paul Gortmaker<paul.gortmaker@windriver.com>
> ---
>
> [adding this to the header move series of commits; see
>   https://lkml.kernel.org/r/1433276168-21550-1-git-send-email-paul.gortmaker@windriver.com
>   for original series posting. ]
>
>   arch/tile/kernel/usb.c | 1 +
>   1 file changed, 1 insertion(+)

Acked-by: Chris Metcalf <cmetcalf@ezchip.com>

or I'm happy to take it into the tile tree if you'd rather I did.

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

Re: [PATCH] tile: add init.h to usb.c to avoid compile failure

[Paul Gortmaker]

On 15-06-05 10:42 AM, Chris Metcalf wrote:
> On 06/05/2015 10:36 AM, Paul Gortmaker wrote:
>> Pending header cleanups will reveal this file is using the
>> init.h content implicitly with the following fail:
>>
>> arch/tile/kernel/usb.c:69:1: warning: data definition has no type or storage class [enabled by default]
>> arch/tile/kernel/usb.c:69:1: error: type defaults to 'int' in declaration of 'arch_initcall'
>> arch/tile/kernel/usb.c:69:1: warning: parameter names (without types) in function declaration [enabled by default]
>> arch/tile/kernel/usb.c:62:19: warning: 'tilegx_usb_init' defined but not used
>>
>> Explicitly add init.h to get arch_initcall and avoid this.
>>
>> Reported-by: kbuild test robot<fengguang.wu@intel.com>
>> Cc: Chris Metcalf<cmetcalf@ezchip.com>
>> Signed-off-by: Paul Gortmaker<paul.gortmaker@windriver.com>
>> ---
>>
>> [adding this to the header move series of commits; see
>>   https://lkml.kernel.org/r/1433276168-21550-1-git-send-email-paul.gortmaker@windriver.com
>>   for original series posting. ]
>>
>>   arch/tile/kernel/usb.c | 1 +
>>   1 file changed, 1 insertion(+)
> 
> Acked-by: Chris Metcalf <cmetcalf@ezchip.com>
> 
> or I'm happy to take it into the tile tree if you'd rather I did.

Thanks, I'll carry it since I'd risk introducing bisection failures
if my header changes go in without this being present 1st.

Paul.