All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <deathsimple@vodafone.de>
To: Daniel Vetter <daniel@ffwll.ch>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH] dmabuf: allow exporter to define customs ioctls
Date: Wed, 9 Mar 2016 10:18:23 +0100	[thread overview]
Message-ID: <56DFEA5F.4000405@vodafone.de> (raw)
In-Reply-To: <CAKMK7uEzCdaBcOFqmTsFCxKKaXbfxvmkSqEtaotj2F5Giba1pQ@mail.gmail.com>

Am 09.03.2016 um 10:03 schrieb Daniel Vetter:
> On Wed, Mar 9, 2016 at 9:54 AM, Benjamin Gaignard
> <benjamin.gaignard@linaro.org> wrote:
>> In addition of the already existing operations allow exporter
>> to use it own custom ioctls.
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> First reaction: No way ever! More seriously, please start by
> explaining why you need this.

I was about to complain as well. Device specific IOCTLs should probably 
better defined as operation on the device which takes the DMA-Buf file 
descriptor as a parameter.

If you really need this (which I doubt) then please define a range of 
IOCTL numbers for which it should apply.

Regards,
Christian.

> -Daniel
>
>> ---
>>   drivers/dma-buf/dma-buf.c | 3 +++
>>   include/linux/dma-buf.h   | 5 +++++
>>   2 files changed, 8 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 9810d1d..6abd129 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -291,6 +291,9 @@ static long dma_buf_ioctl(struct file *file,
>>
>>                  return 0;
>>          default:
>> +               if (dmabuf->ops->ioctl)
>> +                       return dmabuf->ops->ioctl(dmabuf, cmd, arg);
>> +
>>                  return -ENOTTY;
>>          }
>>   }
>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>> index 532108e..b6f9837 100644
>> --- a/include/linux/dma-buf.h
>> +++ b/include/linux/dma-buf.h
>> @@ -70,6 +70,9 @@ struct dma_buf_attachment;
>>    * @vmap: [optional] creates a virtual mapping for the buffer into kernel
>>    *       address space. Same restrictions as for vmap and friends apply.
>>    * @vunmap: [optional] unmaps a vmap from the buffer
>> + * @ioctl: [optional] ioctls supported by the exporter.
>> + *        It is up to the exporter to do the proper copy_{from/to}_user
>> + *        calls. Should return -EINVAL in case of error.
>>    */
>>   struct dma_buf_ops {
>>          int (*attach)(struct dma_buf *, struct device *,
>> @@ -104,6 +107,8 @@ struct dma_buf_ops {
>>
>>          void *(*vmap)(struct dma_buf *);
>>          void (*vunmap)(struct dma_buf *, void *vaddr);
>> +
>> +       int (*ioctl)(struct dma_buf *, unsigned int cmd, unsigned long arg);
>>   };
>>
>>   /**
>> --
>> 1.9.1
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <deathsimple@vodafone.de>
To: Daniel Vetter <daniel@ffwll.ch>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH] dmabuf: allow exporter to define customs ioctls
Date: Wed, 9 Mar 2016 10:18:23 +0100	[thread overview]
Message-ID: <56DFEA5F.4000405@vodafone.de> (raw)
In-Reply-To: <CAKMK7uEzCdaBcOFqmTsFCxKKaXbfxvmkSqEtaotj2F5Giba1pQ@mail.gmail.com>

Am 09.03.2016 um 10:03 schrieb Daniel Vetter:
> On Wed, Mar 9, 2016 at 9:54 AM, Benjamin Gaignard
> <benjamin.gaignard@linaro.org> wrote:
>> In addition of the already existing operations allow exporter
>> to use it own custom ioctls.
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> First reaction: No way ever! More seriously, please start by
> explaining why you need this.

I was about to complain as well. Device specific IOCTLs should probably 
better defined as operation on the device which takes the DMA-Buf file 
descriptor as a parameter.

If you really need this (which I doubt) then please define a range of 
IOCTL numbers for which it should apply.

Regards,
Christian.

> -Daniel
>
>> ---
>>   drivers/dma-buf/dma-buf.c | 3 +++
>>   include/linux/dma-buf.h   | 5 +++++
>>   2 files changed, 8 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 9810d1d..6abd129 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -291,6 +291,9 @@ static long dma_buf_ioctl(struct file *file,
>>
>>                  return 0;
>>          default:
>> +               if (dmabuf->ops->ioctl)
>> +                       return dmabuf->ops->ioctl(dmabuf, cmd, arg);
>> +
>>                  return -ENOTTY;
>>          }
>>   }
>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>> index 532108e..b6f9837 100644
>> --- a/include/linux/dma-buf.h
>> +++ b/include/linux/dma-buf.h
>> @@ -70,6 +70,9 @@ struct dma_buf_attachment;
>>    * @vmap: [optional] creates a virtual mapping for the buffer into kernel
>>    *       address space. Same restrictions as for vmap and friends apply.
>>    * @vunmap: [optional] unmaps a vmap from the buffer
>> + * @ioctl: [optional] ioctls supported by the exporter.
>> + *        It is up to the exporter to do the proper copy_{from/to}_user
>> + *        calls. Should return -EINVAL in case of error.
>>    */
>>   struct dma_buf_ops {
>>          int (*attach)(struct dma_buf *, struct device *,
>> @@ -104,6 +107,8 @@ struct dma_buf_ops {
>>
>>          void *(*vmap)(struct dma_buf *);
>>          void (*vunmap)(struct dma_buf *, void *vaddr);
>> +
>> +       int (*ioctl)(struct dma_buf *, unsigned int cmd, unsigned long arg);
>>   };
>>
>>   /**
>> --
>> 1.9.1
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>


  reply	other threads:[~2016-03-09  9:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-09  8:54 [PATCH] dmabuf: allow exporter to define customs ioctls Benjamin Gaignard
2016-03-09  8:54 ` Benjamin Gaignard
2016-03-09  9:03 ` Daniel Vetter
2016-03-09  9:03   ` Daniel Vetter
2016-03-09  9:18   ` Christian König [this message]
2016-03-09  9:18     ` Christian König
2016-03-09  9:40     ` Benjamin Gaignard
2016-03-09 10:08       ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56DFEA5F.4000405@vodafone.de \
    --to=deathsimple@vodafone.de \
    --cc=benjamin.gaignard@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.