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:	Fri, 17 Apr 2009 12:38:14 -0700
From:	David Brownell <david-b@...bell.net>
To:	"Kumar, Purushotam" <purushotam@...com>
Cc:	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.

On Friday 17 April 2009, Kumar, Purushotam wrote:
> 
> > I'm still not following the requirements here. Why would the hardware
> > only need to have the FIFO primed for those two commands and not every
> > kind of write?
> 
> 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.

Those are in Chapter 3, "Procedures for Common Operations" ...
that is, examples.  Examples, as a rule, are there just to
elaborate ("unpack") the more detailed text, not substitute
for clear specification.  (And TI is generally pretty good
about providing sane documentation, thank you!  Fewer problems
than with "some" vendors.)

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

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

- Dave

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