From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Ossman Subject: Re: [patch 5/5] [RFC] Add MMC Password Protection (lock/unlock) support V7: mmc_omap_dma.diff Date: Fri, 01 Dec 2006 22:20:19 +0100 Message-ID: <45709C93.7050709@drzeus.cx> References: <4564648B.2020005@indt.org.br> <456805F3.1020407@drzeus.cx> <456AEB70.2000100@indt.org.br> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <456AEB70.2000100@indt.org.br> Sender: linux-kernel-owner@vger.kernel.org To: Anderson Briglia Cc: "Linux-omap-open-source@linux.omap.com" , Russell King , Tony Lindgren , "Aguiar Carlos (EXT-INdT/Manaus)" , ext David Brownell , "Lizardo Anderson (EXT-INdT/Manaus)" , linux-kernel@vger.kernel.org List-Id: linux-omap@vger.kernel.org Anderson Briglia wrote: > > This patch is needed only for lock/unlock commands. So, it's necessary to > make MMC omap works when using that feature. It's not a generic patch. > But I can take off this one from the series and send after (if) the > series > is integrated. > The patches are marked "[RFC]" which I interpret as that I shouldn't merge it. Is this incorrect? > > frame depends on data->blksz. When we were using data->blksz_bits > everything was > ok because we always had a multiple of 16 bits (2 bytes). Once a pwd > can has a size > not multiple of 2, the value must be rounded. > According to MMC OMAP Technical Reference Manual, because of each DMA > transfer is of > equal size, it is necessary to have the block size of the transfer be > a multiple of > the DMA write access size (which is 2 bytes). > This sounds very generic and not something that is specific to the password command. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org