linux-kernel - Re: [PATCH] spi: tegra: add spi driver for SLINK 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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Oct 2012 21:48:41 +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>
Subject: Re: [PATCH] spi: tegra: add spi driver for SLINK controller

On Monday 29 October 2012 08:47 PM, Stephen Warren wrote:
> On 10/26/2012 12:49 PM, Laxman Dewangan wrote:
>>>
>>> Why not just always set SLINK_FIFO_ERROR; does it have to be set in the
>>> write only if the status was previously asserted? If that is true, how
>>> do you avoid a race condition where the bit gets set in SLINK_STATUS
>>> after you read it but before you write to clear it?
>> Status gets updated together. There is no steps of updating status.
> Sorry, I don't understand this answer.

The status should be updated once by HW and so there is no race condition.
HW behavior is that if the tx or Rx error occurs, it updates the status, 
generates interrupt and still continue transfer and later on, it 
generates the ready.
In first isr, we read status, error status found and so in isr thread, 
we reset controller to stop the transfer.

So in good state, only ready bit will be set and hence writing 1 to 
clear it.
In error state, clearing error first in ISR and in isr thread resetting 
the controller to stop the controller engine.

>>
>> Is there a way to support the reset of controller. We will need this
>> functionality.
> Why do we need to reset the controller at all; can't we simply program
> all the (few) configuration registers? Are there HW bugs that hang the
> controller and require a reset or something?

HW generates error,  then interrupt and still continue transfer and 
later point of time it generates the transfer done.
We want to stop the transfer once error get detected. For this we need 
to reset controller.
I did disabling rx and tx but still controller shows as busy.

--
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/