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:	Thu, 19 Apr 2007 19:34:46 +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,

>I don't think I've seen that patch. And now we have the work by Philip and
> myself which adds support for both MMC 4.0 and 4.2. The only missing piece is
> 8-bit data and I'm not that interested in adding it until we have a driver that
> can use it.
Here is a link to that patch.

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3489/1

The bus test procedure from this patch can be adopted to the MMCv4
support in the MMC core with small changes to do bus testing procedure
only if the host sets the capability to support 8-bit. That way we
dont break the legacy code. What do you think?

On 4/18/07, Pierre Ossman <drzeus@...eus.cx> wrote:
> Madhusudhan c wrote:
> >
> > 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.
> >
>
> I don't think I've seen that patch. And now we have the work by Philip and
> myself which adds support for both MMC 4.0 and 4.2. The only missing piece is
> 8-bit data and I'm not that interested in adding it until we have a driver that
> can use it.
>
> > 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?
>
> Kindof. The controller drivers should indeed just handle the controller and
> leave the protocol stuff to the mmc core. The problem is that this bus testing
> stuff breaks the previous standards. Sending invalid CRC was not previously a
> supported operation, so many controllers just toss the data when that happens.
> And since the bus testing is specified as a test, not a required part of the
> wide bus song and dance, we've decided to leave it out.
>
> 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