On Wed, Jun 10, 2015 at 04:09:19PM +0300, Dmitry Kalinkin wrote: > On Sun, May 31, 2015 at 6:06 AM, Greg Kroah-Hartman > <gre...@linuxfoundation.org> wrote: > > 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. > >> > >> 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 > > Greg, > > I don't know how to make this happen. I could resend patches CC'ing > previous contributors to linux VME subsystem, and maybe get some > feedback that way. > > Also, there are some patches that IMO don't need any special VME > subsystem expertise, namely: > Documentation: mention vme_master_mmap() in VME API > vme: ca91cx42: return error code on DMA error > staging: vme_user: remove unused counters > staging: vme_user: remove forward declarations > staging: vme_user: remove open/release > staging: vme_user: remove buf_unalloc helper > vme: tsi148: depend on HAS_DMA for Kconfig
I've taken all of these except patches 12, 13, 14 and 16. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
