linux-kernel - RE: [PATCH 1/1] DaVinci: MMC: V4: MMC/SD controller driver for DaVinci family.

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:	Tue, 21 Apr 2009 19:44:57 +0530
From:	"Kumar, Purushotam" <purushotam@...com>
To:	David Brownell <david-b@...bell.net>
CC:	"davinci-linux-open-source@...ux.davincidsp.com" 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	Pierre Ossman <drzeus-mmc@...eus.cx>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/1] DaVinci: MMC: V4: MMC/SD controller driver for
 DaVinci family.

> >
> > This required by SD controller as suggested by IP designer. Please
> > look at SD controller spec at http://www.ti.com/litv/pdf/sprue30d .
> > Please check section 3.2/3.6 and point no 11/10 in the controller spec.
> 
> In this case the spec says in a note in 2.7.2 that priming
> the fifo is needed for "write transactions" ... since no
> "fifo became empty" IRQ is generated.  It does not limit it
> to the WRITE_BLOCK and WRITE_MULTIPLE_BLOCK commands.
> 
> Those examples are for writing single and multiple blocks; there
> are no SDIO write operations shown, for example, or password
> passing operations.  Those would also suffer from the lack of
> a "fifo became empty" IRQ.
> 

It seems you are right that FIFO is required to be primed before any write transaction. 

> > It does not talk about priming by 32 bytes for any other command.
> Said diffferently, *every* PIO write transaction shown primes
> the fifo ... but there are no examples of non-block writes.

We need to prime the FIFO beforehand with whatever data we intend to transfer. We looked into SDIO driver on DM6446 and observed that it requires priming.


> > This restriction is from SD controller.
> 
> Could you confirm that interpretation with the folk who have
> provided that silicon block?
> 
> If your reading is correct, and it's really a restriction to
> those two commands, the documentation should change to say
> that "single and multiple block write commands" require FIFO
> priming ... not all "write transactions" as now written.

Apart from above there was a doubt for:
	if (!host->do_dma && (host->data_dir == DAVINCI_MMC_DATADIR_WRITE))
		davinci_fifo_data_trans(host, 32);
We will also remove check for CMD25 and CMD24 before priming and so it will allow priming for all commands.

Although there does seem to be a bug there ... it should never fill the
fifo with more data than is being sent.

The second parameter is rightly justified as it is the length of fifo. If
you see inside the davinci_fifo_data_trans() the FIFO is only primed based
upon the data size during that transfer. So in a way we are not filling the
fifo with more data.

We will re-submit patch tomorrow. Please let us know if you have any further concerns.
Regards,
Purushotam
--
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/