linux-kernel - RE: [PATCH 3/8] spi: spi-ep93xx: always handle transfer specific settings

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]

Date:	Fri, 28 Jun 2013 18:42:59 -0500
From:	H Hartley Sweeten <hartleys@...ionengravers.com>
To:	Ryan Mallon <rmallon@...il.com>
CC:	Linux Kernel <linux-kernel@...r.kernel.org>,
	"spi-devel-general@...ts.sourceforge.net" 
	<spi-devel-general@...ts.sourceforge.net>,
	"mika.westerberg@....fi" <mika.westerberg@....fi>,
	"broonie@...nel.org" <broonie@...nel.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>
Subject: RE: [PATCH 3/8] spi: spi-ep93xx: always handle transfer specific
 settings

On Friday, June 28, 2013 4:18 PM, Ryan Mallon wrote:
> On 29/06/13 04:43, H Hartley Sweeten wrote:
>> __spi_async(), which starts every SPI message transfer, initializes
>> the bits_per_word and max speed for every transfer in the message.
>> Since the conditional test in ep93xx_spi_process_transfer() will
>> always succeed just remove it and always call ep93xx_spi_chip_setup()
>> to configure the hardware for each transfer in the message.
>> 
>> Remove the redundant ep93xx_spi_chp_setup() in ep93xx_spi_process_transfer()
>> which just initializes the hardware to the "default" based on the SPI
>> device.
>> 
>> Signed-off-by: H Hartley Sweeten <hsweeten@...ionengravers.com>
>> Cc: Ryan Mallon <rmallon@...il.com>
>> Cc: Mika Westerberg <mika.westerberg@....fi>
>> Cc: Mark Brown <broonie@...nel.org>
>> Cc: Grant Likely <grant.likely@...aro.org>
>> ---
>
>
>> +	err = ep93xx_spi_calc_divisors(espi, chip, t->speed_hz);
>> +	if (err) {
>> +		dev_err(&espi->pdev->dev, "failed to adjust speed\n");
>
>
> Printing out the speed it was trying to set might be useful here?

Technically I don't think this can ever happen.

The minimum and maximum possible speeds are determined during the probe.

	espi->max_rate = clk_get_rate(espi->clk) / 2;
	espi->min_rate = clk_get_rate(espi->clk) / (254 * 256);

Each transfer is validated to make sure the speed is greater than the
minimum.

		if (t->speed_hz < espi->min_rate)
			return -EINVAL;

Then the rate is clamped to the min/max rates.

	rate = clamp(rate, espi->min_rate, espi->max_rate);

The calculations for the div_csr and div_cpsr values needed to produce
the desired rate should always succeed.

Patch 7/8 actually replaces that dev_err() message with a more generic
one. In reality, even the new message, and the error checking, could
probably be removed.

Regards,
Hartley