linux-kernel - Re: [PATCH] serial: sh-sci: don't filter on DMA device, use only channel ID

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: <alpine.DEB.2.00.1109072048310.30407@axis700.grange>
Date:	Wed, 7 Sep 2011 22:01:19 +0200 (CEST)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	"Koul, Vinod" <vinod.koul@...el.com>
cc:	"Williams, Dan J" <dan.j.williams@...el.com>,
	"magnus.damm@...il.com" <magnus.damm@...il.com>,
	"lethal@...ux-sh.org" <lethal@...ux-sh.org>,
	"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"damm@...nsource.se" <damm@...nsource.se>
Subject: Re: [PATCH] serial: sh-sci: don't filter on DMA device, use only
 channel ID

On Thu, 8 Sep 2011, Koul, Vinod wrote:

> On Mon, 2011-09-05 at 17:21 +0200, Guennadi Liakhovetski wrote:
> > On Mon, 5 Sep 2011, Vinod Koul wrote:
> > 
> > > On Mon, 2011-09-05 at 17:01 +0200, Guennadi Liakhovetski wrote:
> > > > On Mon, 5 Sep 2011, Vinod Koul wrote:
> > > > 
> > > > > On Mon, 2011-09-05 at 15:48 +0200, Guennadi Liakhovetski wrote:
> > > > > > 
> > > > > > Let me try again. DMA channels on these DMA controllers are not dedicated. 
> > > > > > On one such SoC there can be several such DMA controllers of different 
> > > > > > kinds. One kind is "generic" - it can do memcpy(), besides channels can be 
> > > > > > freely configured for one of onboard peripherals: serial, mmc, etc. Some 
> > > > > > of them can also serve external DMA-capable devices. Another kind of DMA 
> > > > > > controllers, served by the same driver, can only be used with USB 
> > > > > > controllers. Now, if the MMC driver requests a DMA channel, let's say, the 
> > > > > > dmaengine core first finds the USB DMA controller. The MMC driver cannot 
> > > > > > know this. It assigns its MMC DMA configuration to the.private pointer and 
> > > > > > returns true. Next the DMA driver is entered, it checks the private 
> > > > > > pointer, sees an MMC channel request, looks at the DMA controller and 
> > > > > > sees, that it doesn't support MMC. So, .device_alloc_chan_resources() 
> > > > > > fails. When the same is attempted with a suitable DMA controller, the 
> > > > > > shdma driver recognises, that the controller can service MMC and uses the 
> > > > > > data, provided the MMC driver, to configure the DMA channel for MMC.
> > > > > Hmmm, Can't you know in filter function if the respective channel can do
> > > > > the dma for you or not? Maybe export a dma function or use platform data
> > > > > for this (wont you soc have these caps fixed), i prefer latter.
> > > > > That maybe a better approach. 
> > > > 
> > > > How? On a system you can have 3 suitable DMA controllers and 2 unsuitable. 
> > > > Do you want to pass a list of 3 suitable DMA controllers to each 
> > > > peripheral driver?...
> > > The peripheral driver (client driver in slave-dma terminology) should
> > > already know which dmac it wants. (base on information in platform data
> > > etc) That is why the filter function is provided. Please use it properly
> > > Other soc have similar capabilities and they can filter properly so why
> > > cant you..?
> > 
> > Sorry, I have been thinking about these possibilities, but I really didn't 
> > find any similar case in existing drivers. Normally either channels are 
> > fixed - only one channel can be used for a specific peripheral, or any at 
> > all, or there is only one suitable controller. I only see two 
> > possibilities here, and they both look ugly to me:
> > 
> > (1) pass a list of suitable DMA controllers to slave-dma drivers, there in 
> > the filter you'd have to scan that list.
> > (2) select only one out of several suitable DMA controllers in the 
> > platform configuration - that needlessly reduces flexibility.
> > 
> > Whereas on the contrary, the DMA controller itself can perfectly look 
> > through the list of supported peripherals on the current controller and 
> > decide, whether the requested one is among them or not.
> Then why not have shdma_filter_func() exported and then used by all your
> clients for proper filtering.

You're seriously suggesting to export and use an additional shdma private 
function, bypassing the dmaengine API?... That really doesn't sound like a 
good idea to me, sorry. How about using .device_control(DMA_SLAVE_CONFIG) 
from the filter function directly to verify channel suitability?

> I cant agree to the whole point of filtering in alloc
> 
> One channel is allocated, we should _not_ do any further filtering

Sorry, I do not understand this argumentation. Filtering and resource 
allocation are parts of the channel-acquisition process, either of them 
can fail, in which case the channel remains free for future requests.

Thanks
Guennadi

> > > PS: This might well be my last post before Tue EOD PST, traveling to
> > > LPC, if you are there feel free to chat with me on this.
> > 
> > No, unfortunately, I won#t be there. Are you coming to the KS in Prague in 
> > October?
> Not decided yet...

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/