<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/include/linux/mmc/card.h, branch v2.6.16</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>[MMC] Fix missing ','</title>
<updated>2006-01-04T12:40:39+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk@dyn-67.arm.linux.org.uk</email>
</author>
<published>2006-01-04T12:40:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ce11a161c11868f268964274edc7a26a3e063e08'/>
<id>ce11a161c11868f268964274edc7a26a3e063e08</id>
<content type='text'>
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[MMC] Improve MMC card block size selection</title>
<updated>2006-01-03T22:38:44+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk@dyn-67.arm.linux.org.uk</email>
</author>
<published>2006-01-03T22:38:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a6f6c96b65d7f65a7a7bf5cbe874eda182a6b2cc'/>
<id>a6f6c96b65d7f65a7a7bf5cbe874eda182a6b2cc</id>
<content type='text'>
Select a block size for IO based on the read and write block size
combinations, and whether the card supports partial block reads
and/or partial block writes.

If we are able to satisfy block reads but not block writes, mark
the device read only.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Select a block size for IO based on the read and write block size
combinations, and whether the card supports partial block reads
and/or partial block writes.

If we are able to satisfy block reads but not block writes, mark
the device read only.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] sd: SCR register</title>
<updated>2005-09-07T23:57:50+00:00</updated>
<author>
<name>Pierre Ossman</name>
<email>drzeus-list@drzeus.cx</email>
</author>
<published>2005-09-06T22:18:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b57c43ad81602589afca3948a5a7121e40026e17'/>
<id>b57c43ad81602589afca3948a5a7121e40026e17</id>
<content type='text'>
Read the SD specific SCR register from the card.

Signed-off-by: Pierre Ossman &lt;drzeus@drzeus.cx&gt;
Cc: Russell King &lt;rmk@arm.linux.org.uk&gt;
Cc: David Brownell &lt;david-b@pacbell.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Read the SD specific SCR register from the card.

Signed-off-by: Pierre Ossman &lt;drzeus@drzeus.cx&gt;
Cc: Russell King &lt;rmk@arm.linux.org.uk&gt;
Cc: David Brownell &lt;david-b@pacbell.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] sd: read-only switch</title>
<updated>2005-09-07T23:57:50+00:00</updated>
<author>
<name>Pierre Ossman</name>
<email>drzeus-list@drzeus.cx</email>
</author>
<published>2005-09-06T22:18:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a00fc09029f02ca833cf90e5d5625f08c4ac4f51'/>
<id>a00fc09029f02ca833cf90e5d5625f08c4ac4f51</id>
<content type='text'>
Support for the read-only switch on SD cards which must be enforced by the
host.

Signed-off-by: Pierre Ossman &lt;drzeus@drzeus.cx&gt;
Cc: Russell King &lt;rmk@arm.linux.org.uk&gt;
Cc: David Brownell &lt;david-b@pacbell.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Support for the read-only switch on SD cards which must be enforced by the
host.

Signed-off-by: Pierre Ossman &lt;drzeus@drzeus.cx&gt;
Cc: Russell King &lt;rmk@arm.linux.org.uk&gt;
Cc: David Brownell &lt;david-b@pacbell.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PATCH] sd: initialize SD cards</title>
<updated>2005-09-07T23:57:50+00:00</updated>
<author>
<name>Pierre Ossman</name>
<email>drzeus-list@drzeus.cx</email>
</author>
<published>2005-09-06T22:18:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=335eadf2ef6a1122a720aea98e758e5d431da87d'/>
<id>335eadf2ef6a1122a720aea98e758e5d431da87d</id>
<content type='text'>
Support for the Secure Digital protocol in the MMC layer.

A summary of the legal issues surrounding SD cards, as understood by yours
truly:

Members of the Secure Digital Association, hereafter SDA, are required to sign
a NDA[1] before given access to any specifications.  It has been speculated
that including an SD implementation would forbid these members to redistribute
Linux.  This is the basic problem with SD support so it is unclear if it even
is a problem since it has no effect on those of us that aren't members.

The SDA doesn't seem to enforce these rules though since the patches included
here are based on documentation made public by some of the members.  The most
complete specs[2] are actually released by Sandisk, one of the founding
companies of the SDA.

Because of this the NDA is considered a non-issue by most involved in the
discussions concerning these patches.  It might be that the SDA is only
interested in protecting the so called "secure" bits of SD, which so far
hasn't been found in any public spec.  (The card is split into two sections,
one "normal" and one "secure" which has an access scheme similar to TPM:s).

(As a side note, Microsoft is working to make things easier for us since they
want to be able to include the source code for a SD driver in one of their
development kits.  HP is making sure that the new NDA will allow a Linux
implementation.  So far only the SDIO specs have been opened up[3].  More will
hopefully follow.)

 [1] http://www.sdcard.org/membership/images/ippolicy.pdf
 [2] http://www.sandisk.com/pdf/oem/ProdManualSDCardv1.9.pdf
 [3] http://www.sdcard.org/sdio/Simplified%20SDIO%20Card%20Specification.pdf

This patch contains the central parts of the SD support.  If no MMC cards are
found on a bus then the MMC layer proceeds looking for SD cards.  Helper
functions are extended to handle the special needs of SD cards.

Signed-off-by: Pierre Ossman &lt;drzeus@drzeus.cx&gt;
Cc: Russell King &lt;rmk@arm.linux.org.uk&gt;
Cc: David Brownell &lt;david-b@pacbell.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Support for the Secure Digital protocol in the MMC layer.

A summary of the legal issues surrounding SD cards, as understood by yours
truly:

Members of the Secure Digital Association, hereafter SDA, are required to sign
a NDA[1] before given access to any specifications.  It has been speculated
that including an SD implementation would forbid these members to redistribute
Linux.  This is the basic problem with SD support so it is unclear if it even
is a problem since it has no effect on those of us that aren't members.

The SDA doesn't seem to enforce these rules though since the patches included
here are based on documentation made public by some of the members.  The most
complete specs[2] are actually released by Sandisk, one of the founding
companies of the SDA.

Because of this the NDA is considered a non-issue by most involved in the
discussions concerning these patches.  It might be that the SDA is only
interested in protecting the so called "secure" bits of SD, which so far
hasn't been found in any public spec.  (The card is split into two sections,
one "normal" and one "secure" which has an access scheme similar to TPM:s).

(As a side note, Microsoft is working to make things easier for us since they
want to be able to include the source code for a SD driver in one of their
development kits.  HP is making sure that the new NDA will allow a Linux
implementation.  So far only the SDIO specs have been opened up[3].  More will
hopefully follow.)

 [1] http://www.sdcard.org/membership/images/ippolicy.pdf
 [2] http://www.sandisk.com/pdf/oem/ProdManualSDCardv1.9.pdf
 [3] http://www.sdcard.org/sdio/Simplified%20SDIO%20Card%20Specification.pdf

This patch contains the central parts of the SD support.  If no MMC cards are
found on a bus then the MMC layer proceeds looking for SD cards.  Helper
functions are extended to handle the special needs of SD cards.

Signed-off-by: Pierre Ossman &lt;drzeus@drzeus.cx&gt;
Cc: Russell King &lt;rmk@arm.linux.org.uk&gt;
Cc: David Brownell &lt;david-b@pacbell.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Linux-2.6.12-rc2</title>
<updated>2005-04-16T22:20:36+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@ppc970.osdl.org</email>
</author>
<published>2005-04-16T22:20:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2'/>
<id>1da177e4c3f41524e886b7f1b8a0c1fc7321cac2</id>
<content type='text'>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</pre>
</div>
</content>
</entry>
</feed>
