From: Pei Xiao <xiaopei01@kylinos.cn>
To: CL Wang <cl634@andestech.com>, xiaopeitux@foxmail.com
Cc: broonie@kernel.org, linux-spi@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH] spi: atcspi200: validate data buswidth to fix FIELD_PREP build error
Date: Mon, 23 Feb 2026 15:45:22 +0800 [thread overview]
Message-ID: <0eb57f44-2adf-4f15-9fac-ffc4f22374b1@kylinos.cn> (raw)
In-Reply-To: <aZv1cB0ATB66E5hO@swlinux02>
在 2026/2/23 14:36, CL Wang 写道:
> 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.
please go ahead with the modifications, thank you!
Pei .
Thanks!
> Thanks again for catching this!
>
> Best regards,
> CL
prev parent reply other threads:[~2026-02-23 7:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-18 8:21 xiaopeitux
2026-02-23 6:36 ` CL Wang
2026-02-23 7:45 ` Pei Xiao [this message]
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=0eb57f44-2adf-4f15-9fac-ffc4f22374b1@kylinos.cn \
--to=xiaopei01@kylinos.cn \
--cc=broonie@kernel.org \
--cc=cl634@andestech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=lkp@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®