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]
Message-ID: <ff1613620704180453t69585e21h5c31a4fe908d0aac@mail.gmail.com>
Date:	Wed, 18 Apr 2007 17:23:57 +0530
From:	"Madhusudhan c" <cr.madhusudhan@...il.com>
To:	"Pierre Ossman" <drzeus@...eus.cx>
Cc:	linux-kernel@...r.kernel.org, philipl@...rt.org
Subject: Re: MMCv4 support (8-bit support missing)

Hi Perre/Philip,

> Feel free to add me as cc in the future if you want me to notice your mail ;)
Sure. In fact I looked around to find your email id and did not find
it. In future I will include you in cc.

> We haven't determined it as necessary, and as Philip commented, most (if not
> all) controllers cannot properly support the test.
The MMCA spec 4.1 has the below two lines of explaination in the Bus
testing procedure section.

1. "The data pattern sent by the host may optionally include a CRC16
checksum, which is ignored by the card."
2. "The reverse data pattern sent by the card may optionally include a
CRC16 checksum, which is ignored by the host."

I faced a simillar problem as philip mentioned on our hardware. I used
to see failures on CMD19. I used to get a "Data timeout" interrupt.
After speaking to our hardware folks, we got it working. The hardware
folks suggested me to do a soft reset of the data lines upon receiving
the DTO for CMD19.Our controller has a bit in the MMC registers to
soft reset the data lines. It solved the problem. So I expect their
may be simillar stuff on other controllers as well.

Kyung-ju Hyun from samsung had submitted a patch for MMCPlus support
long back, which had the bus testing procedure implemented and it
works fine. I am able to write and read the data pattern back
successfuly with his patch. I am not sure why his patch was not
integrated into the main line kernel.

Why should we be bothered about how controllers respond at the MMC
core level. We need to just implement what specification says and
leave the controller handling part to the controller driver. Am I
correct?

Regards,
Madhusudhan


On 4/18/07, Pierre Ossman <drzeus@...eus.cx> wrote:
> Madhusudhan c wrote:
> > Hi Pierre/philip,
> >
>
> Hi Madhusudhan,
>
> Feel free to add me as cc in the future if you want me to notice your mail ;)
>
> > This is regarding the MMCv4 support that came in as part of the MMC
> > core of 2.6.20 linux kernel version.
> >
> > The high speed MMC cards can support 4-bit/8-bit transfers. The 8-bit
> > support seems to be missing from the MMCv4 support implemented by
> > Philip Langdale .
>
> As soon as hardware with specs is available we'll start hacking. :)
>
> > To support 8-bit transfers the core needs to implement "bus testing
> > procedure". This requires support for CMD19 and CMD14.
> >
> > Why is the support for bus testing procedure msiing from the MMCv4 support?
> >
>
> We haven't determined it as necessary, and as Philip commented, most (if not
> all) controllers cannot properly support the test.
>
> Rgds
> Pierre
>
>
>
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ