Received-SPF: pass (google.com: domain of linux-kernel+bounces-54274-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240205152013.3833940-1-chou.cosmo@gmail.com>
 <20240205152013.3833940-2-chou.cosmo@gmail.com> <4a504043-e24d-4119-8c5d-107f0d371110@roeck-us.net>
 <CAOeEDysSZEeKt==zyexLE1GhE5ZpeDHS7sDLRfcC=4JgiogLKQ@mail.gmail.com> <a05ec2fe-cfe4-48d8-bff4-9f3689c585d3@roeck-us.net>
In-Reply-To: <a05ec2fe-cfe4-48d8-bff4-9f3689c585d3@roeck-us.net>
From: Cosmo Chou <chou.cosmo@gmail.com>
Date: Tue, 6 Feb 2024 11:53:51 +0800
Message-ID: <CAOeEDyscobVHaAe+72P2wEiucgWUDX=2H2W5dq0P1q8RB=7tzg@mail.gmail.com>
Subject: Re: [PATCH v5 1/1] hwmon: Add driver for Astera Labs PT5161L retimer
To: Guenter Roeck <linux@roeck-us.net>
Cc: robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, 
	jdelvare@suse.com, corbet@lwn.net, broonie@kernel.org, 
	naresh.solanki@9elements.com, vincent@vtremblay.dev, 
	patrick.rudolph@9elements.com, luca.ceresoli@bootlin.com, bhelgaas@google.com, 
	festevam@denx.de, alexander.stein@ew.tq-group.com, heiko@sntech.de, 
	jernej.skrabec@gmail.com, macromorgan@hotmail.com, forbidden405@foxmail.com, 
	sre@kernel.org, linus.walleij@linaro.org, devicetree@vger.kernel.org, 
	linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org, 
	linux-doc@vger.kernel.org, cosmo.chou@quantatw.com
Content-Type: text/plain; charset="UTF-8"

On Tue, Feb 06, 2024 at 11:26 AM +0800, Guenter Roeck wrote:
>
> On 2/5/24 19:05, Cosmo Chou wrote:
> > On Tue, Feb 06, 2024 at 3:43 AM +0800, Guenter Roeck wrote:
> >>
> >> On Mon, Feb 05, 2024 at 11:20:13PM +0800, Cosmo Chou wrote:
> >>> This driver implements support for temperature monitoring of Astera Labs
> >>> PT5161L series PCIe retimer chips.
> >>>
> >>> This driver implementation originates from the CSDK available at
> >>> Link: https://github.com/facebook/openbmc/tree/helium/common/recipes-lib/retimer-v2.14
> >>> The communication protocol utilized is based on the I2C/SMBus standard.
> >>>
> >>> Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com>
> >>> ---
> >> [ ... ]
> >>
> >>> +static ssize_t pt5161l_debugfs_read_fw_ver(struct file *file, char __user *buf,
> >>> +                                        size_t count, loff_t *ppos)
> >>> +{
> >>> +     struct pt5161l_data *data = file->private_data;
> >>> +     int ret;
> >>> +     char ver[32];
> >>> +
> >>> +     mutex_lock(&data->lock);
> >>> +     ret = pt5161l_fwsts_check(data);
> >>> +     mutex_unlock(&data->lock);
> >>> +     if (ret)
> >>> +             return ret;
> >>> +
> >>> +     ret = snprintf(ver, sizeof(ver), "%u.%u.%u\n", data->fw_ver.major,
> >>> +                    data->fw_ver.minor, data->fw_ver.build);
> >>> +     if (ret < 0)
> >>> +             return ret;
> >>> +
> >>
> >> You almost got me here ;-). snprintf() never returns a negative error code,
> >> so checking for it is not necessary.
> >>
> > Oh! You're right.
> >
> >>> +     return simple_read_from_buffer(buf, count, ppos, ver, ret + 1);
> >>
> >> Number of bytes written plus 1 ? Why ?
> > It's just to include the string terminator '\0'.
> >
>
> If that was needed, it would be risky. snprintf() truncates the output
> if the buffer is not large enough. You might want to consider using
> scnprintf() instead. But then I am not sure if that is needed in the first
> place. Almost all code I checked doesn't do that, and it seems to be likely
> that the few drivers who do that are simply wrong. Can you explain why the
> string terminator needs to be added to the output ?
>
> Thanks,
> Guenter
>
It's just in case someone reads and prints this, but with a dirty
buffer and doesn't handle the terminator.