- 10 11月, 2014 15 次提交
-
-
由 Sebastian Hesselbarth 提交于
commit bb8175a8 ("mmc: sdhci: clarify DDR timing mode between SD-UHS and eMMC") added MMC_DDR52 as eMMC's DDR mode to be distinguished from SD-UHS. While the differentation may be useful, pxav3 SDHCI controller lacks a corresponding check in its custom .set_uhs_signaling callback for MMC_DDR52. This patch adds a new switch case for MMC_TIMING_MMC_DDR52 to MMC_TIMING_UHS_DDR50 case. Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Sebastian Hesselbarth 提交于
struct sdhci_pxa is private data of PXA SDHCI driver, but not used in sdhci-pxav2 at all. Drop unused references to struct sdhci_pxa. Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Tomeu Vizoso 提交于
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Srinivas Kandagatla 提交于
If the post request is cancelling the channel and descriptor and which are equal to host->dma_current and host->dma_desc_current respectively, then it makes sense to reset these pointers to NULL, so that the driver does not reference it. Also the host_cookie can be reset to 0 in cases of error, so that the core could reissue the same mmc_request. This patch was tested with 'mmc: core: fix prepared requests while doing bkops' to fix the below issue. mmci-pl18x 12400000.sdcc: error during DMA transfer! Unable to handle kernel paging request at virtual address 40000000 pgd = c0204000 [40000000] *pgd=00000000 Internal error: Oops: 805 [#1] SMP ARM Modules linked in: ipv6 ath6kl_sdio ath6kl_core CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.17.0-rc7-linaro-multi-v7 #1 task: c0c9d7e0 ti: c0c92000 task.ti: c0c92000 PC is at v7_dma_inv_range+0x34/0x4c LR is at __dma_page_dev_to_cpu+0x80/0x100 pc : [<c021efc0>] lr : [<c021af18>] psr: 400f0193 sp : c0c93e20 ip : c0c9a478 fp : c08ea538 r10: c0c9f548 r9 : 00000002 r8 : e97d9000 r7 : 00000200 r6 : c0c9d504 r5 : c0db0880 r4 : 00000000 r3 : 0000003f r2 : 00000040 r1 : 40000200 r0 : 40000000 Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5787d Table: a9ef406a DAC: 00000015 Process swapper/0 (pid: 0, stack limit = 0xc0c92250) Stack: (0xc0c93e20 to 0xc0c94000) 3e20: c021f058 e9a17178 e9a171bc e99dfd6c 00000001 00000001 e995de10 00000002 3e40: 00000000 c021b574 00000000 c04bc4a4 00000000 e9b49ac0 c0ce6e6c e99dfda4 3e60: 00000088 e9810780 c0d8291c c072ea58 00000000 c072d3fc 00000000 c072f534 3e80: 00000000 e9b49ac0 00000100 c0c9a444 00000088 c072f6b4 c072f5d4 e9d40080 3ea0: e98107dc 00000000 00000000 c0280a60 00000000 7d55bf61 e9810780 e98107dc 3ec0: 00000000 f0002000 c0d460e8 c0d460e8 c0c92000 c0280b60 e9810780 c0ce7190 3ee0: 00000000 c028369c c02835f4 00000088 00000088 c0280278 c0c8ec70 c020f080 3f00: f000200c c0c9a958 c0c93f28 c02088e4 c04bd630 c04bd5bc 200f0013 ffffffff 3f20: c0c93f5c c0212800 00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b 3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70 3f60: c04bd630 c04bd5bc 200f0013 ffffffff c04bd574 c071bd24 7d50c9b4 c0719a44 3f80: 7d50c9b4 0000015b c0c9a498 c0c92028 c0c9a498 c0c9a4fc ea7a0e40 c0c8ee38 3fa0: c0d460e8 c0276198 00000000 c0d8291a 00000000 c0c9a400 00000000 c0be0bc4 3fc0: ffffffff ffffffff c0be05f8 00000000 00000000 c0c533d8 c0d82ed4 c0c9a47c 3fe0: c0c533d4 c0c9e870 8020406a 511f06f0 00000000 80208074 00000000 00000000 [<c021efc0>] (v7_dma_inv_range) from [<c021af18>] (__dma_page_dev_to_cpu+0x80/0x100) [<c021af18>] (__dma_page_dev_to_cpu) from [<c021b574>] (arm_dma_unmap_sg+0x5c/0x84) [<c021b574>] (arm_dma_unmap_sg) from [<c072ea58>] (mmci_dma_unmap.isra.16+0x60/0x74) [<c072ea58>] (mmci_dma_unmap.isra.16) from [<c072f534>] (mmci_data_irq+0x1fc/0x29c) [<c072f534>] (mmci_data_irq) from [<c072f6b4>] (mmci_irq+0xe0/0x114) [<c072f6b4>] (mmci_irq) from [<c0280a60>] (handle_irq_event_percpu+0x78/0x134) [<c0280a60>] (handle_irq_event_percpu) from [<c0280b60>] (handle_irq_event+0x44/0x64) [<c0280b60>] (handle_irq_event) from [<c028369c>] (handle_fasteoi_irq+0xa8/0x1a8) [<c028369c>] (handle_fasteoi_irq) from [<c0280278>] (generic_handle_irq+0x2c/0x3c) [<c0280278>] (generic_handle_irq) from [<c020f080>] (handle_IRQ+0x40/0x90) [<c020f080>] (handle_IRQ) from [<c02088e4>] (gic_handle_irq+0x38/0x68) [<c02088e4>] (gic_handle_irq) from [<c0212800>] (__irq_svc+0x40/0x54) Exception stack(0xc0c93f28 to 0xc0c93f70) 3f20: 00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b 3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70 3f60: c04bd630 c04bd5bc 200f0013 ffffffff [<c0212800>] (__irq_svc) from [<c04bd5bc>] (msm_cpu_pm_enter_sleep+0x48/0x4c) [<c04bd5bc>] (msm_cpu_pm_enter_sleep) from [<c071bd24>] (qcom_lpm_enter_spc+0x20/0x2c) [<c071bd24>] (qcom_lpm_enter_spc) from [<c0719a44>] (cpuidle_enter_state+0x44/0xf0) [<c0719a44>] (cpuidle_enter_state) from [<c0276198>] (cpu_startup_entry+0x1f4/0x238) [<c0276198>] (cpu_startup_entry) from [<c0be0bc4>] (start_kernel+0x384/0x390) Code: 1e070f3e e1110003 e1c11003 1e071f3e (ee070f36) ---[ end trace cf6cb3f6432c9834 ]--- Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Srinivas Kandagatla 提交于
While starting the bkops the previously prepared request should be canceled and restarted after the bkops. As the prepared resource might already setup the dma channels and ready to be started. Now with the arrival of bkops request this prepared request can be serviced ONLY after the bkops. So holding on to the prepared request in the host driver is confusing at this point in time, so it makes sense to cleanup such dangling requests and reissue this request once bkops is done. Canceling the prepared request would give opportunity to the host drivers to perform cleanup on the prepared request. Without this patch host drivers like mmci gets confused when a blocking request like send_ext_csd(CMD8) is issued while there is already a prepared request. With the help of this patch, the driver can better manage such blocking requests and cleanup the prepared requests which are not started yet. Without this patch I hit below crash on Qualcomm APQ8064 based IFC6410 board with mmci host driver. mmci-pl18x 12400000.sdcc: error during DMA transfer! Unable to handle kernel paging request at virtual address 40000000 pgd = c0204000 [40000000] *pgd=00000000 Internal error: Oops: 805 [#1] SMP ARM Modules linked in: ipv6 ath6kl_sdio ath6kl_core CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.17.0-rc7-linaro-multi-v7 #1 task: c0c9d7e0 ti: c0c92000 task.ti: c0c92000 PC is at v7_dma_inv_range+0x34/0x4c LR is at __dma_page_dev_to_cpu+0x80/0x100 pc : [<c021efc0>] lr : [<c021af18>] psr: 400f0193 sp : c0c93e20 ip : c0c9a478 fp : c08ea538 r10: c0c9f548 r9 : 00000002 r8 : e97d9000 r7 : 00000200 r6 : c0c9d504 r5 : c0db0880 r4 : 00000000 r3 : 0000003f r2 : 00000040 r1 : 40000200 r0 : 40000000 Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5787d Table: a9ef406a DAC: 00000015 Process swapper/0 (pid: 0, stack limit = 0xc0c92250) Stack: (0xc0c93e20 to 0xc0c94000) 3e20: c021f058 e9a17178 e9a171bc e99dfd6c 00000001 00000001 e995de10 00000002 3e40: 00000000 c021b574 00000000 c04bc4a4 00000000 e9b49ac0 c0ce6e6c e99dfda4 3e60: 00000088 e9810780 c0d8291c c072ea58 00000000 c072d3fc 00000000 c072f534 3e80: 00000000 e9b49ac0 00000100 c0c9a444 00000088 c072f6b4 c072f5d4 e9d40080 3ea0: e98107dc 00000000 00000000 c0280a60 00000000 7d55bf61 e9810780 e98107dc 3ec0: 00000000 f0002000 c0d460e8 c0d460e8 c0c92000 c0280b60 e9810780 c0ce7190 3ee0: 00000000 c028369c c02835f4 00000088 00000088 c0280278 c0c8ec70 c020f080 3f00: f000200c c0c9a958 c0c93f28 c02088e4 c04bd630 c04bd5bc 200f0013 ffffffff 3f20: c0c93f5c c0212800 00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b 3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70 3f60: c04bd630 c04bd5bc 200f0013 ffffffff c04bd574 c071bd24 7d50c9b4 c0719a44 3f80: 7d50c9b4 0000015b c0c9a498 c0c92028 c0c9a498 c0c9a4fc ea7a0e40 c0c8ee38 3fa0: c0d460e8 c0276198 00000000 c0d8291a 00000000 c0c9a400 00000000 c0be0bc4 3fc0: ffffffff ffffffff c0be05f8 00000000 00000000 c0c533d8 c0d82ed4 c0c9a47c 3fe0: c0c533d4 c0c9e870 8020406a 511f06f0 00000000 80208074 00000000 00000000 [<c021efc0>] (v7_dma_inv_range) from [<c021af18>] (__dma_page_dev_to_cpu+0x80/0x100) [<c021af18>] (__dma_page_dev_to_cpu) from [<c021b574>] (arm_dma_unmap_sg+0x5c/0x84) [<c021b574>] (arm_dma_unmap_sg) from [<c072ea58>] (mmci_dma_unmap.isra.16+0x60/0x74) [<c072ea58>] (mmci_dma_unmap.isra.16) from [<c072f534>] (mmci_data_irq+0x1fc/0x29c) [<c072f534>] (mmci_data_irq) from [<c072f6b4>] (mmci_irq+0xe0/0x114) [<c072f6b4>] (mmci_irq) from [<c0280a60>] (handle_irq_event_percpu+0x78/0x134) [<c0280a60>] (handle_irq_event_percpu) from [<c0280b60>] (handle_irq_event+0x44/0x64) [<c0280b60>] (handle_irq_event) from [<c028369c>] (handle_fasteoi_irq+0xa8/0x1a8) [<c028369c>] (handle_fasteoi_irq) from [<c0280278>] (generic_handle_irq+0x2c/0x3c) [<c0280278>] (generic_handle_irq) from [<c020f080>] (handle_IRQ+0x40/0x90) [<c020f080>] (handle_IRQ) from [<c02088e4>] (gic_handle_irq+0x38/0x68) [<c02088e4>] (gic_handle_irq) from [<c0212800>] (__irq_svc+0x40/0x54) Exception stack(0xc0c93f28 to 0xc0c93f70) 3f20: 00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b 3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70 3f60: c04bd630 c04bd5bc 200f0013 ffffffff [<c0212800>] (__irq_svc) from [<c04bd5bc>] (msm_cpu_pm_enter_sleep+0x48/0x4c) [<c04bd5bc>] (msm_cpu_pm_enter_sleep) from [<c071bd24>] (qcom_lpm_enter_spc+0x20/0x2c) [<c071bd24>] (qcom_lpm_enter_spc) from [<c0719a44>] (cpuidle_enter_state+0x44/0xf0) [<c0719a44>] (cpuidle_enter_state) from [<c0276198>] (cpu_startup_entry+0x1f4/0x238) [<c0276198>] (cpu_startup_entry) from [<c0be0bc4>] (start_kernel+0x384/0x390) Code: 1e070f3e e1110003 e1c11003 1e071f3e (ee070f36) ---[ end trace cf6cb3f6432c9834 ]--- Kernel panic - not syncing: Fatal exception in interrupt Reported-by: NNicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Andrew Gabbasov 提交于
In mmc_init_card function some of the branches in error handling paths go to "err" label, which skips removing of newly allocated card structure, that will actually not be used. Fix that by using proper "free_card" label. Also, some messages in these branches are reported as warnings, although the operation processing is not continued. Change these messages to error level. Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Andrew Gabbasov 提交于
The debug messages with commands execution results, that are printed after processing the request, do not include results of sbc (set block count) part of request. Add the debug message for that part too. Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Andrew Gabbasov 提交于
Some request fields are initialized just before request processing for sanity purposes. This is done for command, data, and stop parts of the request, but not for sbc (set block count) part. Add such initialization for that part too. Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Andrew Gabbasov 提交于
Add the case of SET_BLOCK_COUNT command error to the error conditions check for making a controller reset at request handling finish. Otherwise, if the SET_BLOCK_COUNT command failed, e.g. with a timeout, the controller state was not reset, and the next command failed too. In the case of data error the controller reset is already done in finish_data() function before sending stop command (if present), so the finish tasklet should make a reset after data error only if no stop command existed in the request. Also, fix the indentation of this condition check to make it more logical. Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Andrew Gabbasov 提交于
As a follow-up of commit "mmc: sdhci: Balance vmmc regulator_enable(), and always enable vqmmc" vmmc regulator disable is also not needed in sdhci_remove_host. The regulator is completely controlled by mmc_power_up and mmc_power_off functions and is already disabled by the time of removing the host. Extra regulator_disable call in sdhci_remove_host is unbalanced and causes a warning reported by regulator core, so should be removed. Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Dirk Behme 提交于
The commit ad93220d ("mmc: sdhci-esdhc-imx: change pinctrl state according to uhs mode") exits the probe in case there are no valid pinctrl states found. As there are configurations doing the pin mux properly in the boot loader, don't exit. Just warn, but go on in case if there are no pinctrl states in the device tree. Signed-off-by: NDirk Behme <dirk.behme@de.bosch.com> Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Matteo Facchinetti 提交于
If available voltages are not given, mmc_regulator_get_supply() function returns 0 and mxcmmc driver doesn't set a value for ocr_avail mask. In accordance with the comment in platform_data/mmc-mxcmmc.h, fix it, assuming MMC_VDD_32_33 | MMC_VDD_33_34 as default value. Signed-off-by: NMatteo Facchinetti <matteo.facchinetti@sirius-es.it> Reviewed-by: NSascha Hauer <s.hauer@pengutronix.de> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Matteo Facchinetti 提交于
During a read of data block using dma, driver might have two ways to finish to read and free the resources: 1) checking STATUS_DATA_TRANS_DONE mask, in the mxcmci_irq() routine (pending to mmc irq) 2) mxmmc driver, registers also a mxcmci_dma_callback() and when transfer is finished, dma driver calls this callback. (pending to dma irq) Both ways are concurrent with each other. Race condition happens when following events occur: /* (1) mxcmci driver start data transfer */ 158.418970: mpc_dma_execute: mpc_dma_execute(): will_access_peripheral start cid=31 158.418976: mpc_dma_issue_pending <-mxcmci_request 158.418983: mxcmci_start_cmd <-mxcmci_request /* (2) mxcmci driver receive mmc irq */ 158.419656: mxcmci_irq <-handle_irq_event_percpu 158.419692: mxcmci_read_response <-mxcmci_irq /* (3) mxcmci driver checks that transfer is complete and call mxcmci_finish_data() */ 158.419726: mxcmci_data_done <-mxcmci_irq 158.419729: mxcmci_finish_data <-mxcmci_data_done 158.419733: dma_direct_unmap_sg <-mxcmci_finish_data 158.419736: mxcmci_swap_buffers.isra.24 <-mxcmci_finish_data 158.419762: mxcmci_read_response <-mxcmci_data_done /* (4) mxcmci driver (no dma): send stop command */ 158.419765: mxcmci_start_cmd <-mxcmci_data_done /* (5) mxcmci driver (no dma): receive the stop command irq response */ 158.419782: mxcmci_irq <-handle_irq_event_percpu 158.419812: mxcmci_read_response <-mxcmci_irq 158.419843: mxcmci_finish_request <-mxcmci_irq /* (6) dma driver: receive dma irq (finish data transfer) related by request on step 1 */ 158.419853: mpc_dma_irq <-handle_irq_event_percpu 158.420001: mpc_dma_irq_process <-mpc_dma_irq 158.420004: mpc_dma_irq_process <-mpc_dma_irq /* (7) dma driver: start dma tasklet to finish the dma irq handling */ 158.420008: mpc_dma_irq_process: mpc_dma_irq_process(): completed ch:31 /* (8) mxcmci driver: start next data transfer using dma */ 158.420174: mxcmci_request <-mmc_start_req 158.420182: dma_direct_map_sg <-mxcmci_request 158.420192: mpc_dma_prep_slave_sg <-mxcmci_request /* (9) dma driver: schedule irq tasklet and execute mxcmci dma driver callback */ 158.420250: mpc_dma_tasklet <-tasklet_action 158.420254: mpc_dma_process_completed <-tasklet_action 158.420267: mxcmci_dma_callback <-mpc_dma_process_completed /* ERROR!!! (10) mxcmci driver callback works on dma data related to the step 1 that is already finished */ 158.420271: mxcmci_data_done <-mpc_dma_process_completed 158.420273: mxcmci_finish_data <-mxcmci_data_done /* ERROR!!! (11) mxcmci driver: clear data that should be used by step 8 and send an other mmc stop command (already sended on step 4) */ 158.420276: dma_direct_unmap_sg <-mxcmci_finish_data 158.420279: mxcmci_swap_buffers.isra.24 <-mxcmci_finish_data 158.420330: mxcmci_read_response <-mxcmci_data_done 158.420333: mxcmci_start_cmd <-mxcmci_data_done 158.420338: dma_run_dependencies <-mpc_dma_process_completed ... ... ... 168.474223: mxcmci_watchdog <-call_timer_fn 168.474236: mxcmci_watchdog: mxcmci_watchdog 168.474397: mpc_dma_device_control <-mxcmci_watchdog In accordance with the other drivers that using the dma engine, fix it, leaving *only* to dma driver the complete control to ending the read operation. Removing STATUS_READ_OP_DONE event activation, has as effect to force mxcmci driver to handle the finish data transfer only by mxcmci dma callback. Signed-off-by: NMatteo Facchinetti <matteo.facchinetti@sirius-es.it> Acked-by: NSascha Hauer <s.hauer@pengutronix.de> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Peter Guo 提交于
Fix Dell E5440 when reboot Linux, can't find o2micro sd host chip issue. Fixes: 01acf691 (mmc: sdhci-pci: add support of O2Micro/BayHubTech SD hosts) Signed-off-by: NPeter Guo <peter.guo@bayhubtech.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Baruch Siach 提交于
Make force_ro consistent with other sysfs entries. Fixes: 371a689f ('mmc: MMC boot partitions support') Cc: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by: NBaruch Siach <baruch@tkos.co.il> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 08 11月, 2014 6 次提交
-
-
由 Johannes Berg 提交于
The ENABLE_DEV_COREDUMP option is misleading as it implies that it gets the framework enabled, this isn't true it just allows it to get enabled if a driver needs it. Rename it to ALLOW_DEV_COREDUMP to better capture its semantics. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Reviewed-by: NJosh Triplett <josh@joshtriplett.org> Acked-by: NAristeu Rozanski <aris@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Aristeu Rozanski 提交于
It's desirable for allnconfig and tinyconfig targets to result in the least amount of code possible. DISABLE_DEV_COREDUMP exists as a way to switch off DEV_COREDUMP regardless if any drivers select WANT_DEV_COREDUMP. This patch renames the option to ENABLE_DEV_COREDUMP and setting it to 'n' (as in allnconfig or tinyconfig) will effectively disable device coredump. Cc: Josh Triplett <josh@joshtriplett.org> Reviewed-by: NJosh Triplett <josh@joshtriplett.org> Signed-off-by: NAristeu Rozanski <arozansk@redhat.com> Reviewed-by: NJohannes Berg <johannes@sipsolutions.net> Acked-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Laurent Pinchart 提交于
Clients instantiated from OF get an IRQ mapping created at device registration time. Dispose the mapping when the client is removed. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
由 Wolfram Sang 提交于
iowait is for blkio [1]. I2C shouldn't use it. [1] https://lkml.org/lkml/2014/11/3/317Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com> Cc: stable@kernel.org
-
由 Wolfram Sang 提交于
We have a central copy of the GPL for that. Some addresses were already outdated. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
-
由 Yijing Wang 提交于
There is a race condition when removing glue directory. It can be reproduced in following test: path 1: Add first child device device_add() get_device_parent() /*find parent from glue_dirs.list*/ list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry) if (k->parent == parent_kobj) { kobj = kobject_get(k); break; } .... class_dir_create_and_add() path2: Remove last child device under glue dir device_del() cleanup_device_parent() cleanup_glue_dir() kobject_put(glue_dir); If path2 has been called cleanup_glue_dir(), but not call kobject_put(glue_dir), the glue dir is still in parent's kset list. Meanwhile, path1 find the glue dir from the glue_dirs.list. Path2 may release glue dir before path1 call kobject_get(). So kernel will report the warning and bug_on. This is a "classic" problem we have of a kref in a list that can be found while the last instance could be removed at the same time. This patch reuse gdp_mutex to fix this race condition. The following calltrace is captured in kernel 3.4, but the latest kernel still has this bug. ----------------------------------------------------- <4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40() <4>[ 3965.441474] Hardware name: Romley <4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)... ... <4>[ 3965.441605] Call Trace: <4>[ 3965.441611] [<ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0 <4>[ 3965.441615] [<ffffffff810371c5>] warn_slowpath_null+0x15/0x20 <4>[ 3965.441618] [<ffffffff81215963>] kobject_get+0x33/0x40 <4>[ 3965.441624] [<ffffffff812d1e45>] get_device_parent.isra.11+0x135/0x1f0 <4>[ 3965.441627] [<ffffffff812d22d4>] device_add+0xd4/0x6d0 <4>[ 3965.441631] [<ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40 .... <2>[ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65! <4>[ 3965.441915] invalid opcode: 0000 [#1] SMP ... <4>[ 3965.686743] [<ffffffff811a677e>] sysfs_create_group+0xe/0x10 <4>[ 3965.686748] [<ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20 <4>[ 3965.686753] [<ffffffff811fcabb>] blk_register_queue+0x3b/0x120 <4>[ 3965.686756] [<ffffffff812030bc>] add_disk+0x1cc/0x490 .... ------------------------------------------------------- Signed-off-by: NYijing Wang <wangyijing@huawei.com> Signed-off-by: NWeng Meiling <wengmeiling.weng@huawei.com> Cc: <stable@vger.kernel.org> #3.4+ Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 07 11月, 2014 2 次提交
-
-
由 Johan Hovold 提交于
Add new quirk for devices that cannot handle control-line state requests. Note that we currently send these requests to all devices, regardless of whether they claim to support it, but that errors are only logged if support is claimed. Since commit 0943d8ea ("USB: cdc-acm: use tty-port dtr_rts"), which only changed the timings for these requests slightly, this has been reported to cause occasional firmware crashes on Simtec Electronics Entropy Key devices after re-enumeration. Enable the quirk for this device. Reported-by: NNix <nix@esperi.org.uk> Tested-by: NNix <nix@esperi.org.uk> Cc: stable <stable@vger.kernel.org> # v3.16 Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Francesco Ruggeri 提交于
Commit f95499c3 ("n_tty: Don't wait for buffer work in read() loop") introduces a race window where a pty master can be signalled that the pty slave was closed before all the data that the slave wrote is delivered. Commit f8747d4a ("tty: Fix pty master read() after slave closes") fixed the problem in case of n_tty_read, but the problem still exists for n_tty_poll. This can be seen by running 'for ((i=0; i<100;i++));do ./test.py ;done' where test.py is: import os, select, pty (pid, pty_fd) = pty.fork() if pid == 0: os.write(1, 'This string should be received by parent') else: poller = select.epoll() poller.register( pty_fd, select.EPOLLIN ) ready = poller.poll( 1 * 1000 ) for fd, events in ready: if not events & select.EPOLLIN: print 'missed POLLIN event' else: print os.read(fd, 100) poller.close() The string from the slave is missed several times. This patch takes the same approach as the fix for read and special cases this condition for poll. Tested on 3.16. Signed-off-by: NFrancesco Ruggeri <fruggeri@arista.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 06 11月, 2014 17 次提交
-
-
由 Dmitry Eremin-Solenikov 提交于
If PM_RUNTIME is enabled, it is easy to trigger the following backtrace on pxa2xx hosts: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8() Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty #104 [<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14) [<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c) [<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24) [<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8) [<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34) [<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54) [<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74) [<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8) [<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208) [<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0) [<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8) [<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc) [<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc) [<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4) [<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec) [<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24) ---[ end trace 46524156d8faa4f6 ]--- This happens because suspend function tries to disable a clock that is already disabled by runtime_suspend callback. Add if (!pm_runtime_suspended()) checks to suspend/resume path. Fixes: 7d94a505 (spi/pxa2xx: add support for runtime PM) Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com> Reported-by: NAndrea Adami <andrea.adami@gmail.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-
由 Jingchang Lu 提交于
The info pointer points to an uninitialized kmalloced space. If a device doesn't have clk property, then info->clk may have unpredicated value and cause call trace. So use kzalloc to make sure it is NULL initialized. Signed-off-by: NJingchang Lu <jingchang.lu@freescale.com> Acked-by: Arnd Bergmann <arnd@arndb.de Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Imre Deak 提交于
We can call this function for a dummy console that doesn't support setting the font mapping, which will result in a null ptr BUG. So check for this case and return error for consoles w/o font mapping support. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=59321Signed-off-by: NImre Deak <imre.deak@intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Matthias Brugger 提交于
The calculation of value quot for highspeed register set to three was wrong. This patch fixes the calculation so that the serial port for baudrates bigger then 576000 baud is working correctly. Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Arnd Bergmann 提交于
The horrible split between the low-level part of the edma support and the dmaengine front-end driver causes problems on multiplatform kernels. This is an attempt to improve the situation slightly by only registering the dmaengine devices that are actually present. Signed-off-by: NArnd Bergmann <arnd@arndb.de> [olof: add missing include of linux/dma-mapping.h] Signed-off-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Peter Hurley 提交于
Only print one warning when a task is on the read_wait or write_wait wait queue at final tty release. Cc: <stable@vger.kernel.org> # 3.4.x+ Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Hurley 提交于
Kernel oops can cause the tty to be unreleaseable (for example, if n_tty_read() crashes while on the read_wait queue). This will cause tty_release() to endlessly loop without sleeping. Use a killable sleep timeout which grows by 2n+1 jiffies over the interval [0, 120 secs.) and then jumps to forever (but still killable). NB: killable just allows for the task to be rewoken manually, not to be terminated. Cc: <stable@vger.kernel.org> # since before 2.6.32 Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Hurley 提交于
uart_get_baud_rate() will return baud == 0 if the max rate is set to the "magic" 38400 rate and the SPD_* flags are also specified. On the first iteration, if the current baud rate is higher than the max, the baud rate is clamped at the max (which in the degenerate case is 38400). On the second iteration, the now-"magic" 38400 baud rate selects the possibly higher alternate baud rate indicated by the SPD_* flag. Since only two loop iterations are performed, the loop is exited, a kernel WARNING is generated and a baud rate of 0 is returned. Reproducible with: setserial /dev/ttyS0 spd_hi base_baud 38400 Only perform the "magic" 38400 -> SPD_* baud transform on the first loop iteration, which prevents the degenerate case from recognizing the clamped baud rate as the "magic" 38400 value. Reported-by: NRobert Święcki <robert@swiecki.net> Cc: <stable@vger.kernel.org> # all Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Oussama Ghorbel 提交于
The USB OTG port does not work since v3.16 on omap platform. This is a regression introduced by the commit eb82a3d8 (phy: omap-usb2: Balance pm_runtime_enable() on probe failure and remove). This because the call to pm_runtime_enable() function is moved after the call to devm_phy_create() function, which has side effect since later in the subsequent calls of devm_phy_create() there is a check with pm_runtime_enabled() to configure few things. Fixes: eb82a3d8Signed-off-by: NOussama Ghorbel <ghorbel@pivasoftware.com> Tested-by: NRabin Vincent <rabin@rab.in> Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mark Knibbs 提交于
The timeout argument to usb_stor_control_msg() is specified in jiffies, not milliseconds. Signed-off-by: NMark Knibbs <markk@clara.co.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Make sure to only raise DTR on transitions from B0 in set_termios. Also allow set_termios to be called from open with a termios_old of NULL. Note that DTR will not be raised prematurely in this case. Cc: stable <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
This reverts commit bda9893c as it was incorrect. Reported-by: NMark Knibbs <markk@clara.co.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Lars-Peter Clausen 提交于
"raw" is a property of a channel, but should not be part of the name of channel. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Cc: <stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <jic23@kernel.org>
-
由 Lars-Peter Clausen 提交于
We should check if a channel is enabled, not if no channels are enabled. Fixes: 550268ca ("staging:iio: scrap scan_count and ensure all drivers use active_scan_mask") Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Cc: <stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <jic23@kernel.org>
-
由 Lars-Peter Clausen 提交于
In older versions of the IIO framework it was possible to pass a completely different set of channels to iio_buffer_register() as the one that is assigned to the IIO device. Commit 959d2952 ("staging:iio: make iio_sw_buffer_preenable much more general.") introduced a restriction that requires that the set of channels that is passed to iio_buffer_register() is a subset of the channels assigned to the IIO device as the IIO core will use the list of channels that is assigned to the device to lookup a channel by scan index in iio_compute_scan_bytes(). If it can not find the channel the function will crash. This patch fixes the issue by making sure that the same set of channels is assigned to the IIO device and passed to iio_buffer_register(). Note that we need to remove the IIO_CHAN_INFO_RAW and IIO_CHAN_INFO_SCALE info attributes from the channels since we don't actually want those to be registered. Fixes the following crash: Unable to handle kernel NULL pointer dereference at virtual address 00000016 pgd = d2094000 [00000016] *pgd=16e39831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM Modules linked in: CPU: 1 PID: 1695 Comm: bash Not tainted 3.17.0-06329-g29461ee #9686 task: d7768040 ti: d5bd4000 task.ti: d5bd4000 PC is at iio_compute_scan_bytes+0x38/0xc0 LR is at iio_compute_scan_bytes+0x34/0xc0 pc : [<c0316de8>] lr : [<c0316de4>] psr: 60070013 sp : d5bd5ec0 ip : 00000000 fp : 00000000 r10: d769f934 r9 : 00000000 r8 : 00000001 r7 : 00000000 r6 : c8fc6240 r5 : d769f800 r4 : 00000000 r3 : d769f800 r2 : 00000000 r1 : ffffffff r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 18c5387d Table: 1209404a DAC: 00000015 Process bash (pid: 1695, stack limit = 0xd5bd4240) Stack: (0xd5bd5ec0 to 0xd5bd6000) 5ec0: d769f800 d7435640 c8fc6240 d769f984 00000000 c03175a4 d7435690 d7435640 5ee0: d769f990 00000002 00000000 d769f800 d5bd4000 00000000 000b43a8 c03177f4 5f00: d769f810 0162b8c8 00000002 c8fc7e00 d77f1d08 d77f1da8 c8fc7e00 c01faf1c 5f20: 00000002 c010694c c010690c d5bd5f88 00000002 c8fc6840 c8fc684c c0105e08 5f40: 00000000 00000000 d20d1580 00000002 000af408 d5bd5f88 c000de84 c00b76d4 5f60: d20d1580 000af408 00000002 d20d1580 d20d1580 00000002 000af408 c000de84 5f80: 00000000 c00b7a44 00000000 00000000 00000002 b6ebea78 00000002 000af408 5fa0: 00000004 c000dd00 b6ebea78 00000002 00000001 000af408 00000002 00000000 5fc0: b6ebea78 00000002 000af408 00000004 bee96a4c 000a6094 00000000 000b43a8 5fe0: 00000000 bee969cc b6e2eb77 b6e6525c 40070010 00000001 00000000 00000000 [<c0316de8>] (iio_compute_scan_bytes) from [<c03175a4>] (__iio_update_buffers+0x248/0x438) [<c03175a4>] (__iio_update_buffers) from [<c03177f4>] (iio_buffer_store_enable+0x60/0x7c) [<c03177f4>] (iio_buffer_store_enable) from [<c01faf1c>] (dev_attr_store+0x18/0x24) [<c01faf1c>] (dev_attr_store) from [<c010694c>] (sysfs_kf_write+0x40/0x4c) [<c010694c>] (sysfs_kf_write) from [<c0105e08>] (kernfs_fop_write+0x110/0x154) [<c0105e08>] (kernfs_fop_write) from [<c00b76d4>] (vfs_write+0xbc/0x170) [<c00b76d4>] (vfs_write) from [<c00b7a44>] (SyS_write+0x40/0x78) [<c00b7a44>] (SyS_write) from [<c000dd00>] (ret_fast_syscall+0x0/0x30) Fixes: 959d2952 ("staging:iio: make iio_sw_buffer_preenable much more general.") Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Cc: <stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <jic23@kernel.org>
-
由 George McCollister 提交于
Signed-off-by: NGeorge McCollister <george.mccollister@gmail.com> Acked-by: NHartmut Knaack <knaack.h@gmx.de> Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <jic23@kernel.org>
-
由 Daniel Baluta 提交于
Because IIO_EV_DIR_* are not bitmasks but enums, IIO_EV_DIR_RISING | IIO_EV_DIR_FALLING is not equal with IIO_EV_DIR_EITHER. This could lead to potential misformatted sysfs attributes like: * in_accel_x_thresh_(null)_en * in_accel_x_thresh_(null)_period * in_accel_x_thresh_(null)_value or even memory corruption. Fixes: b4b491c0 (iio: accel: kxcjk-1013: Support threshold) Signed-off-by: NDaniel Baluta <daniel.baluta@intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: NJonathan Cameron <jic23@kernel.org>
-