Messages in this thread | | | From | "Sunyoung Kang" <> | Subject | RE: [PATCH] media: v4l2-compat-ioctl32.c: copy reserved2 field in get_v4l2_buffer32 | Date | Tue, 21 Apr 2020 12:33:42 +0900 |
| |
Thank you for your detailed guide. And I'll look into how to handle the additional information.
Thanks Sunyoung
> -----Original Message----- > From: Arnd Bergmann <arnd@arndb.de> > Sent: Monday, April 20, 2020 8:23 PM > 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 > Subject: Re: [PATCH] media: v4l2-compat-ioctl32.c: copy reserved2 field in > get_v4l2_buffer32 > > 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
| |