linux-kernel - Re: [PATCH] spi: tegra: add spi driver for sflash controller

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] [day] [month] [year] [list]

Message-ID: <50A29489.5090606@nvidia.com>
Date:	Wed, 14 Nov 2012 00:12:17 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	"broonie@...nsource.wolfsonmicro.com" 
	<broonie@...nsource.wolfsonmicro.com>,
	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"spi-devel-general@...ts.sourceforge.net" 
	<spi-devel-general@...ts.sourceforge.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Stephen Warren <swarren@...dia.com>
Subject: Re: [PATCH] spi: tegra: add spi driver for sflash controller

On Tuesday 13 November 2012 10:55 PM, Stephen Warren wrote:
> On 11/12/2012 10:00 PM, Laxman Dewangan wrote:
>
>> +static int tegra_sflash_resume(struct device *dev)
>> +{
>> +	struct spi_master *master = dev_get_drvdata(dev);
>> +	struct tegra_sflash_data *tsd = spi_master_get_devdata(master);
>> +	int ret;
>> +
>> +	ret = pm_runtime_get_sync(dev);
>> +	if (ret<  0) {
>> +		dev_err(dev, "pm runtime failed, e = %d\n", ret);
>> +		return ret;
>> +	}
>> +	tegra_sflash_writel(tsd, tsd->command_reg, SPI_COMMAND);
>> +	pm_runtime_put(dev);
> Can we avoid this whole function simply by programming SPI_COMMAND at
> the start of each transaction? That seems simpler. I assume that
> shouldn't e.g. leave any chip-selects in some bad state, or at least if
> it does, that shouldn't be a problem, because before the driver probes()
> at kernel boot, SPI_COMMAND won't have been programmed either.
>
> Aside from that,

I am not sure about the side effect of moving this to transfer but I can 
suspect:
When client driver is active, it need the proper state of CS. If we move 
this to transfer then probbaly CS is not in proper state until client 
calls the transfer function and this is not correct. The CS should be 
inactive state for all devices in non-transfer states.

> Acked-by: Stephen Warren<swarren@...dia.com>
> Tested-by: Stephen Warren<swarren@...dia.com>

Thanks for testing. I will respin patch V2 for taking care of above 
comments.
--
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/