linux-kernel - Re: [PATCH 3/4] atmel-mci: support multiple mmc slots

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, 25 Sep 2008 15:51:49 +0200
From:	Haavard Skinnemoen <haavard.skinnemoen@...el.com>
To:	Pierre Ossman <drzeus-list@...eus.cx>
Cc:	kernel@...32linux.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] atmel-mci: support multiple mmc slots

Pierre Ossman <drzeus-list@...eus.cx> wrote:
> On Wed, 24 Sep 2008 16:35:27 +0200
> Haavard Skinnemoen <haavard.skinnemoen@...el.com> wrote:
> 
> > 
> > On AP7000, the clock line is shared. Do I have to run the clock at the
> > minimum of the two slots' maximum rates, or does it only matter when
> > the card is being accessed?
> > 
> 
> I'd say always. I'd never dare overclock something that's powered, even
> if we're not currently communicating with it.

Ok.

> Remember to deal with the case of a powered but unclocked card. This
> will primarily happen during card init, but it could should up later as
> well if we start implementing aggressive power management.

Ok, but how _do_ I deal with that? If the clock is turned off due to
power management, it should be safe to leave it running at the same
rate. But how about initialization? Should I stall the queue until the
newly-powered card gets a clock rate?

> > > > > (This will also get a bit more painful when/if the core starts
> > > > > disabling the clock when a card is idle)
> > > > 
> > > > The atmel-mci driver already stops the clock between requests.
> > > 
> > > Then I expect a patch to remove that. Fiddling with the clock is
> > > dangerous and I've seen everything from hung cards to silently broken
> > > writes when you disable the clock too early after a request.
> > 
> > Ok. I'll see if I can fix that -- I take it you want a patch for
> > 2.6.27, then?
> > 
> 
> .28 should be fine. It's a pretty uncommon bug.

Ok, good. A change like that needs quite extensive testing.

Btw, I just noticed that other thread about pxamci clock management.
Will it cause problems if the clock stops briefly from time to time?
Currently, the controller stops the clock if the FIFO gets full/empty
during transfer -- this is configurable, but I'd much rather let the
clock stop than risk FIFO overruns/underruns...

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