Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CGME20200417025205epcas2p46d33e64f2de49041d2ca68ecc98fc83e@epcas2p4.samsung.com>
 <20200417024543.66785-1-sy0816.kang@samsung.com> <20200417083506.GB141762@kroah.com>
 <145301d6152f$6d5b6240$481226c0$@samsung.com> <20200418073719.GA2410414@kroah.com>
 <000001d616ac$4ceaf1a0$e6c0d4e0$@samsung.com>
In-Reply-To: <000001d616ac$4ceaf1a0$e6c0d4e0$@samsung.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Mon, 20 Apr 2020 13:23:11 +0200
Message-ID: <CAK8P3a37dAwH=gjUJjJE2061MD3jpqP8p+QkkZj9Ok3WcfH0dg@mail.gmail.com>
Subject: Re: [PATCH] media: v4l2-compat-ioctl32.c: copy reserved2 field in get_v4l2_buffer32
To:     Sunyoung Kang <sy0816.kang@samsung.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        Hans Verkuil <hverkuil-cisco@xs4all.nl>,
        Thomas Gleixner <tglx@linutronix.de>,
        Linux Media Mailing List <linux-media@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Apr 20, 2020 at 2:40 AM Sunyoung Kang <sy0816.kang@samsung.com> wrote:
>
> I understand what you mean.
> However, the way to transmit information about the buffer is only flags in
> v4l2_buffer
> In flags in v4l2_buffer, there is no reserved bit field that can be used for
> custom.
> Additional information about the buffer is needed to provide various
> functions required by the customers but flags is not enough. So reserved2 is
> used as an alternative.
> Can you suggest a better opinion?

If you have a driver that needs to pass additional information that is not
supported by the subsystem, this is generally either because there is something
wrong in the driver, or because there is something wrong in the subsystem.

Whichever is at fault should be fixed. If it's the subsystem, then you should
explain why it's wrong and make a suggestion for how to address it, e.g.
introducing a new ioctl command or redefining the reserved members to
be defined in the way you need.

In any case, the ioctl commands should be driver independent, so that
any hardware with the same feature as your driver can work with the
same user space.

     Arnd