- 08 Feb, 2015 37 commits
-
-
Bob Paauwe authored
commit af1a7301 upstream. When creating a fence for a tiled object, only fence the area that makes up the actual tiles. The object may be larger than the tiled area and if we allow those extra addresses to be fenced, they'll get converted to addresses beyond where the object is mapped. This opens up the possiblity of writes beyond the end of object. To prevent this, we adjust the size of the fence to only encompass the area that makes up the actual tiles. The extra space is considered un-tiled and now behaves as if it was a linear object. Testcase: igt/gem_tiled_fence_overflow Reported-by:
Dan Hettena <danh@ghs.com> Signed-off-by:
Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Mugunthan V N authored
commit 02a54164 upstream. In Dual EMAC, the default VLANs are used to segregate Rx packets between the ports, so adding the same default VLAN to the switch will affect the normal packet transfers. So returning error on addition of dual EMAC default VLANs. Even if EMAC 0 default port VLAN is added to EMAC 1, it will lead to break dual EMAC port separations. Fixes: d9ba8f9e (driver: net: ethernet: cpsw: dual emac interface implementation) Reported-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ashay Jaiswal authored
commit 83b0302d upstream. The regulator framework maintains a list of consumer regulators for a regulator device and protects it from concurrent access using the regulator device's mutex lock. In the case of regulator_put() the consumer is removed and regulator device's parameters are updated without holding the regulator device's mutex. This would lead to a race condition between the regulator_put() and any function which traverses the consumer list or modifies regulator device's parameters. Fix this race condition by holding the regulator device's mutex in case of regulator_put. Signed-off-by:
Ashay Jaiswal <ashayj@codeaurora.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Mika Westerberg authored
commit c957e8f0 upstream. Once the current message is finished, the driver notifies SPI core about this by calling spi_finalize_current_message(). This function queues next message to be transferred. If there are more messages in the queue, it is possible that the driver is asked to transfer the next message at this point. When spi_finalize_current_message() returns the driver clears the drv_data->cur_chip pointer to NULL. The problem is that if the driver already started the next message clearing drv_data->cur_chip will cause NULL pointer dereference which crashes the kernel like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 IP: [<ffffffffa0022bc8>] cs_deassert+0x18/0x70 [spi_pxa2xx_platform] PGD 78bb8067 PUD 37712067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G O 3.18.0-rc4-mjo #5 Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS MNW2CRB1.X64.0071.R30.1408131301 08/13/2014 task: ffff880077f9f290 ti: ffff88007a820000 task.ti: ffff88007a820000 RIP: 0010:[<ffffffffa0022bc8>] [<ffffffffa0022bc8>] cs_deassert+0x18/0x70 [spi_pxa2xx_platform] RSP: 0018:ffff88007a823d08 EFLAGS: 00010202 RAX: 0000000000000008 RBX: ffff8800379a4430 RCX: 0000000000000026 RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff8800379a4430 RBP: ffff88007a823d18 R08: 00000000ffffffff R09: 000000007a9bc65a R10: 000000000000028f R11: 0000000000000005 R12: ffff880070123e98 R13: ffff880070123de8 R14: 0000000000000100 R15: ffffc90004888000 FS: 0000000000000000(0000) GS:ffff880079a80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000048 CR3: 000000007029b000 CR4: 00000000001007e0 Stack: ffff88007a823d58 ffff8800379a4430 ffff88007a823d48 ffffffffa0022c89 0000000000000000 ffff8800379a4430 0000000000000000 0000000000000006 ffff88007a823da8 ffffffffa0023be0 ffff88007a823dd8 ffffffff81076204 Call Trace: [<ffffffffa0022c89>] giveback+0x69/0xa0 [spi_pxa2xx_platform] [<ffffffffa0023be0>] pump_transfers+0x710/0x740 [spi_pxa2xx_platform] [<ffffffff81076204>] ? pick_next_task_fair+0x744/0x830 [<ffffffff81049679>] tasklet_action+0xa9/0xe0 [<ffffffff81049a0e>] __do_softirq+0xee/0x280 [<ffffffff81049bc0>] run_ksoftirqd+0x20/0x40 [<ffffffff810646df>] smpboot_thread_fn+0xff/0x1b0 [<ffffffff810645e0>] ? SyS_setgroups+0x150/0x150 [<ffffffff81060f9d>] kthread+0xcd/0xf0 [<ffffffff81060ed0>] ? kthread_create_on_node+0x180/0x180 [<ffffffff8187a82c>] ret_from_fork+0x7c/0xb0 Fix this by clearing drv_data->cur_chip before we call spi_finalize_current_message(). Reported-by:
Martin Oldfield <m@mjoldfield.com> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Joe Thornber authored
commit 766a7888 upstream. Commit 9b1cc9f2 ("dm cache: share cache-metadata object across inactive and active DM tables") mistakenly ignored the use of ERR_PTR returns. Restore missing IS_ERR checks and ERR_PTR returns where appropriate. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Joe Thornber authored
commit 2a7eaea0 upstream. You can't modify the metadata in these modes. It's better to fail these messages immediately than let the block-manager deny write locks on metadata blocks. Otherwise these failed metadata changes will trigger 'needs_check' to get set in the metadata superblock -- requiring repair using the thin_check utility. Signed-off-by:
-
Johannes Berg authored
commit 0fa7b391 upstream. In case userspace attempts to obtain key information for or delete a unicast key, this is currently erroneously rejected unless the driver sets the WIPHY_FLAG_IBSS_RSN flag. Apparently enough drivers do so it was never noticed. Fix that, and while at it fix a potential memory leak: the error path in the get_key() function was placed after allocating a message but didn't free it - move it to a better place. Luckily admin permissions are needed to call this operation. Fixes: e31b8213 ("cfg80211/mac80211: allow per-station GTKs") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Mathy Vanhoef authored
commit 3a5c5e81 upstream. Fix a regression introduced by commit a5e70697 ("mac80211: add radiotap flag and handling for 5/10 MHz") where the IEEE80211_CHAN_CCK channel type flag was incorrectly replaced by the IEEE80211_CHAN_OFDM flag. This commit fixes that by using the CCK flag again. Fixes: a5e70697 ("mac80211: add radiotap flag and handling for 5/10 MHz") Signed-off-by:
Mathy Vanhoef <vanhoefm@gmail.com> Signed-off-by:
-
Trond Myklebust authored
commit 3175e1dc upstream. If we start state recovery on a client that failed to initialise correctly, then we are very likely to Oops. Reported-by:
"Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de> Link: http://lkml.kernel.org/r/130621862.279655.1421851650684.JavaMail.zimbra@desy.deSigned-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Peng Tao authored
commit ee8a1a8b upstream. We only support swap file calling nfs_direct_IO. However, application might be able to get to nfs_direct_IO if it toggles O_DIRECT flag during IO and it can deadlock because we grab inode->i_mutex in nfs_file_direct_write(). So return 0 for such case. Then the generic layer will fall back to buffer IO. Signed-off-by:
Peng Tao <tao.peng@primarydata.com> Signed-off-by:
-
Jochen Hein authored
commit 1d90d6d5 upstream. Without this the aux port does not get detected, and consequently the touchpad will not work. With this patch the touchpad is detected: $ dmesg | grep -E "(SYN|i8042|serio)" pnp 00:03: Plug and Play ACPI device, IDs SYN1d22 PNP0f13 (active) i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4 psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd00123/0x840300/0x126800, board id: 2863, fw id: 1473085 input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input6 dmidecode excerpt for this laptop is: Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Medion Product Name: Akoya E7225 Version: 1.0 Signed-off-by:
Jochen Hein <jochen@jochen.org> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Peter Hutterer authored
commit 8543cf1c upstream. LEN0037 found in the Lenovo ThinkPad X1 Carbon 2nd (2014 model) Reported-and-tested-by:
Bjoern Olausson <bjoern@olausson.de> Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
-
Paul Osmialowski authored
commit 34e81ad5 upstream. This patch solves deadlock between clock prepare mutex and regmap mutex reported by Tomasz Figa in [1] by implementing solution from [2]: "always leave the clock of the i2c controller in a prepared state". [1] https://lkml.org/lkml/2014/7/2/171 [2] https://lkml.org/lkml/2014/7/2/207 On each i2c transfer handled by s3c24xx_i2c_xfer(), clk_prepare_enable() was called, which calls clk_prepare() then clk_enable(). clk_prepare() takes prepare_lock mutex before proceeding. Note that i2c transfer functions are invoked from many places in kernel, typically with some other additional lock held. It may happen that function on CPU1 (e.g. regmap_update_bits()) has taken a mutex (i.e. regmap lock mutex) then it attempts i2c communication in order to proceed (so it needs to obtain clock related prepare_lock mutex during transfer preparation stage due to clk_prepare() call). At the same time other task on CPU0 wants to operate on clock (e.g. to (un)prepare clock for some other reason) so it has taken prepare_lock mutex. CPU0: CPU1: clk_disable_unused() regulator_disable() clk_prepare_lock() map->lock(map->lock_arg) regmap_read() s3c24xx_i2c_xfer() map->lock(map->lock_arg) clk_prepare_lock() Implemented solution from [2] leaves i2c clock prepared. Preparation is done in s3c24xx_i2c_probe() function. Without this patch, it is immediately unprepared by clk_disable_unprepare() call. I've replaced this call with clk_disable() and I've added clk_unprepare() call in s3c24xx_i2c_remove(). The s3c24xx_i2c_xfer() function now uses clk_enable() instead of clk_prepare_enable() (and clk_disable() instead of clk_unprepare_disable()). Signed-off-by:
Paul Osmialowski <p.osmialowsk@samsung.com> Reviewed-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Ilya Dryomov authored
commit e69b8d41 upstream. This effectively reverts the last hunk of 392a9dad ("rbd: detect when clone image is flattened"). The problem with parent_overlap != 0 condition is that it's possible and completely valid to have an image with parent_overlap == 0 whose parent state needs to be cleaned up on unmap. The next commit, which drops the "clone image now standalone" logic, opens up another window of opportunity to hit this, but even without it # cat parent-ref.sh #!/bin/bash rbd create --image-format 2 --size 1 foo rbd snap create foo@snap rbd snap protect foo@snap rbd clone foo@snap bar rbd resize --allow-shrink --size 0 bar rbd resize --size 1 bar DEV=$(rbd map bar) rbd unmap $DEV leaves rbd_device/rbd_spec/etc and rbd_client along with ceph_client hanging around. My thinking behind calling rbd_dev_parent_put() unconditionally is that there shouldn't be any requests in flight at that point in time as we are deep into unmap sequence. Hence, even if rbd_dev_unparent() caused by flatten is delayed by in-flight requests, it will have finished by the time we reach rbd_dev_unprobe() caused by unmap, thus turning unconditional rbd_dev_parent_put() into a no-op. Fixes: http://tracker.ceph.com/issues/10352Signed-off-by:
Ilya Dryomov <idryomov@redhat.com> Reviewed-by:
Josh Durgin <jdurgin@redhat.com> Reviewed-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Clemens Ladisch authored
commit 0767e95b upstream. When the last subscriber to a "Through" port has been removed, the subscribed destination ports might still be active, so it would be wrong to send "all sounds off" and "reset controller" events to them. The proper place for such a shutdown would be the closing of the actual MIDI port (and close_substream() in rawmidi.c already can do this). This also fixes a deadlock when dummy_unuse() tries to send events to its own port that is already locked because it is being freed. Reported-by:
Peter Billam <peter@www.pjb.com.au> Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Laurent Dufour authored
commit e6eb2eba upstream. The commit 3b8a3c01 ("powerpc/pseries: Fix endiannes issue in RTAS call from xmon") was fixing an endianness issue in the call made from xmon to RTAS. However, as Michael Ellerman noticed, this fix was not complete, the token value was not byte swapped. This lead to call an unexpected and most of the time unexisting RTAS function, which is silently ignored by RTAS. This fix addresses this hole. Reported-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by:
-
Ahmed S. Darwish authored
commit e638642b upstream. While being in an ERROR_WARNING state, and receiving further bus error events with error counters still in the ERROR_WARNING range of 97-127 inclusive, the state handling code erroneously reverts back to ERROR_ACTIVE. Per the CAN standard, only revert to ERROR_ACTIVE when the error counters are less than 96. Moreover, in certain Kvaser models, the BUS_ERROR flag is always set along with undefined bits in the M16C status register. Thus use bitwise operators instead of full equality for checking that register against bus errors. Signed-off-by:
Ahmed S. Darwish <ahmed.darwish@valeo.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Ahmed S. Darwish authored
commit 14c10c2a upstream. On some x86 laptops, plugging a Kvaser device again after an unplug makes the firmware always ignore the very first command. For such a case, provide some room for retries instead of completely exiting the driver init code. Signed-off-by:
-
Ahmed S. Darwish authored
commit 3803fa69 upstream. Send expected argument to the URB completion hander: a CAN netdevice instead of the network interface private context `kvaser_usb_net_priv'. This was discovered by having some garbage in the kernel log in place of the netdevice names: can0 and can1. Signed-off-by:
-
Ahmed S. Darwish authored
commit ded50066 upstream. Upon receiving a hardware event with the BUS_RESET flag set, the driver kills all of its anchored URBs and resets all of its transmit URB contexts. Unfortunately it does so under the context of URB completion handler `kvaser_usb_read_bulk_callback()', which is often called in an atomic context. While the device is flooded with many received error packets, usb_kill_urb() typically sleeps/reschedules till the transfer request of each killed URB in question completes, leading to the sleep in atomic bug. [3] In v2 submission of the original driver patch [1], it was stated that the URBs kill and tx contexts reset was needed since we don't receive any tx acknowledgments later and thus such resources will be locked down forever. Fortunately this is no longer needed since an earlier bugfix in this patch series is now applied: all tx URB contexts are reset upon CAN channel close. [2] Moreover, a BUS_RESET is now treated _exactly_ like a BUS_OFF event, which is the recommended handling method advised by the device manufacturer. [1] http://article.gmane.org/gmane.linux.network/239442 http://www.webcitation.org/6Vr2yagAQ [2] can: kvaser_usb: Reset all URB tx contexts upon channel close 889b77f7 [3] Stacktrace: <IRQ> [<ffffffff8158de87>] dump_stack+0x45/0x57 [<ffffffff8158b60c>] __schedule_bug+0x41/0x4f [<ffffffff815904b1>] __schedule+0x5f1/0x700 [<ffffffff8159360a>] ? _raw_spin_unlock_irqrestore+0xa/0x10 [<ffffffff81590684>] schedule+0x24/0x70 [<ffffffff8147d0a5>] usb_kill_urb+0x65/0xa0 [<ffffffff81077970>] ? prepare_to_wait_event+0x110/0x110 [<ffffffff8147d7d8>] usb_kill_anchored_urbs+0x48/0x80 [<ffffffffa01f4028>] kvaser_usb_unlink_tx_urbs+0x18/0x50 [kvaser_usb] [<ffffffffa01f45d0>] kvaser_usb_rx_error+0xc0/0x400 [kvaser_usb] [<ffffffff8108b14a>] ? vprintk_default+0x1a/0x20 [<ffffffffa01f5241>] kvaser_usb_read_bulk_callback+0x4c1/0x5f0 [kvaser_usb] [<ffffffff8147a73e>] __usb_hcd_giveback_urb+0x5e/0xc0 [<ffffffff8147a8a1>] usb_hcd_giveback_urb+0x41/0x110 [<ffffffffa0008748>] finish_urb+0x98/0x180 [ohci_hcd] [<ffffffff810cd1a7>] ? acct_account_cputime+0x17/0x20 [<ffffffff81069f65>] ? local_clock+0x15/0x30 [<ffffffffa000a36b>] ohci_work+0x1fb/0x5a0 [ohci_hcd] [<ffffffff814fbb31>] ? process_backlog+0xb1/0x130 [<ffffffffa000cd5b>] ohci_irq+0xeb/0x270 [ohci_hcd] [<ffffffff81479fc1>] usb_hcd_irq+0x21/0x30 [<ffffffff8108bfd3>] handle_irq_event_percpu+0x43/0x120 [<ffffffff8108c0ed>] handle_irq_event+0x3d/0x60 [<ffffffff8108ec84>] handle_fasteoi_irq+0x74/0x110 [<ffffffff81004dfd>] handle_irq+0x1d/0x30 [<ffffffff81004727>] do_IRQ+0x57/0x100 [<ffffffff8159482a>] common_interrupt+0x6a/0x6a Signed-off-by:
-
Peter Ujfalusi authored
commit 20602e34 upstream. We should select FSR also to be driven by McBSP, not only FSX. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by:
Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by:
-
Zidan Wang authored
commit 22ee76da upstream. wm8960 codec can't support sample rate 11250, it must be 11025. Signed-off-by:
Zidan Wang <b50113@freescale.com> Acked-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
-
Andy Shevchenko authored
commit 67bf9cda upstream. The FIFO size is 40 accordingly to the specifications, but this means 0x40, i.e. 64 bytes. This patch fixes the typo and enables FIFO size autodetection for Intel MID devices. Fixes: 7063c0d9 (spi/dw_spi: add DMA support) Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Adrian Hunter authored
commit 1f7f2652 upstream. Add PCI IDs for SPT eMMC, SDIO and SD card. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Adrian Hunter authored
commit a06586b6 upstream. Braswell eMMC host controller specifies an incorrect timeout clock frequncy in the capabilities registers. The correct value is 1 MHz. Signed-off-by:
-
Alan Cox authored
commit 066173b6 upstream. The hardware is the same as used in Baytrail. Add these new PCI IDs to the driver's list of supported IDs. Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Adam Lee authored
commit 522624f9 upstream. Break out definitions in sdhci-pci.c to sdhci-pci.h, for introducing module files like sdhci-pci-xxx.c Signed-off-by:
Adam Lee <adam.lee@canonical.com> Signed-off-by:
Chris Ball <chris@printf.net> Signed-off-by:
-
Micky Ching authored
commit 9107ebbf upstream. Add support for realtek rts5250 pci card reader. The card reader has some problems with DDR50 mode, so add a new quirks2 for broken ddr50. Signed-off-by:
Micky Ching <micky_ching@realsil.com.cn> Signed-off-by:
-
David Cohen authored
commit 13868bf2 upstream. This patch defines a quirk for platforms unable to enable HS200 support. Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Reviewed-by:
Chuanxiao Dong <chuanxiao.dong@intel.com> Acked-by:
Dong Aisheng <b29396@freescale.com> Cc: stable <stable@vger.kernel.org> # [3.13] Signed-off-by:
-
David Cohen authored
commit 390145f9 upstream. Due to unknown hw issue so far, Merrifield is unable to enable HS200 support. This patch adds quirk to avoid SDHCI to initialize with error below: [ 53.850132] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.12.0-rc6-00037-g3d7c8d9-dirty #36 [ 53.850150] Hardware name: Intel Corporation Merrifield/SALT BAY, BIOS 397 2013.09.12:11.51.40 [ 53.850167] 00000000 00000000 ee409e48 c18816d2 00000000 ee409e78 c123e254 c1acc9b0 [ 53.850227] 00000000 00000000 c1b14148 000003de c16c03bf c16c03bf ee75b480 ed97c54c [ 53.850282] ee75b480 ee409e88 c123e292 00000009 00000000 ee409ef8 c16c03bf c1207fac [ 53.850339] Call Trace: [ 53.850376] [<c18816d2>] dump_stack+0x4b/0x79 [ 53.850408] [<c123e254>] warn_slowpath_common+0x84/0xa0 [ 53.850436] [<c16c03bf>] ? sdhci_send_command+0xb4f/0xc50 [ 53.850462] [<c16c03bf>] ? sdhci_send_command+0xb4f/0xc50 [ 53.850490] [<c123e292>] warn_slowpath_null+0x22/0x30 [ 53.850516] [<c16c03bf>] sdhci_send_command+0xb4f/0xc50 [ 53.850545] [<c1207fac>] ? native_sched_clock+0x2c/0xb0 [ 53.850575] [<c14c1f93>] ? delay_tsc+0x73/0xb0 [ 53.850601] [<c14c1ebe>] ? __const_udelay+0x1e/0x20 [ 53.850626] [<c16bdeb3>] ? sdhci_reset+0x93/0x190 [ 53.850654] [<c16c05b0>] sdhci_finish_data+0xf0/0x2e0 [ 53.850683] [<c16c130f>] sdhci_irq+0x31f/0x930 [ 53.850713] [<c12cb080>] ? __buffer_unlock_commit+0x10/0x20 [ 53.850740] [<c12cbcd7>] ? trace_buffer_unlock_commit+0x37/0x50 [ 53.850773] [<c1288f3c>] handle_irq_event_percpu+0x5c/0x220 [ 53.850800] [<c128bc96>] ? handle_fasteoi_irq+0x16/0xd0 [ 53.850827] [<c128913a>] handle_irq_event+0x3a/0x60 [ 53.850852] [<c128bc80>] ? unmask_irq+0x30/0x30 [ 53.850878] [<c128bcce>] handle_fasteoi_irq+0x4e/0xd0 [ 53.850895] <IRQ> [<c1890b52>] ? do_IRQ+0x42/0xb0 [ 53.850943] [<c1890a31>] ? common_interrupt+0x31/0x38 [ 53.850973] [<c12b00d8>] ? cgroup_mkdir+0x4e8/0x580 [ 53.851001] [<c1208d32>] ? default_idle+0x22/0xf0 [ 53.851029] [<c1209576>] ? arch_cpu_idle+0x26/0x30 [ 53.851054] [<c1288505>] ? cpu_startup_entry+0x65/0x240 [ 53.851082] [<c18793d5>] ? rest_init+0xb5/0xc0 [ 53.851108] [<c1879320>] ? __read_lock_failed+0x18/0x18 [ 53.851138] [<c1bf6a15>] ? start_kernel+0x31b/0x321 [ 53.851164] [<c1bf652f>] ? repair_env_string+0x51/0x51 [ 53.851190] [<c1bf6363>] ? i386_start_kernel+0x139/0x13c [ 53.851209] ---[ end trace 92777f5fe48d33f2 ]--- [ 53.853449] mmcblk0: error -84 transferring data, sector 11142162, nr 304, cmd response 0x0, card status 0x0 [ 53.853476] mmcblk0: retrying using single block read [ 55.937863] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock [ 56.207951] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock [ 66.228785] mmc0: Timeout waiting for hardware interrupt. [ 66.230855] ------------[ cut here ]------------ Signed-off-by:
-
Adrian Hunter authored
commit d0ed8e6b upstream. Add ACPI HID INT344D for an Intel SDIO host controller. Signed-off-by:
-
Adrian Hunter authored
commit 7147eaf3 upstream. Add a HID (INT33BB) and UID (3) for a SD Card host controller. Signed-off-by:
-
Maurice Petallo authored
commit d61b5946 upstream. "SDHCI_QUIRK2_PRESET_VALUE_BROKEN" quirk is added to prohibit preset value enabling for Baytrail eMMC controller. Signed-off-by:
Maurice Petallo <mauricex.r.petallo@intel.com> Acked-by:
-
Adrian Hunter authored
commit c6748017 upstream. Intel SDIO has broken card detect so add a quirk to reflect that. Signed-off-by:
-
Adrian Hunter authored
commit aad95dc4 upstream. Add ACPI HID 80860F16 as a host controller for a SD card. Signed-off-by:
-
Mika Westerberg authored
commit 07c001c1 upstream. Newer Intel PCHs with LPSS have the same SDHCI controller than Haswell but ACPI ID is different. Add this ID to the driver list. Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Mark Rutland authored
commit 44b82b77 upstream. [backport to 3.12.x: fold in missing MIDR_EL1 recording] Commit d7a49086 (arm64: cpuinfo: print info for all CPUs) attempted to clean up /proc/cpuinfo, but due to concerns regarding further changes was reverted in commit 5e39977e (Revert "arm64: cpuinfo: print info for all CPUs"). There are two major issues with the arm64 /proc/cpuinfo format currently: * The "Features" line describes (only) the 64-bit hwcaps, which is problematic for some 32-bit applications which attempt to parse it. As the same names are used for analogous ISA features (e.g. aes) despite these generally being architecturally unrelated, it is not possible to simply append the 64-bit and 32-bit hwcaps in a manner that might not be misleading to some applications. Various potential solutions have appeared in vendor kernels. Typically the format of the Features line varies depending on whether the task is 32-bit. * Information is only printed regarding a single CPU. This does not match the ARM format, and does not provide sufficient information in big.LITTLE systems where CPUs are heterogeneous. The CPU information printed is queried from the current CPU's registers, which is racy w.r.t. cross-cpu migration. This patch attempts to solve these issues. The following changes are made: * When a task with a LINUX32 personality attempts to read /proc/cpuinfo, the "Features" line contains the decoded 32-bit hwcaps, as with the arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In the absense of compat support, the Features line is empty. The set of hwcaps injected into a task's auxval are unaffected. * Properties are printed per-cpu, as with the ARM port. The per-cpu information is queried from pre-recorded cpu information (as used by the sanity checks). * As with the previous attempt at fixing up /proc/cpuinfo, the hardware field is removed. The only users so far are 32-bit applications tied to particular boards, so no portable applications should be affected, and this should prevent future tying to particular boards. The following differences remain: * No model_name is printed, as this cannot be queried from the hardware and cannot be provided in a stable fashion. Use of the CPU {implementor,variant,part,revision} fields is sufficient to identify a CPU and is portable across arm and arm64. * The following system-wide properties are not provided, as they are not possible to provide generally. Programs relying on these are already tied to particular (32-bit only) boards: - Hardware - Revision - Serial No software has yet been identified for which these remaining differences are problematic. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: stable@vger.kernel.org # 3.12.x Signed-off-by:
Mark Rutland <mark.rutland@arm.com> [Mark: backport to v3.12.x] Signed-off-by:
-
- 02 Feb, 2015 3 commits
-
-
Nicholas Bellinger authored
commit 046ba642 upstream. This patch drops the arbitrary maximum I/O size limit in sbc_parse_cdb(), which currently for fabric_max_sectors is hardcoded to 8192 (4 MB for 512 byte sector devices), and for hw_max_sectors is a backend driver dependent value. This limit is problematic because Linux initiators have only recently started to honor block limits MAXIMUM TRANSFER LENGTH, and other non-Linux based initiators (eg: MSFT Fibre Channel) can also generate I/Os larger than 4 MB in size. Currently when this happens, the following message will appear on the target resulting in I/Os being returned with non recoverable status: SCSI OP 28h with too big sectors 16384 exceeds fabric_max_sectors: 8192 Instead, drop both [fabric,hw]_max_sector checks in sbc_parse_cdb(), and convert the existing hw_max_sectors into a purely informational attribute used to represent the granuality that backend driver and/or subsystem code is splitting I/Os upon. Also, update FILEIO with an explicit FD_MAX_BYTES check in fd_execute_rw() to deal with the one special iovec limitiation case. v2 changes: - Drop hw_max_sectors check in sbc_parse_cdb() Reported-by:
Lance Gropper <lance.gropper@qosserver.com> Reported-by:
Stefan Priebe <s.priebe@profihost.ag> Cc: Christoph Hellwig <hch@lst.de> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Roland Dreier <roland@purestorage.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Hannes Reinecke authored
commit 506787a2 upstream. tcm_loop has the I_T nexus associated with the HBA. This causes commands to become misdirected if the HBA has more than one target portal group; any command is then being sent to the first target portal group instead of the correct one. The nexus needs to be associated with the target portal group instead. Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Heiko Carstens authored
commit 291fdb0b upstream. Change the type of compat_sys_msgrcv's msgtyp parameter from long to compat_long_t, since compat user space passes only a 32 bit signed value. Let the compat wrapper do proper sign extension to 64 bit of this parameter. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
