From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932316AbbEaDR3 (ORCPT ); Sat, 30 May 2015 23:17:29 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:39757 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754383AbbEaDRW (ORCPT ); Sat, 30 May 2015 23:17:22 -0400 Date: Sun, 31 May 2015 12:06:11 +0900 From: Greg Kroah-Hartman To: Dmitry Kalinkin Cc: linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org, Martyn Welch , Manohar Vanga , Igor Alekseev Subject: Re: [PATCHv3 00/16] vme DMA and user space driver improvements Message-ID: <20150531030611.GA10021@kroah.com> References: <1432814833-5320-1-git-send-email-dmitry.kalinkin@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432814833-5320-1-git-send-email-dmitry.kalinkin@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 28, 2015 at 03:06:57PM +0300, Dmitry Kalinkin wrote: > The first item in this submission documents previously introduced > vme_master_mmap() call. Following, there are three fixes for the tsi148 > driver's DMA. There was one bug that rendered it imposible to use DMA > lists with more than one item. The other was related to the place where > dma_map_single was called on the first DMA descriptor in the DMA list. The > last bug was about DMA transfer not stopping at interruption by signal, > which is a possible DoS attack vector. I also made an attempt to fix the > same issue in the ca91cx42 driver. I don't have access to this hardware to > test, so this is based only on my understanding of the datasheet (checked > ca91c042's errata as well). > > A new /sys/bus/vme/dma0 device with a new ioctl for making DMA transfers > was introduced in vme_user driver. The logic of the function is similar to > the one found in existing drivers. > > One question that I had while implementing this feature was whether we > should keep vme_dma_attr objects until vme_dma_list_exec() call. API > doesn't specify this, the existing vme bridge drivers copy all information > from attributes during vme_dma_list_add(). So for simplicity this > implementation frees vme_dma_attr's before vme_dma_list_exec() is done. > > A simple test against AVM16 board displays speeds around 45 MiB/s for > A32/D32 reads for both BLT and MBLT (with MBLT being slightly faster). > > Changes in v2 [patches 1-6, now 1-5 and 8]: > * vme_addr check for vme_user DMA > * limit on DMA operation length in vme_user > * reorder dma_op ioctl struct to omit __packed attribute > * change dma_op->write into dma_op->dir > * use vme_check_window assure DMA operation correctness > > New changes include vme_user code cleanup, a couple of ca91cx42 fixes > (again, tested for compilation only). > > I also propose a change to export some of VME subsytem related constants > to the user space. These can be useful if vme_user is to go into the kernel. > Also, email > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2012-July/029084.html > mentions that we probably can now get rid of this comment: > > /* XXX We do not want to push aspace, cycle and width > > * to userspace as they are > > */ > > v3 adresses code style problems I need an ack from the VME maintainer before I can take these... thanks, greg k-h