- 23 2月, 2012 3 次提交
-
-
由 Dan Carpenter 提交于
The intent was to clear out the icount struct here, but we accidentally clear stack memory instead. It probably will lead to a NULL dereference right away. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 RongQing.Li 提交于
ip6_route_output() never returns NULL, so it is wrong to check if the return value is NULL. Signed-off-by: NRongQing.Li <roy.qing.li@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guo-Fu Tseng 提交于
Set the RX FIFO flush watermark lower. According to Federico and JMicron's reply, setting it to 16QW would be stable on most platforms. Otherwise, user might experience packet drop issue. CC: stable@kernel.org Reported-by: NFederico Quagliata <federico@quagliata.org> Fixed-by: NFederico Quagliata <federico@quagliata.org> Signed-off-by: NGuo-Fu Tseng <cooldavid@cooldavid.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 22 2月, 2012 3 次提交
-
-
由 Yevgeny Petrilin 提交于
In port type change flow, need to set the new port types only after all interfaces have finished the unregister process. Otherwise, during unregister, one of the interfaces might issue a SET_PORT command with wrong port types, it can cause bad FW behavior. Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Yevgeny Petrilin 提交于
Under the spinlock we call request_irq(), which allocates memory with GFP_KERNEL, This causes the following trace when DEBUG_SPINLOCK is enabled, it can cause the following trace: BUG: spinlock wrong CPU on CPU#2, ethtool/2595 lock: ffff8801f9cbc2b0, .magic: dead4ead, .owner: ethtool/2595, .owner_cpu: 0 Pid: 2595, comm: ethtool Not tainted 3.0.18 #2 Call Trace: spin_bug+0xa2/0xf0 do_raw_spin_unlock+0x71/0xa0 _raw_spin_unlock+0xe/0x10 mlx4_assign_eq+0x12b/0x190 [mlx4_core] mlx4_en_activate_cq+0x252/0x2d0 [mlx4_en] ? mlx4_en_activate_rx_rings+0x227/0x370 [mlx4_en] mlx4_en_start_port+0x189/0xb90 [mlx4_en] mlx4_en_set_ringparam+0x29a/0x340 [mlx4_en] dev_ethtool+0x816/0xb10 ? dev_get_by_name_rcu+0xa4/0xe0 dev_ioctl+0x2b5/0x470 handle_mm_fault+0x1cd/0x2d0 sock_do_ioctl+0x5d/0x70 sock_ioctl+0x79/0x2f0 do_vfs_ioctl+0x8c/0x340 sys_ioctl+0xa1/0xb0 system_call_fastpath+0x16/0x1b Replacing with mutex, which is enough in this case. Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dave Jones 提交于
In 16adf5d0 I removed an over-broad alias that caused zaurus.ko to bind to unrelated devices. I had a report that at least one valid case no longer auto-loads because of this. This patch adds an ID for that case. Reported-by: NRaphael Wimmer <raphael.wimmer@ur.de> Signed-off-by: NDave Jones <davej@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 21 2月, 2012 1 次提交
-
-
由 Jack Morgenstein 提交于
BF can be disabled in some cases, the capability field, bf_reg_size is set to zero in this case. Don't map the BF area in this case, it would cause failures. In addition, leaving the BF area unmapped also alerts the ETH driver to not use BF. Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 20 2月, 2012 6 次提交
-
-
由 Oliver Hartkopp 提交于
In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the hardware can cause an infinite loop in the common sja1000 isr. Use the already retrieved status register to indicate a possible hardware removal and double check by reading the mode register in sja1000_is_absent. Cc: stable@kernel.org [3.2+] Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net> Acked-by: NWolfgang Grandegger <wg@grandegger.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Nikola Pajkovsky 提交于
WARNING: drivers/net/ethernet/broadcom/built-in.o(.init.text+0x5d): Section mismatch in reference from the function b44_init() to the function .exit.text:b44_pci_exit() module exits with b44_cleanup() Signed-off-by: NNikola Pajkovsky <n.pajkovsky@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Julia Lawall 提交于
The calls to pci_iounmap are in the wrong order, as compared to the associated calls to pci_iomap. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression e,x; statement S,S1; int ret; @@ e = pci_iomap(x,...) ... when != pci_iounmap(x,e) if (<+...e...+>) S ... when any when != pci_iounmap(x,e) *if (...) { ... when != pci_iounmap(x,e) return ...; } ... when any pci_iounmap(x,e); // </smpl> Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
netdev->irq is unsigned, so it's never less than zero. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Tested-by: NJan Weitzel <j.weitzel@phytec.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Neil Horman 提交于
I was recently shown that vmxnet3 devices on transmit, will drop very small udp frames consistently. This is due to a regression introduced by commit 39d4a96f. This commit attempts to introduce an optimization to the tx path, indicating that the underlying hardware behaves optimally when at least 54 bytes of header data are available for direct access. This causes problems however, if the entire frame is less than 54 bytes long. The subsequent pskb_may_pull in vmxnet3_parse_and_copy_hdr fails, causing an error return code, which leads to vmxnet3_tq_xmit dropping the frame. Fix it by placing a cap on the copy length. For frames longer than 54 bytes, we do the pull as we normally would. If the frame is shorter than that, copy the whole frame, but no more. This ensures that we still get the optimization for qualifying frames, but don't do any damange for frames that are too short. Also, since I'm unable to do this, it wuold be great if vmware could follow up this patch with some additional code commentary as to why 54 bytes is an optimal pull length for a virtual NIC driver. The comment that introduced this was vague on that. Thanks! Signed-off-by: NNeil Horman <nhorman@tuxdriver.com> Reported-by: NMax Matveev <mmatveev@redhat.com> CC: Max Matveev <mmatveev@redhat.com> CC: "David S. Miller" <davem@davemloft.net> CC: Shreyas Bhatewara <sbhatewara@vmware.com> CC: "VMware, Inc." <pv-drivers@vmware.com> Signed-off-by: NShreyas N Bhatewara <sbhatewara@vmware.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eric Dumazet 提交于
This driver attempts to use two TX rings but lacks proper support : 1) IRQ handler only takes care of TX completion on first TX ring 2) the stop/start logic uses the legacy functions (for non multiqueue drivers) This means all packets witk skb mark set to 1 are sent through high queue but are never cleaned and queue eventualy fills and block the device, triggering the infamous "NETDEV WATCHDOG" message. Lets use a single TX ring to fix the problem, this driver is not a real multiqueue one yet. Minimal fix for stable kernels. Reported-by: NThomas Meyer <thomas@m3y3r.de> Tested-by: NThomas Meyer <thomas@m3y3r.de> Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Cc: Jay Cliburn <jcliburn@gmail.com> Cc: Chris Snook <chris.snook@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 16 2月, 2012 14 次提交
-
-
由 majianpeng 提交于
Signed-off-by: Nmajianpeng <majianpeng@gmail.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Jan Weitzel 提交于
There a two different irq variables ks->irq and netdev->irq. Only ks->irq is set on probe, so disabling irq in ks_start_xmit fails. This patches remove ks->irq from private data and use only netdev->irq. Tested on a kernel 3.0 based OMAP4430 SMP Board Signed-off-by: NJan Weitzel <j.weitzel@phytec.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Thomas Graf 提交于
VETH_INFO_PEER carries struct ifinfomsg plus optional IFLA attributes. A minimal size of sizeof(struct ifinfomsg) must be enforced or we may risk accessing that struct beyond the limits of the netlink message. Signed-off-by: NThomas Graf <tgraf@suug.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Giuseppe CAVALLARO 提交于
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Giuseppe CAVALLARO 提交于
This patch moves the MAC HW initialization and the HW feature verification from the open to the probe function as D. Miller suggested. So the patch actually reorganizes and tidies-up some parts of the driver and indeed fixes some problem when tune its HW features. These can be overwritten by looking at the HW cap register at run-time and that generated problems. Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com> Reviewed-by: NFrancesco Virlinzi <francesco.virlinzi@st.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Francesco Virlinzi 提交于
In case of we use an external Wake-Up IRQ line (priv->wol_irq != dev->irq) we need to invoke the request_irq. Signed-off-by: NFrancesco Virlinzi <francesco.virlinzi@st.com> Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Giuseppe CAVALLARO 提交于
If this bit is set and the CRC error is reset, then the packet is valid. Only report this as stat info. Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Tim Gardner 提交于
BugLink: http://bugs.launchpad.net/bugs/900802 Cc: stable@vger.kernel.org 3.2+ Signed-off-by: NTill Kamppeter <till.kamppeter@gmail.com> Signed-off-by: NTim Gardner <tim.gardner@canonical.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eugenia Emantayev 提交于
Add unicast steering entries to resource tracker. Do qp_detach also for these entries when VF doesn't shut down gracefully. Otherwise there is leakage of these resources, since they are not tracked. Signed-off-by: NEugenia Emantayev <eugenia@mellanox.co.il> Reviewed-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eugenia Emantayev 提交于
When adding new unicast steer entry, before moving qp to state ready, actually before calling mlx4_RST2INIT_QP_wrapper(), there were added a lot of entries with local_qpn=0 into radix tree. This fact impacted the get_res() function and proper functioning of resource tracker in addition to adding trash entries into radix tree. Signed-off-by: NEugenia Emantayev <eugenia@mellanox.co.il> Reviewed-by: NYevgeny Petrilin <yevgenyp@melllanox.co.il> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eugenia Emantayev 提交于
When passing MLX4_UC_STEER=1 it was translated to value 2 after mlx4_QP_ATTACH_wrapper. Therefore in new_steering_entry() unicast steer entries were added to index 2 of array of size 2. Fixing this bug by shift right to one position. Signed-off-by: NEugenia Emantayev <eugenia@mellanox.co.il> Reviewed-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Pavel Roskin 提交于
Rate control algorithms are supposed to stop processing when they encounter a rate with the index -1. Checking for rate->count not being zero is not enough. Allowing a rate with negative index leads to memory corruption in ath_debug_stat_rc(). One consequence of the bug is discussed at https://bugzilla.redhat.com/show_bug.cgi?id=768639Signed-off-by: NPavel Roskin <proski@gnu.org> Cc: stable@vger.kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Amitkumar Karwar 提交于
Driver maintains different flags for WEP, WPA, WPA2 security modes. Appropriate flag is set using security information provided in connect request. mwifiex_is_network_compatible() routine uses them to check if driver's setting is compatible with AP. Association is aborted if the routine fails. For some corner cases, it is observed that association is failed even for valid security information based on association history. This patch fixes the problem by clearing previous security setting during each association. We should set WEP key provided in connect request as default tx key. This missing change is also added here. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Lars-Peter Clausen 提交于
Currently registers with a value of 0 are ignored when initializing the register defaults from raw defaults. This worked in the past, because registers without a explicit default were assumed to have a default value of 0. This was changed in commit b03622a8 ("regmap: Ensure rbtree syncs registers set to zero properly"). As a result registers, which have a raw default value of 0 are now assumed to have no default. This again can result in unnecessary writes when syncing the cache. It will also result in unnecessary reads for e.g. the first update operation. In the case where readback is not possible this will even let the update operation fail, if the register has not been written to before. So this patch removes the check. Instead it adds a check to ignore raw defaults for registers which are volatile, since those registers are not cached. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@vger.kernel.org
-
- 15 2月, 2012 4 次提交
-
-
由 Manoj Iyer 提交于
T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0a5c ProdID=21f3 Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=74DE2B344A7B C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Signed-off-by: NManoj Iyer <manoj.iyer@canonical.com> Tested-by: NDennis Chua <dennis.chua@canonical.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Daniel Wagner 提交于
[ 2096.384084] btusb_send_frame:684: hci0 [ 2096.384087] usb 3-1: BOGUS urb flags, 2 --> 0 [ 2096.384091] Bluetooth: hci0 urb ffff8801b61d3a80 submission failed (22) According the documentation in usb_submit_urb() URB_ISO_ASAP flag is only allowed for endpoints of type USB_ENDPOINT_XFER_ISOC. This reverts commit b8aabfc9. Signed-off-by: NDaniel Wagner <daniel.wagner@bmw-carit.de> Acked-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Eric Dumazet 提交于
Jean Delvare reported bonding on top of 3c59x adapters was not detecting network cable removal fast enough. 3c59x indeed uses a 60 seconds timer to check link status if carrier is on, and 5 seconds if carrier is off. This patch reduces timer period to 5 seconds if device is a bonding slave. Reported-by: NJean Delvare <jdelvare@suse.de> Acked-by: NJean Delvare <jdelvare@suse.de> Acked-by: NSteffen Klassert <steffen.klassert@secunet.com> Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michal Schmidt 提交于
'poll' was a debugging option, but turning it on these days leads to kernel panic. Remove it. Signed-off-by: NMichal Schmidt <mschmidt@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 14 2月, 2012 9 次提交
-
-
由 Alex Deucher 提交于
MSI_REARM_EN register is a write only trigger register. There is no need RMW when re-arming. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=41668Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> CC: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
- Add missing DFP6 connection state handling - crtc routing bits not used on DCE4+ Noticed by sylware on phoronix. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
Silly bad return path. Reported-and-Tested-by: Mikko Vinni Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> CC: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Seungwon Jeon 提交于
Current PIO mode makes a kernel crash with CONFIG_HIGHMEM. Highmem pages have a NULL from sg_virt(sg). This patch fixes the following problem. Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 817 [#1] PREEMPT SMP Modules linked in: CPU: 0 Not tainted (3.0.15-01423-gdbf465f #589) PC is at dw_mci_pull_data32+0x4c/0x9c LR is at dw_mci_read_data_pio+0x54/0x1f0 pc : [<c0358824>] lr : [<c035988c>] psr: 20000193 sp : c0619d48 ip : c0619d70 fp : c0619d6c r10: 00000000 r9 : 00000002 r8 : 00001000 r7 : 00000200 r6 : 00000000 r5 : e1dd3100 r4 : 00000000 r3 : 65622023 r2 : 0000007f r1 : eeb96000 r0 : e1dd3100 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment xkernel Control: 10c5387d Table: 61e2004a DAC: 00000015 Process swapper (pid: 0, stack limit = 0xc06182f0) Stack: (0xc0619d48 to 0xc061a000) 9d40: e1dd3100 e1a4f000 00000000 e1dd3100 e1a4f000 00000200 9d60: c0619da4 c0619d70 c035988c c03587e4 c0619d9c e18158f4 e1dd3100 e1dd3100 9d80: 00000020 00000000 00000000 00000020 c06e8a84 00000000 c0619e04 c0619da8 9da0: c0359b24 c0359844 e18158f4 e1dd3164 e1dd3168 e1dd3150 3d02fc79 e1dd3154 9dc0: e1dd3178 00000000 00000020 00000000 e1dd3150 00000000 c10dd7e8 e1a84900 9de0: c061e7cc 00000000 00000000 0000008d c06e8a84 c061e780 c0619e4c c0619e08 9e00: c00c4738 c0359a34 3d02fc79 00000000 c0619e4c c05a1698 c05a1670 c05a165c 9e20: c04de8b0 c061e780 c061e7cc e1a84900 ffffed68 0000008d c0618000 00000000 9e40: c0619e6c c0619e50 c00c48b4 c00c46c8 c061e780 c00423ac c061e7cc ffffed68 9e60: c0619e8c c0619e70 c00c7358 c00c487c 0000008d ffffee38 c0618000 ffffed68 9e80: c0619ea4 c0619e90 c00c4258 c00c72b0 c00423ac ffffee38 c0619ecc c0619ea8 9ea0: c004241c c00c4234 ffffffff f8810000 0000006d 00000002 00000001 7fffffff 9ec0: c0619f44 c0619ed0 c0048bc0 c00423c4 220ae7a9 00000000 386f0d30 0005d3a4 9ee0: c00423ac c10dd0b8 c06f2cd8 c0618000 c0594778 c003a674 7fffffff c0619f44 9f00: 386f0d30 c0619f18 c00a6f94 c005be3c 80000013 ffffffff 386f0d30 0005d3a4 9f20: 386f0d30 0005d2d1 c10dd0a8 c10dd0b8 c06f2cd8 c0618000 c0619f74 c0619f48 9f40: c0345858 c005be00 c00a2440 c0618000 c0618000 c00410d8 c06c1944 c00410fc 9f60: c0594778 c003a674 c0619f9c c0619f78 c004a7e8 c03457b4 c0618000 c06c18f8 9f80: 00000000 c0039c70 c06c18d4 c003a674 c0619fb4 c0619fa0 c04ceafc c004a714 9fa0: c06287b4 c06c18f8 c0619ff4 c0619fb8 c0008b68 c04cea68 c0008578 00000000 9fc0: 00000000 c003a674 00000000 10c5387d c0628658 c003aa78 c062f1c4 4000406a 9fe0: 413fc090 00000000 00000000 c0619ff8 40008044 c0008858 00000000 00000000 Backtrace: [<c03587d8>] (dw_mci_pull_data32+0x0/0x9c) from [<c035988c>] (dw_mci_read_data_pio+0x54/0x1f0) r6:00000200 r5:e1a4f000 r4:e1dd3100 [<c0359838>] (dw_mci_read_data_pio+0x0/0x1f0) from [<c0359b24>] (dw_mci_interrupt+0xfc/0x4a4) [<c0359a28>] (dw_mci_interrupt+0x0/0x4a4) from [<c00c4738>] (handle_irq_event_percpu+0x7c/0x1b4) [<c00c46bc>] (handle_irq_event_percpu+0x0/0x1b4) from [<c00c48b4>] (handle_irq_event+0x44/0x64) [<c00c4870>] (handle_irq_event+0x0/0x64) from [<c00c7358>] (handle_fasteoi_irq+0xb4/0x124) r7:ffffed68 r6:c061e7cc r5:c00423ac r4:c061e780 [<c00c72a4>] (handle_fasteoi_irq+0x0/0x124) from [<c00c4258>] (generic_handle_irq+0x30/0x38) r7:ffffed68 r6:c0618000 r5:ffffee38 r4:0000008d [<c00c4228>] (generic_handle_irq+0x0/0x38) from [<c004241c>] (asm_do_IRQ+0x64/0xe0) r5:ffffee38 r4:c00423ac [<c00423b8>] (asm_do_IRQ+0x0/0xe0) from [<c0048bc0>] (__irq_svc+0x80/0x14c) Exception stack(0xc0619ed0 to 0xc0619f18) Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Acked-by: NWill Newton <will.newton@imgtec.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ludovic Desroches 提交于
Sometimes a software reset is needed. Then some registers are saved and restored but the interrupt mask register is missing. It causes issues with sdio devices whose interrupts are masked after reset. Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Rabin Vincent 提交于
Signed-off-by: NRabin Vincent <rabin.vincent@stericsson.com> Signed-off-by: NJohan Rudholm <johan.rudholm@stericsson.com> Signed-off-by: NUlf Hansson <ulf.hansson@stericsson.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Guennadi Liakhovetski 提交于
If the driver is loaded with a card in the slot, mmc_add_host() will schedule an immediate card-detection work, which will start IO and wait for command completion. Usually the kernel first returns to the sh_mmcif probe function, lets it finish and only then schedules the rescan work. But sometimes, expecially under heavy system load, the work will be scheduled immediately before returning to the probe method. In this case it is important for the driver to be fully prepared for IO. For sh_mmcif this means, that also the timeout work has to be initialised before calling mmc_add_host(). It is also better to prepare interrupts beforehand. Besides, since mmc_add_host() does card-detection itself, there is no need to do it again immediately afterwards. Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Guennadi Liakhovetski 提交于
When DMA is in use and the card is ejected during IO, DMA transfers have to be terminated, otherwise the dmaengine driver fails to operate properly, when the card is re-inserted. Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Jurgen Heeks 提交于
Found this issue during code review. Actually, there are two issues which both compensate together in lucky case. In unlucky case the bus width probing might not work as expected. Signed-off-by: NJurgen Heeks <jurgen.heeks@nokia.com> Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-