linux-kernel - Re: [PATCH 1/3] spi: Add helper functions for setting up transfers

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: <50EDE2FA.3060308@kernel.org>
Date:	Wed, 09 Jan 2013 21:36:58 +0000
From:	Jonathan Cameron <jic23@...nel.org>
To:	Lars-Peter Clausen <lars@...afoo.de>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Julia Lawall <Julia.Lawall@...6.fr>,
	spi-devel-general@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, Jonathan Cameron <jic23@....ac.uk>,
	linux-iio@...r.kernel.org
Subject: Re: [PATCH 1/3] spi: Add helper functions for setting up transfers

On 01/09/2013 08:56 PM, Lars-Peter Clausen wrote:
> On 01/09/2013 08:20 PM, Jonathan Cameron wrote:
>> On 01/09/2013 05:31 PM, Lars-Peter Clausen wrote:
>>> Quite often the pattern used for setting up and transferring a synchronous SPI
>>> transaction looks very much like the following:
>>>
>>> 	struct spi_message msg;
>>> 	struct spi_transfer xfers[] = {
>>> 		...
>>> 	};
>>>
>>> 	spi_message_init(&msg);
>>> 	spi_message_add_tail(&xfers[0], &msg);
>>> 	...
>>> 	spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);
>>>
>>> 	ret = spi_sync(&msg);
>>>
>>> This patch adds two new helper functions for handling this case. The first
>>> helper function spi_message_init_with_transfers() takes a spi_message and an
>>> array of spi_transfers. It will initialize the message and then call
>>> spi_message_add_tail() for each transfer in the array. E.g. the following
>>>
>>> 	spi_message_init(&msg);
>>> 	spi_message_add_tail(&xfers[0], &msg);
>>> 	...
>>> 	spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);
>>>
>>> can be rewritten as
>>>
>>> 	spi_message_init_with_transfers(&msg, xfers, ARRAY_SIZE(xfers));
>>>
>>> The second function spi_sync_transfer() takes a SPI device and an array of
>>> spi_transfers. It will allocate a new spi_message (on the stack) and add all
>>> transfers in the array to the message. Finally it will call spi_sync() on the
>>> message.
>>>
>>> E.g. the follwing
>>>
>>> 	struct spi_message msg;
>>> 	struct spi_transfer xfers[] = {
>>> 		...
>>> 	};
>>>
>>> 	spi_message_init(&msg);
>>> 	spi_message_add_tail(&xfers[0], &msg);
>>> 	...
>>> 	spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);
>>>
>>> 	ret = spi_sync(spi, &msg);
>>>
>>> can be rewritten as
>>>
>>> 	struct spi_transfer xfers[] = {
>>> 		...
>>> 	};
>>>
>>> 	ret = spi_sync_transfer(spi, xfers, ARRAY_SIZE(xfers));
>>>
>>> The patch also adds a new cocci script which can detect such sequences as
>>> described above and transform them automatically to use the new helper
>>> functions.
>>>
>>> Signed-off-by: Lars-Peter Clausen <lars@...afoo.de>
>>>
>> Principle looks good to me and some nice little duplication removal
>> savings.
>>
>> My coccinelle isn't really up to checking that, but for the functions
>> Acked-by: Jonathan Cameron <jic23@...nel.org>
>>
>> When all comments are in on the code we'll have to think about how to
>> merge this.  If you have much else planned that will hit those iio drivers
>> then things will get uggly unless it goes through that tree.
>>
>> Guess it all depends on whether others like the patch though ;)
> 
> The IIO patches can easily wait another release until the spi has made it's way
> up into mainline. I just didn't want to send out the helper functions without
> any realworld examples on how they can be used.
> 
Good point, though obviously send them again after this patch has merged
given the fine nature of my memory ;)
--
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/