Here are the patches for Secure Digital support that I've been sitting
on for a while. I tried to get some feedback on inclusion of this
previously but since I didn't get any I'll just submit the thing.
It was originally diffed against 2.6.10 but it applies to 2.6.11 just
fine (only minor fuzz).
Change summary:
* Detects if connected card is SD or MMC. Marks host as in SD mode if SD
is detected (since SD isn't a bus system).
* Reads extra registers from SD cards (SCR) and parses CSD differently
depending on SD/MMC mode.
* Support for 4-bit mode. This has been design to be fairly isolated
from the SD bit so that it can (hopefully) be reused with MMC.
* New callback added for reading the read-only switch on SD cards.
Changed files:
mmc.c : SD detection and register parsing.
mmc_block.c : Checks read-only flag for cards (not SD-specific).
mmc_sysfs.c : Exposes SCR register.
card.h : Added flags to determine card type, RO and new register.
host.h : Added flags for bus width, RO test and mode (SD/MMC).
mmc.h : Added R6 define and new defines.
protocol.h : Added needed SD commands.
This patch is backwards compatible and only needs updated drivers to
take advantage of 4-bit bus and reading the RO switch (unmodified
drivers will default to 1-bit bus and write enable).
There might be new bugs that surface with this though. With my own
drivers I discovered that very small transfers (< 16 bytes) always
failed. Testing is needed but I do not have access to do it myself. MMC
should not break with this since MMC is detected before SD.
Rgds
Pierre
Hi!
> Here are the patches for Secure Digital support that I've been
> sitting on for a while. I tried to get some feedback on inclusion of
> this previously but since I didn't get any I'll just submit the thing.
> It was originally diffed against 2.6.10 but it applies to 2.6.11 just
> fine (only minor fuzz).
This is great! Hopefully it will mean no-more-binary-only-modules-on-zaurus...
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Hi Pierre,
> Here are the patches for Secure Digital support that I've been sitting
> on for a while. I tried to get some feedback on inclusion of this
> previously but since I didn't get any I'll just submit the thing.
> It was originally diffed against 2.6.10 but it applies to 2.6.11 just
> fine (only minor fuzz).
lately I got a request for the support of a Bluetooth SD card. These are
using SDIO and I think at the moment only memory cards are handled. Do
you have any plans for SDIO support?
Regards
Marcel
Marcel Holtmann wrote:
>Hi Pierre,
>
>
>
>>Here are the patches for Secure Digital support that I've been sitting
>>on for a while. I tried to get some feedback on inclusion of this
>>previously but since I didn't get any I'll just submit the thing.
>>It was originally diffed against 2.6.10 but it applies to 2.6.11 just
>>fine (only minor fuzz).
>>
>>
>
>lately I got a request for the support of a Bluetooth SD card. These are
>using SDIO and I think at the moment only memory cards are handled. Do
>you have any plans for SDIO support?
>
>
>
I would if I had some hardware to play with *hint* *hint* ;)
The SDIO spec is publically available on the SD card associations web
page so it shouldn't be too difficult to get some basic support. But I
can't do much as long as I don't have any hardware to test it with. I
might also need specs for the card itself. I haven't looked too much at
SDIO at the moment.
Rgds
Pierre
Hi Pierre,
> >lately I got a request for the support of a Bluetooth SD card. These are
> >using SDIO and I think at the moment only memory cards are handled. Do
> >you have any plans for SDIO support?
>
> I would if I had some hardware to play with *hint* *hint* ;)
I don't have one of these cards either :(
> The SDIO spec is publically available on the SD card associations web
> page so it shouldn't be too difficult to get some basic support. But I
> can't do much as long as I don't have any hardware to test it with. I
> might also need specs for the card itself. I haven't looked too much at
> SDIO at the moment.
The Bluetooth HCI transport for SDIO is also available and I think most
SD card manufactures are using it.
So what we need is a hardware sponsor. Any volunteers?
Regards
Marcel
Pierre Ossman wrote:
> I would if I had some hardware to play with *hint* *hint* ;)
Same here. I have some basic chipset docs.
On Thu, Mar 03, 2005 at 01:22:56PM +0100, Pierre Ossman wrote:
> Here are the patches for Secure Digital support that I've been sitting
> on for a while. I tried to get some feedback on inclusion of this
> previously but since I didn't get any I'll just submit the thing.
> It was originally diffed against 2.6.10 but it applies to 2.6.11 just
> fine (only minor fuzz).
Can we please come to a consensus about GEN_FL_REMOVABLE. After
talking to other kernel developers, particularly in the block
interface area, I am convinced that it is fundamentally incorrect
to set this flag for MMC/SD devices.
Unfortunately, it appears that you're not convinced. This needs
resolving since it is an interface issue.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Russell King wrote:
>On Thu, Mar 03, 2005 at 01:22:56PM +0100, Pierre Ossman wrote:
>
>
>>Here are the patches for Secure Digital support that I've been sitting
>>on for a while. I tried to get some feedback on inclusion of this
>>previously but since I didn't get any I'll just submit the thing.
>>It was originally diffed against 2.6.10 but it applies to 2.6.11 just
>>fine (only minor fuzz).
>>
>>
>
>Can we please come to a consensus about GEN_FL_REMOVABLE. After
>talking to other kernel developers, particularly in the block
>interface area, I am convinced that it is fundamentally incorrect
>to set this flag for MMC/SD devices.
>
>Unfortunately, it appears that you're not convinced. This needs
>resolving since it is an interface issue.
>
>
>
Oh, sorry. That part wasn't supposed to be included in there.
As I haven't found any applications depending on any specific behaviour
then I'm quite content with your behaviour :)
I can make a new patch or you can just undo that line once you've
applied the current one.
Rgds
Pierre
On Sat, Mar 05, 2005 at 01:23:16PM +0100, Pierre Ossman wrote:
> I can make a new patch or you can just undo that line once you've
> applied the current one.
I'd rather not just apply this patch - there's rather a lot there to
just apply on top of what's already merged.
Is there any chance you can split it up into a smaller set of changes
so it's more obvious what's going on at each stage please?
We'll also need to run this by Linus first, explaining why you believe
it's now ok to merge this. (Added Linus...)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Russell King wrote:
>On Sat, Mar 05, 2005 at 01:23:16PM +0100, Pierre Ossman wrote:
>
>
>>I can make a new patch or you can just undo that line once you've
>>applied the current one.
>>
>>
>
>I'd rather not just apply this patch - there's rather a lot there to
>just apply on top of what's already merged.
>
>Is there any chance you can split it up into a smaller set of changes
>so it's more obvious what's going on at each stage please?
>
>
Sure. I'll try to divide it into smaller pieces. It will result in some
patches that are just there to prepare for the other ones though (i.e.
they don't add any functionality by themselves).
>We'll also need to run this by Linus first, explaining why you believe
>it's now ok to merge this. (Added Linus...)
>
>
>
First of, I can't really back up the claim that it isn't ok. The SDA has
a paragraph about non-disclosure in their "IP Policy"
(http://www.sdcard.org/membership/images/ippolicy.pdf) but it also
states that exceptions can be granted.
Against this stands the new information that the SDA is changing its
policy and making the specs public. This information comes from some of
the guys at HP research and hasn't been confirmed by any public
statement from SDA. The SDA have, however, already released the SDIO
specs. Presumably as part of this new policy.
It was also pointed out in the previous thread by myself, Alan Cox and
Ian Molton that SD specs have been publically available from different
companies for quite some time. As such it is difficult for anyone to
claim that these are secret and can be regulated by a NDA. The only part
that hasn't been found in the wild is the spec for the 'secure' parts of
the cards. But that also means that it isn't included in this patch so
it shouldn't pose a problem.
As always, IANAL so I can't give any definite answer. But from my point
of view they would have a very weak case if they tried to claim that the
information in this patch is a trade secret.
Rgds
Pierre
Pierre Ossman:
> First of, I can't really back up the claim that it isn't ok. The SDA has a
> paragraph about non-disclosure in their "IP Policy"
> (http://www.sdcard.org/membership/images/ippolicy.pdf) but it also states
> that exceptions can be granted.
That IP policy covers their members and has no bearing on us as we have no
agreements with them.
The code is "our" own so it isn't covered by any IP or copyright
restrictions other than the GPL.
There aren't any patents relating to SD cards.
The simple sequences we use have been gleaned from various public documents
(intel's website, SD card manufacturer data sheets, etc.) so nobody can
claim we're using anything secret.
I therefore can't see a problem with including the code.
Richard
As promised, here is the patch broken down into smaller pieces. The
patch is now divided into six distinct parts:
* Protocol definitions.
* SD card initialisation.
* Reading read-only switch.
* Getting SCR register.
* Exposing SCR register through sysfs.
* Wide (4-bit) bus support.
Rgds
Pierre
Protocol definitions.
The basic commands needed for the later patches. The R1_APP_CMD seems to
be misdefined in protocol.h so this patch changes it.
SD card initialisation.
This patch contains the central parts of the SD support.
The system first tries to detect MMC cards, and if none are found then
it procedes to look for an SD card. This is incorrect acording to SD
specifications but I find it odd that MMC is supposed to cope with SD
commands and not the other way around (since MMC is the older of the
two). This behaviour is the one Windows uses and has posed no problems
with any cards tested so far.
It provides flags for the card and host to mark them as SD. The host
needs to be marked because the MMC layer needs to determine if it should
send MMC or SD commands at points where no specific card is involved.
A new helper function called mmc_wait_for_app_cmd() is added to handle
the APP commands which are used frequently with SD.
CID and CSD parsing are extended to handle SD formats.
Read-only support.
This patch adds a new callback for the drivers to facilitate reading the
SD card read-only switch. If the callback is not provided then a warning
will be printed and it will default to write-enable.
The read-only switch is a host enforced read-only so the MMC block layer
has been changed to not allow rw mounts of ro cards. It also prints a
'(ro)' for read-only cards.
SCR download.
This patch downloads the SCR register from the card. Unlike the other
registers this one is transfered over the data bus. That required some
changes to other routines to allow a card to be selected after the host
was aquired.
This is one of the more error prone parts. The transfer is very small (8
bytes) and might trigger corner cases in the drivers.
SCR sysfs access.
This provides access to the SCR register via sysfs. Since the latest bk
contains some changes to the sysfs part this probably needs updating.
The patch is trivial though so it should be easy.
Wide bus support.
This adds 4-bit bus support to the MMC layer. It is designed to
(hopefully) be compatible with a future 4-bit MMC implementation. This
is done by seperating the three different instances of bus width defines:
* Protocol definition: SD_BUS_WIDTH_x
* SCR contents: SD_SCR_BUS_WIDTH_x
* Host mode: MMC_BUS_WIDTH_x
They have the same values atm but drivers should not rely on this.
MMC_BUS_WIDTH_x is not meant to be SD specific.
The MMC layer changes bus width when a card is selected. This is because
the SD spec says that a card is only required to keep a certain bus
width as long as it's selected.
Layers further up do not need to know which mode the host/card is in.
They will only see a change in speed.
I suppose a copyright notice is appropriate to indicate the origins of
the SD additions.
mmc.c is the only file with substancial changes so it should be enough
with a notice there.
On Sun, Mar 06, 2005 at 02:37:01AM +0100, Pierre Ossman wrote:
> Protocol definitions.
>
> The basic commands needed for the later patches. The R1_APP_CMD seems to
> be misdefined in protocol.h so this patch changes it.
Applied, thanks.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Pierre Ossman wrote:
> Russell King wrote:
>
>> We'll also need to run this by Linus first, explaining why you believe
>> it's now ok to merge this. (Added Linus...)
>>
>
> It was also pointed out in the previous thread by myself, Alan Cox and
> Ian Molton that SD specs have been publically available from different
> companies for quite some time. As such it is difficult for anyone to
> claim that these are secret and can be regulated by a NDA. The only part
> that hasn't been found in the wild is the spec for the 'secure' parts of
> the cards. But that also means that it isn't included in this patch so
> it shouldn't pose a problem.
>
This issue doesn't seem to reach any kind of resolution so I figured I'd
take a poke at the people responsible. :)
Just to back up the claim that the specs are in the open here are some
links:
http://www.google.com/search?hl=en&q=%22Secure+Digital+Card%22+%22Product+Manual%22+site%3Asandisk.com&btnG=Google+Search
Which gives you several PDF:s with enough information to implement a SD
host. The one I've been using is:
http://www.sandisk.com/download/Product%20Manuals/Product%20ManualSDCardv1.7.pdf
Rgds
Pierre