linux-kernel - Re: [PATCH v5 08/10] spi: expose master transfer size limitation.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <5FC39638-EEE0-4CFA-B464-0B4743CB6AB6@sperl.org>
Date:	Fri, 4 Dec 2015 15:30:50 +0100
From:	Martin Sperl <martin@...rl.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	Michal Suchanek <hramrach@...il.com>,
	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 02.12.2015, at 00:12, Mark Brown <broonie@...nel.org> wrote:
> 
> 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.

As I just came across: spi_master.max_dma_len, so I wonder how this 
value would differ from the proposed spi_master.max_transfer_size
on specific HW?

For all practical purposes I would assume both are identical.

Martin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/