From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752428AbbHTG3i (ORCPT ); Thu, 20 Aug 2015 02:29:38 -0400 Received: from mga09.intel.com ([134.134.136.24]:57499 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752203AbbHTG3f (ORCPT ); Thu, 20 Aug 2015 02:29:35 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,713,1432623600"; d="scan'208";a="787307830" Date: Thu, 20 Aug 2015 12:01:36 +0530 From: Vinod Koul To: Geert Uytterhoeven Cc: Dan Williams , Arnd Bergmann , Tony Lindgren , Matt Porter , dmaengine@vger.kernel.org, linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] dmaengine: Stricter legacy checking in dma_request_slave_channel_compat() Message-ID: <20150820063136.GD13546@localhost> References: <1439816935-27554-1-git-send-email-geert+renesas@glider.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1439816935-27554-1-git-send-email-geert+renesas@glider.be> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 17, 2015 at 03:08:55PM +0200, Geert Uytterhoeven wrote: > dma_request_slave_channel_compat() is meant for drivers that support > both DT and legacy platform device based probing: if DT channel DMA > setup fails, it will fall back to platform data based DMA channel setup, > using hardcoded DMA channel IDs and a filter function. > > However, if the DTS doesn't provide a "dmas" property for the device, > the fallback is also used. If the legacy filter function is not > hardcoded in the DMA slave driver, but comes from platform data, it will > be NULL. Then dma_request_slave_channel_compat() will succeed > incorrectly, and return a DMA channel, as a NULL legacy filter function > actually means "all channels are OK", not "do not match". > > Later, when trying to use that DMA channel, it will fail with: > > rcar-dmac e6700000.dma-controller: rcar_dmac_prep_slave_sg: bad parameter: len=1, id=-22 > > To fix this, ensure that both the filter function and the DMA channel ID > are not NULL before using the legacy fallback. > > Note that some DMA slave drivers can handle this failure, and will fall > back to PIO. > > See also commit 056f6c87028544de ("dmaengine: shdma: Make dummy > shdma_chan_filter() always return false"), which fixed the same issue > for the case where shdma_chan_filter() is hardcoded in a DMA slave > driver. Applied, thanks -- ~Vinod