From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Neal Patalay <nealpatalay0@gmail.com>
Cc: andy@kernel.org, hansg@kernel.org, mchehab@kernel.org,
gregkh@linuxfoundation.org, sakari.ailus@linux.intel.com,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-staging@lists.linux.dev, matt@mattwardle.net,
error27@gmail.com, mugrinphoto@gmail.com
Subject: Re: [PATCH] staging: media: atomisp: refactor pipe graph dump stage formatting
Date: Thu, 2 Jul 2026 12:11:26 +0300 [thread overview]
Message-ID: <akYrPsbQnjPfAPkq@ashevche-desk.local> (raw)
In-Reply-To: <20260701161534.31152-1-nealpatalay0@gmail.com>
On Wed, Jul 01, 2026 at 09:15:34AM -0700, Neal Patalay wrote:
> The original implementation of ia_css_debug_pipe_graph_dump_stage()
> includes an off-by-one error where the original strscpy size dropped
strscpy()
> characters immediately before newlines. It also allocates over 600
> bytes across multiple buffers on the stack. Address these shortcomings
> and reduce stack usage with a single 256 byte buffer via a new helper
> function, ia_css_debug_build_info().
Thanks, this is useful! See my comments below.
> Fixes: ad85094b293e ("Revert "media: staging: atomisp: Remove driver"")
Nope. Find the actual commit in the history.
...
> +static void ia_css_debug_build_info(char *info, size_t info_size, int *offset, bool flag,
> + const char *flag_str, size_t flag_str_size, int *line_len)
> +{
> + if (flag) {
So, this makes code much better if
if (!flag)
return;
BUT, the usual way of such functions is to make check in the caller(s) and drop
this "flag" completely.
> + /* If new line length exceeds max line length, replace the last ',' with a "\\n" */
The media subsystem is quite strict about 80 character limit, this line way
too long.
> + if (*line_len > 0 && info_size - *offset >= 2 &&
> + *line_len + flag_str_size > ENABLE_LINE_MAX_LENGTH) {
> + info[*offset - 1] = '\\';
> + info[*offset] = 'n';
> + *offset += 1;
> + *line_len = 0;
> + }
> +
> + int len_written = scnprintf(info + *offset, info_size - *offset, "%s,", flag_str);
> + *offset += len_written;
> + *line_len += len_written;
> + }
> +}
...
> +#define ADD_INFO(flag, flag_str) ia_css_debug_build_info(enable_info, sizeof(enable_info), \
> + &offset, bi->enable.flag, flag_str, sizeof(flag_str), &line_len)
Use logical split and make this all to be shorter.
> + /* Build string in enable_info buffer */
> + ADD_INFO(reduced_pipe, "rp");
> + ADD_INFO(vf_veceven, "vfve");
> + ADD_INFO(dis, "dis");
> + ADD_INFO(dvs_envelope, "dvse");
> + ADD_INFO(uds, "uds");
> + ADD_INFO(dvs_6axis, "dvs6");
> + ADD_INFO(block_output, "bo");
> + ADD_INFO(ds, "ds");
> + ADD_INFO(bayer_fir_6db, "bf6");
> + ADD_INFO(raw_binning, "rawb");
> + ADD_INFO(continuous, "cont");
> + ADD_INFO(s3a, "s3a");
> + ADD_INFO(fpnr, "fpnr");
> + ADD_INFO(sc, "sc");
> + ADD_INFO(macc, "macc");
> + ADD_INFO(output, "outp");
> + ADD_INFO(ref_frame, "reff");
> + ADD_INFO(tnr, "tnr");
> + ADD_INFO(xnr, "xnr");
> + ADD_INFO(params, "par");
> + ADD_INFO(ca_gdc, "cagdc");
> + ADD_INFO(isp_addresses, "ispa");
> + ADD_INFO(in_frame, "inf");
> + ADD_INFO(out_frame, "outf");
> + ADD_INFO(high_speed, "hs");
> +
> +#undef ADD_INFO
Instead of doing this way, consider making an string literal array and just
loop over it. This might need to reconsider representation of those flags
as well. Yet, don't come to the conclusion, you need to try and see which
one is better. The current approach is okay if my suggestion will look less
readable.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-07-02 9:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 16:15 [PATCH] staging: media: atomisp: refactor pipe graph dump stage formatting Neal Patalay
2026-07-02 9:11 ` Andy Shevchenko [this message]
2026-07-05 3:28 ` Neal Patalay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=akYrPsbQnjPfAPkq@ashevche-desk.local \
--to=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=error27@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hansg@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=matt@mattwardle.net \
--cc=mchehab@kernel.org \
--cc=mugrinphoto@gmail.com \
--cc=nealpatalay0@gmail.com \
--cc=sakari.ailus@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox