On Tue, Jan 13, 2026 at 05:30:55PM +0100, Quentin Schulz wrote: > Hi Tom, > > On 12/25/25 4:37 PM, Tom Rini wrote: > > Given how the support for CONFIG_CMD_TFTPPUT is woven through the > > support for the tftp protocol we currently end up including "put" > > support in xPL phases, if enabled. This in turn can lead to size > > overflow on those platforms as xPL tends to be constrained. To resolve > > this, use "CMD_TFTPPUT" in the code to check for both CONFIG_CMD_TFTPPUT > > being true and not being in an xPL build phase. > > > > Signed-off-by: Tom Rini <[email protected]> > > --- > > Cc: Jerome Forissier <[email protected]> > > --- > > net/tftp.c | 31 ++++++++++++++++++++----------- > > 1 file changed, 20 insertions(+), 11 deletions(-) > > > > diff --git a/net/tftp.c b/net/tftp.c > > index 3b0f4cd2006e..78ec44159c1b 100644 > > --- a/net/tftp.c > > +++ b/net/tftp.c > > @@ -22,6 +22,15 @@ > > DECLARE_GLOBAL_DATA_PTR; > > +/* > > + * We cannot use the 'tftpput' command in xPL phases. Given how the > > + * support is integrated in the code, this is how we disable that support > > + * in xPL. > > + */ > > +#if defined(CONFIG_CMD_TFTPPUT) && !defined(CONFIG_XPL_BUILD) > > +#define CMD_TFTPPUT > > +#endif > > + > > Doesn't > > #if CONFIG_IS_ENABLED(CMD_TFTPPUT) > > work? > > Of course, CONFIG_SPL_CMD_TFTPPUT, TPL_, VPL_, ... will never exist, so that > should tackle it properly and be more consistent with the reset of the > (recent) code base?
That probably works too but is getting too clever and obfuscates the problem I feel. It makes a certain amount of sense to use *IS_ENABLED macros in the more recent portions of the code base where we've more generally split cmd processing from protocol implementation as well more cleanly sharing code between phases, but here I prefer something more clear especially since for CMD it really should never be valid in xPL phases, but I think we still do end up with a funny spot or two. -- Tom
signature.asc
Description: PGP signature
