linux-kernel - Re: [PATCH v4 2/3] dw_dmac: max_mem_width limits value for SRC/DST_TR

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] [day] [month] [year] [list]

Date:	Tue, 4 Sep 2012 09:38:47 +0300
From:	Andy Shevchenko <andy.shevchenko@...il.com>
To:	Hein Tibosch <hein_tibosch@...oo.es>
Cc:	Viresh Kumar <viresh.kumar@...aro.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Hans-Christian Egtvedt <egtvedt@...fundet.no>,
	Arnd Bergmann <arnd.bergmann@...aro.org>,
	spear-devel <spear-devel@...t.st.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"ludovic.desroches" <ludovic.desroches@...el.com>,
	Havard Skinnemoen <havard@...nnemoen.net>,
	Nicolas Ferre <nicolas.ferre@...el.com>
Subject: Re: [PATCH v4 2/3] dw_dmac: max_mem_width limits value for
 SRC/DST_TR_WID register

On Mon, Sep 3, 2012 at 4:06 PM, Hein Tibosch <hein_tibosch@...oo.es> wrote:
> 1. The first draft of the patches worked with the max allowable value for
> the SRC_WIDTH & DST_WIDTH fields: 0,1,2,3... Viresh thought it was not
> transparent enough, he suggested to make it simpler with a binary choice of
> 32- or 64-bits, defaulting to 64-bits.
> But Andy is right: there are versions supporting 256-bit wide memory transfers.
> I'd also go for this previous solution and use: "min(max_mem_width, width)"
>
> The only problem is that one doesn't want to change arch code for other
> platforms (ARM) so I proposed: let "max_mem_width=0" mean: leave it up to
> the driver, for now 3 : 64-bits.
Sounds better to support all possible options without any additional
layer of conversion, isn't it?

> 2. In another version I made 'max_mem_width' a member of 'dw_dma_platform_data'
> because I also see it as 'constant' for all dma slaves.
> But the dw_dmac controller can be used for multiple (types of) memories
> and in that case, maybe a limit per slave might be desirable? My knowledge
> of DMA-hardware doesn't reach far enough to judge that.
As Viresh told early that will not cover memory-to-memory transfers.

> I'd say: for now let it become a member of 'dw_dma_platform_data' because
> it's the max value of a register field.
I support such choice.

> 3. Felipe Balbi: why don't we ask the DW IP for its maximum allowed value of
> SRC_WIDTH & DST_WIDTH (on the memory side)? Sure, would be elegant!
It's not so simple, unfortunately.

> Alternatively, we could do a small dma-memcpy-test at start-up and try all
> values from 5 (or 7) down to 2. The first value that works correctly will be
> used as the maximum.
Oh, it might be good idea to get this value in case neither IP nor
platform data provides it.
I'm pretty sure the platform device driver has to know this beforehand.

-- 
With Best Regards,
Andy Shevchenko
--
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/