[PATCH v2] staging: greybus: add missing includes

Rui Miguel Silva rui.silva at linaro.org
Wed Aug 28 15:17:50 UTC 2019


Hi Randy,
On Wed 28 Aug 2019 at 16:09, Randy Dunlap wrote:
> On 8/28/19 1:35 AM, Greg Kroah-Hartman wrote:
>> On Tue, Aug 27, 2019 at 09:59:17PM +0100, Rui Miguel Silva wrote:
>>> Before moving greybus core out of staging and moving header files to
>>> include/linux some greybus header files were missing the necessary
>>> includes. This would trigger compilation faillures with some example
>>> errors logged bellow for with CONFIG_KERNEL_HEADER_TEST=y.
>>>
>>> So, add the necessary headers to compile clean before relocating the
>>> header files.
>>>
>>> ./include/linux/greybus/hd.h:23:50: error: unknown type name 'u16'
>>>   int (*cport_disable)(struct gb_host_device *hd, u16 cport_id); ^~~
>>> ./include/linux/greybus/greybus_protocols.h:1314:2: error: unknown type name '__u8'
>>>   __u8 data[0];
>>>   ^~~~
>>> ./include/linux/greybus/hd.h:24:52: error: unknown type name 'u16'
>>>   int (*cport_connected)(struct gb_host_device *hd, u16 cport_id); ^~~
>>> ./include/linux/greybus/hd.h:25:48: error: unknown type name 'u16'
>>>   int (*cport_flush)(struct gb_host_device *hd, u16 cport_id); ^~~
>>> ./include/linux/greybus/hd.h:26:51: error: unknown type name 'u16'
>>>   int (*cport_shutdown)(struct gb_host_device *hd, u16 cport_id, ^~~
>>> ./include/linux/greybus/hd.h:27:5: error: unknown type name 'u8'
>>> u8 phase, unsigned int timeout);
>>>      ^~
>>> ./include/linux/greybus/hd.h:28:50: error: unknown type name 'u16'
>>>   int (*cport_quiesce)(struct gb_host_device *hd, u16 cport_id, ^~~
>>> ./include/linux/greybus/hd.h:29:5: error: unknown type name 'size_t'
>>>      size_t peer_space, unsigned int timeout);
>>>      ^~~~~~
>>> ./include/linux/greybus/hd.h:29:5: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
>>> ./include/linux/greybus/hd.h:1:1:
>>> +#include <stddef.h>
>>>  /* SPDX-License-Identifier: GPL-2.0 */
>>> ./include/linux/greybus/hd.h:29:5:
>>>      size_t peer_space, unsigned int timeout);
>>>      ^~~~~~
>>> ./include/linux/greybus/hd.h:30:48: error: unknown type name 'u16'
>>>   int (*cport_clear)(struct gb_host_device *hd, u16 cport_id); ^~~
>>> ./include/linux/greybus/hd.h:32:49: error: unknown type name 'u16'
>>>   int (*message_send)(struct gb_host_device *hd, u16 dest_cport_id, ^~~
>>> ./include/linux/greybus/hd.h:33:32: error: unknown type name 'gfp_t'
>>> struct gb_message *message, gfp_t gfp_mask); ^~~~~
>>> ./include/linux/greybus/hd.h:35:55: error: unknown type name 'u16'
>>>   int (*latency_tag_enable)(struct gb_host_device *hd, u16 cport_id);
>>>
>>> Reported-by: kbuild test robot <lkp at intel.com>
>>> Reported-by: Gao Xiang <hsiangkao at aol.com>
>>> Signed-off-by: Rui Miguel Silva <rui.silva at linaro.org>
>>> Acked-by: Alex Elder <elder at kernel.org>
>>> ---
>>>
>>> v1->v2:
>>> lkp at intel:
>>>   - added greybus_protocols.h include to svc.h header
>>> Alex Elder:
>>>   - remove extra line in operation.h
>>>
>>> Looks like lkp can now find missing headers that we can not :),
>>> it must be the config. but it is right.
>>>
>>> Greg please note the new include in svc.h may need to be changed
>>> when moving headers to include/linux
>>
>> As a version of your first patch is already in my tree, this one will
>> not apply :(
>>
>> Can you just send a fix-up patch against my staging-next branch instead?
>>
>> thanks,
>>
>> greg k-h
>> _______________________________________________
>> devel mailing list
>> devel at linuxdriverproject.org
>> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
>>
>
> linux-next of 20190828 has these warnings:
>
> ./../include/linux/greybus/svc.h:91:18: warning: 'struct gb_svc_l2_timer_cfg' declared inside parameter list will not be visible outside of this definition or declaration
> ./../include/linux/greybus/operation.h:188:34: warning: 'struct gb_host_device' declared inside parameter list will not be visible outside of this definition or declaration
>
>
> Are they fixed by some of these patches?
>

Yes, this [0] should fix it.

---
Cheers,
	Rui

[0]: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2019-August/138016.html


More information about the devel mailing list