New TI LP55231 device has same I2C register layout as LP5523. Therefore,
all of LED operations can be shared with the LP5523 driver.

To support new LP55231 device explicitly, the device description
is added in the configuration file.
Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>

Some triggers create sysfs files when they are enabled. Send a uevent
"change" notification whenever the trigger is changed to allow userspace
processes such as udev to modify permissions on the new files.

A change notification will also be sent during registration of led class
devices or led triggers if the default trigger of an led class device
is found.

(bryan.wu@canonical.com: rename trigger to trig to fix the build error)
Signed-off-by: NColin Cross <ccross@android.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>

(a) use LP5523_ENABLE rather than magic number 0x40
(b) use min_t() in lp5523_mux_parse()
(c) skip while loop and just return if invalid command
Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>

The return value of this function is not handled any place, so
make it as void type.

And three if-statements are replaced with switch-statements.
Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>

Turning off the brightness of each channel is required
when removing the driver.

So use flush_work() rather than cancel_work_sync() to execute
remaining brightness works.
Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>

The name of each led channel is configurable.
If the name is NULL, just use the channel id for making the channel name
Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>

Use of_get_child_count() instead of custom implementation.
Signed-off-by: NTobias Klauser <klto@zhaw.ch>
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>

Use the wrapper functions, so we can directly pass a struct
platfrom_device.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>

Instead of having to define the match table to NULL if CONFIG_OF isn't
set, use the of_match_ptr() macro which will do this for us.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>

Delay execution of led_set_brightness() if need to stop soft-blink
timer.

This allows led_set_brightness to be called in hard-irq context even if
soft-blink was activated on that LED.
Signed-off-by: NFabio Baltieri <fabio.baltieri@gmail.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>

Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>

There are more variants of Clevo M5x0V laptops and Positivo Mobile is just one of them.
Another one is UMAX VisionBook 2400WXC. Use only generic Clevo DMI strings to match all
variants.
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>

Enable autoloading of leds-clevo-mail by using MODULE_DEVICE_TABLE.
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>

c1dcad2d added a new driver configured by
HID_LENOVO_TPKBD but made the hid_have_special_driver entry non-optional which
lead to a recognized but non-working device if the new driver wasn't
configured (which is the correct default).
Signed-off-by: NAndres Freund <andres@anarazel.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When we do FLR and save PCI config we did it in the wrong order.
The end result was that if a PCI device was unbind from
its driver, then binded to xen-pciback, and then back to its
driver we would get:

> lspci -s 04:00.0
04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
13:42:12 # 4 :~/
> echo "0000:04:00.0" > /sys/bus/pci/drivers/pciback/unbind
> modprobe e1000e
e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
e1000e 0000:04:00.0: Disabling ASPM L0s L1
e1000e 0000:04:00.0: enabling device (0000 -> 0002)
xen: registering gsi 48 triggering 0 polarity 1
Already setup the GSI :48
e1000e 0000:04:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e: probe of 0000:04:00.0 failed with error -2

This fixes it by first saving the PCI configuration space, then
doing the FLR.
Reported-by: NRen, Yongjie <yongjie.ren@intel.com>
Reported-and-Tested-by: NTobias Geiger <tobias.geiger@vido.info>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: stable@vger.kernel.org

Allocate a structure not a pointer to it !
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.

The underlaying reason is that if the supplied driver passes in a
DMA_BIT_MASK(64) ( hwdev->coherent_dma_mask is set to 0xffffffffffffffff)
our dma_mask will be u64 set to 0xffffffffffffffff even if we set it to
DMA_BIT_MASK(32) previously. Meaning we do not reset the upper bits.
By using the dma_alloc_coherent_mask function - it does the proper casting
and we get 0xfffffffff.

This caused not working sound on a system with 4 GB and a 64-bit
compatible sound-card with sets the DMA-mask to 64bit.

On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
DMA-memory is always allocated inside the 32-bit address-range by calling
dma_alloc_coherent_mask.

This patch adds the same functionality to xen swiotlb and is a rebase of the
original patch from Ronny Hegewald which never got upstream b/c the
underlaying reason was not understood until now.

The original email with the original patch is in:
http://old-list-archives.xen.org/archives/html/xen-devel/2010-02/msg00038.html
the original thread from where the discussion started is in:
http://old-list-archives.xen.org/archives/html/xen-devel/2010-01/msg00928.htmlSigned-off-by: NRonny Hegewald <ronny.hegewald@online.de>
Signed-off-by: NStefano Panella <stefano.panella@citrix.com>
Acked-By: NDavid Vrabel <david.vrabel@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: stable@vger.kernel.org

After commit 26b88520 ("mmc:
omap_hsmmc: remove private DMA API implementation"), the Nokia N800
here stopped booting:

[    2.086181] Waiting for root device /dev/mmcblk0p1...
[    2.324066] Unhandled fault: imprecise external abort (0x406) at 0x00000000
[    2.331451] Internal error: : 406 [#1] ARM
[    2.335784] Modules linked in:
[    2.339050] CPU: 0    Not tainted  (3.6.0-rc3 #60)
[    2.344146] PC is at default_idle+0x28/0x30
[    2.348602] LR is at trace_hardirqs_on_caller+0x15c/0x1b0

...

This turned out to be due to memory corruption caused by long-broken
PIO code in drivers/mmc/host/omap.c.  (Previously, this driver had
been using DMA; but the above commit caused the MMC driver to fall
back to PIO mode with an unmodified Kconfig.)

The PIO code, added with the rest of the driver in commit
730c9b7e ("[MMC] Add OMAP MMC host
driver"), confused bytes with 16-bit words.  This bug caused memory
located after the PIO transfer buffer to be corrupted with transfers
larger than 32 bytes.  The driver also did not increment the buffer
pointer after the transfer occurred.  This bug resulted in data
corruption during any transfer larger than 64 bytes.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

For several MoviNAND eMMC parts, there are known issues with secure
erase and secure trim.  For these specific MoviNAND devices, we skip
these operations.

Specifically, there is a bug in the eMMC firmware that causes
unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE
enabled.

References:

http://forum.xda-developers.com/showthread.php?t=1644364
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkBSigned-off-by: NIan Chen <ian.cy.chen@samsung.com>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: stable <stable@vger.kernel.org> [3.0+]
Signed-off-by: NChris Ball <cjb@laptop.org>

The documentation for the dw_mmc part says that the low power
mode should normally only be set for MMC and SD memory and should
be turned off for SDIO cards that need interrupts detected.

The best place I could find to do this is when the SDIO interrupt
was first enabled.  I rely on the fact that dw_mci_setup_bus()
will be called when it's time to reenable.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Data transfer will be continued until all the bytes are transmitted,
even if data crc error occurs during a multiple-block data transfer.
This means RXDR/TXDR interrupts will occurs until data transfer is
terminated. Early setting of host->sg to NULL prevents going into
xxx_data_pio functions, hence permanent unhandled RXDR/TXDR interrupts
occurs. And checking error interrupt status in the xxx_data_pio functions
is no need because dw_mci_interrupt does do the same. This patch also
removes it.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NWill Newton <will.newton@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Datasheet of SYNOPSYS mentions that DTO(Data Transfer Over) interrupt
will be raised even if some error interrupts, however it is actually
found that DTO does not occur. SYNOPSYS has confirmed this issue.
Current implementation defers the call of tasklet_schedule until DTO
when the error interrupts is happened. This patch fixes error handling.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NWill Newton <will.newton@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

RINTSTS status includes masked interrupts as well as unmasked.
data_status and cmd_status are set by value of RINTSTS in interrupt handler
and tasklet finally uses it to decide whether error is happened or not.
In addition, MINTSTS status is used for setting data_status in PIO.
Masked error interrupt will not be handled and that status can be considered
non-error case.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Reviewed By: Girish K S <girish.shivananjappa@linaro.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NWill Newton <will.newton@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Even if the datasheet says that the not busy flag has to be used only
for write operations, it's false except for version lesser than v2xx.

Not waiting on the not busy flag for read operations can cause the
controller to hang-up during the initialization of some SD cards
with DMA after the first CMD6 -- the next command is sent too early.
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Cc: stable <stable@vger.kernel.org> [3.5, 3.6]
Signed-off-by: NChris Ball <cjb@laptop.org>

Since commit 30832ab5 ("mmc: sdhci: Always pass clock request value
zero to set_clock host op") was merged, esdhc_set_clock starts hitting
"if (clock == 0)" where ESDHC_SYSTEM_CONTROL has been operated.  This
causes SDHCI card-detection function being broken.  Fix the regression
by moving "if (clock == 0)" above ESDHC_SYSTEM_CONTROL operation.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Release the lock before mmc_signal_sdio_irq is called by
mxs_mmc_enable_sdio_irq.

Backtrace:
[   65.470000] =============================================
[   65.470000] [ INFO: possible recursive locking detected ]
[   65.470000] 3.5.0-rc5 #2 Not tainted
[   65.470000] ---------------------------------------------
[   65.470000] ksdioirqd/mmc0/73 is trying to acquire lock:
[   65.470000]  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
[   65.470000]
[   65.470000] but task is already holding lock:
[   65.470000]  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
[   65.470000]
[   65.470000] other info that might help us debug this:
[   65.470000]  Possible unsafe locking scenario:
[   65.470000]
[   65.470000]        CPU0
[   65.470000]        ----
[   65.470000]   lock(&(&host->lock)->rlock#2);
[   65.470000]   lock(&(&host->lock)->rlock#2);
[   65.470000]
[   65.470000]  *** DEADLOCK ***
[   65.470000]
[   65.470000]  May be due to missing lock nesting notation
[   65.470000]
[   65.470000] 1 lock held by ksdioirqd/mmc0/73:
[   65.470000]  #0:  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
[   65.470000]
[   65.470000] stack backtrace:
[   65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98)
[   65.470000] [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98) from [<c005d3f8>] (lock_acquire+0xa0/0x108)
[   65.470000] [<c005d3f8>] (lock_acquire+0xa0/0x108) from [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c)
[   65.470000] [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc])
[   65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc])
[   65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274)
[   65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98)
[   65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8)
[   65.470000] BUG: spinlock lockup suspected on CPU#0, ksdioirqd/mmc0/73
[   65.470000]  lock: 0xc3358724, .magic: dead4ead, .owner: ksdioirqd/mmc0/73, .owner_cpu: 0
[   65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c01b46b0>] (do_raw_spin_lock+0x100/0x144)
[   65.470000] [<c01b46b0>] (do_raw_spin_lock+0x100/0x144) from [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c)
[   65.470000] [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc])
[   65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc])
[   65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274)
[   65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98)
[   65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8)
Reported-by: NAttila Kinali <attila@kinali.ch>
Signed-off-by: NLauri Hintsala <lauri.hintsala@bluegiga.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Release the lock before mmc_signal_sdio_irq is called by mxs_mmc_irq_handler.

Backtrace:
[   79.660000] =============================================
[   79.660000] [ INFO: possible recursive locking detected ]
[   79.660000] 3.4.0-00009-g3e96082-dirty #11 Not tainted
[   79.660000] ---------------------------------------------
[   79.660000] swapper/0 is trying to acquire lock:
[   79.660000]  (&(&host->lock)->rlock#2){-.....}, at: [<c026ea3c>] mxs_mmc_enable_sdio_irq+0x18/0xd4
[   79.660000]
[   79.660000] but task is already holding lock:
[   79.660000]  (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8
[   79.660000]
[   79.660000] other info that might help us debug this:
[   79.660000]  Possible unsafe locking scenario:
[   79.660000]
[   79.660000]        CPU0
[   79.660000]        ----
[   79.660000]   lock(&(&host->lock)->rlock#2);
[   79.660000]   lock(&(&host->lock)->rlock#2);
[   79.660000]
[   79.660000]  *** DEADLOCK ***
[   79.660000]
[   79.660000]  May be due to missing lock nesting notation
[   79.660000]
[   79.660000] 1 lock held by swapper/0:
[   79.660000]  #0:  (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8
[   79.660000]
[   79.660000] stack backtrace:
[   79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c005f9c0>] (__lock_acquire+0x1948/0x1d48)
[   79.660000] [<c005f9c0>] (__lock_acquire+0x1948/0x1d48) from [<c005fea0>] (lock_acquire+0xe0/0xf8)
[   79.660000] [<c005fea0>] (lock_acquire+0xe0/0xf8) from [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58)
[   79.660000] [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4)
[   79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8)
[   79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254)
[   79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c)
[   79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110)
[   79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50)
[   79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84)
[   79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60)
[   79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40)
[   79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc)
[   79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8)
[   79.660000] BUG: spinlock lockup on CPU#0, swapper/0
[   79.660000]  lock: c398cb2c, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0
[   79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144)
[   79.660000] [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144) from [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58)
[   79.660000] [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4)
[   79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8)
[   79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254)
[   79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c)
[   79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110)
[   79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50)
[   79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84)
[   79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60)
[   79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40)
[   79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc)
[   79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8)
Signed-off-by: NLauri Hintsala <lauri.hintsala@bluegiga.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Descriptor array structure has been moved into blackfin dma.h head file.
This patch fix below error:

drivers/mmc/host/bfin_sdh.c:52:8: error: redefinition of 'struct
dma_desc_array'
make[4]: *** [drivers/mmc/host/bfin_sdh.o] Error 1
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NBob Liu <lliubbo@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

UBI was mistakingly using 'kfree()' instead of 'kmem_cache_free()' when
freeing "attach eraseblock" structures in vtbl.c. Thankfully, this happened
only when we were doing auto-format, so many systems were unaffected. However,
there are still many users affected.

It is strange, but the system did not crash and nothing bad happened when
the SLUB memory allocator was used. However, in case of SLOB we observed an
crash right away.

This problem was introduced in 2.6.39 by commit
"6c1e875c UBI: add slab cache for ubi_scan_leb objects"

A note for stable trees:
  Because variable were renamed, this won't cleanly apply to older kernels.
  Changing names like this should help:
	1. ai -> si
	2. aeb_slab_cache -> seb_slab_cache
	3. new_aeb -> new_seb
Reported-by: NRichard Genoud <richard.genoud@gmail.com>
Tested-by: NRichard Genoud <richard.genoud@gmail.com>
Tested-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: stable@vger.kernel.org [v2.6.39+]
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Going through the motions of printing the debug message information
takes a long time; using the keyboard can lead to a 160 us irqsoff
latency. This patch skips hid_dump_input() when there are no open
handles, which brings latency down to 100 us.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Gobi devices are composite, needing both the qcserial and
qmi_wwan drivers to support all functions.  Re-syncing the
list of supported devices with qcserial.

Cc: Aleksander Morgado <aleksander@lanedo.com>
Cc: Thomas Tuttle <ttuttle@chromium.org>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@tempietto.lan>

The intent was to set 4 bytes of data so that's why the sp_len is set
to 4 on the next line.  The cast to u_long pointer clears 8 bytes
on 64 bit arches.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid S. Miller <davem@tempietto.lan>

This driver can be built as a module, set the missing owner field of
struct gpio_chip to prevent removal of modules exporting active GPIOs.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

irq_alloc_descs() returns negative error code on failure.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Make GPIO_MC9S08DZ60 depend on I2C=y, this fixes below build error:

  LD      init/built-in.o
drivers/built-in.o: In function `mc9s08dz60_get_value':
clk-fixed-factor.c:(.text+0x7214): undefined reference to `i2c_smbus_read_byte_data'
drivers/built-in.o: In function `mc9s08dz60_set':
clk-fixed-factor.c:(.text+0x727c): undefined reference to `i2c_smbus_read_byte_data'
clk-fixed-factor.c:(.text+0x72bc): undefined reference to `i2c_smbus_write_byte_data'
drivers/built-in.o: In function `mc9s08dz60_i2c_driver_init':
clk-fixed-factor.c:(.init.text+0x290): undefined reference to `i2c_register_driver'
drivers/built-in.o: In function `mc9s08dz60_i2c_driver_exit':
clk-fixed-factor.c:(.exit.text+0x2c): undefined reference to `i2c_del_driver'
make: *** [vmlinux] Error 1
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

davinci mdio device is not unregistered from mdiobus when removing
the module, which causes BUG_ON() when free the device from mdiobus.

Calling mdiobus_unregister() before mdiobus_free() fixes the issue.
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Foxconn-branded Novatel E396, Gobi3k modem.

Cc: Dan Williams <dcbw@redhat.com>
Cc: Bjørn Mork <bjorn@mork.no>
Cc: Ben Chan <benchan@google.com>
Signed-off-by: NAleksander Morgado <aleksander@lanedo.com>
Acked-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A usbnet device can share a multifunction device
with a storage device. If the storage device is autoresumed
the usbnet devices also needs to be autoresumed. Allocating
memory with GFP_KERNEL can deadlock in this case.

This should go back into all kernels that have
commit 65841fd5
That is 3.5
Signed-off-by: NOliver Neukum <oneukum@suse.de>
CC: stable@kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The RxCFG register of the CS89x0 could be configured incorrectly
(because of misplaced parentheses), resulting in the disabling
of packet reception.
Signed-off-by: NJaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch correct poll_bnx2x (ndo_poll_controller call) which was not
functioning well with MSI-X.
Signed-off-by: NMerav Sicron <meravs@broadcom.com>
Signed-off-by: NDmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>