| Message ID | 20160720041332.30789-2-paul.gortmaker@windriver.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, * Paul Gortmaker <paul.gortmaker@windriver.com> [160719 21:17]: > During unrelated work, attempting to remove an include of the > linux/module.h in favour of "struct module;" in order to reduce > header entanglement, we found doing so caused a build failure in > this file. We're planning to drop this file after v4.8-rc1 after I've verified that legacy booting still works at v4.8-rc1. Are you OK if I pick this patch into my omap-for-v4.8/legacy branch? Or if you have a minimal immutable branch against v4.7-rc1 with just this patch I can merge it in no problem. Regards, Tony
[Re: [PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals] On 21/07/2016 (Thu 23:41) Tony Lindgren wrote: > Hi, > > * Paul Gortmaker <paul.gortmaker@windriver.com> [160719 21:17]: > > During unrelated work, attempting to remove an include of the > > linux/module.h in favour of "struct module;" in order to reduce > > header entanglement, we found doing so caused a build failure in > > this file. > > We're planning to drop this file after v4.8-rc1 after I've > verified that legacy booting still works at v4.8-rc1. > > Are you OK if I pick this patch into my omap-for-v4.8/legacy > branch? Or if you have a minimal immutable branch against v4.7-rc1 > with just this patch I can merge it in no problem. Is the legacy branch a contingency plan for the case where legacy booting doesn't work? If so, that should be OK. Having the patch present, or having the file deleted both take care of my concern -- which was was introducing build regressions when adding the gpio header cleanup into for-4.9 content. THanks, Paul. -- > > Regards, > > Tony
* Paul Gortmaker <paul.gortmaker@windriver.com> [160722 07:02]: > [Re: [PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals] On 21/07/2016 (Thu 23:41) Tony Lindgren wrote: > > > Hi, > > > > * Paul Gortmaker <paul.gortmaker@windriver.com> [160719 21:17]: > > > During unrelated work, attempting to remove an include of the > > > linux/module.h in favour of "struct module;" in order to reduce > > > header entanglement, we found doing so caused a build failure in > > > this file. > > > > We're planning to drop this file after v4.8-rc1 after I've > > verified that legacy booting still works at v4.8-rc1. > > > > Are you OK if I pick this patch into my omap-for-v4.8/legacy > > branch? Or if you have a minimal immutable branch against v4.7-rc1 > > with just this patch I can merge it in no problem. > > Is the legacy branch a contingency plan for the case where legacy > booting doesn't work? If so, that should be OK. Well it's just a branch of omap legacy booting related patches for v4.8. But looking at it now, looks like I already pushed out the removal of the last two remaining board files before I took few weeks off. But I did not add it to Linux next to keep things working until -rc1. > Having the patch present, or having the file deleted both take care of > my concern -- which was was introducing build regressions when adding > the gpio header cleanup into for-4.9 content. OK. As I've already pushed out the board-*.c removal branch, I suggest we just drop the $subject patch to avoid a merge conflict. Regards, Tony
[Re: [PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals] On 22/07/2016 (Fri 22:55) Tony Lindgren wrote: > * Paul Gortmaker <paul.gortmaker@windriver.com> [160722 07:02]: [...] > > Having the patch present, or having the file deleted both take care of > > my concern -- which was was introducing build regressions when adding > > the gpio header cleanup into for-4.9 content. > > OK. As I've already pushed out the board-*.c removal branch, I > suggest we just drop the $subject patch to avoid a merge conflict. Sounds like a plan. I'll just keep it in my local queue so my tests don't fail and drop it on the floor once I see your removal loop around to me via linux-next or master. Thanks, Paul. -- > > Regards, > > Tony
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c index a5ab712c1a59..4ddda1d33ec1 100644 --- a/arch/arm/mach-omap2/board-rx51-peripherals.c +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c @@ -978,7 +978,7 @@ static struct twl4030_platform_data rx51_twldata __initdata = { .vio = &rx51_vio, }; -static struct tpa6130a2_platform_data rx51_tpa6130a2_data __initdata_or_module = { +static struct tpa6130a2_platform_data rx51_tpa6130a2_data __initdata = { .power_gpio = 98, };
During unrelated work, attempting to remove an include of the linux/module.h in favour of "struct module;" in order to reduce header entanglement, we found doing so caused a build failure in this file. It turns out this file uses __init_or_module which lives in the module.h header, but it wasn't including module.h -- which was being masked by the module.h in include/linux/gpio/driver.h - the one we want to remove/replace. However, if we dig into Makefile / Kconfig we find: mach-omap2/board-rx51-peripherals.o ----> mach-omap2/Makefile:obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-peripherals.o arch/arm/mach-omap2/Kconfig:config MACH_NOKIA_RX51 arch/arm/mach-omap2/Kconfig: bool "Nokia N900 (RX-51) phone" ...and hence the __init_or_module is pointless, as it will always evaluate to plain __init. With ARM and GPIO being different subsystems, we'll need to get this in ARM 1st, and then wait a release before changing the GPIO header, otherwise we'll risk triggering build failures. Cc: Tony Lindgren <tony@atomide.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: linux-omap@vger.kernel.org Cc: linux-gpio@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> --- arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)