The only function of these 'prepare' and 'complete' is to
disable the 'card detect' irq during suspend.

The commit which added this,
commit a48ce884
    mmc: omap_hsmmc: Introduce omap_hsmmc_prepare/complete

justified it by the need to avoid the registration of new devices
during suspend.
However mmc_pm_notify will set ->rescan_disable in the 'prepare'
stage and clear it in the 'complete' stage, so no card detection
will actually happen.
Also the interrupt will be disabled before final suspend as part
of common suspend processing.

So this disabling of the interrupt is unnecessary, and interferes
with a transition to using common code for card-detect management.

Cc: Felipe Balbi <balbi@ti.com>
Cc: Venkatraman S <svenkatr@ti.com>
Cc: Chris Ball <cjb@laptop.org>
Signed-off-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Fix returning IRQ_HANDLED with spin_lock held.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Use the module_pci_driver() macro to make the code simpler
by eliminating module_init and module_exit calls.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The commit 0718e59a ("mmc: sdhci: move FSL ESDHC reset handling quirk into
esdhc code") states that Freescale esdhc is the only controller which needs
the interrupt registers restored after a reset. So it moves
SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET quirk handling code into the
esdhc-imx driver only. Unfortunately the same controller is used in
other boards which use the of-esdhc driver instead (like powerpc P2020).

Restore interrupts after reset in the sdhci-of-esdhc driver also.
Signed-off-by: NAlessio Igor Bogani <alessio.bogani@elettra.eu>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add manual tuning function in CSR atlas7 SoC. It is mainly used
for the UHS-I SD card working SDR50 SDR104 mode.

The tuning principle can be seen in SD spec part1 v3.01 4.2.4.5
(tuning command).

SD host send the cmd19 and set the delay value(0-127).
and the sdcard return 64 bytes data. If the data is same with
the tuning data. The delay value is valid. Execute this commmand
128 times. And calculate the longest window of the valid values.
The value in the middle of this window is the best value.
Signed-off-by: NMinda Chen <Minda.Chen@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

We're running into cases where our enabling of the SDIO interrupt in
dw_mmc doesn't actually take effect.  Specifically, adding patch like
this:

 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -1076,6 +1076,9 @@ static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, int enb)

      mci_writel(host, INTMASK,
           (int_mask | SDMMC_INT_SDIO(slot->id)));
 +    int_mask = mci_readl(host, INTMASK);
 +    if (!(int_mask & SDMMC_INT_SDIO(slot->id)))
 +      dev_err(&mmc->class_dev, "failed to enable sdio irq\n");
    } else {

...actually triggers the error message.  That's because the
dw_mci_enable_sdio_irq() unsafely does a read-modify-write of the
INTMASK register.

We can't just use the standard host->lock since that lock is not irq
safe and mmc_signal_sdio_irq() (called from interrupt context) calls
dw_mci_enable_sdio_irq().  Add a new irq-safe lock to protect INTMASK.

An alternate solution to this is to punt mmc_signal_sdio_irq() to the
tasklet and then protect INTMASK modifications by the standard host
lock.  This seemed like a bit more of a high-latency change.
Reported-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In the patch (9623b5b9 mmc: dw_mmc: Disable low power mode if SDIO
interrupts are used) I added code that disabled the low power mode of
dw_mmc when SDIO interrupts are used.  That code worked but always
felt a little hacky because we ended up disabling low power as a side
effect of the first enable_sdio_irq() call.  That wouldn't be so bad
except that disabling low power involves a complicated process of
writing to the CMD/CMDARG registers and that extra process makes it
difficult to cleanly the read-modify-write race in
dw_mci_enable_sdio_irq() (see future patch in the series).

Change the code to take advantage of the init_card() callback of the
mmc core to do this right at bootup.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In (3fcb027d ARM: MXC: mxcmmc: work around a bug in the SDHC busy line
handling) the optional init_card() callback was added.  According to
the original change it was "for now only called from
mmc_sdio_init_card()".

This callback really ought to be called from the SD and MMC init
functions as well.  One current user of this callback
(mxcmci_init_card) will not work as expected if you insert an SDIO
card, then eject it and put a normal SD card in.  Specifically the
normal SD card will not get to run with 4-bit data.

I'd like to use the init_card() callback to handle a similar quirk on
dw_mmc when using SDIO Interrupts (the "low power" feature of the card
needs to be disabled), so that will add a second user of the function.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NGrant Grundler <grundler@chromium.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The commit 646cafc6 (clk: Change clk_ops->determine_rate to
return a clk_hw as the best parent) opens a possibility for
null pointer dereference, fix this.
Signed-off-by: NStanimir Varbanov <svarbanov@mm-sol.com>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMichael Turquette <mturquette@linaro.org>

This reverts commit da788acb.

That commit tried to fix the section mismatch warning by moving the
ppc_corenet_clk_driver struct to init section. This is definitely wrong
because the kernel would free the memories occupied by this struct
after boot while this driver is still registered in the driver core.
The kernel would panic when accessing this driver struct.

Cc: stable@vger.kernel.org # 3.17
Signed-off-by: NKevin Hao <haokexin@gmail.com>
Acked-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NMichael Turquette <mturquette@linaro.org>

Lockdep reported a possible deadlock between the cpuclk lock and for example
the i2c driver.

       CPU0                    CPU1
       ----                    ----
  lock(clk_lock);
                               local_irq_disable();
                               lock(&(&i2c->lock)->rlock);
                               lock(clk_lock);
  <Interrupt>
    lock(&(&i2c->lock)->rlock);

 *** DEADLOCK ***

The generic clock-types of the core ccf already use spin_lock_irqsave when
touching clock registers, so do the same for the cpuclk.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NMichael Turquette <mturquette@linaro.org>
[mturquette@linaro.org: removed initialization of "flags"]

Call spin_lock_init() before the spinlocks are used, both in early init
and probe functions preventing a lockdep splat.

I have been observing lockdep complaining [1] during boot on my a80 optimus [2]
when CONFIG_PROVE_LOCKING has been enabled. This patch resolves the splat,
and has been tested on a few other sunxi platforms without issue.

[1] http://storage.kernelci.org/next/next-20150107/arm-multi_v7_defconfig+CONFIG_PROVE_LOCKING=y/lab-tbaker/boot-sun9i-a80-optimus.html
[2] http://kernelci.org/boot/?a80-optimusSigned-off-by: NTyler Baker <tyler.baker@linaro.org>
Cc: <stable@vger.kernel.org>
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The arm-cci driver completes the probe sequence even if the cci node is
marked as disabled. Add a check in the driver to honour the cci status
in the device tree.
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Acked-by: NSudeep Holla <sudeep.holla@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Tested-by: NSudeep Holla <sudeep.holla@arm.com>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

synchronize_irq() can sleep waiting, for pending IRQ handlers so driver
should release the tp->lock spin lock before invoking synchronize_irq()
Reported-by: NPeter Hurley <peter@hurleysoftware.com>
Tested-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NPrashant Sreedharan <prashant@broadcom.com>
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently tg3_reset_task() uses only tp->lock for synchronizing with code
paths like tg3_open() etc. But since tp->lock is released before doing
synchronize_irq(), rtnl_lock should be taken in tg3_reset_task() to
synchronize it with other code paths.
Reported-by: NPeter Hurley <peter@hurleysoftware.com>
Tested-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NPrashant Sreedharan <prashant@broadcom.com>
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is to avoid the race between tg3_timer() and the execution paths
which does not invoke tg3_timer_stop() and releases tp->lock before
calling synchronize_irq()
Reported-by: NPeter Hurley <peter@hurleysoftware.com>
Tested-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NPrashant Sreedharan <prashant@broadcom.com>
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch is fixing a race condition that may cause setting
count_pending to -1, which results in unwanted big bulk of arp messages
(in case of "notify peers").

Consider following scenario:

count_pending == 2
   CPU0                                           CPU1
					team_notify_peers_work
					  atomic_dec_and_test (dec count_pending to 1)
					  schedule_delayed_work
 team_notify_peers
   atomic_add (adding 1 to count_pending)
					team_notify_peers_work
					  atomic_dec_and_test (dec count_pending to 1)
					  schedule_delayed_work
					team_notify_peers_work
					  atomic_dec_and_test (dec count_pending to 0)
   schedule_delayed_work
					team_notify_peers_work
					  atomic_dec_and_test (dec count_pending to -1)

Fix this race by using atomic_dec_if_positive - that will prevent
count_pending running under 0.

Fixes: fc423ff0 ("team: add peer notification")
Fixes: 492b200e  ("team: add support for sending multicast rejoins")
Signed-off-by: NJiri Pirko <jiri@resnulli.us>
Signed-off-by: NJiri Benc <jbenc@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Adds FCoE config option I40E_FCOE, so that FCoE can be enabled
as needed but otherwise have it disabled by default.

This also eliminate multiple FCoE config checks, instead now just
one config check for CONFIG_I40E_FCOE.

The I40E FCoE was added with 3.17 kernel and therefore this patch
shall be applied to stable 3.17 kernel also.

CC: <stable@vger.kernel.org>
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NJim Young <jamesx.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

DWC3 gadget sets up a pool of 32 TRBs for each EP during initialization. This
means, the max TRBs that can be submitted for an EP is fixed to 32. Since the
request queue for an EP is a linked list, any number of requests can be queued
to it by the gadget layer.  However, the dwc3 driver must not submit TRBs more
than the pool it has created for. This limit wasn't respected when SG was used
resulting in submitting more than the max TRBs, eventually leading to
non-transfer of the TRBs submitted over the max limit.

Root cause:
When SG is used, there are two loops iterating to prepare TRBs:
 - Outer loop over the request_list
 - Inner loop over the SG list
The code was missing break to get out of the outer loop.

Fixes: eeb720fb (usb: dwc3: gadget: add support for SG lists)
Cc: <stable@vger.kernel.org> # v3.9+
Signed-off-by: NAmit Virdi <amit.virdi@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3
request (dwc3_request). So while preparing TRBs, the 'last' flag should be set
only when it is the last TRB being prepared from the last dwc3_request entry.

The current implementation uses list_is_last to check if the dwc3_request is the
last entry from the request_list. However, list_is_last returns false for the
last entry too. This is because, while preparing the first TRB from a request,
the function dwc3_prepare_one_trb modifies the request's next and prev pointers
while moving the URB to req_queued. Hence, list_is_last always returns false no
matter what.

The correct way is not to access the modified pointers of dwc3_request but to
use list_empty macro instead.

Fixes: e5ba5ec8 (usb: dwc3: gadget: fix scatter gather implementation)
Signed-off-by: NAmit Virdi <amit.virdi@st.com>
Cc: <stable@vger.kernel.org> # v3.9+
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Host controllers lacking the required internal vmmc regulator may still
follow the spec with regard to the LSB of SDHCI_POWER_CONTROL.  Set the
SDHCI_POWER_ON bit when vmmc is enabled to encourage the controller to
to drive CMD, DAT, SDCLK.

This fixes a regression observed on some Qualcomm and Nvidia boards
caused by 52221610 mmc: sdhci: Improve external VDD regulator support.

Fixes: 52221610 (mmc: sdhci: Improve external VDD regulator support)
Signed-off-by: NTim Kryger <tim.kryger@gmail.com>
Tested-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

On i.MX28, the MDIO bus is shared between the two FEC instances.
The driver makes sure that the second FEC uses the MDIO bus of the
first FEC. This is done conditionally if FEC_QUIRK_ENET_MAC is set.
However, in newer designs, such as Vybrid or i.MX6SX, each FEC MAC
has its own MDIO bus. Simply removing the quirk FEC_QUIRK_ENET_MAC
is not an option since other logic, triggered by this quirk, is
still needed.

Furthermore, there are board designs which use the same MDIO bus
for both PHY's even though the second bus would be available on the
SoC side. Such layout are popular since it saves pins on SoC side.
Due to the above quirk, those boards currently do work fine. The
boards in the mainline tree with such a layout are:
- Freescale Vybrid Tower with TWR-SER2 (vf610-twr.dts)
- Freescale i.MX6 SoloX SDB Board (imx6sx-sdb.dts)

This patch adds a new quirk FEC_QUIRK_SINGLE_MDIO for i.MX28, which
makes sure that the MDIO bus of the first FEC is used in any case.

However, the boards above do have a SoC with a MDIO bus for each FEC
instance. But the PHY's are not connected in a 1:1 configuration. A
proper device tree description is needed to allow the driver to
figure out where to find its PHY. This patch fixes that shortcoming
by adding a MDIO bus child node to the first FEC instance, along
with the two PHY's on that bus, and making use of the phy-handle
property to add a reference to the PHY's.
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In netfront the Rx and Tx path are independent and use different
locks.  The Tx lock is held with hard irqs disabled, but Rx lock is
held with only BH disabled.  Since both sides use the same stats lock,
a deadlock may occur.

  [ INFO: possible irq lock inversion dependency detected ]
  3.16.2 #16 Not tainted
  ---------------------------------------------------------
  swapper/0/0 just changed the state of lock:
   (&(&queue->tx_lock)->rlock){-.....}, at: [<c03adec8>]
  xennet_tx_interrupt+0x14/0x34
  but this lock took another, HARDIRQ-unsafe lock in the past:
   (&stat->syncp.seq#2){+.-...}
  and interrupts could create inverse lock ordering between them.
  other info that might help us debug this:
   Possible interrupt unsafe locking scenario:

         CPU0                    CPU1
         ----                    ----
    lock(&stat->syncp.seq#2);
                                 local_irq_disable();
                                 lock(&(&queue->tx_lock)->rlock);
                                 lock(&stat->syncp.seq#2);
    <Interrupt>
      lock(&(&queue->tx_lock)->rlock);

Using separate locks for the Rx and Tx stats fixes this deadlock.
Reported-by: NDmitry Piotrovsky <piotrovskydmitry@gmail.com>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since ALE table is a common resource for both the interfaces in Dual EMAC
mode and while bringing up the second interface in cpsw_ndo_set_rx_mode()
all the multicast entries added by the first interface is flushed out and
only second interface multicast addresses are added. Fixing this by
flushing multicast addresses based on dual EMAC port vlans which will not
affect the other emac port multicast addresses.

Fixes: d9ba8f9e (driver: net: ethernet: cpsw: dual emac interface implementation)
Cc: <stable@vger.kernel.org> # v3.9+
Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes a NULL pointer dereference on led_dat->mode_val. Due to
this bug, a kernel oops can be observed at probe time on the LaCie 2Big
and 5Big v2 boards:

Unable to handle kernel NULL pointer dereference at virtual address 00000008
[...]
[<c03f244c>] (netxbig_led_probe) from [<c02c8c6c>] (platform_drv_probe+0x4c/0x9c)
[<c02c8c6c>] (platform_drv_probe) from [<c02c72d0>] (driver_probe_device+0x98/0x25c)
[<c02c72d0>] (driver_probe_device) from [<c02c7520>] (__driver_attach+0x8c/0x90)
[<c02c7520>] (__driver_attach) from [<c02c5c24>] (bus_for_each_dev+0x68/0x94)
[<c02c5c24>] (bus_for_each_dev) from [<c02c6408>] (bus_add_driver+0x124/0x1dc)
[<c02c6408>] (bus_add_driver) from [<c02c7ac0>] (driver_register+0x78/0xf8)
[<c02c7ac0>] (driver_register) from [<c000888c>] (do_one_initcall+0x80/0x1cc)
[<c000888c>] (do_one_initcall) from [<c0733618>] (kernel_init_freeable+0xe4/0x1b4)
[<c0733618>] (kernel_init_freeable) from [<c058db9c>] (kernel_init+0xc/0xec)
[<c058db9c>] (kernel_init) from [<c0009850>] (ret_from_fork+0x14/0x24)
[...]

This bug was introduced by commit 588a6a99
("leds: netxbig: fix attribute-creation race").
Signed-off-by: NSimon Guinot <simon.guinot@sequanux.org>
Cc: <stable@vger.kernel.org> # 3.17+
Acked-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

In commit 5ad24def ("cxgb4vf: Fix ethtool get_settings for VF driver")
mdio_addr of port_info structure was used unininitialzed. Fixing it.
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The "smemc" clock is removed on BG2Q SoCs. In fact, bit19 of clkenable
register is for nfc. Current code use bit19 for non-exist "smemc"
incorrectly, this prevents eMMC from working due to the sdhci's
"core" clk is still gated.
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Cc: stable@vger.kernel.org # 3.16+
Signed-off-by: NMichael Turquette <mturquette@linaro.org>

All slow clk users are not properly claiming it (get + prepare + enable)
before using it.
If all users properly claiming this clock release it, the clock is
disabled, but faulty users still depends on it, and the system hangs.

This fix prevents the slow clock from being disabled, and should solve the
hanging issue, but offending drivers should be patched to properly claim
this clock.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: NBo Shen <voice.shen@atmel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NMichael Turquette <mturquette@linaro.org>

In case of PCI driver we will get a warning:
	dw_dmac_pci 0000:00:18.0: Unbalanced pm_runtime_enable!
	dw_dmac_pci 0000:00:18.0: DesignWare DMA Controller, 8 channels

This happens due to pm_runtime_enable() call from the driver when PM runtime is
enabled by core.

This patch moves that call to the platform driver where it might make sense.

Fixes: bb32baf7 (dmaengine: dw: enable runtime PM)
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The driver was recently adapted to a core API change, but the
change was incomplete, missing out the suspend helper and
leaving an extraneous local variable around:

usb/phy/phy-mv-usb.c: In function 'mv_otg_update_state':
usb/phy/phy-mv-usb.c:341:18: warning: unused variable 'phy' [-Wunused-variable]

usb/phy/phy-mv-usb.c: In function 'mv_otg_suspend':
usb/phy/phy-mv-usb.c:861:16: error: 'struct usb_phy' has no member named 'state'
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: e47d9254 ("usb: move the OTG state from the USB PHY to the OTG structure")
Signed-off-by: NFelipe Balbi <balbi@ti.com>

static code analysis from cppcheck reports:

[drivers/video/fbdev/broadsheetfb.c:673]:
  (error) Memory leak: sector_buffer

sector_buffer is not being kfree'd on each call to
broadsheet_spiflash_rewrite_sector(), so free it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

of_platform_device_create is only defined when CONFIG_OF_ADDRESS is set,
which is normally always the case when CONFIG_OF is defined, except on Sparc,
so explicitly check for CONFIG_OF_ADDRESS rather then for CONFIG_OF.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Fixes following warning generated by sparse:

drivers/staging/vt6655/baseband.c:2180:45: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/vt6655/baseband.c:2180:45:    expected struct vnt_private *priv
drivers/staging/vt6655/baseband.c:2180:45:    got void [noderef] <asn:2>*dwIoBase

Compile tested on next-20141219.
Signed-off-by: NEddie Kovsky <ewk@edkovsky.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the asssocated access point is strong byBBVGACurrent will be adjusted
accordingly.

Users will nolonger see distant access points without taking down interface.

When changing channel reset byBBVGACurrent back to pDevice->abyBBVGA[0] for
max sensitivity.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move PSTxDesc->m_td1TD1 to inside spin locks.

if m_td1TD1.byTCR has TCR_EDP and TCR_STP are set, the interrupt handler will
try and complete the buffer before it is completed. Usually on the tail
of a burst of tx packets.

This results in a partially completed packet being transmitted or worse
sitll dead lock when skb is freed by the interrupt handler.

Set head_td->m_td1TD1.byTCR to 0 in first lock of vnt_tx_packet to stop
interrupt handler completing the buffer. Move Set TSR1 & ReqCount in
s_cbFillTxBufHead to the second lock.

cbReqCount is carried to the second lock in pTDInfo->dwReqCount without
the padding removed.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

this patch fixes following sparse warnings:

drivers/staging/vt6655/device_main.c:1503:25: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/vt6655/device_main.c:1503:25:    expected void [noderef] <asn:2>*<noident>
drivers/staging/vt6655/device_main.c:1503:25:    got struct vnt_private *
drivers/staging/vt6655/device_main.c:1503:25: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/vt6655/device_main.c:1503:25:    expected void [noderef] <asn:2>*<noident>
drivers/staging/vt6655/device_main.c:1503:25:    got struct vnt_private *
drivers/staging/vt6655/device_main.c:1505:25: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/vt6655/device_main.c:1505:25:    expected void [noderef] <asn:2>*<noident>
drivers/staging/vt6655/device_main.c:1505:25:    got struct vnt_private *
drivers/staging/vt6655/device_main.c:1505:25: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/vt6655/device_main.c:1505:25:    expected void [noderef] <asn:2>*<noident>
drivers/staging/vt6655/device_main.c:1505:25:    got struct vnt_private *
Signed-off-by: NMike Krinkin <krinkin.m.u@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit e4c7f259 ("USB: kaweth.c: use GFP_ATOMIC under spin_lock")
makes sure that kaweth_internal_control_msg() allocates memory with GFP_ATOMIC,
but kaweth_internal_control_msg() also calls usb_start_wait_urb()
that still allocates memory with GFP_NOIO.

The patch fixes usb_start_wait_urb() as well.

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: NOliver Neukum <oliver@neukum.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

The clock is enabled without being prepared, this leads to:

WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:889 __clk_enable+0x24/0xa8()

and a non working ethernet interface.

Use clk_prepare_enable() and clk_disable_unprepare() to handle the clock.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>