- 19 1月, 2015 19 次提交
-
-
由 Ulf Hansson 提交于
Since mmc_of_parse() may fail, let's deal with it and thus do proper error handling. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Ulf Hansson 提交于
Since mmc_of_parse() may fail, let's deal with it and thus do proper error handling. Cc: Christian Daudt <bcm@fixthebug.org> Cc: Matt Porter <mporter@linaro.org> Cc: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
-
由 Ulf Hansson 提交于
Since mmc_of_parse() may fail, let's deal with it and thus do proper error handling. Cc: Jonas Jensen <jonas.jensen@gmail.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Seungwon Jeon 提交于
Move exynos related definition to header file. And this also changes some of the registers name to match the standard naming convention. Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> [Alim: updated the commit message] Signed-off-by: NAlim Akhtar <alim.akhtar@samsung.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Seungwon Jeon 提交于
Add checking whether the clock is valid. Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Signed-off-by: NAlim Akhtar <alim.akhtar@samsung.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Seungwon Jeon 提交于
Even though 1MB is reserved for descriptor table in IDMAC, the dw_mmc host driver is allowed to receive only maximum 128KB block length in one request. This is caused by setting improper max_blk_count. It needs to be e adjusted so that descriptor table is used fully. It is found that the performance is improved with the increased the max_blk_count. Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Signed-off-by: NAlim Akhtar <alim.akhtar@samsung.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Dan Carpenter 提交于
Static checkers complain about the inconsistent NULL checking here: drivers/mmc/host/mxs-mmc.c:680 mxs_mmc_probe() warn: variable dereferenced before check 'ssp->dmach' (see line 660) The variable can't actually be NULL so we can remove the check. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 David Lanzendörfer 提交于
Removing a relict from reverse engineering of the Android driver code in sunxi_mmc_clk_set_rate. Signed-off-by: NDavid Lanzendörfer <david.lanzendoerfer@o2s.ch> Reported-by: <lixiang@allwinnertech.com> Acked-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 David Lanzendörfer 提交于
Fixing the register name in sunxi_mmc_reset_host since the SDXC_HARDWARE_RESET bit is actually located within REG_GCTRL and not REG_CMDR as it was pointed out by Allwinner. Signed-off-by: NDavid Lanzendörfer <david.lanzendoerfer@o2s.ch> Reported-by: <lixiang@allwinnertech.com> Acked-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 David Lanzendörfer 提交于
1) Adding a comment in order to clarify the choice of the locks within sunxi_mmc_handle_manual_stop 2) As <lixiang@allwinnertech.com> has pointed out the wait_dma variable was not accessed within the spin lock block in sunxi_mmc_request and so (even if it should never happend) it would have theoretically been possible that some other function would access the variable at the same time as the function. This has been changed now and the function is using local variables outside the lock and copys the value over during the lock phase. Signed-off-by: NDavid Lanzendörfer <david.lanzendoerfer@o2s.ch> Reported-by: <lixiang@allwinnertech.com> Acked-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Hans de Goede 提交于
The last descriptor might be the first descriptor as well, so use masking to add the LD (last descriptor) bit and drop the DIC (disable interrupt on completion) bit rather then hard assignment as hard assignment will override the FD (first descriptor) bit if there is only 1 descriptor. Also set the ER (end of ring) bit and clear buf_addr_ptr2 on the last descriptor, like the android kernel code does. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDavid Lanzendörfer <david.lanzendoerfer@o2s.ch> Reported-by: <lixiang@allwinnertech.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 NeilBrown 提交于
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>
-
由 Axel Lin 提交于
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>
-
由 Wei Yongjun 提交于
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>
-
由 Alessio Igor Bogani 提交于
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>
-
由 Minda Chen 提交于
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>
-
由 Doug Anderson 提交于
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>
-
由 Doug Anderson 提交于
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>
-
由 Doug Anderson 提交于
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>
-
- 18 1月, 2015 3 次提交
-
-
由 Stanimir Varbanov 提交于
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>
-
由 Kevin Hao 提交于
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>
-
由 Heiko Stübner 提交于
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"]
-
- 17 1月, 2015 2 次提交
-
-
由 Tyler Baker 提交于
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>
-
由 Abhilash Kesavan 提交于
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>
-
- 15 1月, 2015 8 次提交
-
-
由 Prashant Sreedharan 提交于
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>
-
由 Prashant Sreedharan 提交于
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>
-
由 Prashant Sreedharan 提交于
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>
-
由 Jiri Pirko 提交于
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>
-
由 Vasu Dev 提交于
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>
-
由 Hariprasad Shenai 提交于
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Amit Virdi 提交于
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>
-
由 Amit Virdi 提交于
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>
-
- 14 1月, 2015 8 次提交
-
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-