Re: [PATCH v4 17/20] platform/x86/intel/tpmi: Use scnprintf() to build the debugfs names

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]

On Tue, 13 Oct 2026, Kuppuswamy Sathyanarayanan wrote:
> On 10/13/2026 2:14 AM, Andy Shevchenko wrote:
> > On Tue, Oct 13, 2026 at 11:42:00AM +0300, Ilpo Järvinen wrote:
> >> On Mon, 12 Oct 2026, Andy Shevchenko wrote:
> >>> On Tue, Oct 06, 2026 at 11:30:34AM -0700, Kuppuswamy Sathyanarayanan wrote:
> >>>> snprintf() is on its way out in favour of scnprintf(). Neither of the two
> >>>> callers in tpmi_dbgfs_register() looks at the return value, so the
> >>>> difference in what the two return does not matter here.
> >>>
> >>> I believe I asked it already: Why do we care? Do you get any compilation
> >>> warning (assuming `make W=1`)?
> >>
> >> I do care that we've two functions for essentially the same thing and 
> >> would prefer to have just one that remains (and obviously that would be 
> >> the c variant).
> > 
> > I see, thanks for the hint, but it's not clear from the commit message.
> 
> Agreed. There is no W=1 warning behind this. It is only about converging
> on scnprintf(), as Ilpo explained. Below is a reworded commit message
> that says so directly.
> 
> Ilpo, would you prefer that I send a v5 with this change, or are you
> fine with updating the commit message when you apply the series?
> 
> ---
> platform/x86/intel/tpmi: Use scnprintf() to build the debugfs names
> 
> The kernel has both snprintf() and scnprintf() for formatting into a
> fixed size buffer. The preference is to settle on scnprintf() and stop
> adding snprintf() users, so that only one of the two remains in use.
> 
> Convert the two callers in tpmi_dbgfs_register(). Neither of them looks
> at the return value, so the difference in what the two functions return
> does not matter here. 
> 
> No functional change intended.
> 
> Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com

Hi,

The proposed text seems fine.

I'm afraid I might forget to change it so sending v5 is safer from that 
perspective. Closing an old version from patchwork is pretty simple for 
me.

-- 
 i.