On Wed, Aug 28, 2019 at 04:17:50PM +0100, Rui Miguel Silva wrote: > 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@xxxxxxxxx> > >>> Reported-by: Gao Xiang <hsiangkao@xxxxxxx> > >>> Signed-off-by: Rui Miguel Silva <rui.silva@xxxxxxxxxx> > >>> Acked-by: Alex Elder <elder@xxxxxxxxxx> > >>> --- > >>> > >>> v1->v2: > >>> lkp@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@xxxxxxxxxxxxxxxxxxxxxx > >> 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. Which I just queued up, so it should show up in linux-next tomorrow. thanks! greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
