This is based on dgrp-1.9 available from
ftp://ftp1.digi.com/support/beta/linux/dgrp/dgrp-1.9.tgzSigned-off-by: NBill Pemberton <wfp5p@virginia.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently the MFD core supports remapping MFD cell interrupts using an
irqdomain but only if the MFD is being instantiated using device tree
and only if the device tree bindings use the pattern of registering IPs
in the device tree with compatible properties.  This will be actively
harmful for drivers which support non-DT platforms and use this pattern
for their DT bindings as it will mean that the core will silently change
remapping behaviour and it is also limiting for drivers which don't do
DT with this particular pattern.  There is also a potential fragility if
there are interrupts not associated with MFD cells and all the cells are
omitted from the device tree for some reason.

Instead change the code to take an IRQ domain as an optional argument,
allowing drivers to take the decision about the parent domain for their
interrupts.  The one current user of this feature is ab8500-core, it has
the domain lookup pushed out into the driver.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Without these, DVI is broken.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

'struct omap_video_timings' was updated w/ a 'bool interlaced'.  Without
a matching update in omap_connector, this field could have undefined
values from the stack, which isn't quite ideal.

Update the fxns to convert omapdss<->drm timings structs, and zero-init
'struct omap_video_timings' when it is declared on stack to avoid issues
like this in the future.
Signed-off-by: NRob Clark <rob@ti.com>
Reviewed-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

64bit arches have a buggy r8712u driver, let's fix it.

skb->tail must be set properly or network stack behavior is undefined.

Addresses https://bugzilla.redhat.com/show_bug.cgi?id=847525
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=45071Signed-off-by: NEric Dumazet <edumazet@google.com>
Cc: Dave Jones <davej@redhat.com>
Cc: stable <stable@vger.kernel.org> [2.6.37+]
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This structure might have made sense many years ago, but at this
point it is only used in one specific driver, and referenced in
stale comments elsewhere.  Rather than change the sunsu.c driver,
simply move the struct to be within the exclusive domain of that
driver, so it won't get inadvertently picked up and used by other
serial drivers going forward.  The comments referencing the now
driver specific struct are updated accordingly.

Note that 8250.c has a struct that is similar in usage, with the
name serial8250_config; but is 100% independent and untouched here.

Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes a race condition that results in memory
corruption when using cleancache.

The race exists between the zcache shrinker handler,
shrink_zcache_memory() and cleancache_get_page().

In most cases, the shrinker will both evict a zbpg
from its buddy list and flush it from tmem before a
cleancache_get_page() occurs on that page. A subsequent
cleancache_get_page() will fail in the tmem layer.

In the rare case that two occur together and the
cleancache_get_page() path gets through the tmem
layer before the shrinker path can flush tmem,
zbud_decompress() does a check to see if the zbpg is a
"zombie", i.e. not on a buddy list, which means the shrinker
is in the process of reclaiming it. If the zbpg is a zombie,
zbud_decompress() returns -EINVAL.

However, this return code is being ignored by the caller,
zcache_pampd_get_data_and_free(), which results in the
caller of cleancache_get_page() thinking that the page has
been properly retrieved when it has not.

This patch modifies zcache_pampd_get_data_and_free() to
convey the failure up the stack so that the caller of
cleancache_get_page() knows the page retrieval failed.

This needs to be applied to stable trees as well.
zcache-main.c was named zcache.c before v3.1, so
I'm not sure how you want to handle trees earlier
than that.
Signed-off-by: NSeth Jennings <sjenning@linux.vnet.ibm.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: NMinchan Kim <minchan@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixed a bug. Data was being written to user space using an IOCTL
command encoded with _IOC_WRITE access mode.
Signed-off-by: NDae S. Kim <dae@velatum.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Hi,

This patch fixes a bug with driver failing to negotiate a connection.

The bug was traced to commit
203e4615
staging: vt6656: removed custom definitions of Ethernet packet types

In that patch, definitions in include/linux/if_ether.h replaced ones
in tether.h which had both big and little endian definitions.

include/linux/if_ether.h only refers to big endian values, cpu_to_be16
should be used for the correct endian architectures.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Cc: stable <stable@vger.kernel.org> # 2.6.37+
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

"addr" is a pointer so it's either 4 or 8 bytes, but actually we want
to compare 6 bytes (ETH_ALEN).

As network stack already provides helper function
is_zero_ether_addr() we use that instead of memcmp
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Acked-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NRupesh Gujare <rgujare@ozmodevices.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The function pointer scan in struct cfg80211_ops is not
supposed to be assigned a function with a struct net_device
pointer as an argument. Instead access the net_device struct
in the following way:

struct net_device *dev = request->wdev->netdev;

sparse gives these warnings:

drivers/staging/wlan-ng/cfg80211.c:726:17: warning:
        incorrect type in initializer (incompatible argument 2
        (different base types))
        expected int ( *scan )( ... )
        got int ( extern [toplevel] *<noident> )( ... )

drivers/staging/wlan-ng/cfg80211.c:726:2: warning:
        initialization from incompatible pointer type [enabled by default]

drivers/staging/wlan-ng/cfg80211.c:726:2: warning:
        (near initialization for ‘prism2_usb_cfg_ops.scan’)
        [enabled by default]
Signed-off-by: NEmil Goode <emilgoode@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Don't zero out bits 15..12 of the data value in `das08jr_ao_winsn()` as
that knobbles the upper three-quarters of the output range for the
'das08jr-16-ao' board.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The element of `das08_boards[]` for the 'das08jr-16-ao' board has the
`ai_encoding` member set to `das08_encode12`.  It should be set to
`das08_encode16` same as the 'das08jr/16' board.  After all, this board
has 16-bit AI resolution.

The description of the A/D LSB register at offset 0 seems incorrect in
the user manual "cio-das08jr-16-ao.pdf" as it implies that the AI
resolution is only 12 bits.  The diagrams of the A/D LSB and MSB
registers show 15 data bits and a sign bit, which matches what the
software expects for the `das08_encode16` AI encoding method.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When attaching a PCI device manually via the comedi driver `attach` hook
(`das08_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG`
ioctl), its reference count is incremented in the `for_each_pci_dev`
loop (in `das08_find_pci()`).  It is decremented when the `detach` hook
(`das08_detach()`) is called to detach the device.  However, when the
PCI device is attached automatically via the `attach_pci` hook
(`das08_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.

Increment the PCI device reference count in `das08_attach_pci()` to
correct the mismatch.

Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When attaching a PCI device manually via the comedi driver `attach` hook
(`pci230_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG`
ioctl), its reference count is incremented in the `for_each_pci_dev`
loop (in `pci230_find_pci_dev()`).  It is decremented when the `detach`
hook (`pci230_detach()`) is called to detach the device.  However, when
the PCI device is attached automatically via the `attach_pci` hook
(`pci230_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.

Increment the PCI device reference count in `pci230_attach_pci()` to
correct the mismatch.

Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When attaching a PCI device manually via the comedi driver `attach` hook
(`pc263_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG`
ioctl), its reference count is incremented in the `for_each_pci_dev`
loop (in `pc263_find_pci_dev()`).  It is decremented when the `detach`
hook (`pc263_detach()`) is called to detach the device.  However, when
the PCI device is attached automatically via the `attach_pci` hook
(`pc263_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.

Increment the PCI device reference count in `pc263_attach_pci()` to
correct the mismatch.

Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When attaching a PCI device manually via the comedi driver `attach` hook
(`pc236_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG`
ioctl), its reference count is incremented in the `for_each_pci_dev`
loop (in `pc236_find_pci_dev()`).  It is decremented when the `detach`
hook (`pc236_detach()`) is called to detach the device.  However, when
the PCI device is attached automatically via the `attach_pci` hook
(`pc236_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.

Increment the PCI device reference count in `pc236_attach_pci()` to
correct the mismatch.

Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When attaching a PCI device manually via the comedi driver `attach` hook
(`dio200_attach()`) (called by the comedi core for the
`COMEDI_DEVCONFIG` ioctl), its reference count is incremented in the
`for_each_pci_dev` loop (in `dio200_find_pci_dev()`).  It is decremented
when the `detach` hook (`dio200_detach()`) is called to detach the
device.  However, when the PCI device is attached automatically via the
`attach_pci` hook (`dio200_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.

Increment the PCI device reference count in `dio200_attach_pci()` to
correct the mismatch.

Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When attaching a PCI device manually via the comedi driver `attach` hook
(`pci224_attach()`) (called by the comedi core for the
`COMEDI_DEVCONFIG` ioctl), its reference count is incremented in the
`for_each_pci_dev` loop (in `pci224_find_pci_dev()`).  It is decremented
when the `detach` hook (`pci224_detach()`) is called to detach the
device.  However, when the PCI device is attached automatically via the
`attach_pci` hook (`pci224_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.

Increment the PCI device reference count in `pci224_attach_pci()` to
correct the mismatch.

Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.

Cc: stable <stable@vger.kernel.org> # 3.5.x
Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NPeter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

"val" is used as a divisor later, so we should check for zero here to
avoid a division by zero.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.

Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Reported-by: NBjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
CC: Pavel Machek <pavel@ucw.cz>
CC: Paul Gortmaker <paul.gortmaker@windriver.com>
CC: "John W. Linville" <linville@tuxdriver.com>
CC: Eliad Peller <eliad@wizery.com>
CC: Devendra Naga <devendra.aaru@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.

Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Reported-by: NBjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
CC: Forest Bond <forest@alittletooquiet.net>
CC: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: Jesper Juhl <jj@chaosbits.net>
CC: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The values reported by the AD7780 are unsigned with a binary offset:

	0x000000 is negative fullscale
	0x800000 is zeroscale
	0xffffff is positive fullscale

So mark the channel in the channel spec as unsigned rather than signed.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

The temperature channel reports values in degree Kelvin with sensitivity of 5630
codes per degree. If the chip is configured in bipolar mode there is an
additional binary offset of 0x800000 and the sensitivity is divided by two.

Currently the driver does the mapping from the raw value to degree Celsius when
doing a manual conversion. This has several disadvantages, the major one being
that it does not work for buffered mode, also by doing the division by the
sensitivity in the driver the precession of the reported value is needlessly
reduced.

Furthermore the current calculation only works in bipolar mode and the current
scale is of by a factor of 1000.

This patch modifies the driver to report correct offset and scale values in
both unipolar and bipolar mode and to report the raw temperature value
for manual conversions.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

In bipolar mode there is a a binary offset of 2**(N-1) (with N being the number
of bits) on the reported value. Currently this value is subtracted when doing a
manual read. While this works for manual channel readings it does not work for
buffered mode. So report the offset in the channels offset property, which will
work in both modes.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>

The values reported by the AD7793 are unsigned.
	In uniploar mode:
			0x000000 is zeroscale
			0xffffff is fullscale
	In bipolar mode:
			0x000000 is negative fullscale
			0x800000 is zeroscale
			0xffffff is positive fullscale

In bipolar mode there is a binary offset, but the values are still unsigned.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Write to the correct register when setting the ACX bit.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Without the break statement we fall right through to the default case and return
an error value.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

The internal reference for the ad7793 and similar is 1.17V
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Make the "in-in_scale_available" attribute follow the new naming spec and
rename it to "in_voltage-voltage_scale_available".
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

The temperature channel uses the internal 1.17V reference with 0.81 mv/C. The
reported temperature is in Kevlin, so we need to add the Kelvin to Celcius
offset when reporting the offset for the temperature channel.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

In bipolar mode there is a a binary offset of 2**(N-1) (with N being the number
of bits) on the reported value. Currently this value is subtracted when doing a
manual read. While this works for manual channel readings it does not work for
buffered mode. So report the offset in the channels offset property, which will
work in both modes.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

The values reported by the AD7793 are unsigned.
	In uniploar mode:
			0x000000 is zeroscale
			0xffffff is fullscale
	In bipolar mode:
			0x000000 is negative fullscale
			0x800000 is zeroscale
			0xffffff is positive fullscale

In bipolar mode there is a binary offset, but the values are still unsigned.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Without the break statement we fall right through to the default case and return
an error value.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

drivers/staging/iio/adc/ad7298_ring.c:97:37: warning: 'time_ns' may
be used uninitialized in this function [-Wmaybe-uninitialized]
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Cc: Ian Abbott <abbotti@mev.co.uk>
Cc: Mori Hess <fmhess@users.sourceforge.net>
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ravishankar Karkala Mallikarjunayya <ravishankar.km@greenturtles.in>
Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Cc: Ian Abbott <abbotti@mev.co.uk>
Cc: Mori Hess <fmhess@users.sourceforge.net>
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Cc: Ian Abbott <abbotti@mev.co.uk>
Cc: Mori Hess <fmhess@users.sourceforge.net>
Cc: Bernd Porr <berndporr@f2s.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Randy noticed that with CONFIG_INET turned off, the following build
errors happen:
	ERROR: "register_inetaddr_notifier" [drivers/staging/csr/csr_wifi.ko] undefined!
	ERROR: "unregister_inetaddr_notifier" [drivers/staging/csr/csr_wifi.ko] undefined!
Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>