From: Alex Elder <elder@ieee.org>
To: Francesco Dolcini <francesco@dolcini.it>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
linux-bluetooth@vger.kernel.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
greybus-dev@lists.linaro.org, linux-iio@vger.kernel.org,
netdev@vger.kernel.org, chrome-platform@lists.linux.dev,
platform-driver-x86@vger.kernel.org,
linux-serial@vger.kernel.org, linux-sound@vger.kernel.org
Cc: "Francesco Dolcini" <francesco.dolcini@toradex.com>,
"Luiz Augusto von Dentz" <luiz.dentz@gmail.com>,
"Johan Hovold" <johan@kernel.org>,
"Alex Elder" <elder@kernel.org>,
"Jonathan Cameron" <jic23@kernel.org>,
"Lee Jones" <lee@kernel.org>, "Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Eric Dumazet" <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
"Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
"Hans de Goede" <hdegoede@redhat.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Benson Leung" <bleung@chromium.org>,
"Tzung-Bi Shih" <tzungbi@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH v2] treewide, serdev: change receive_buf() return type to size_t
Date: Wed, 24 Jan 2024 15:59:46 -0600 [thread overview]
Message-ID: <51d07f81-45f4-4772-915f-ed5dac602a40@ieee.org> (raw)
In-Reply-To: <20240122180551.34429-1-francesco@dolcini.it>
On 1/22/24 12:05 PM, Francesco Dolcini wrote:
> From: Francesco Dolcini <francesco.dolcini@toradex.com>
>
> receive_buf() is called from ttyport_receive_buf() that expects values
> ">= 0" from serdev_controller_receive_buf(), change its return type from
> ssize_t to size_t.
>
> The need for this clean-up was noticed while fixing a warning, see
> commit 94d053942544 ("Bluetooth: btnxpuart: fix recv_buf() return value").
> Changing the callback prototype to return an unsigned seems the best way
> to document the API and ensure that is properly used.
>
> GNSS drivers implementation of serdev receive_buf() callback return
> directly the return value of gnss_insert_raw(). gnss_insert_raw()
> returns a signed int, however this is not an issue since the value
> returned is always positive, because of the kfifo_in() implementation.
Agreed.
> gnss_insert_raw() could be changed to return also an unsigned, however
> this is not implemented here as request by the GNSS maintainer Johan
> Hovold.
I was going to suggest this, and suggest changing the "ret" in
gnss_insert_raw() to return size_t. But to really do that right
it would include some other changes as well. Leaving it as an
int as Johan suggests preserves correct behavior.
One minor point below, plus a couple comments affirming that
an int return value is OK because it's always non-negative.
Reviewed-by: Alex Elder <elder@linaro.org>
> Suggested-by: Jiri Slaby <jirislaby@kernel.org>
> Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc@kernel.org/
> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> #for-iio
> ---
> v1:
> - https://lore.kernel.org/all/20231214170146.641783-1-francesco@dolcini.it/
> v2:
> - rebased on 6.8-rc1
> - add acked-by Jonathan
> - do not change gnss_insert_raw()
> - do not change the code style of the gnss code
> - commit message improvements, explain the reasons for doing only minimal
> changes on the GNSS part
> ---
> drivers/bluetooth/btmtkuart.c | 4 ++--
> drivers/bluetooth/btnxpuart.c | 4 ++--
> drivers/bluetooth/hci_serdev.c | 4 ++--
> drivers/gnss/serial.c | 2 +-
> drivers/gnss/sirf.c | 2 +-
> drivers/greybus/gb-beagleplay.c | 6 +++---
> drivers/iio/chemical/pms7003.c | 4 ++--
> drivers/iio/chemical/scd30_serial.c | 4 ++--
> drivers/iio/chemical/sps30_serial.c | 4 ++--
> drivers/iio/imu/bno055/bno055_ser_core.c | 4 ++--
> drivers/mfd/rave-sp.c | 4 ++--
> drivers/net/ethernet/qualcomm/qca_uart.c | 2 +-
> drivers/nfc/pn533/uart.c | 4 ++--
> drivers/nfc/s3fwrn5/uart.c | 4 ++--
> drivers/platform/chrome/cros_ec_uart.c | 4 ++--
> drivers/platform/surface/aggregator/core.c | 4 ++--
> drivers/tty/serdev/serdev-ttyport.c | 10 ++++------
> include/linux/serdev.h | 8 ++++----
> sound/drivers/serial-generic.c | 4 ++--
> 19 files changed, 40 insertions(+), 42 deletions(-)
>
. . .
> diff --git a/drivers/mfd/rave-sp.c b/drivers/mfd/rave-sp.c
> index 6ff84b2600c5..62a6613fb070 100644
> --- a/drivers/mfd/rave-sp.c
> +++ b/drivers/mfd/rave-sp.c
> @@ -471,8 +471,8 @@ static void rave_sp_receive_frame(struct rave_sp *sp,
> rave_sp_receive_reply(sp, data, length);
> }
>
> -static ssize_t rave_sp_receive_buf(struct serdev_device *serdev,
> - const u8 *buf, size_t size)
> +static size_t rave_sp_receive_buf(struct serdev_device *serdev,
> + const u8 *buf, size_t size)
> {
> struct device *dev = &serdev->dev;
> struct rave_sp *sp = dev_get_drvdata(dev);
One return path in this function returns (src - buf), which is
*almost* guaranteed to be positive. The one case it wouldn't
be is if the assignment of end wraps around, and that's not
checked.
I think it's fine, but... That seems theoretically possible.
> diff --git a/drivers/net/ethernet/qualcomm/qca_uart.c b/drivers/net/ethernet/qualcomm/qca_uart.c
> index 223321897b96..20f50bde82ac 100644
. . .
> diff --git a/drivers/platform/surface/aggregator/core.c b/drivers/platform/surface/aggregator/core.c
> index 9591a28bc38a..ba550eaa06fc 100644
> --- a/drivers/platform/surface/aggregator/core.c
> +++ b/drivers/platform/surface/aggregator/core.c
> @@ -227,8 +227,8 @@ EXPORT_SYMBOL_GPL(ssam_client_bind);
>
> /* -- Glue layer (serdev_device -> ssam_controller). ------------------------ */
>
> -static ssize_t ssam_receive_buf(struct serdev_device *dev, const u8 *buf,
> - size_t n)
> +static size_t ssam_receive_buf(struct serdev_device *dev, const u8 *buf,
> + size_t n)
> {
> struct ssam_controller *ctrl;
> int ret;
Here you the return value will be positive despite ret being
a signed int. So like the GNSS case, this is OK.
> diff --git a/drivers/tty/serdev/serdev-ttyport.c b/drivers/tty/serdev/serdev-ttyport.c
> index e94e090cf0a1..3d7ae7fa5018 100644
. . .
> diff --git a/sound/drivers/serial-generic.c b/sound/drivers/serial-generic.c
> index d6e5aafd697c..36409a56c675 100644
> --- a/sound/drivers/serial-generic.c
> +++ b/sound/drivers/serial-generic.c
> @@ -100,8 +100,8 @@ static void snd_serial_generic_write_wakeup(struct serdev_device *serdev)
> snd_serial_generic_tx_wakeup(drvdata);
> }
>
> -static ssize_t snd_serial_generic_receive_buf(struct serdev_device *serdev,
> - const u8 *buf, size_t count)
> +static size_t snd_serial_generic_receive_buf(struct serdev_device *serdev,
> + const u8 *buf, size_t count)
> {
> int ret;
> struct snd_serial_generic *drvdata = serdev_device_get_drvdata(serdev);
Same thing here.
next prev parent reply other threads:[~2024-01-24 21:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 18:05 [PATCH v2] treewide, serdev: change receive_buf() return type to size_t Francesco Dolcini
2024-01-24 11:38 ` Ilpo Järvinen
2024-01-24 18:20 ` Rob Herring
2024-01-24 18:43 ` Maximilian Luz
2024-01-24 21:59 ` Alex Elder [this message]
2024-01-25 7:37 ` Johan Hovold
2024-01-25 10:42 ` Lee Jones
2024-03-25 1:54 ` patchwork-bot+chrome-platform
2024-03-25 2:13 ` patchwork-bot+chrome-platform
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=51d07f81-45f4-4772-915f-ed5dac602a40@ieee.org \
--to=elder@ieee.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=elder@kernel.org \
--cc=francesco.dolcini@toradex.com \
--cc=francesco@dolcini.it \
--cc=gregkh@linuxfoundation.org \
--cc=greybus-dev@lists.linaro.org \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jic23@kernel.org \
--cc=jirislaby@kernel.org \
--cc=johan@kernel.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=kuba@kernel.org \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=robh@kernel.org \
--cc=tzungbi@kernel.org \
/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