staging/vt6656: Fix too large integer constant warning on 32-bit

drivers/staging/vt6656/card.c: In function ‘CARDqGetNextTBTT’:
drivers/staging/vt6656/card.c:793: warning: integer constant is too large for ‘unsigned long’ type

Commit c7b7cad0d8df823ea063c86a54316bbcbfa04a7c ("staging/vt6656: Fix
sparse warning constant 0xffffffff00000000U is so big it is unsigned long")
changed the constant to "0xffffffff00000000UL", but that only works on
64-bit.  Change it "0xffffffff00000000ULL" to fix it for 32-bit, too.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: dt9812: use CR_CHAN() for channel number

As pointed out by Dan Carpenper in
<http://driverdev.linuxdriverproject.org/pipermail/devel/2013-February/036025.html>,
the dt9812 comedi driver's use of the `chanspec` member of `struct
comedi_insn` as a channel number is incorrect.  Change it to use
`CR_CHAN(insn->chanspec)` as the channel number (where `insn` is a
pointer to the `struct comedi_insn` being processed).

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable <stable@vger.kernel.org> # 3.8 onwards
Cc: Anders Blomdell <anders.blomdell@control.lth.se>
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jbd2: fix use after free in jbd2_journal_dirty_metadata()

jbd2_journal_dirty_metadata() didn't get a reference to journal_head it
was working with. This is OK in most of the cases since the journal head
should be attached to a transaction but in rare occasions when we are
journalling data, __ext4_journalled_writepage() can race with
jbd2_journal_invalidatepage() stripping buffers from a page and thus
journal head can be freed under hands of jbd2_journal_dirty_metadata().

Fix the problem by getting own journal head reference in
jbd2_journal_dirty_metadata() (and also in jbd2_journal_set_triggers()
which can possibly have the same issue).

Reported-by: Zheng Liu <gnehzuil.liu@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
xen: arm: mandate EABI and use generic atomic operations.

Rob Herring has observed that c81611c4e96f "xen: event channel arrays are
xen_ulong_t and not unsigned long" introduced a compile failure when building
without CONFIG_AEABI:

/tmp/ccJaIZOW.s: Assembler messages:
/tmp/ccJaIZOW.s:831: Error: even register required -- `ldrexd r5,r6,[r4]'

Will Deacon pointed out that this is because OABI does not require even base
registers for 64-bit values. We can avoid this by simply using the existing
atomic64_xchg operation and the same containerof trick as used by the cmpxchg
macros. However since this code is used on memory which is shared with the
hypervisor we require proper atomic instructions and cannot use the generic
atomic64 callbacks (which are based on spinlocks), therefore add a dependency
on !GENERIC_ATOMIC64. Since we already depend on !CPU_V6 there isn't much
downside to this.

While thinking about this we also observed that OABI has different struct
alignment requirements to EABI, which is a problem for hypercall argument
structs which are shared with the hypervisor and which must be in EABI layout.
Since I don't expect people to want to run OABI kernels on Xen depend on
CONFIG_AEABI explicitly too (although it also happens to be enforced by the
!GENERIC_ATOMIC64 requirement too).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Rob Herring <robherring2@gmail.com>
Acked-by: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
xen/acpi: remove redundant acpi/acpi_drivers.h include

It's redundant since linux/acpi.h has include it when CONFIG_ACPI enabled,
and when CONFIG_ACPI disabled it will trigger compiling warning

In file included from drivers/xen/xen-stub.c:28:0:
include/acpi/acpi_drivers.h:103:31:
warning: 'struct acpi_device' declared inside parameter list [enabled by default]
include/acpi/acpi_drivers.h:103:31:
warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
include/acpi/acpi_drivers.h:107:43:
warning: 'struct acpi_pci_root' declared inside parameter list [enabled by default]

Reported-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Merge tag 'nfc-fixes-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes

Samuel Ortiz <sameo@linux.intel.com> says:

This is the first NFC pull request for 3.9 fixes

With this one we have:

- A fix for properly decreasing socket ack log.
- A timer and works cleanup upon NFC device removal.
- A monitoroing socket cleanup round from llcp_socket_release.
- A proper error report to pending sockets upon NFC device removal.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
usb: musb: core: fix possible build error with randconfig

when making commit e574d57 (usb: musb: fix
compile warning) I forgot to git add this
part of the patch which ended up introducing
a possible build error.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
qcaux: add Franklin U600

4 ports; AT/PPP is standard CDC-ACM.  The other three (added by this
patch) are QCDM/DIAG, possibly GPS, and unknown.

Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'nfc-next-3.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next

Samuel Ortiz <sameo@linux.intel.com> says:

This is the first NFC pull request for 3.10.

The 2 features we have with this one are:

- An LLCP Service Name Lookup (SNL) netlink interface for querying LLCP
  service availability from user space.
  Along the way, Thierry also improved the existing SNL interface for
  aggregating SNL responses.

- An initial LLCP socket options implementation, for setting the Receive
  Window (RW) and the Maximum Information Unit Extension (MIUX) per socket.
  This is need for the LLCP validation tests.

We also have a microread MEI build failure here: I am not sending this one to
3.9 because the MEI bus code is not there yet, so it won't break for anyone
else than me.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
orinoco_usb: don't release nonexistent firmware

Initialize fw_entry to NULL to prevent cleanup code from passing
bogus pointer to release_firmware() when priv allocation fails.

Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
iwlegacy: fix sparse warnings

Make local functions and tables static. Make ops table
Mark 3945 ops as read_mostly.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
wireless:rtlwifi: replaced kmalloc+memcpy with kmemdup

Signed-off-by: Andrei Epure <epure.andrei@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mwl8k: don't overwrite regulatory settings on fw reload

Currently the caps are parsed on every firmware reload, causing any
channel flags to be cleared.
When there is a firmware to interface mode mismatch, the triggered
firmware reload causes a reset of the regulatory settings, causing all
channels to become available:

root@openrouter:/# iw phy phy0 info
Wiphy phy0
        Band 1:
		(...)
                Frequencies:
                        * 2412 MHz [1] (0.0 dBm)
                        * 2417 MHz [2] (0.0 dBm)
                        * 2422 MHz [3] (0.0 dBm)
                        * 2427 MHz [4] (0.0 dBm)
                        * 2432 MHz [5] (0.0 dBm)
                        * 2437 MHz [6] (0.0 dBm)
                        * 2442 MHz [7] (0.0 dBm)
                        * 2447 MHz [8] (0.0 dBm)
                        * 2452 MHz [9] (0.0 dBm)
                        * 2457 MHz [10] (0.0 dBm)
                        * 2462 MHz [11] (0.0 dBm)
                        * 2467 MHz [12] (0.0 dBm)
                        * 2472 MHz [13] (0.0 dBm)
                        * 2484 MHz [14] (0.0 dBm)
		(...)

To prevent this, only parse the caps on the first firmware load during
hardware probe, and store them locally to know we have already parsed
them.

Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ARM: multiplatform: Sort the max gpio numbers.

When building a multiplatform kernel, we could end up with a smaller
number of GPIOs than the one required by the platform the kernel was
running on.

Sort the max GPIO number by descending order so that we always take the
highest number required.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Merge tag 'mxs-fixes-3.9-2' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes

From Shawn Guo <shawn.guo@linaro.org>:

The 2nd mxs fixes for 3.9:
 - Fix an error caused by incorrect conflict resolution when
   applying the patch

* tag 'mxs-fixes-3.9-2' of git://git.linaro.org/people/shawnguo/linux-2.6:
  ARM: mxs: cfa10049: Fix fb initialisation function

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Merge tag 'imx-fixes-3.9-2' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes

From Shawn Guo <shawn.guo@linaro.org>:

The 2nd take of imx fixes for 3.9:
 - Fix pll1_sys clk initial status
 - Fix a typo in imx DEBUG_LL Kconfig

* tag 'imx-fixes-3.9-2' of git://git.linaro.org/people/shawnguo/linux-2.6:
  ARM: imx: fix typo "DEBUG_IMX50_IMX53_UART"
  ARM: imx: pll1_sys should be an initial on clk

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Merge tag 'mvebu_fixes_for_v3.9' of git://git.infradead.org/users/jcooper/linux into fixes

mvebu fixes for v3.9 from Jason Cooper <jason@lakedaemon.net>:

The first four patches:

  89c58c1 rtc: rtc-mv: Add support for clk to avoid lockups
  de88747 gpio: mvebu: Add clk support to prevent lockup
  7bf5b40 ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels
  93fff4c ARM: kirkwood: of_serial: fix clock gating by removing clock-frequency

are Cc'd to stable since they were held over from the previous merge window.

The rest are a small collection of fixes and a couple of devicetree conversion
catchups.

* tag 'mvebu_fixes_for_v3.9' of git://git.infradead.org/users/jcooper/linux:
  arm: mach-orion5x: fix typo in compatible string of a .dts file
  arm: mvebu: fix address-cells in mpic DT node
  arm: plat-orion: fix address decoding when > 4GB is used
  arm: mvebu: Reduce reg-io-width with UARTs
  ARM: Dove: add RTC device node
  arm: mvebu: enable the USB ports on Armada 370 Reference Design board
  ARM: dove: drop "select COMMON_CLK_DOVE"
  rtc: rtc-mv: Add support for clk to avoid lockups
  gpio: mvebu: Add clk support to prevent lockup
  ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels
  ARM: kirkwood: of_serial: fix clock gating by removing clock-frequency

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Arm: socfpga: pl330: Add #dma-cells for generic dma binding support

This patch adds #dma-cells property to PL330 DMA controller nodes for
supporting generic dma dt bindings on SOCFPGA platform. #dma-channels
and #dma-requests are not required now but added in advance.

Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Bluetooth: Device 0cf3:3008 should map AR 3012

T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0cf3 ProdID=3008 Rev= 0.01
S:  Manufacturer=Atheros Communications
S:  Product=Bluetooth USB Host Controller
S:  SerialNumber=Alaska Day 2006
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

Signed-off-by: Sunguk Lee <d3m3vilurr@gmail.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
quota: add missing use of dq_data_lock in __dquot_initialize

The bulk of __dquot_initialize runs under the dqptr_sem which
protects the inode->i_dquot pointers. It doesn't protect the
dereferenced contents, though. Those are protected by the
dq_data_lock, which is missing around the dquot_resv_space call.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Jan Kara <jack@suse.cz>