compat: fix firmware_class compilation for older kernels

For some reason request_firmware_nowait() is not being
mapped to backport_request_firmware_nowait() when building
compat as a standalone module for older kernels. Fix this
by manually forcing the code with the backport_ prefix.

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: backport memweight()

mcgrof@frijol ~/linux-next (git::master)$ git describe --contains 639b9e34
v3.6-rc1~41^2~73

commit 639b9e34f15e4b2c30068a4e4485586af0cdf709
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date:   Mon Jul 30 14:40:55 2012 -0700

    string: introduce memweight()

    memweight() is the function that counts the total number of bits set in
    memory area.  Unlike bitmap_weight(), memweight() takes pointer and size
    in bytes to specify a memory area which does not need to be aligned to
    long-word boundary.

    [akpm@linux-foundation.org: rename `w' to `ret']
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Cc: Anders Larsen <al@alarsen.net>
    Cc: Alasdair Kergon <agk@redhat.com>
    Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Andreas Dilger <adilger.kernel@dilger.ca>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Cc: Matthew Wilcox <matthew@wil.cx>
    Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
    Cc: Tony Luck <tony.luck@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: backport poll_requested_events() and poll_does_not_wait()

The main thing for the backport was the poll_table key and qproc
fields renames. We only enable this for kernels > 2.6.31 given that
these old fields only exist as of that kernel and this is currently
only used by video drivers which are only supported as of v3.2.

mcgrof@frijol ~/linux-next (git::master)$ git describe --contains 626cf236
v3.4-rc1~109^2~52

commit 626cf236608505d376e4799adb4f7eb00a8594af
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Fri Mar 23 15:02:27 2012 -0700

    poll: add poll_requested_events() and poll_does_not_wait() functions

    In some cases the poll() implementation in a driver has to do different
    things depending on the events the caller wants to poll for.  An example
    is when a driver needs to start a DMA engine if the caller polls for
    POLLIN, but doesn't want to do that if POLLIN is not requested but instead
    only POLLOUT or POLLPRI is requested.  This is something that can happen
    in the video4linux subsystem among others.

    Unfortunately, the current epoll/poll/select implementation doesn't
    provide that information reliably.  The poll_table_struct does have it: it
    has a key field with the event mask.  But once a poll() call matches one
    or more bits of that mask any following poll() calls are passed a NULL
    poll_table pointer.

    Also, the eventpoll implementation always left the key field at ~0 instead
    of using the requested events mask.

    This was changed in eventpoll.c so the key field now contains the actual
    events that should be polled for as set by the caller.

    The solution to the NULL poll_table pointer is to set the qproc field to
    NULL in poll_table once poll() matches the events, not the poll_table
    pointer itself.  That way drivers can obtain the mask through a new
    poll_requested_events inline.

    The poll_table_struct can still be NULL since some kernel code calls it
    internally (netfs_state_poll() in ./drivers/staging/pohmelfs/netfs.h).  In
    that case poll_requested_events() returns ~0 (i.e.  all events).

    Very rarely drivers might want to know whether poll_wait will actually
    wait.  If another earlier file descriptor in the set already matched the
    events the caller wanted to wait for, then the kernel will return from the
    select() call without waiting.  This might be useful information in order
    to avoid doing expensive work.

    A new helper function poll_does_not_wait() is added that drivers can use
    to detect this situation.  This is now used in sock_poll_wait() in
    include/net/sock.h.  This was the only place in the kernel that needed
    this information.

    Drivers should no longer access any of the poll_table internals, but use
    the poll_requested_events() and poll_does_not_wait() access functions
    instead.  In order to enforce that the poll_table fields are now prepended
    with an underscore and a comment was added warning against using them
    directly.

    This required a change in unix_dgram_poll() in unix/af_unix.c which used
    the key field to get the requested events.  It's been replaced by a call
    to poll_requested_events().

    For qproc it was especially important to change its name since the
    behavior of that field changes with this patch since this function pointer
    can now be NULL when that wasn't possible in the past.

    Any driver accessing the qproc or key fields directly will now fail to compile.

    Some notes regarding the correctness of this patch: the driver's poll()
    function is called with a 'struct poll_table_struct *wait' argument.  This
    pointer may or may not be NULL, drivers can never rely on it being one or
    the other as that depends on whether or not an earlier file descriptor in
    the select()'s fdset matched the requested events.

    There are only three things a driver can do with the wait argument:

    1) obtain the key field:

        events = wait ? wait->key : ~0;

       This will still work although it should be replaced with the new
       poll_requested_events() function (which does exactly the same).
       This will now even work better, since wait is no longer set to NULL
       unnecessarily.

    2) use the qproc callback. This could be deadly since qproc can now be
       NULL. Renaming qproc should prevent this from happening. There are no
       kernel drivers that actually access this callback directly, BTW.

    3) test whether wait == NULL to determine whether poll would return without
       waiting. This is no longer sufficient as the correct test is now
       wait == NULL || wait->_qproc == NULL.

       However, the worst that can happen here is a slight performance hit in
       the case where wait != NULL and wait->_qproc == NULL. In that case the
       driver will assume that poll_wait() will actually add the fd to the set
       of waiting file descriptors. Of course, poll_wait() will not do that
       since it tests for wait->_qproc. This will not break anything, though.

       There is only one place in the whole kernel where this happens
       (sock_poll_wait() in include/net/sock.h) and that code will be replaced
       by a call to poll_does_not_wait() in the next patch.

       Note that even if wait->_qproc != NULL drivers cannot rely on poll_wait()
       actually waiting. The next file descriptor from the set might match the
       event mask and thus any possible waits will never happen.

    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Reviewed-by: Jonathan Corbet <corbet@lwn.net>
    Reviewed-by: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Davide Libenzi <davidel@xmailserver.org>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
    Cc: David Miller <davem@davemloft.net>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: backport kernel dma-buf implementation

dma-buf was added via commit d15bd7ee on v3.3 but completed
in a more sound fassion in later kernels, you should preferably
be at v3.5 a least, so we take the latest dma-buf implementation
and port it for usage on kernels [3.0-3.4]. We take the
implementation as of next-20130328.

This is implemented as a non modular solution upstream but
we can carry the implementation into our compat module.

Note that although commit f23513e8d was added on v2.6.23
that allowed the kernel to call get_unused_fd_flags(flags)
for O_CLOEXEC setting, this routine was not exported until
v3.7. dma-buf makes use of it, and since our backported
dma-buf implementation is modular it means we have to work
around the lack of get_unused_fd_flags() exported symbol
on older kernels. Due to the security concerns noted by
Ulrich on f23513e8 we need to ensure the operatin is
atomic so we fix this on our port of dma-buf for older
kernels by adding our own dma_buf_fd_set_flag() to be called
when dma_buf_fd() is used. This implementation is available
for usage on kernels >= 3.0. We disable it for v3.5 as
we're happy with that implementation.

mcgrof@frijol ~/linux-next (git::master)$ git describe --contains \
	d15bd7ee445d0702ad801fdaece348fdb79e6581
v3.3-rc1~161^2~2

mcgrof@frijol ~/linux-next (git::master)$ git describe --contains \
	f23513e8d96cf5e6cf8d2ff0cb5dd6bbc33995e4
v2.6.23-rc1~894

mcgrof@frijol ~/linux-stable (git::linux-3.2.y)$ git describe --contains \
	1a7bd226
v3.7-rc1~134^2~69

Carried over the implementation from linux-next next-20130328

commit d15bd7ee445d0702ad801fdaece348fdb79e6581
Author: Sumit Semwal <sumit.semwal@ti.com>
Date:   Mon Dec 26 14:53:15 2011 +0530

    dma-buf: Introduce dma buffer sharing mechanism

    This is the first step in defining a dma buffer sharing mechanism.

    A new buffer object dma_buf is added, with operations and API to allow easy
    sharing of this buffer object across devices.

    The framework allows:
    - creation of a buffer object, its association with a file pointer, and
       associated allocator-defined operations on that buffer. This operation is
       called the 'export' operation.
    - different devices to 'attach' themselves to this exported buffer object, to
      facilitate backing storage negotiation, using dma_buf_attach() API.
    - the exported buffer object to be shared with the other entity by asking for
       its 'file-descriptor (fd)', and sharing the fd across.
    - a received fd to get the buffer object back, where it can be accessed using
       the associated exporter-defined operations.
    - the exporter and user to share the scatterlist associated with this buffer
       object using map_dma_buf and unmap_dma_buf operations.

    Atleast one 'attach()' call is required to be made prior to calling the
    map_dma_buf() operation.

    Couple of building blocks in map_dma_buf() are added to ease introduction
    of sync'ing across exporter and users, and late allocation by the exporter.

    For this first version, this framework will work with certain conditions:
    - *ONLY* exporter will be allowed to mmap to userspace (outside of this
       framework - mmap is not a buffer object operation),
    - currently, *ONLY* users that do not need CPU access to the buffer are
       allowed.

    More details are there in the documentation patch.

    This is based on design suggestions from many people at the mini-summits[1],
    most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
    Daniel Vetter <daniel@ffwll.ch>.

    The implementation is inspired from proof-of-concept patch-set from
    Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
    between two v4l2 devices. [2]

    [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
    [2]: http://lwn.net/Articles/454389

    Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
    Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
    Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  OK  ]
16  2.6.39              [  OK  ]
17  3.0.65              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.38              [  OK  ]
20  3.3.8               [  OK  ]
21  3.4.32              [  OK  ]
22  3.5.7               [  OK  ]
23  3.6.11              [  OK  ]
24  3.7.9               [  OK  ]
25  3.8.0               [  OK  ]
26  3.9-rc1             [  OK  ]

Cc: daniel.vetter@ffwll.ch
Cc: airlied@redhat.com
Cc: sumit.semwal@linaro.org
Cc: rob.clark@linaro.org
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>