From: CL Wang <cl634@andestech.com>
To: <xiaopeitux@foxmail.com>
Cc: <broonie@kernel.org>, <linux-spi@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, Pei Xiao <xiaopei01@kylinos.cn>,
"kernel test robot" <lkp@intel.com>, <cl634@andestech.com>
Subject: Re: [PATCH] spi: atcspi200: validate data buswidth to fix FIELD_PREP build error
Date: Mon, 23 Feb 2026 14:36:32 +0800 [thread overview]
Message-ID: <aZv1cB0ATB66E5hO@swlinux02> (raw)
In-Reply-To: <tencent_E59C90CD95B9DE440871635139437A79410A@qq.com>
Hi Pei,
Thanks for the patch to address the GCC compiler warning.
While I understand that the SPI framework theoretically guarantees
op->data.buswidth won't produce an out-of-bounds value here, I have
some concerns regarding the proposed error handling.
Using a direct return; inside atcspi_set_trans_ctl() creates a silent failure.
Since the function returns void, the callers (atcspi_prepare_trans and
atcspi_exec_mem_op) remain completely unaware of the error. They will blindly
proceed with the transfer, leaving the hardware in an unconfigured or unknown
state. Additionally, using a forced bitwise truncation could also lead to
uncontrollable hardware behavior.
A safer approach would be to either modify the function signatures to propagate
the error (e.g., returning -EINVAL), or at least fall back to a safe default
(like forcing width_code = 0 for standard 1-bit mode) along with
a WARN_ON_ONCE().
Since this requires a bit more structural adjustment in the driver, would you
mind if I take this over and submit a proper fix? I will make sure to add a
Suggested-by tag to acknowledge your effort in bringing this up.
Thanks again for catching this!
Best regards,
CL
>
next prev parent reply other threads:[~2026-02-23 6:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-18 8:21 [PATCH] spi: atcspi200: validate data buswidth to fix FIELD_PREP build error xiaopeitux
2026-02-23 6:36 ` CL Wang [this message]
2026-02-23 7:45 ` Pei Xiao
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=aZv1cB0ATB66E5hO@swlinux02 \
--to=cl634@andestech.com \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=lkp@intel.com \
--cc=xiaopei01@kylinos.cn \
--cc=xiaopeitux@foxmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.