On Thu, Dec 18, 2025 at 08:41:57AM -0600, Andrew Davis wrote:
> On 12/18/25 8:16 AM, Tom Rini wrote:
> > On Wed, Dec 17, 2025 at 11:03:43AM +0530, Anshul Dalal wrote:
> > > On Tue Dec 16, 2025 at 7:31 PM IST, Tom Rini wrote:
> > > > On Tue, Dec 16, 2025 at 01:52:37PM +0530, Anshul Dalal wrote:
> > > > > Hi all,
> > > > >
> > > > > Any updates on this patch? If possible could we pull this fix into
> > > > > master as well for the 2026.01 release?
> > > >
> > > > I thought the feedback was that this was a generic problem and so the
> > > > Kconfig logic should be universal, or there was an incorrectly /
> > > > sub-optimally handled case in the tiny printf code, that needs fixing.
> > >
> > > We have a few ways to go about fixing this:
> > >
> > > 1. Fix the commit 1e24e84db41a ("tiny-printf: Handle formatting of %p
> > > with an extra Kconfig"):
> > >
> > > Pointer formatting used to fall back to %x handling before the
> > > commit. Though going by the commit description, it looks like the
> > > change was intended. So, I'm unsure if we should re-introduce the
> > > confusing handling back where %p is handled but not %pa or %pap.
> > >
> > > 2. Add SPL_USE_TINY_PRINTF_POINTER_SUPPORT per defconfig:
> > >
> > > This was what v2 of the series were attempting to do but as Andrew
> > > pointed out, there might be other platforms with similar issues and
> > > it would be better to fix it for K3 overall.
> > >
> > > 3. Change usage of %p in k3_sysfw_dfu_download to %x:
> > >
> > > This is a suitable fix imo but we might still have to fix similar
> > > usages of %p in other places. We'd also have to be more careful when
> > > bringing proper U-Boot code to SPL since %p would not work the same
> > > way.
> > >
>
> For what it's worth my preference would be this one. We should just work
> to avoid using %p in general outside of debug statements.I'm also fine with that. > > > 4. Unconditionally select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3: > > > > > > This allows us to remedy the problems with above 3 solutions with > > > very little overhead to the SPL size (<100 bytes). > > > > > How about unconditionally select this for all platforms? If it is only > saving 100 bytes it shouldn't be an issue for most, then platforms that > have verified they do not need it (or need to save every last byte) can > then disable it. Seems odd to make a change like "1e24e84db41a" and not > have the default be the existing behavior. There's just lots of platforms that can't afford much growth. > > > If this problem is faced by non K3 platforms as well, perhaps it might > > > be better to take the hit and make SPL_USE_TINY_PRINTF_POINTER_SUPPORT > > > default y. > > > > Ah, so now I understand the problem, with point 3. So yes, I think the > > right fix is to add "select SPL_USE_TINY_PRINTF_POINTER_SUPPORT if > > SPL_USE_TINY_PRINTF && DFU && CPU_V7R" under the ARCH_K3 symbol. > > > > Just the length and specificity of that conditional string is making > me think that is not the right solution. What happens when we find > the same issue for SPL DFU on ARM64, or in some other code not > related to DFU, etc.. Part of the answer is that since we should be printing "?" now instead of the wrong value, it should be easier to spot the wrong code. Perhaps we also need something in doc/develop/spl.rst to talk about it (we default to a tiny subset printf, some things don't work without additional options, avoid %p unless you must and then enable SPL_USE...)? -- Tom
signature.asc
Description: PGP signature
