[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151201231233.GA1929@sirena.org.uk>
Date: Tue, 1 Dec 2015 23:12:33 +0000
From: Mark Brown <broonie@...nel.org>
To: Michal Suchanek <hramrach@...il.com>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
David Woodhouse <dwmw2@...radead.org>,
Brian Norris <computersforpeace@...il.com>,
Han Xu <han.xu@...escale.com>,
Boris Brezillon <boris.brezillon@...e-electrons.com>,
Javier Martinez Canillas <javier@....samsung.com>,
Stephen Warren <swarren@...dia.com>,
"Andrew F. Davis" <afd@...com>, Marek Vasut <marex@...x.de>,
Rafał Miłecki <zajec5@...il.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Gabor Juhos <juhosg@...nwrt.org>,
Bean Huo 霍斌斌 <beanhuo@...ron.com>,
Furquan Shaikh <furquan@...gle.com>,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-spi@...r.kernel.org
Subject: Re: [PATCH v5 08/10] spi: expose master transfer size limitation.
On Tue, Dec 01, 2015 at 04:51:06PM -0000, Michal Suchanek wrote:
> +static inline size_t
> +spi_max_transfer_size(struct spi_device *spi)
> +{
> + struct spi_master *master = spi->master;
> + if (!master->max_transfer_size)
> + return 0;
> + return master->max_transfer_size(spi);
> +}
Can we change this to return SIZE_MAX instead (ie, the maximum value for
a size_t)? That way callers don't need to worry if there is a limit, if
they want to handle it they can just unconditionally assume that a limit
will be provided.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists