History: This support changes a method to "serialized" on the fly if the
method generates an AE_ALREADY_EXISTS error, indicating the possibility
that it cannot handle reentrancy.

This fix repairs a couple of issues seen in the field, especially on
machines with many cores.

1) Delete method children only upon the exit of the last thread, so
as to not delete objects out from under running threads.

2) Set the "serialized" bit for the method only upon the exit of the
last thread, so as to not cause deadlock when running threads attempt
to exit.

3) Cleanup the use of the AML "MethodFlags" and internal method flags
so that there is no longer any confustion between the two.
Reported-by: NDana Myers <dana.myers@oracle.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Prevents issues if the namespace is changing underneath the
debugger.  Especially temporary nodes, since the debugger displays
these also.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Reviewed-by: NRafael Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Fixes a race condition between method execution and namespace
walks that can possibly fault. Problem was apparently introduced
in version 20100528 as a result of a performance optimization
that reduces the number of namespace walks upon method exit
by using the delete_namespace_subtree function instead of the
delete_namespace_by_owner function used previously. Bug is in
the delete_namespace_subtree function.
Signed-off-by: NDana Myers <dana.myers@oracle.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Reviewed-by: NRafael Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

We will leak the memory allocated to 'local_gpe_event_info' if
'acpi_ut_acquire_mutex()' fails or if 'acpi_ev_valid_gpe_event()' fails in
drivers/acpi/acpica/evgpe.c::acpi_ev_asynch_execute_gpe_method().
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Reviewed-by: NRafael Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Modify/add some comments to minimize ACPICA/linux GPE code divergence.
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The global event handler is called whenever a general purpose
or fixed ACPI event occurs.

Also update Linux OSL to collect events counter with
global event handler.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This feature provides an automatic device notification for wake devices
when a wakeup GPE occurs and there is no corresponding GPE method or
handler. Rather than ignoring such a GPE, an implicit AML Notify
operation is performed on the parent device object.
This feature is not part of the ACPI specification and is provided for
Windows compatibility only.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Change the local variable in acpi_ev_asynch_execute_gpe_method()
back into a pointer as ACPICA code base does.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The new GPE handler callback has 2 additional parameters, gpe_device and
gpe_number.

typedef
u32 (*acpi_gpe_handler) (acpi_handle gpe_device, u32 gpe_number, void *context);
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Some function and variable names are renamed to be consistent with
ACPICA code base.

acpi_raw_enable_gpe -> acpi_ev_add_gpe_reference
acpi_raw_disable_gpe -> acpi_ev_remove_gpe_reference
acpi_gpe_can_wake -> acpi_setup_gpe_for_wake
acpi_gpe_wakeup -> acpi_set_gpe_wake_mask
acpi_update_gpes -> acpi_update_all_gpes
acpi_all_gpes_initialized -> acpi_gbl_all_gpes_initialized
acpi_handler_info -> acpi_gpe_handler_info
...
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Create a new file evxfgpe.c and move GPE specific functions to it.
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Commit 3f5a2a71 zeroes out the statistics
message block (SMB) and coalescing message block (CMB) when adapter ring
resources are freed.  This is desirable behavior, but, as a side effect,
the commit leads to an oops when atl1_set_ringparam() attempts to alter
the number of rx or tx elements in the ring buffer (by using ethtool
-G, for example).  We don't want SMB or CMB to change during this
operation.

Modify atl1_set_ringparam() to preserve SMB and CMB when changing ring
parameters.

Cc: stable@kernel.org
Signed-off-by: NJay Cliburn <jcliburn@gmail.com>
Reported-by: NTõnu Raitviir <jussuf@linux.ee>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

em28xx uses core assisted locking, so it shouldn't use .ioctl.
The .ioctl callback was replaced by .unlocked_ioctl for video nodes,
but not for radio nodes. This is now corrected.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It seems that cx88 and ivtv use wm8775 on some different modes. The
patch that added support for a board with wm8775 broke ivtv boards with
this device. As we're too close to release 2.6.37, let's just revert
it.
Reported-by: NAndy Walls <awalls@md.metrocast.net>
Reported-by: NEric Sharkey <eric@lisaneric.org>
Reported-by: NAuric <auric@aanet.com.au>
Reported by: David Gesswein <djg@pdp8online.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch fixes a regression that crept into 2.6.36.

The volume control scale in the cx25840 driver has an unusual mapping
from register values to v4l2 volume control values.  Enforce the mapping
limits, so that the default volume control setting does not fall out of
bounds to prevent the cx25840 module device probe from failing.
Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

use mv_xor_slot_cleanup() instead of __mv_xor_slot_cleanup() as the former function
aquires the spin lock that needed to protect the drivers data.

Cc: <stable@kernel.org>
Signed-off-by: NSaeed Bishara <saeed@marvell.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

The owner field was removed from struct attribute in
6fd69dc5, so don't assign it anymore.
Signed-off-by: NMaurus Cuelenaere <mcuelenaere@gmail.com>
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

The earlier call to atm_dev_lookup increases the reference count of dev,
so decrease it on the way out.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression x, E;
constant C;
@@

x = atm_dev_lookup(...);
... when != false x != NULL
    when != true x == NULL
    when != \(E = x\|x = E\)
    when != atm_dev_put(dev);
*return -C;
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 56543af9 "starfire: use BUILD_BUG_ON for netdrv_addr_t" revealed
that the preprocessor condition used to find the size of dma_addr_t
yielded the wrong result for some architectures and configurations.
This was kluged for 64-bit PowerPC in commit 3e502e63 by adding yet
another case to the condition.  However, 64-bit MIPS configurations
are not detected reliably either.

This should be fixed by using CONFIG_ARCH_DMA_ADDR_T_64BIT, but that
isn't yet defined everywhere it should be.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Besides -ETIMEDOUT and -EINTR, pci_read_vpd may return other error
values like -ENODEV or -EINVAL which are ignored due to the buggy
check, but the data are not read from VPD anyway and this is checked
subsequently with at most 3 needless loop iterations. This does not
show up as a runtime bug.

CC: Matt Carlson <mcarlson@broadcom.com>
CC: Michael Chan <mchan@broadcom.com>
Signed-off-by: NDavid Sterba <dsterba@suse.cz>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We are leaking memory in drivers/net/cnic.c::cnic_alloc_uio_rings() if
either of the calls to dma_alloc_coherent() fail. This patch fixes it by
freeing both the memory allocated with kzalloc() and memory allocated with
previous calls to dma_alloc_coherent() when there's a failure.

Thanks to  Joe Perches <joe@perches.com>  for suggesting a better
implementation than my initial version.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Acked-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Hi,

In drivers/isdn/gigaset/capi.c::do_disconnect_req() we will leak the
memory allocated (with kmalloc) to 'b3cmsg' if the call to alloc_skb()
fails.

...
		b3cmsg = kmalloc(sizeof(*b3cmsg), GFP_KERNEL);
	allocation here ------^
		if (!b3cmsg) {
			dev_err(cs->dev, "%s: out of memory\n", __func__);
			send_conf(iif, ap, skb, CAPI_MSGOSRESOURCEERR);
			return;
		}
		capi_cmsg_header(b3cmsg, ap->id, CAPI_DISCONNECT_B3, CAPI_IND,
				 ap->nextMessageNumber++,
				 cmsg->adr.adrPLCI | (1 << 16));
		b3cmsg->Reason_B3 = CapiProtocolErrorLayer1;
		b3skb = alloc_skb(CAPI_DISCONNECT_B3_IND_BASELEN, GFP_KERNEL);
		if (b3skb == NULL) {
			dev_err(cs->dev, "%s: out of memory\n", __func__);
			send_conf(iif, ap, skb, CAPI_MSGOSRESOURCEERR);
			return;
	leak here ------^
...

This leak is easily fixed by just kfree()'ing the memory allocated to
'b3cmsg' right before we return. The following patch does that.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Acked-by: NTilman Schmidt <tilman@imap.cc>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 7e24cce3 because it
was never appropriate for mainline.

Do not check for init flag before starting I/O - zram module is unusable
without this fix.

The oops mentioned in the reverted commit message was actually a problem
only with the zram version as present in project's own repository where
we allocate struct zram_stats_cpu upon device initialization.  OTOH, In
mainline/staging version of zram, we allocate struct stats upfront, so
this oops cannot happen in mainline version.

Checking for init_done flag in zram_make_request() results in a *no-op*
for any I/O operation since we simply always return success.  This flag
is actually set when the first write occurs on a zram disk which
triggers its initialization.

Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=25722Reported-by: NDennis Jansen <dennis.jansen@web.de>
Signed-off-by: NNitin Gupta <ngupta@vflare.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

As we have already detected something attached to the chip during
initialisation, always report the LVDS connector status as connected
during probing.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As I feared, whilst this fixed the clocks for the Lenovo U160, it broke
many other machines. So lets reverts commit 448f53a1
and search for the real bug.

Reported-and-tested-by: Travis Hume <travis@computoring.org> [et al]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25842
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32698Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

After grabbing a msg from the msgq, the mcfqspi_work function calls
list_del_init on the mcfqspi->msgq which unintentionally deletes the rest
of the list before it can be processed. If qspi call was made using
spi_sync, this can result in a process hang.
Signed-off-by: NJate Sujjavanich <jsujjavanich@syntech-fuelmaster.com>
Acked-by: NSteven King <sfking@fdwdc.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

When SPI wake up from OFF mode, CS is in the wrong state: force it to the
inactive state.

During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the clocks
and restore context when device is not used.Each time the CS was in the correct
state.  It was only when system was put suspend to ram with off-mode activated
that on resume the CS was in wrong state( ie activated).

Changelog:
* Change from v1 to v2:
  - Rebase on linus/master (after 2.6.37-rc1)
  - Do some clean-up and fix indentation on both patches
  - Add more explanations for patch 2

* Change from v2 to v3:
  - Use directly resume function of spi_master instead of using function
  - from spi_device as Grant Likely pointed it out.
  - Force this transition explicitly for each CS used by a device.

* Change from v3 to v4:
  - Patch clean-up according to Kevin Hilman and checkpatch.
  - Now force CS to be in inactive state only if it was inactive when it was
    suspended.

* Change from v4 to v5:
  - Rebase on linus/master (after 2.6.37-rc3)
  - Collapse some lines as pointed by Grant Likely
  - Fix a spelling

* Change from v5 to v6:
  - Rebase on linus/master (after 2.6.37-rc7)
  - Use CONFIG_SUSPEND instead of CONFIG_PM
  - Didn't use legacy PM methods anymore. Instead, add a struct dev_pm_ops and
    add the resume method there.
  - Fix multi-line comment style

* Change from v6 to v7:
  - Rebase on linus/master (after 2.6.37-rc8)
  - Drop an extra line
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

The intent here was to test if the allocation failed but we tested
"SharedMemSize" instead of "SharedMemAddr" by mistake.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Reviewed-by: NJiri Pirko <jpirko@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Linux would not connect to other router running old version Cisco IOS (12.0).
This is most likely a bug in that version of IOS, since it is fixed
in later versions. As a workaround this patch allows a module parameter
to be set to disable compressing the protocol ID.

See: https://bugzilla.vyatta.com/show_bug.cgi?id=3979

RFC 1990 allows an implementation to formulate MP fragments as if protocol
compression had been negotiated.  This allows us to always send compressed
protocol IDs.  But some implementations don't accept MP fragments with
compressed protocol IDs.  This parameter allows us to interoperate with
them.  The default value of the configurable parameter is the same as the
current behavior:  protocol compression is enabled.  If protocol compression
is disabled we will not send compressed protocol IDs.

This is based on an earlier patch by Bob Gilligan (using a sysctl).
Module parameter is writable to allow for enabling even if ppp
is already loaded for other uses.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
Acked-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch avoids disabling the vlan flags using ethtool.
Signed-off-by: NBreno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A race exists when initializing ueagle-atm devices where the generic atm
device may not yet be created before the driver attempts to initialize
it's PHY signal state, which checks whether the atm device has been
created or not.  This often causes the sysfs 'carrier' attribute to be
'1' even though no signal has actually been found.

uea_probe
   usbatm_usb_probe
      driver->bind (uea_bind)
         uea_boot
            kthread_run(uea_kthread)     uea_kthread
      usbatm_atm_init                       uea_start_reset
         atm_dev_register                      UPDATE_ATM_SIGNAL

UPDATE_ATM_SIGNAL checks whether the ATM device has been created and if
not, will not update the PHY signal state.  Because of the race that
does not always happen in time, and the PHY signal state remains
ATM_PHY_SIG_FOUND even though no signal exists.

To fix the race, just create the kthread during initialization, and only
after initialization is complete, start the thread that reboots the
device and initializes PHY state.

[ 3030.490931] uea_probe: calling usbatm_usb_probe
[ 3030.490946] ueagle-atm 8-2:1.0: usbatm_usb_probe: trying driver ueagle-atm with vendor=1110, product=9031, ifnum  0
[ 3030.493691] uea_bind: setting usbatm
[ 3030.496932] usb 8-2: [ueagle-atm] using iso mode
[ 3030.497283] ueagle-atm 8-2:1.0: usbatm_usb_probe: using 3021 byte buffer for rx channel 0xffff880125953508
   <kthread already started before usbatm_usb_probe() has returned>
[ 3030.497292] usb 8-2: [ueagle-atm] (re)booting started
   <UPDATE_ATM_SIGNAL checks whether ATM device has been created yet before setting PHY state>
[ 3030.497298] uea_start_reset: atm dev (null)
   <and since it hasn't been created yet PHY state is not set>
[ 3030.497306] ueagle-atm 8-2:1.0: usbatm_usb_probe: using 3392 byte buffer for tx channel 0xffff8801259535b8
[ 3030.497374] usbatm_usb_probe: about to init
[ 3030.497379] usbatm_usb_probe: calling usbatm_atm_init
   <atm device finally gets created>
[ 3030.497384] usbatm_atm_init: creating atm device!
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The current code mis-calculates the ramoops header size, leading to an
overflow over the next record at best, or over a non-allocated region at
worst.  Fix that calculation.
Signed-off-by: NAhmed S. Darwish <darwish.07@gmail.com>
Acked-by: NMarco Stornelli <marco.stornelli@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

LCDC hardware can support 1920x1080 formats, adjust the driver to cover them.
Besides, instead of guessing some "reasonable" validity checks, only verify
values in .fb_check_var(), that we are sure, we cannot support.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

MX27 and MX25 have 10 bits in the YMAX field of LCDC Size Register.

Fix the maximum value for yres.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

We don't need or want MSR usage here, on x86-64.
x86-64 was disabled intentionally in Kconfig, but commit
9272dcc2 changed that.

drivers/ata/pata_cs5536.c:47:1: warning: "rdmsr" redefined
In file included from arch/x86/include/asm/irqflags.h:60,
                 from include/linux/irqflags.h:15,
                 from arch/x86/include/asm/system.h:11,
                 from arch/x86/include/asm/processor.h:17,
                 from include/linux/prefetch.h:14,
                 from include/linux/list.h:7,
                 from include/linux/module.h:9,
                 from drivers/ata/pata_cs5536.c:33:
arch/x86/include/asm/paravirt.h:146:1: warning: this is the location of the previous definition
drivers/ata/pata_cs5536.c:48:1: warning: "wrmsr" redefined
arch/x86/include/asm/paravirt.h:154:1: warning: this is the location of the previous definition
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

GPEs with corresponding _Lxx/_Exx control methods need to be disabled
during initialization in case they have been enabled by the BIOS, so
that they don't fire up until they are enabled by acpi_update_gpes().

References: https://bugzilla.kernel.org/show_bug.cgi?id=25412Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Joel Soete reported oopses during pppoe over sundance NIC, caused by
a bug in skb allocation and dma mapping code, where skb_reserve()
bytes weren't taken into account. As a followup to the patch:
"sundance: Fix oopses with corrupted skb_shared_info" very similar
code is fixed here for three other drivers.
Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
Cc: Joel Soete <soete.joel@scarlet.be>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Joel Soete reported oopses at the beginning of pppoe connections since
v2.6.35. After debugging the bug was found in sundance skb allocation
and dma mapping code, where skb_reserve() bytes aren't taken into
account. This is an old bug, only uncovered by some change in 2.6.35.

Initial debugging patch by: Eric Dumazet <eric.dumazet@gmail.com>
Reported-by: NJoel Soete <soete.joel@scarlet.be>
Tested-by: NJoel Soete <soete.joel@scarlet.be>
Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A recent patch has introduced a regression, whereby a second open of an
soc-camera video device breaks the running capture. This patch fixes this bug
by guaranteeing, that video buffers get initialised only during the first open
of the device node.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>