Subject: [PATCH 11/15] [media] Deprecate v4l2_mbus_pixelcode

From: [email-masked] (Boris Brezillon)
Date: Wed, 5 Nov 2014 16:30:49 +0100

On Wed, 05 Nov 2014 16:19:56 +0100
Hans Verkuil <[email-masked]> wrote:

> 
> 
> On 11/05/14 16:15, Boris Brezillon wrote:
> > On Wed, 5 Nov 2014 17:08:15 +0200
> > Sakari Ailus <[email-masked]> 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 <[email-masked]>
> >>> ---
> >>>  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