Reduce code size and simplify error path.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Fix to return error code instead always return 0 from function
dell_send_intensity().
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Since commit 61b365a5 ("drm/nouveau: populate master subdev pointer
only when fully constructed"), the nouveau_mxm(bios) call will return
NULL, since it's still being called from the constructor.  Instead, pass
the mxm pointer via the unused data field.

See https://bugs.freedesktop.org/show_bug.cgi?id=73791Reported-by: NAndreas Reis <andreas.reis@gmail.com>
Tested-by: NAndreas Reis <andreas.reis@gmail.com>
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The 32-bit sched_clock() interface supports 64 bits since
3.13-rc1. Upgrade to the 64-bit function to allow us to remove
the 32-bit registration interface.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1389922686-6249-1-git-send-email-sboyd@codeaurora.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

This reverts commit f6308b36 (ACPI: Add BayTrail SoC GPIO and LPSS
ACPI IDs), because it causes the Alan Cox' ASUS T100TA to "crash and
burn" during boot if the Baytrail pinctrl driver is compiled in.

Fixes: f6308b36 (ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs)
Reported-by: NOne Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Requested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 7509963c (e1000e: Fix a compile flag mis-match for
suspend/resume) moved suspend and resume hooks to be available when
CONFIG_PM is set. However, it can be set even if CONFIG_PM_SLEEP is not set
causing following warnings to be emitted:

drivers/net/ethernet/intel/e1000e/netdev.c:6178:12: warning:
  	‘e1000_suspend’ defined but not used [-Wunused-function]

drivers/net/ethernet/intel/e1000e/netdev.c:6185:12: warning:
	‘e1000_resume’ defined but not used [-Wunused-function]

To fix this make the hooks to be available only when CONFIG_PM_SLEEP is set
and remove CONFIG_PM wrapping from driver ops because this is already
handled by SET_SYSTEM_SLEEP_PM_OPS() and SET_RUNTIME_PM_OPS().
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: Dave Ertman <davidx.m.ertman@intel.com>
Cc: Aaron Brown <aaron.f.brown@intel.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

The driver does not check value returned by dma_map_page. The patch
fixes this.

v2: Removed the bugfix for non-bug ;-) (thanks Sathya)
Signed-off-by: NIvan Vecera <ivecera@redhat.com>
Acked-by: NSathya Perla <Sathya.perla@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The bnx2x driver in its pci shutdown() callback releases its pci bars (in the
same manner it does during its pci remove() callback).
During a system reboot while VFs are enabled, its possible for the VF's remove
to be called (as a result of pci_disable_sriov()) after its shutdown callback
has already finished running; This will cause a paging request fault as the VF
tries to access the pci bar which it has previously released, crashing the
system.

This patch further differentiates the shutdown and remove callbacks, preventing the
pci release procedures from being called during shutdown.
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NAriel Elior <ariele@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

rhine_reset_task() misses to disable the tx scheduler upon reset,
this can lead to a crash if work is still scheduled while we're resetting
the tx queue.

Fixes:
[   93.591707] BUG: unable to handle kernel NULL pointer dereference at 0000004c
[   93.595514] IP: [<c119d10d>] rhine_napipoll+0x491/0x6
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add new PCI ID to support new model "Kaveri" family.
Signed-off-by: NPhilip Pokorny <ppokorny@penguincomputing.com>
Cc: stable@vger.kernel.org
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

After a suspend/resume cycle, the NCT6791 is back to its original BIOS
programming. In this state, HWMON IO access may be locked.
Re-enable it during resume.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Some Intel CPUs do not set the 'valid' bit in IA32_THERM_STATUS if the
temperature is too low to be measured. This condition will not change until
the CPU is hot enough for its temperature to be measured. Returning an error
in such conditions is not very useful. Drop checking the valid bit and just
return the reported temperature instead.
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

The ADC resolution of the PMIC is 10-bits, this means that the maximum
possible value is 1023 and not the 1024 as originally in the code.
Signed-off-by: NAnthony Olech <anthony.olech.opensource@diasemi.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Intel's turbostat code uses only 7 bits from MSR_IA32_TEMPERATURE_TARGET to
read TjMax, and also only accepts it if the reported temperature is at least
85 degrees C. Play safe and do the same.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Since we now have to use PCI IDs to detect CPU types anyway, use this mechanism
to detect CE41x0 CPUs. Advantage is that it only requires a single entry and
covers all variants of CE41x0, including those unknown to us.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Atom S12x0 CPUs are identified by the CPU host bridge ID. Add an override
table based on PCI IDs as well as code to detect it.

PCI access functions can now be called with PCI disabled, so unlike previous
attempts to use PCI IDs, the code no longer depends on it. If PCI is disabled,
the CPU will not be identified correctly. Since it is unlikely that anything
will work in this case, this is an acceptable limitation.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro
is not preferred.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Regression from "device: populate master subdev pointer only when fully
constructed"
Reported-by: NBob Gleitsmann <rjgleits@bellsouth.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

vlan gets the same netdev features except vlan filter.
Signed-off-by: NJitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A number of new dm96xx variants now exist.
Reported-by: NJoseph Chang <joseph_chang@davicom.com.tw>
Signed-off-by: NPeter Korsgaard <peter@korsgaard.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When the core number exceeds 9, the size of the buffer storing the
alarm attribute name is insufficient and the attribute name is
truncated. This causes libsensors to skip these attributes as the
truncated name is not recognized.
Reported-by: NAndreas Hollmann <hollmann@in.tum.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: stable@vger.kernel.org
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Introduce function for the "Perform network-subchannel operation"
CHSC command with operation code "bridgeport information",
and bit definitions for "characteristics" pertaning to this command.
Signed-off-by: NEugene Crosser <eugene.crosser@ru.ibm.com>
Reviewed-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Commit 60e453a9 ("USBNET: fix handling padding packet")
added an extra SG entry in case padding is necessary, but
failed to update the initialisation of the list. This can
cause list traversal to fall off the end of the list,
resulting in an oops.

Fixes: 60e453a9 ("USBNET: fix handling padding packet")
Reported-by: NThomas Kear <thomas@kear.co.nz>
Cc: Ming Lei <ming.lei@canonical.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Tested-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If an array is started degraded, and then the missing device
is found it can be re-added and a minimal bitmap-based recovery
will bring it fully up-to-date.

If the array is read-only a recovery would not be allowed.
But also if the array is read-only and the missing device was
present very recently, then there could be no need for any
recovery at all, so we simply include the device in the read-only
array without any recovery.

However... if the missing device was removed a little longer ago
it could be missing some updates, but if a bitmap is present it will
be conditionally accepted pending a bitmap-based update.  We don't
currently detect this case properly and will include that old
device into the read-only array with no recovery even though it really
needs a recovery.

This patch keeps track of whether a bitmap-based-recovery is really
needed or not in the new Bitmap_sync rdev flag.  If that is set,
then the device will not be added to a read-only array.

Cc: Andrei Warkentin <andreiw@vmware.com>
Fixes: d70ed2e4
Cc: stable@vger.kernel.org (3.2+)
Signed-off-by: NNeilBrown <neilb@suse.de>

commit e875ecea
    md/raid10 record bad blocks as needed during recovery.

added code to the "cannot recover this block" path to record a bad
block rather than fail the whole recovery.
Unfortunately this new case was placed *after* r10bio was freed rather
than *before*, yet it still uses r10bio.
This is will crash with a null dereference.

So move the freeing of r10bio down where it is safe.

Cc: stable@vger.kernel.org (v3.1+)
Fixes: e875eceaReported-by: NDamian Nowak <spam@nowaker.net>
URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181Signed-off-by: NNeilBrown <neilb@suse.de>

commit 6d183de4
    md/raid5: fix newly-broken locking in get_active_stripe.

simplified a BUG_ON, but removed too much so now it sometimes fires
when it shouldn't.

When the STRIPE_EXPANDING flag is set, the stripe_head might be on a
special list while multiple stripe_heads are collected, or it might
not be on any list, even a 'free' list when the refcount is zero.  As
long as STRIPE_EXPANDING is set, it will be found and added back to a
list eventually.

So both of the BUG_ONs which test for the ->lru being empty or not
need to avoid the case where STRIPE_EXPANDING is set.

The patch which broke this was marked for -stable, so this patch needs
to be applied to any branch that received 6d183de4

Fixes: 6d183de4
Cc: stable@vger.kernel.org (any release to which above was applied)
Signed-off-by: NNeilBrown <neilb@suse.de>

The new iobarrier implementation in raid1 (which keeps normal writes
and resync activity separate) counts every request what is not before
the current resync point in either next_window_requests or
current_window_requests.
It flags that the request is counted by setting ->start_next_window.

allow_barrier follows this model exactly and decrements one of the
*_window_requests if and only if ->start_next_window is set.

However wait_barrier(), which increments *_window_requests uses a
slightly different test for setting -.start_next_window (which is set
from the return value of this function).
So there is a possibility of the counts getting out of sync, and this
leads to the resync hanging.

So change wait_barrier() to return a non-zero value in exactly the
same cases that it increments *_window_requests.

But was introduced in 3.13-rc1.
Reported-by: NBruno Wolff III <bruno@wolff.to>
URL: https://bugzilla.kernel.org/show_bug.cgi?id=68061
Fixes: 79ef3a8a
Cc: majianpeng <majianpeng@gmail.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

If we discover a bad block when reading we split the request and
potentially read some of it from a different device.

The code path of this has two bugs in RAID10.
1/ we get a spin_lock with _irq, but unlock without _irq!!
2/ The calculation of 'sectors_handled' is wrong, as can be clearly
   seen by comparison with raid1.c

This leads to at least 2 warnings and a probable crash is a RAID10
ever had known bad blocks.

Cc: stable@vger.kernel.org (v3.1+)
Fixes: 856e08e2Reported-by: NDamian Nowak <spam@nowaker.net>
URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181Signed-off-by: NNeilBrown <neilb@suse.de>

commit 5d8c71f9
    md: raid5 crash during degradation

Fixed a crash in an overly simplistic way which could leave
R5_WriteError or R5_MadeGood set in the stripe cache for devices
for which it is no longer relevant.
When those devices are removed and spares added the flags are still
set and can cause incorrect behaviour.

commit 14a75d3e
    md/raid5: preferentially read from replacement device if possible.

Fixed the same bug if a more effective way, so we can now revert
the original commit.
Reported-and-tested-by: NAlexander Lyakas <alex.bolshoy@gmail.com>
Cc: stable@vger.kernel.org (3.2+ - 3.2 will need a different fix though)
Fixes: 5d8c71f9Signed-off-by: NNeilBrown <neilb@suse.de>

This reverts commit 3fbd6439.

This caused some strange booting lockup issues on an Intel G33
belonging to Daniel Vetter, very unusual, I was hoping Daniel
would track this down, but it looks like instead I'll have to hack
a different fix for -next.
Signed-off-by: NDave Airlie <airlied@redhat.com>

There was only one macro in here, LL_CDEBUG_PAGE().  So open code it in
the 2 places it was used so that the developer seeing it can see just
how horrid it really is, and they can remove it as I doubt it really is
ever needed anymore.  But for now, keep the same functionality and
remove a whole file (with a duplicate name of other files in the lustre
repo, another confusion...)

Cc: Peng Tao <bergwolf@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Odd page size checks aren't even being used, so delete them so no one
gets a bright idea to use them ever.

Cc: Peng Tao <bergwolf@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The uart timer will schedule a tasklet when it fires. It is possible that it
can fire inside _shutdown before it is killed in the dma and pdc cleanup
routines. This causes a tasklet that exists after the port is shutdown, so when
the kernel finally executes it, it panics as the tty port is NULL.

This is a somewhat rare condition but its possible if a program keeps on
opening/closing the port. It has been observed in particular with systemd
boot messages that were causing a kernel panic because of this behavior.

Moving the timer deletion to the beginning of the function stops a tasklet from
being scheduled unexpectedly.
Signed-off-by: NMarek Roszko <mark.roszko@gmail.com>
Cc: stable <stable@vger.kernel.org> # v3.12
[nicolas.ferre@atmel.com: modify commit message, call setup_timer() in any case]
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We have met a bug that the high bandwidth ISO-TX transfer has failed
at the last packet if it is less than 1024, the TD status shows it
is "Transaction Error".

The root cause of this problem is: the mult value at qh is not correct
for current TD's transfer length. We use TD list to queue un-transfer
TDs, and change mult for new adding TDs. If new adding TDs transfer length
less than 1024, but the queued un-transfer TDs transfer length is larger
than 1024, the transfer error will occur, and vice versa.
Usually, this problem occurs at the last packet, and the first packet for
new frame.

We fixed this problem by setting Mult at QH as the largest value (3), and
set MultO (Multiplier Override) at TD according to every transfer length.
It can cover both hardware version less than 2.3 (the real mult is MultO
if it is not 0) and 2.3+ (the real mult is min(qh.mult, td.multo)).

Since the MultO bits are only existed at TX TD, we keep the ISO-RX behavior
unchanged.

For stable tree: 3.11+.

Cc: stable <stable@vger.kernel.org>
Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
Reported-by: NMatthieu Vanin <b47495@freescale.com>
Tested-by: NMatthieu Vanin <b47495@freescale.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For otgsc, both enable bits and status bits are in it. So we need
to make sure the status bits are not be cleared when write enable
bits. It can fix one bug that we plug in/out Micro AB cable fast,
and sometimes, the IDIS will be cleared wrongly when handle last
ID interrupt (ID 0->1), so the current interrupt will not occur.

For stable tree: 3.12+

Cc: stable@vger.kernel.org
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

hw_phymode_configure configures the PORTSC registers and allow the
following phy_inits to operate on the right parameters. This fix a problem
where the UPLI (ISP1504) could not be detected, because the Viewport was not
available and read the viewport return 0's only.
Signed-off-by: NChris Ruehl <chris.ruehl@gtsys.com.hk>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

* init the sts flag to 0 (missed)
* fix write the real bit not sts value
* Set PORTCS_STS and DEVLC_STS only if sts = 1

[Peter Chen: This one and the next patch fix the problem occurred imx27
and imx31, and imx27 and imx31 usb support are enabled until 3.14, so
these two patches isn't needed for -stable]
Signed-off-by: NChris Ruehl <chris.ruehl@gtsys.com.hk>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Due to imx28 needs ARM swp instruction for writing, we set
CI_HDRC_IMX28_WRITE_FIX for imx28.

This patch is needed for stable tree 3.11+

Cc: stable@vger.kernel.org
Cc: robert.hodaszi@digi.com
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Tested-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
register error issue", All USB register write operations must
use the ARM SWP instruction. So, we implement special hw_write
and hw_test_and_clear for imx28.

Discussion for it at below:
http://marc.info/?l=linux-usb&m=137996395529294&w=2

This patch is needed for stable tree 3.11+.

Cc: stable@vger.kernel.org
Cc: robert.hodaszi@digi.com
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Tested-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>