Received-SPF: pass (google.com: domain of linux-kernel+bounces-59758-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <20240209060353.6613-1-abhishekpandit@chromium.org>
 <20240208220230.v4.1.Iacf5570a66b82b73ef03daa6557e2fc0db10266a@changeid> <ZcY2kVlUn7SJ5pW8@smile.fi.intel.com>
In-Reply-To: <ZcY2kVlUn7SJ5pW8@smile.fi.intel.com>
From: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Date: Fri, 9 Feb 2024 10:01:07 -0800
Message-ID: <CANFp7mW0F_zyaKJg0LusT6Cp4h0_8Z4jq+R1GUGtpyZrv99iVw@mail.gmail.com>
Subject: Re: [PATCH v4 1/3] usb: typec: ucsi: Limit read size on v1.2
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>, linux-usb@vger.kernel.org, 
	jthies@google.com, pmalani@chromium.org, 
	Neil Armstrong <neil.armstrong@linaro.org>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, 
	Fabrice Gasnier <fabrice.gasnier@foss.st.com>, 
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Hans de Goede <hdegoede@redhat.com>, 
	Rajaram Regupathy <rajaram.regupathy@intel.com>, Saranya Gopal <saranya.gopal@intel.com>, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 9, 2024 at 6:28=E2=80=AFAM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Thu, Feb 08, 2024 at 10:02:38PM -0800, Abhishek Pandit-Subedi wrote:
> > Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was
> > increased from 16 to 256. In order to avoid overflowing reads for older
> > systems, add a mechanism to use the read UCSI version to truncate read
> > sizes on UCSI v1.2.
>
> ...
>
> > +     if (ucsi->version <=3D UCSI_VERSION_1_2)
> > +             buf_size =3D min_t(size_t, 16, buf_size);
>
> Please, avoid using min_t(). Here the clamp() can be used.
I think this is likely the 4th time I've been tripped up by an
undocumented practice in this patch series. <linux/minmax.h> says
nothing about avoiding min_t -- why prefer clamp()? Please add the
recommendation here
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/in=
clude/linux/minmax.h#n10)
and I am more than happy to change it after.

> Shouldn't magic number be defined?
The comment right above this line documents the number.
As this is the only use right now, I don't see a need to make it a
macro/constant yet.

>
> --
> With Best Regards,
> Andy Shevchenko
>
>

Cheers,
Abhishek