| Message ID | 20191120112738.7031-1-mpe@ellerman.id.au (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | crypto: vmx - Avoid weird build failures | expand |
On Wed, Nov 20, 2019 at 10:27:38PM +1100, Michael Ellerman wrote: > In the vmx crypto Makefile we assign to a variable called TARGET and > pass that to the aesp8-ppc.pl and ghashp8-ppc.pl scripts. > > The variable is meant to describe what flavour of powerpc we're > building for, eg. either 32 or 64-bit, and big or little endian. > > Unfortunately TARGET is a fairly common name for a make variable, and > if it happens that TARGET is specified as a command line parameter to > make, the value specified on the command line will override our value. > > In particular this can happen if the kernel Makefile is driven by an > external Makefile that uses TARGET for something. > > This leads to weird build failures, eg: > nonsense at /build/linux/drivers/crypto/vmx/ghashp8-ppc.pl line 45. > /linux/drivers/crypto/vmx/Makefile:20: recipe for target 'drivers/crypto/vmx/ghashp8-ppc.S' failed > > Which shows that we passed an empty value for $(TARGET) to the perl > script, confirmed with make V=1: > > perl /linux/drivers/crypto/vmx/ghashp8-ppc.pl > drivers/crypto/vmx/ghashp8-ppc.S > > We can avoid this confusion by using override, to tell make that we > don't want anything to override our variable, even a value specified > on the command line. We can also use a less common name, given the > script calls it "flavour", let's use that. > > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> > --- > drivers/crypto/vmx/Makefile | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Patch applied. Thanks.
diff --git a/drivers/crypto/vmx/Makefile b/drivers/crypto/vmx/Makefile index cab32cfec9c4..709670d2b553 100644 --- a/drivers/crypto/vmx/Makefile +++ b/drivers/crypto/vmx/Makefile @@ -3,13 +3,13 @@ obj-$(CONFIG_CRYPTO_DEV_VMX_ENCRYPT) += vmx-crypto.o vmx-crypto-objs := vmx.o aesp8-ppc.o ghashp8-ppc.o aes.o aes_cbc.o aes_ctr.o aes_xts.o ghash.o ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y) -TARGET := linux-ppc64le +override flavour := linux-ppc64le else -TARGET := linux-ppc64 +override flavour := linux-ppc64 endif quiet_cmd_perl = PERL $@ - cmd_perl = $(PERL) $(<) $(TARGET) > $(@) + cmd_perl = $(PERL) $(<) $(flavour) > $(@) targets += aesp8-ppc.S ghashp8-ppc.S
In the vmx crypto Makefile we assign to a variable called TARGET and pass that to the aesp8-ppc.pl and ghashp8-ppc.pl scripts. The variable is meant to describe what flavour of powerpc we're building for, eg. either 32 or 64-bit, and big or little endian. Unfortunately TARGET is a fairly common name for a make variable, and if it happens that TARGET is specified as a command line parameter to make, the value specified on the command line will override our value. In particular this can happen if the kernel Makefile is driven by an external Makefile that uses TARGET for something. This leads to weird build failures, eg: nonsense at /build/linux/drivers/crypto/vmx/ghashp8-ppc.pl line 45. /linux/drivers/crypto/vmx/Makefile:20: recipe for target 'drivers/crypto/vmx/ghashp8-ppc.S' failed Which shows that we passed an empty value for $(TARGET) to the perl script, confirmed with make V=1: perl /linux/drivers/crypto/vmx/ghashp8-ppc.pl > drivers/crypto/vmx/ghashp8-ppc.S We can avoid this confusion by using override, to tell make that we don't want anything to override our variable, even a value specified on the command line. We can also use a less common name, given the script calls it "flavour", let's use that. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> --- drivers/crypto/vmx/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)