On Tue, 30 Jun 2020, Herbert Xu wrote: > On Mon, Jun 29, 2020 at 01:30:03PM +0100, Lee Jones wrote: > > A recent change to the Regulator consumer API (which this driver > > utilises) add prototypes for the some suspend functions. These > > functions require including header file include/linux/suspend.h. > > > > The following tree of includes affecting this driver will be > > present: > > > > In file included from include/linux/elevator.h:6, > > from include/linux/blkdev.h:288, > > from include/linux/blk-cgroup.h:23, > > from include/linux/writeback.h:14, > > from include/linux/memcontrol.h:22, > > from include/linux/swap.h:9, > > from include/linux/suspend.h:5, > > from include/linux/regulator/consumer.h:35, > > from drivers/crypto/ux500/hash/hash_core.c:28: > > > > include/linux/elevator.h pulls in include/linux/hashtable.h which > > contains its own version of hash_init(). This confuses the build > > system and results in the following error (amongst others): > > > > drivers/crypto/ux500/hash/hash_core.c:1362:19: error: passing argument 1 of '__hash_init' from incompatible pointer type [-Werror=incompatible-pointer-types] > > 1362 | return hash_init(req); > > > > Fix this by namespacing the local hash_init() such that the > > source of confusion is removed. > > > > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> > > Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > > Cc: David S. Miller <davem@xxxxxxxxxxxxx> > > Cc: linux-crypto@xxxxxxxxxxxxxxx > > Signed-off-by: Lee Jones <lee.jones@xxxxxxxxxx> > > --- > > > > Ideally this should go into v5.8's -rcs else it runs the risk of > > breaking when Linus pulls everything in for v5.9-rc1. [...] > I also dislike pulling in the kitchen sink when all you need in > consumer.h is the definition of suspend_state_t. A better solution > would be to move the definition of suspend_state_t into linux/types.h > and including that instead of suspend.h in consumer.h. IMHO, including (whole) headers into source/header files is the norm. Even if only a small portion is actually referenced. Very seldom do consumers of an API use more than a fraction of what is available. Whether it's a couple of function calls, a struct or a type. Pulling headers apart and placing items in more convenient places i.e. into headers which are more commonly included, messes with the compartmentalisation of subsystems and sounds like more of a hack than simply saying "to enable suspend functions we need to reference the suspend API" like we are here. > I have no objections to this patch. However, I'd rather put > it on a topic branch which you could pull rather than pushing > it into 5.8 straight away. An immutable branch sounds like a sensible solution. Thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
