On Wed, 05 Nov 2014 16:19:56 +0100 Hans Verkuil <hansverk@xxxxxxxxx> wrote: > > > On 11/05/14 16:15, Boris Brezillon wrote: > > On Wed, 5 Nov 2014 17:08:15 +0200 > > Sakari Ailus <sakari.ailus@xxxxxx> wrote: > > > >> Hi Boris, > >> > >> On Tue, Nov 04, 2014 at 10:55:06AM +0100, Boris Brezillon wrote: > >>> The v4l2_mbus_pixelcode enum (or its values) should be replaced by the > >>> media_bus_format enum. > >>> Keep this enum in v4l2-mediabus.h and create a new header containing > >>> the v4l2_mbus_framefmt struct definition (which is not deprecated) so > >>> that we can add a #warning statement in v4l2-mediabus.h and hopefully > >>> encourage users to move to the new definitions. > >>> > >>> Replace inclusion of v4l2-mediabus.h with v4l2-mbus.h in all common headers > >>> and update the documentation Makefile to parse v4l2-mbus.h instead of > >>> v4l2-mediabus.h. > >>> > >>> Signed-off-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxxxxxxx> > >>> --- > >>> Documentation/DocBook/media/Makefile | 2 +- > >>> include/media/v4l2-mediabus.h | 2 +- > >>> include/uapi/linux/Kbuild | 1 + > >>> include/uapi/linux/v4l2-mbus.h | 35 +++++++++++++++++++++++++++++++++++ > >>> include/uapi/linux/v4l2-mediabus.h | 26 ++++---------------------- > >> > >> I would keep the original file name, even if the compatibility definitions > >> are there. I don't see any harm in having them around as well. > >> > > > > That's the part I was not sure about. > > The goal of this patch (and the following ones) is to deprecate > > v4l2_mbus_pixelcode enum and its values by adding a #warning when > > v4l2-mediabus.h file is included, thus encouraging people to use new > > definitions. > > Since v4l2-mediabus.h contains struct v4l2_mbus_framefmt this header remains > a legal header, so you can't use #warning here in any case. > Actually this patch moves the struct v4l2_mbus_framefmt definition into another header before adding the warning statement. Anyway, this is really a detail, and if everybody agrees that we should just leave the old definition in place, I'm fine with that. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
