linux-kernel - Re: [PATCH 2/2] mmc: Test bus-width for old MMC devices

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: <D8F224E6-5973-4CCB-97BC-0CE6102B4F6F@marvell.com>
Date:	Sun, 5 Dec 2010 17:53:49 -0800
From:	Philip Rakity <prakity@...vell.com>
To:	Chris Ball <cjb@...top.org>
CC:	Takashi Iwai <tiwai@...e.de>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Aries Lee <arieslee@...cron.com>
Subject: Re: [PATCH 2/2] mmc: Test bus-width for old MMC devices


Chris,

One other difference I have been told between the patches but NOT verified is

a) Takasi code was not tested with Dual Data Rate

b) Performance is not an issue since we are dealing with uSeconds and the code is called once
when mmc is detected.  

c)  I will adapt my code to what Takahi did over the next few days and post changes to the CAP

d) The work was independent and done at the same time !! (amazing)


On Dec 5, 2010, at 10:40 AM, Chris Ball wrote:

> Hi Takashi, Philip,
> 
> On Sun, Dec 05, 2010 at 11:50:40AM +0100, Takashi Iwai wrote:
>>> I'm planning on taking Takashi's since it looks a little cleaner; Philip,
>>> please could you take a look at Takashi's patch and add anything you
>>> think should be present from your own patch as a new incremental patch?
>> 
>> One missing thing in my (originally Aries') patch is the quirk bit to
>> enable/disable the bus-width test.  In Philip's latest patch, the
>> default is off.
>> 
>> I'm also not sure whether this bus-width test should be enabled as
>> default.  I guess it's better for performance, so I'd vote for turning
>> on as default.  But, having a quirk for turning off would be safer for
>> working around old hardware problems, of course.
> 
> Sounds good, although we're trying hard not to add new quirk bits.
> I don't see a way around doing that here, though.
> 
> We've got plenty of time until the .38 release -- let's turn it on by
> default and test during .38-rc, and we can revisit whether to leave it
> on closer to the release.  It's not as simple as "turning it on could
> cause problems so let's not do that", because we're *already* seeing
> problems from things like enabling 8-bit width on setups that don't
> support it.
> 
> Thanks!
> 
> -- 
> Chris Ball   <cjb@...top.org>   <http://printf.net/>
> One Laptop Per Child

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