Casting the return value which is a void pointer is redundant.
The conversion from void pointer to any other pointer type is
guaranteed by the C programming language.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NVineet Gupta <vgupta@synopsys.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Casting the return value which is a void pointer is redundant.
The conversion from void pointer to any other pointer type is
guaranteed by the C programming language.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NSonic Zhang <sonic.zhang@analog.com>
Acked-by: NVineet Gupta <vgupta@synopsys.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Casting the return value which is a void pointer is redundant.
The conversion from void pointer to any other pointer type is
guaranteed by the C programming language.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NVineet Gupta <vgupta@synopsys.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Casting the return value which is a void pointer is redundant.
The conversion from void pointer to any other pointer type is
guaranteed by the C programming language.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NVineet Gupta <vgupta@synopsys.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The channel IDs are set to -1 by default. It will prevent
dmaengine from trying to provide the first free channel if
it fails to allocate exclusive channel. This will fix an
issue with ACPI enumerated UARTs that do not support DMA
but still end up getting a DMA channel incorrectly.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It should be available for DT users as well. This does not
enable DMA by default except with ACPI. DT users can enable
DMA based on a property.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

DMA engines usually expect the fifo trigger level to be
aligned with the burst size. It should not be changed even
with small baud rates. This will fix an issue with
Designware DMA engine where the data can not be transferred
over UART with lower baud rates then 2400.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

pch_uart currently isn't auto-loaded if built as a module.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is a PCI driver and should be auto-loaded based on PCI ID.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Kconfig for this option suggests it's only relevant on STi SoCs,
so add depends to have it not show up on archs that won't ever run it.
Signed-off-by: NDave Jones <davej@fedoraproject.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit f7d2c0bb (serial: i.MX: evaluate linux,stdout-path property) introduced
the following sparse warning:

drivers/tty/serial/imx.c:1916:77: warning: Using plain integer as NULL pointer

Pass NULL as the last argument of add_preferred_console() instead of zero.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Enabling the ARM DCC console and using without a JTAG connection will
simply hang the system. Since distros like to turn on all options, this
is a reoccurring problem to debug. We can do better by checking if
anything is attached and handling characters. There is no way to probe
this, so send a newline and check that it is handled.

Cc: Paolo Pisati <paolo.pisati@canonical.com>
Cc: Tim Gardner <tim.gardner@canonical.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Although originally conceived as a hook for port drivers to know
when a port reference is dropped, no driver uses this method.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the tty driver mistakenly drops the last port reference
before the tty has been released, issue a diagnostic and
abort the port destruction.

This will leak memory and may zombify the port, but might
otherwise keep the machine in runnable state.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove braces from single-statement conditional in
n_tty_set_termios.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Flatten conditional evaluation in n_tty_set_termios; remove
canon_change.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

n_tty's .set_termios method unconditionally performs reader wakeup;
remove extra reader wakeup for canonical mode changes.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sure to properly initialize the IIO buffer data structure.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Set the IIO device as the parent for the character device

We need to make sure that the IIO device is not freed while the character device
exists, otherwise the freeing of the IIO device might race against the file open
callback. Do this by setting the character device's parent to the IIO device,
this will cause the character device to grab a reference to the IIO device and
only release it once the character device itself has been removed.

Also move the registration of the character device before the registration of
the IIO device to avoid the (rather theoretical case) that the IIO device is
already freed again before we can add the character device and grab a reference
to the IIO device.

We also need to move the call to cdev_del() from iio_dev_release() to
iio_device_unregister() (where it should have been in the first place anyway) to
avoid a reference cycle. As iio_dev_release() is only called once all reference
are dropped, but the character device holds a reference to the IIO device.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Make sure that the IIO device is not freed while we still have file descriptors
for it.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Make sure to stop sampling when the device is removed, otherwise it will
continue to sample forever.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

if device has available_scan_masks set and the buffer is enabled without
any scan_elements enabled, in a NULL pointer is dereferenced in iio_compute_scan_bytes()

[   18.993713] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   19.002593] pgd = debd4000
[   19.005432] [00000000] *pgd=9ebc0831, *pte=00000000, *ppte=00000000
[   19.012329] Internal error: Oops: 17 [#1] PREEMPT ARM
[   19.017639] Modules linked in:
[   19.020843] CPU: 0    Not tainted  (3.9.11-00036-g75c888a-dirty #207)
[   19.027587] PC is at _find_first_bit_le+0xc/0x2c
[   19.032440] LR is at iio_compute_scan_bytes+0x2c/0xf4
[   19.037719] pc : [<c021dc60>]    lr : [<c03198d0>]    psr: 200d0013
[   19.037719] sp : debd9ed0  ip : 00000000  fp : 000802bc
[   19.049713] r10: 00000000  r9 : 00000000  r8 : deb67250
[   19.055206] r7 : 00000000  r6 : 00000000  r5 : 00000000  r4 : deb67000
[   19.062011] r3 : de96ec00  r2 : 00000000  r1 : 00000004  r0 : 00000000
[   19.068847] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   19.076324] Control: 10c5387d  Table: 9ebd4019  DAC: 00000015

problem is the rollback code in iio_update_buffers(), old_mask may be NULL (e.g. on first
call)

I'm not too confident about the fix; works for me...
Signed-off-by: NPeter Meerwald <pmeerw@pmeerw.net>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

dev_to_iio_dev() is a false friend
Signed-off-by: NPeter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

dev_to_iio_dev() is a false friend
Signed-off-by: NPeter Meerwald <pmeerw@pmeerw.net>
Cc: Oleksandr Kravchenko <o.v.kravchenko@globallogic.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

dev_to_iio_dev() is a false friend
Signed-off-by: NPeter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

On systems that support intel_pstate, acpi_cpufreq fails to load, and
udev keeps trying until trace gets filled up and kernel crashes.

The root cause is driver return ret from cpufreq_register_driver(),
because when some other driver takes over before, it will return
EBUSY and then udev will keep trying ...

cpufreq_register_driver() should return EEXIST instead so that the
system can boot without appending intel_pstate=disable and still use
intel_pstate.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This reverts commit 7c510133.

Well looks like not enough digging was done, libdrm_nouveau before 2.4.33
used contexts,

292da616fe1f936ca78a3fa8e1b1b19883e343b6 nouveau: pull in major libdrm rewrite

got rid of them,
Reported-by: NPaul Zimmerman <Paul.Zimmerman@synopsys.com>
Reported-by: NMikael Pettersson <mikpe@it.uu.se>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Commit 448bd857 (PCI/PM: add PCIe runtime D3cold support) added a
piece of code to pci_acpi_wake_dev() causing that function to behave
in a special way for devices in D3cold (so that their configuration
registers are not accessed before those devices are resumed).
However, it didn't take the clearing of the pme_poll flag into
account.  That has to be done for all devices, even if they are in
D3cold, or pci_pme_list_scan() will not know that wakeup has been
signaled for the device and will poll its PME Status bit
unnecessarily.

Fix the problem by moving the clearing of the pme_poll flag in
pci_acpi_wake_dev() before the code introduced by commit 448bd857.
Reported-and-tested-by: NDavid E. Box <david.e.box@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: 3.6+ <stable@vger.kernel.org> # 3.6+

This bug was introduced by commit
7a163bfb ("netconsole: avoid a crash with
multiple sysfs writers"). In store_enabled() we have the following
sequence: acquire nt->mutex then rtnl, but in the netconsole netdev
notifier we have rtnl then nt->mutex effectively leading to a deadlock.
The NULL pointer dereference that the above commit tries to fix is
actually due to another bug in netpoll_cleanup(). This is fixed by dropping
the mutex from the netdev notifier as it's already protected by rtnl.
Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The patch 136d8f37 broke the skge driver.
Note this part of the patch:
+               if (skge_rx_setup(skge, e, nskb, skge->rx_buf_size) < 0) {
+                       dev_kfree_skb(nskb);
+                       goto resubmit;
+               }
+
                pci_unmap_single(skge->hw->pdev,
                                 dma_unmap_addr(e, mapaddr),
                                 dma_unmap_len(e, maplen),
                                 PCI_DMA_FROMDEVICE);
                skb = e->skb;
                prefetch(skb->data);
-               skge_rx_setup(skge, e, nskb, skge->rx_buf_size);

The function skge_rx_setup modifies e->skb to point to the new skb. Thus,
after this change, the new buffer, not the old, is returned to the
networking stack.

This bug is present in kernels 3.11, 3.11.1 and 3.12-rc1. The patch should
be queued for 3.11-stable.
Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
Reported-by: NMikulas Patocka <mpatocka@redhat.com>
Reported-by: NVasiliy Glazov <vascom2@gmail.com>
Tested-by: NMikulas Patocka <mpatocka@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If local fragmentation is allowed, then ip_select_ident() and
ip_select_ident_more() need to generate unique IDs to ensure
correct defragmentation on the peer.

For example, if IPsec (tunnel mode) has to encrypt large skbs
that have local_df bit set, then all IP fragments that belonged
to different ESP datagrams would have used the same identificator.
If one of these IP fragments would get lost or reordered, then
peer could possibly stitch together wrong IP fragments that did
not belong to the same datagram. This would lead to a packet loss
or data corruption.
Signed-off-by: NAnsis Atteka <aatteka@nicira.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Without this patch, if a frontend cycles through states Closing
and Closed (which Windows frontends need to do) then the netdev
will be destroyed and requires re-invocation of hotplug scripts
to restore state before the frontend can move to Connected. Thus
when udev is not in use the backend gets stuck in InitWait.

With this patch, the netdev is left alone whilst the backend is
still online and is only de-registered and freed just prior to
destroying the vif (which is also nicely symmetrical with the
netdev allocation and registration being done during probe) so
no re-invocation of hotplug scripts is required.
Signed-off-by: NPaul Durrant <paul.durrant@citrix.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Acked-by: NWei Liu <wei.liu2@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Otherwise the system will burn even brighter and worse, leave the user
wondering what's going on exactly.

Since we already have a panic handler which will (try) to restore the
entire fbdev console mode, we can just bail out.  Inspired by a patch from
Konstantin Khlebnikov.  The callchain leading to this, cut&pasted from
Konstantin's original patch:

callstack:
panic()
bust_spinlocks(1)
unblank_screen()
vc->vc_sw->con_blank()
fbcon_blank()
fb_blank()
info->fbops->fb_blank()
drm_fb_helper_blank()
drm_fb_helper_dpms()
drm_modeset_lock_all()
mutex_lock(&dev->mode_config.mutex)

Note that the entire locking in the fb helper around panic/sysrq and kdbg
is ...  non-existant.  So we have a decent change of blowing up
everything.  But since reworking this ties in with funny concepts like the
fbdev notifier chain or the impressive things which happen around
console_lock while oopsing, I'll leave that as an exercise for braver
souls than me.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Dave Airlie <airlied@gmail.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Commit cdc58d60 "cpufreq: imx6q-cpufreq:
remove device tree parsing for cpu nodes" assumed the pdev->dev is set to
cpu0 device in the platform code. But it actually points to the virtual
cpufreq-cpu0 platform device which is not present in the device tree.
Most of the information needed by cpufreq is stored in cpu0 DT node.
So cpu_dev must point to cpu0 device.

This patch fixes the wrong assignment to cpu_dev.
Reported-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NSudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit f837a9b5 "cpufreq: cpufreq-cpu0:
remove device tree parsing for cpu nodes" assumed the pdev->dev is set to
cpu0 device in the platform code. But it actually points to the virtual
cpufreq-cpu0 platform device which is not present in the device tree.
Most of the information needed by cpufreq is stored in cpu0 DT node.
So cpu_dev must point to cpu0 device.

This patch fixes the wrong assignment to cpu_dev.
Reported-and-tested-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: NSudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Fix uninitialized warning.

drivers/gpu/drm/ttm/ttm_object.c: In function ‘ttm_base_object_lookup’:
drivers/gpu/drm/ttm/ttm_object.c:213:10: error: ‘base’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
  kref_put(&base->refcount, ttm_release_base);
          ^
drivers/gpu/drm/ttm/ttm_object.c:221:26: note: ‘base’ was declared here
  struct ttm_base_object *base;
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

After a vmalloc failure in ttm_dma_tt_alloc_page_directory(),
ttm_dma_tt_init() will call ttm_tt_destroy() to cleanup, and end up
inside the driver's unpopulate() hook when populate() has never yet
been called.

On nouveau, the first issue to be hit because of this is that
dma_address[] may be a NULL pointer.  After working around this,
ttm_pool_unpopulate() may potentially hit the same issue with
the pages[] array.

It seems to make more sense to avoid calling unpopulate on already
unpopulated TTMs than to add checks to all the implementations.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Cc: stable@vger.kernel.org
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix mask generation for modified channels.
Signed-off-by: NLukasz Czerwinski <l.czerwinski@samsung.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

ade7854_probe can fail. Return the value obtained from it
instead of 0 (success).
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Cc: Barry Song <21cnbao@gmail.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>