Add a comment to clarify reason for using ACPI_FREE_BUFFER directly
instead of ACPI_FREE.

In addition to that, change one instance in which ACPI_FREE_BUFFER()
should be used instead of ACPI_FREE().

[rjw: Subject and changelog]
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

For Linux, there are no functional changes/binary generation differences
introduced by this patch.

This change adds a new macro to all files that contain external ACPICA
interfaces. It can be detected and used by the host (via the host-specific
header) for any special processing required for such modules. Lv Zheng.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI spec requires the reset register width to be 8, so we
now hardcode it and ignore the FADT value. This provides/maintains
compatibility with other ACPI implementations that have allowed
BIOS code with bad register width values to go unnoticed.
Matthew Garett, Bob Moore, Lv Zheng.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This change fixes potential memory leaks in the error paths of the GPE
handling code. Lv Zheng.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In the common case, the ACPI_ALLOCATE and related macros now resolve
directly to their respective acpi_os* OSL interfaces. Two options:
1) The ACPI_ALLOCATE_ZEROED macro defaults to a simple local implementation
   by default, unless overridden by the USE_NATIVE_ALLOCATE_ZEROED define.
2) For ACPI execution simulation environment (AcpiExec) which is not
   shipped with the Linux kernel, the macros can optionally be resolved to
   the local interfaces that track each allocation (used to immediately
   detect memory leaks).
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This change adds and deploys "safe" versions of strcpy and strcat that
ensure that the target buffer does not overflow. These safe functions
are only helpful for processing user input and command lines. For most
ACPICA code however, the required buffer length is precisely calculated
before buffer allocation, so the use of these functions is unnecessary.
ACPICA BZ 1043.

This change only applies to the ACPICA utilities and the debugger, none
of which are not shipped with the kernel yet, so the kernel's behavior
remains unchanged after it.

References: https://bugs.acpica.org/show_bug.cgi?id=1043Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The original upstream ACPICA change added full history and limited
line editing to the debugger:

 This change adds full history and limited line editing for Unix and
 Linux systems. It does not use readline() because of portability issues.
 Instead it uses the POSIX termio interface to put the terminal in raw
 input mode so that the various special keys can be trapped (such as
 up-arrow and down-arrow for history support).

Since the debugger is not shipped in the kernel, it only is necessary
to update one header file to keep the kernel source in sync with the
upstream.

[rjw: Changelog]
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Mostly for consistency. ACPICA BZ 1042.

Actually, currently no one is experiencing problem without this check
as the obj_handle is guaranteed to be valid.

References: https://bugs.acpica.org/show_bug.cgi?id=1042Reported-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This change increases the default width for the length of tables from
5 to 6, to improve alignment/readability on systems with large tables.
These are being seen more frequently, especially large DSDTs (greater
than 1 MB).
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Set the global debug flag to "no output" when the debugger is shutdown.
ACPICA BZ 1011. Tomasz Nowicki.

Since the debugger is not shipped in the Linux kernel upstream, this
change doesn't affect Linux kernel's behavior.

References: https://bugs.acpica.org/show_bug.cgi?id=1011Signed-off-by: NTomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The SCI interrupt number is not needed for the SCI handlers, and was
just unnecessary overhead.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch introduces new macors to handle RSDP signature and cleans up the
affected codes.  Lv Zheng.
Some updates are only used for ACPICA utilities which are not shipped in
the kernel yet.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Reviewed-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch reduces code redundancy by moving the FACS/S3PT checksum
verification skip logic into acpi_tb_verify_checksum() and other
calls of this function also get benefit from this change.  Lv Zheng.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Reviewed-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Paths command displays the full pathname and object type for
the entire namespace. Alternative to the Namespace command.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This change removes some dangerous code that attempts to free the
handler context pointer in some (rare) circumstances. The owner of
the handler owns this pointer and the ACPICA code should never
touch it. Although not seen to be an issue in any kernel, it did
show up as a problem under AcpiExec. Also, set the internal storage
field for the context pointer to zero when the region is deactivated,
simply for sanity. David Box.
Signed-off-by: NDavid E. Box <david.e.box@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This change adds support to allow hosts to install System Control
Interrupt handlers. Certain ACPI functionality requires the host
to handle raw SCIs. For example, the "SCI Doorbell" that is defined
for memory power state support requires the host device driver to
handle SCIs to examine if the doorbell has been activated. Multiple
SCI handlers can be installed to allow for future expansion.
Debugger support is included.
Lv Zheng, Bob Moore. ACPICA BZ 1032.

Bug summary:
It is reported when the PCC (Platform Communication Channel, via
MPST table, defined in ACPI specification 5.0) subchannel responds
to the host, it issues an SCI and the host must probe the subchannel
for channel status.

Buglink: http://bugs.acpica.org/show_bug.cgi?id=1032Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Reviewed-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Perform a sanity check on the start object to prevent problems
later. ACPICA BZ 1025.
This patch only adds additional input parameter validation, no actual
kernel suffering has been discovered.

Buglink: http://bugs.acpica.org/show_bug.cgi?id=1025Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Increase the size of a couple of the debugger line buffers.
ACPICA BZ 1037.

The debugger related code is not in the kernel so the behavior of the
kernel is not affected.

Buglink: http://bugs.acpica.org/show_bug.cgi?id=1037Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Allow for longer filenames in the module name output during
trace operations.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

If an error happens in the middle of a split 32/32 64-bit I/O
operation, do not modify the target of the return value pointer.
Makes the code consistent with the rest of ACPICA. Bjorn Helgaas.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Emit the full offending pathname in the error message.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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>