1. 24 1月, 2015 1 次提交
  2. 18 1月, 2015 3 次提交
  3. 17 1月, 2015 2 次提交
  4. 15 1月, 2015 8 次提交
  5. 14 1月, 2015 9 次提交
    • T
      mmc: sdhci: Set SDHCI_POWER_ON with external vmmc · 3cbc6123
      Tim Kryger 提交于
      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>
      3cbc6123
    • S
      net: fec: fix MDIO bus assignement for dual fec SoC's · 3d125f9c
      Stefan Agner 提交于
      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>
      3d125f9c
    • D
      xen-netfront: use different locks for Rx and Tx stats · 900e1833
      David Vrabel 提交于
      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>
      900e1833
    • M
      drivers: net: cpsw: fix multicast flush in dual emac mode · 25906052
      Mugunthan V N 提交于
      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>
      25906052
    • S
      leds: netxbig: fix oops at probe time · 0c86ac2c
      Simon Guinot 提交于
      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>
      0c86ac2c
    • H
      cxgb4vf: Initialize mdio_addr before using it · fd48e639
      Hariprasad Shenai 提交于
      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>
      fd48e639
    • J
      clk: berlin: bg2q: remove non-exist "smemc" gate clock · b71e8ecd
      Jisheng Zhang 提交于
      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>
      b71e8ecd
    • B
      clk: at91: keep slow clk enabled to prevent system hang · dca1a4b5
      Boris Brezillon 提交于
      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>
      dca1a4b5
    • A
      dmaengine: dw: balance PM runtime calls · 6acf3998
      Andy Shevchenko 提交于
      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>
      6acf3998
  6. 13 1月, 2015 11 次提交
  7. 12 1月, 2015 6 次提交
    • J
      usb: serial: handle -ENODEV quietly in generic_submit_read_urb · 04f9c6e6
      Jeremiah Mahler 提交于
      If a USB serial device (e.g. /dev/ttyUSB0) with an active program is
      unplugged, an -ENODEV (19) error will be produced after it gives up
      trying to resubmit a read.
      
        usb_serial_generic_submit_read_urb - usb_submit_urb failed: -19
      
      Add -ENODEV as one of the permanent errors along with -EPERM that
      usb_serial_generic_submit_read_urb() handles quietly without an error.
      Signed-off-by: NJeremiah Mahler <jmmahler@gmail.com>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      04f9c6e6
    • J
      usb: serial: silence all non-critical read errors · aa8e2212
      Jeremiah Mahler 提交于
      If a USB serial device is unplugged while there is an active program
      using the device it may spam the logs with -EPROTO (71) messages as it
      attempts to retry.
      
      Most serial usb drivers (metro-usb, pl2303, mos7840, ...) only output
      these messages for debugging.  The generic driver treats these as
      errors.
      
      Change the default output for the generic serial driver from error to
      debug to silence these non-critical errors.
      Signed-off-by: NJeremiah Mahler <jmmahler@gmail.com>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      aa8e2212
    • A
      mmc: sdhci-pci: Add support for Intel SPT · 1f7f2652
      Adrian Hunter 提交于
      Add PCI IDs for SPT eMMC, SDIO and SD card.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      1f7f2652
    • A
      mmc: sdhci-acpi: Add ACPI HID INT344D · d0ed8e6b
      Adrian Hunter 提交于
      Add ACPI HID INT344D for an Intel SDIO host controller.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      d0ed8e6b
    • K
      mmc: sdhci: Fix sleep in atomic after inserting SD card · 2836766a
      Krzysztof Kozlowski 提交于
      Sleep in atomic context happened on Trats2 board after inserting or
      removing SD card because mmc_gpio_get_cd() was called under spin lock.
      
      Fix this by moving card detection earlier, before acquiring spin lock.
      The mmc_gpio_get_cd() call does not have to be protected by spin lock
      because it does not access any sdhci internal data.
      The sdhci_do_get_cd() call access host flags (SDHCI_DEVICE_DEAD). After
      moving it out side of spin lock it could theoretically race with driver
      removal but still there is no actual protection against manual card
      eject.
      
      Dmesg after inserting SD card:
      [   41.663414] BUG: sleeping function called from invalid context at drivers/gpio/gpiolib.c:1511
      [   41.670469] in_atomic(): 1, irqs_disabled(): 128, pid: 30, name: kworker/u8:1
      [   41.677580] INFO: lockdep is turned off.
      [   41.681486] irq event stamp: 61972
      [   41.684872] hardirqs last  enabled at (61971): [<c0490ee0>] _raw_spin_unlock_irq+0x24/0x5c
      [   41.693118] hardirqs last disabled at (61972): [<c04907ac>] _raw_spin_lock_irq+0x18/0x54
      [   41.701190] softirqs last  enabled at (61648): [<c0026fd4>] __do_softirq+0x234/0x2c8
      [   41.708914] softirqs last disabled at (61631): [<c00273a0>] irq_exit+0xd0/0x114
      [   41.716206] Preemption disabled at:[<  (null)>]   (null)
      [   41.721500]
      [   41.722985] CPU: 3 PID: 30 Comm: kworker/u8:1 Tainted: G        W      3.18.0-rc5-next-20141121 #883
      [   41.732111] Workqueue: kmmcd mmc_rescan
      [   41.735945] [<c0014d2c>] (unwind_backtrace) from [<c0011c80>] (show_stack+0x10/0x14)
      [   41.743661] [<c0011c80>] (show_stack) from [<c0489d14>] (dump_stack+0x70/0xbc)
      [   41.750867] [<c0489d14>] (dump_stack) from [<c0228b74>] (gpiod_get_raw_value_cansleep+0x18/0x30)
      [   41.759628] [<c0228b74>] (gpiod_get_raw_value_cansleep) from [<c03646e8>] (mmc_gpio_get_cd+0x38/0x58)
      [   41.768821] [<c03646e8>] (mmc_gpio_get_cd) from [<c036d378>] (sdhci_request+0x50/0x1a4)
      [   41.776808] [<c036d378>] (sdhci_request) from [<c0357934>] (mmc_start_request+0x138/0x268)
      [   41.785051] [<c0357934>] (mmc_start_request) from [<c0357cc8>] (mmc_wait_for_req+0x58/0x1a0)
      [   41.793469] [<c0357cc8>] (mmc_wait_for_req) from [<c0357e68>] (mmc_wait_for_cmd+0x58/0x78)
      [   41.801714] [<c0357e68>] (mmc_wait_for_cmd) from [<c0361c00>] (mmc_io_rw_direct_host+0x98/0x124)
      [   41.810480] [<c0361c00>] (mmc_io_rw_direct_host) from [<c03620f8>] (sdio_reset+0x2c/0x64)
      [   41.818641] [<c03620f8>] (sdio_reset) from [<c035a3d8>] (mmc_rescan+0x254/0x2e4)
      [   41.826028] [<c035a3d8>] (mmc_rescan) from [<c003a0e0>] (process_one_work+0x180/0x3f4)
      [   41.833920] [<c003a0e0>] (process_one_work) from [<c003a3bc>] (worker_thread+0x34/0x4b0)
      [   41.841991] [<c003a3bc>] (worker_thread) from [<c003fed8>] (kthread+0xe4/0x104)
      [   41.849285] [<c003fed8>] (kthread) from [<c000f268>] (ret_from_fork+0x14/0x2c)
      [   42.038276] mmc0: new high speed SDHC card at address 1234
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: 94144a46 ("mmc: sdhci: add get_cd() implementation")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      2836766a
    • T
      mmc: sdhci-pxav3: do the mbus window configuration after enabling clocks · aa8165f9
      Thomas Petazzoni 提交于
      In commit 5491ce3f ("mmc: sdhci-pxav3: add support for the Armada
      38x SDHCI controller"), the sdhci-pxav3 driver was extended to include
      support for the SDHCI controller found in the Armada 38x
      processor. This mainly involved adding some MBus window related
      configuration.
      
      However, this configuration is currently done too early in ->probe():
      it is done before clocks are enabled, while this configuration
      involves touching the registers of the controller, which will hang the
      SoC if the clock is disabled. It wasn't noticed until now because the
      bootloader typically leaves gatable clocks enabled, but in situations
      where we have a deferred probe (due to a CD GPIO that cannot be taken,
      for example), then the probe will be re-tried later, after a clock
      disable has been done in the exit path of the failed probe attempt of
      the device. This second probe() will hang the system due to the clock
      being disabled.
      
      This can for example be produced on Armada 385 GP, which has a CD GPIO
      connected to an I2C PCA9555. If the driver for the PCA9555 is not
      compiled into the kernel, then we will have the following sequence of
      events:
      
        1. The SDHCI probes
        2. It does the MBus configuration (which works, because the clock is
           left enabled by the bootloader)
        3. It enables the clock
        4. It tries to get the CD GPIO, which fails due to the driver being
           missing, so -EPROBE_DEFER is returned.
        5. Before returning -EPROBE_DEFER, the driver cleans up what was
           done, which includes disabling the clock.
        6. Later on, the SDHCI probe is tried again.
        7. It does the MBus configuration, which hangs because the clock is
           no longer enabled.
      
      This commit does the obvious fix of doing the MBus configuration after
      the clock has been enabled by the driver.
      
      Fixes: 5491ce3f ("mmc: sdhci-pxav3: add support for the Armada 38x SDHCI controller")
      Cc: <stable@vger.kernel.org> # v3.15+
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      aa8165f9