On Sat, Aug 16, 2025 at 12:43:52PM -0700, Eric Biggers wrote: > -perlasm-flavour-$(CONFIG_32BIT) := o32 > -perlasm-flavour-$(CONFIG_64BIT) := 64 > - > -quiet_cmd_perlasm = PERLASM $@ > - cmd_perlasm = $(PERL) $(<) $(perlasm-flavour-y) $(@) > - > -$(obj)/poly1305-core.S: $(src)/poly1305-mips.pl FORCE > - $(call if_changed,perlasm) [...] > +ifeq ($(CONFIG_MIPS),y) > +libpoly1305-y += mips/poly1305-core.o > +poly1305-perlasm-flavour-$(CONFIG_32BIT) := o32 > +poly1305-perlasm-flavour-$(CONFIG_64BIT) := 64 > +quiet_cmd_perlasm_poly1305 = PERLASM $@ > + cmd_perlasm_poly1305 = $(PERL) $< $(poly1305-perlasm-flavour-y) $@ > +$(obj)/mips/poly1305-core.S: $(src)/mips/poly1305-mips.pl > + $(call if_changed,perlasm_poly1305) > +endif Small issue that I noticed: I removed the "FORCE" from the rule for poly1305-core.S since none of the other perlasm rules had it. But it's actually needed because, unlike the other perlasm rules, this one uses 'if_changed' instead of 'cmd'. 'if_changed' requires FORCE. And I believe it does need to use 'if_changed', since the contents of the generated .S file depends on the perlasm-flavour passed as an argument to the perl script. That can change when the kernel config changes. So, TLDR: I'll restore the FORCE to the rule, and add a comment. The RISC-V optimized Poly1305 code added by the third patch will need if_changed and FORCE for the same reason. Of course, it's unfortunate that these are written in Perl at all. But that is the convention used by Andy / CRYPTOGAMS, so that is what we'll use unless someone wants to rewrite it... - Eric
