When we allow for separate devices for data and metadata
in a later patch, we will need to be able to calculate
the superblock offset based on more than the bdev.
Signed-off-by: NJonathan Brassow <jbrassow@redhat.com>

Setting ->recovery to 0 is generally not a good idea as it could clear
bits that shouldn't be cleared.  In particular, MD_RECOVERY_FROZEN
should only be cleared on explicit request from user-space.

So when we need to clear things, just clear the bits that need
clearing.

As there are a few different places which reap a resync process - and
some do an incomplte job - factor out the code for doing the from
md_check_recovery and call that function instead of open coding part
of it.
Signed-off-by: NNeilBrown <neilb@suse.de>
Reported-by: NJonathan Brassow <jbrassow@redhat.com>

As md_stop_writes manipulates the sync_thread and calls md_update_sb,
it need to be called with mddev_lock held.

In all internal cases it is, but the symbol is exported for dm-raid to
call and in that case the lock won't be help.
Do make an exported version which takes the lock, and an internal
version which does not.
Signed-off-by: NNeilBrown <neilb@suse.de>

With the module parameter 'start_dirty_degraded' set,
raid5_spare_active() previously called sysfs_notify_dirent() with a NULL
argument (rdev->sysfs_state) when a rebuild finished.
Signed-off-by: NJonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>

When an md device is in the process of coming on line it is possible
for an IO request (typically a partition table probe) to get through
before the array is fully initialised, which can cause unexpected
behaviour (e.g. a crash).

So explicitly record when the array is ready for IO and don't allow IO
through until then.

There is no possibility for a similar problem when the array is going
off-line as there must only be one 'open' at that time, and it is busy
off-lining the array and so cannot send IO requests.  So no memory
barrier is needed in md_stop()

This has been a bug since commit 409c57f3 in 2.6.30 which
introduced md_make_request.  Before then, each personality would
register its own make_request_fn when it was ready.
This is suitable for any stable kernel from 2.6.30.y onwards.

Cc: <stable@kernel.org>
Signed-off-by: NNeilBrown <neilb@suse.de>
Reported-by: N"Hawrylewicz Czarnowski, Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@intel.com>

Noticed-by: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

commit 589a594b (2.6.37-rc4) fixed a problem were md_thread would
sometimes call the ->run function at a bad time.

If an error is detected during array start up after the md_thread has
been started, the md_thread is killed.  This resulted in the ->run
function being called once.  However the array may not be in a state
that it is safe to call ->run.

However the fix imposed meant that  ->run was not called on a timeout.
This means that when an array goes idle, bitmap bits do not get
cleared promptly.  While the array is busy the bits will still be
cleared when appropriate so this is not very serious.  There is no
risk to data.

Change the test so that we only avoid calling ->run when the thread
is being stopped.  This more explicitly addresses the problem situation.

This is suitable for 2.6.37-stable and any -stable kernel to which
589a594b was applied.

Cc: stable@kernel.org
Signed-off-by: NNeilBrown <neilb@suse.de>

Commit 1a855a06 (2.6.37-rc4) fixed a problem where devices were
re-added when they shouldn't be but caused a regression in a less
common case that means sometimes devices cannot be re-added when they
should be.

In particular, when re-adding a device to an array without metadata
we should always access the device, but after the above commit we
didn't.

This patch sets the In_sync flag in that case so that the re-add
succeeds.

This patch is suitable for any -stable kernel to which 1a855a06 was
applied.

Cc: stable@kernel.org
Signed-off-by: NNeilBrown <neilb@suse.de>

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>

This reverts commit 3138b32d.

as it caused a crash upon battery removal:
https://bugzilla.kernel.org/show_bug.cgi?id=25302Signed-off-by: NLen Brown <len.brown@intel.com>

Low level drivers may behave differently depending on the current
link->lpm_policy.  During ata_eh_set_lpm(), DIPM enable commands are
issued after the successful completion of ap->ops->set_lpm(), which
means that the controller is already in the target state.  This causes
DIPM enable commands to be processed with mismatching controller power
state and link->lpm_policy value.

In ahci, link->lpm_policy is used to ignore certain PHY events if LPM
is enabled; however, as DIPM commands are issued with stale
link->lpm_policy, they sometimes end up triggering these conditions
and get aborted leading to LPM configuration failure.

Fix it by updating link->lpm_policy before issuing DIPM enable
commands.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NKyle McMartin <kyle@mcmartin.ca>
Cc: stable@kernel.org
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

ata_qc_complete() contains special handling for certain commands.  For
example, it schedules EH for device revalidation after certain
configurations are changed.  These shouldn't be applied to EH
commands but they were.

In most cases, it doesn't cause an actual problem because EH doesn't
issue any command which would trigger special handling; however, ACPI
can issue such commands via _GTF which can cause weird interactions.

Restructure ata_qc_complete() such that EH commands are always passed
on to __ata_qc_complete().

stable: Please apply to -stable only after 2.6.38 is released.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NKyle McMartin <kyle@mcmartin.ca>
Cc: stable@kernel.org
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Found by this build-error if BMDMA is disabled:

drivers/ata/pata_mpc52xx.c: In function 'mpc52xx_ata_init_one':
drivers/ata/pata_mpc52xx.c:662: error: 'ata_bmdma_interrupt' undeclared (first use in this function)
...

Move the Kconfig entry to the proper location as needed since
9a7780c9 (libata-sff: make BMDMA optional)
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>