Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1164498 > unrolled thread

Re: [PATCHv3 00/16] vme DMA and user space driver improvements

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCHv3 00/16] vme DMA and user space driver improvements Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-06-13 02:40 +0200
    Re: [PATCHv3 00/16] vme DMA and user space driver improvements Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-06-13 06:50 +0200

#1164498 — Re: [PATCHv3 00/16] vme DMA and user space driver improvements

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
> <gregkh@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1164542

On Sat, Jun 13, 2015 at 05:30:09AM +0300, Dmitry Kalinkin wrote:
> 
> > On 13 Jun 2015, at 05:24, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > 
> > On Sat, Jun 13, 2015 at 05:04:28AM +0300, Dmitry Kalinkin wrote:
> >> On Sat, Jun 13, 2015 at 3:31 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> I thought 12 was the most harmless out of the whole set. Am I wrong?
> > 
> > You added a new userspace api, that someone else is going to have to
> > maintain, that's not "harmless" at all.
> That is 16.

Oops, no, that was 8, I didn't include that either, maybe that's why 12
and others didn't apply.

Anyway, rebase on my tree and resend and we can go from there.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web