summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-09-01cxgb4: Detect and display firmware reported errorsHariprasad Shenai
The adapter firmware can indicate error conditions to the host. If the firmware has indicated an error, print out the reason for the firmware error. Based on original work by Casey Leedom <leedom@chelsio.com> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-01cxgb4: Fix T5 adapter accessing T4 adapter registersHariprasad Shenai
Fixes few register access for both T4 and T5. PCIE_CORE_UTL_SYSTEM_BUS_AGENT_STATUS & PCIE_CORE_UTL_PCI_EXPRESS_PORT_STATUS is T4 only register don't let T5 access them. For T5 MA_PARITY_ERROR_STATUS2 is additionally read. MPS_TRC_RSS_CONTROL is T4 only register, for T5 use MPS_T5_TRC_RSS_CONTROL. Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-01cxgb4: Fixed the code to use correct length for part numberHariprasad Shenai
Previously it was using the length value of serial number. Also added macro for VPD unique identifier (0x82). Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-01cxgb4: Fix for handling 1Gb/s SFP+ Transceiver ModulesHariprasad Shenai
We previously assumed that a Port's Capabilities and Advertised Capabilities would never change from Port Initialization time. This is no longer true when we can have 10Gb/s and 1Gb/s SFP+ Transceiver Modules randomly swapped. Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-02ALSA: hda - Fix COEF setups for ALC1150 codecTakashi Iwai
ALC1150 codec seems to need the COEF- and PLL-setups just like its compatible ALC882 codec. Some machines (e.g. SunMicro X10SAT) show the problem like too low output volumes unless the COEF setup is applied. Reported-and-tested-by: Dana Goyette <danagoyette@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-09-01stmmac: only remove RXCSUM feature if no rx coe is availableGiuseppe CAVALLARO
In case of the HW is not able to do the receive checksum offloading the only feature to remove is NETIF_F_RXCSUM. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-01stmmac: fix the rx csum featureGiuseppe CAVALLARO
For new GMACs it is possible to turn-on/off the COE. In the current driver, when disabled the Rx-checksum via ethtool, the tool reported that csum was disabled but the HW continued to set the IPC. Indeed this is because the fix_features allows this. So the patch fixes this problem by adding the set_features. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-01Merge branch 'amd-xgbe-net'David S. Miller
Tom Lendacky says: ==================== amd-xgbe: AMD XGBE driver fixes 2014-08-29 The following series of patches includes fixes to the driver. - Tx hardware queue flushing support dependent on hardware version - Incorrect reported fifo size - Proper mmd select in XPCS debugfs support - Proper queue count for configuring Tx flow control This patch series is based on net. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-01amd-xgbe: Use the Tx queue count for Tx flow control supportLendacky, Thomas
When configuring Tx flow control the Rx queue count was used instead of the Tx queue count for looping through the Tx hardware queues. Fix the code to use the Tx queue count. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-01amd-xgbe: Fix the xpcs mmd debugfs supportLendacky, Thomas
The debugfs support for the xpcs registers did not properly use the specified mmd (xpcs_mmd entry) which resulted in the default mmd value always being used. Update the debugfs support to generate the proper mmd register value. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-01amd-xgbe: Reported fifo size from hardware is not correctLendacky, Thomas
The fifo size reported by the hardware is not correct. Add support to limit the reported size to what is actually present. Also, fix the argument types used in the fifo size calculation function. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-01amd-xgbe: Check for Tx hardware queue flushing supportLendacky, Thomas
The flushing of the Tx hardware queues is only supported at a certain level of the hardware. Retrieve the current version of the hardware and use that to determine if flushing is supported. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-01drivers: net: NET_XGENE should depend on HAS_DMAGeert Uytterhoeven
If NO_DMA=y: drivers/built-in.o: In function `xgene_enet_delete_ring': xgene_enet_main.c:(.text+0x28755a): undefined reference to `dma_free_coherent' drivers/built-in.o: In function `xgene_enet_setup_tx_desc': xgene_enet_main.c:(.text+0x287774): undefined reference to `dma_map_single' xgene_enet_main.c:(.text+0x287780): undefined reference to `dma_mapping_error' drivers/built-in.o: In function `xgene_enet_tx_completion': xgene_enet_main.c:(.text+0x2878e6): undefined reference to `dma_unmap_single' drivers/built-in.o: In function `xgene_enet_refill_bufpool': xgene_enet_main.c:(.text+0x2879d4): undefined reference to `dma_map_single' xgene_enet_main.c:(.text+0x2879e0): undefined reference to `dma_mapping_error' drivers/built-in.o: In function `xgene_enet_rx_frame': xgene_enet_main.c:(.text+0x287aaa): undefined reference to `dma_unmap_single' drivers/built-in.o: In function `xgene_enet_free_desc_ring': xgene_enet_main.c:(.text+0x287f98): undefined reference to `dma_free_coherent' drivers/built-in.o: In function `xgene_enet_create_desc_ring': xgene_enet_main.c:(.text+0x28808e): undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `xgene_enet_probe': xgene_enet_main.c:(.text+0x2883d4): undefined reference to `dma_set_mask' xgene_enet_main.c:(.text+0x2883ec): undefined reference to `dma_supported' Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-02xfs: trim eofblocks before collapse rangeBrian Foster
xfs_collapse_file_space() currently writes back the entire file undergoing collapse range to settle things down for the extent shift algorithm. While this prevents changes to the extent list during the collapse operation, the writeback itself is not enough to prevent unnecessary collapse failures. The current shift algorithm uses the extent index to iterate the in-core extent list. If a post-eof delalloc extent persists after the writeback (e.g., a prior zero range op where the end of the range aligns with eof can separate the post-eof blocks such that they are not written back and converted), xfs_bmap_shift_extents() becomes confused over the encoded br_startblock value and fails the collapse. As with the full writeback, this is a temporary fix until the algorithm is improved to cope with a volatile extent list and avoid attempts to shift post-eof extents. Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-09-02xfs: xfs_file_collapse_range is delalloc challengedDave Chinner
If we have delalloc extents on a file before we run a collapse range opertaion, we sync the range that we are going to collapse to convert delalloc extents in that region to real extents to simplify the shift operation. However, the shift operation then assumes that the extent list is not going to change as it iterates over the extent list moving things about. Unfortunately, this isn't true because we can't hold the ILOCK over all the operations. We can prevent new IO from modifying the extent list by holding the IOLOCK, but that doesn't prevent writeback from running.... And when writeback runs, it can convert delalloc extents is the range of the file prior to the region being collapsed, and this changes the indexes of all the extents in the file. That causes the collapse range operation to Go Bad. The right fix is to rewrite the extent shift operation not to be dependent on the extent list not changing across the entire operation, but this is a fairly significant piece of work to do. Hence, as a short-term workaround for the problem, sync the entire file before starting a collapse operation to remove all delalloc ranges from the file and so avoid the problem of concurrent writeback changing the extent list. Diagnosed-and-Reported-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-09-02xfs: don't log inode unless extent shift makes extent modificationsBrian Foster
The file collapse mechanism uses xfs_bmap_shift_extents() to collapse all subsequent extents down into the specified, previously punched out, region. This function performs some validation, such as whether a sufficient hole exists in the target region of the collapse, then shifts the remaining exents downward. The exit path of the function currently logs the inode unconditionally. While we must log the inode (and abort) if an error occurs and the transaction is dirty, the initial validation paths can generate errors before the transaction has been dirtied. This creates an unnecessary filesystem shutdown scenario, as the caller will cancel a transaction that has been marked dirty. Modify xfs_bmap_shift_extents() to OR the logflags bits as modifications are made to the inode bmap. Only log the inode in the exit path if logflags has been set. This ensures we only have to cancel a dirty transaction if modifications have been made and prevents an unnecessary filesystem shutdown otherwise. Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-09-02xfs: use ranged writeback and invalidation for direct IODave Chinner
Now we are not doing silly things with dirtying buffers beyond EOF and using invalidation correctly, we can finally reduce the ranges of writeback and invalidation used by direct IO to match that of the IO being issued. Bring the writeback and invalidation ranges back to match the generic direct IO code - this will greatly reduce the perturbation of cached data when direct IO and buffered IO are mixed, but still provide the same buffered vs direct IO coherency behaviour we currently have. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-09-02xfs: don't zero partial page cache pages during O_DIRECT writesDave Chinner
Similar to direct IO reads, direct IO writes are using truncate_pagecache_range to invalidate the page cache. This is incorrect due to the sub-block zeroing in the page cache that truncate_pagecache_range() triggers. This patch fixes things by using invalidate_inode_pages2_range instead. It preserves the page cache invalidation, but won't zero any pages. cc: stable@vger.kernel.org Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-09-02xfs: don't zero partial page cache pages during O_DIRECT writesChris Mason
xfs is using truncate_pagecache_range to invalidate the page cache during DIO reads. This is different from the other filesystems who only invalidate pages during DIO writes. truncate_pagecache_range is meant to be used when we are freeing the underlying data structs from disk, so it will zero any partial ranges in the page. This means a DIO read can zero out part of the page cache page, and it is possible the page will stay in cache. buffered reads will find an up to date page with zeros instead of the data actually on disk. This patch fixes things by using invalidate_inode_pages2_range instead. It preserves the page cache invalidation, but won't zero any pages. [dchinner: catch error and warn if it fails. Comment.] cc: stable@vger.kernel.org Signed-off-by: Chris Mason <clm@fb.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-09-02xfs: don't dirty buffers beyond EOFDave Chinner
generic/263 is failing fsx at this point with a page spanning EOF that cannot be invalidated. The operations are: 1190 mapwrite 0x52c00 thru 0x5e569 (0xb96a bytes) 1191 mapread 0x5c000 thru 0x5d636 (0x1637 bytes) 1192 write 0x5b600 thru 0x771ff (0x1bc00 bytes) where 1190 extents EOF from 0x54000 to 0x5e569. When the direct IO write attempts to invalidate the cached page over this range, it fails with -EBUSY and so any attempt to do page invalidation fails. The real question is this: Why can't that page be invalidated after it has been written to disk and cleaned? Well, there's data on the first two buffers in the page (1k block size, 4k page), but the third buffer on the page (i.e. beyond EOF) is failing drop_buffers because it's bh->b_state == 0x3, which is BH_Uptodate | BH_Dirty. IOWs, there's dirty buffers beyond EOF. Say what? OK, set_buffer_dirty() is called on all buffers from __set_page_buffers_dirty(), regardless of whether the buffer is beyond EOF or not, which means that when we get to ->writepage, we have buffers marked dirty beyond EOF that we need to clean. So, we need to implement our own .set_page_dirty method that doesn't dirty buffers beyond EOF. This is messy because the buffer code is not meant to be shared and it has interesting locking issues on the buffer dirty bits. So just copy and paste it and then modify it to suit what we need. Note: the solutions the other filesystems and generic block code use of marking the buffers clean in ->writepage does not work for XFS. It still leaves dirty buffers beyond EOF and invalidations still fail. Hence rather than play whack-a-mole, this patch simply prevents those buffers from being dirtied in the first place. cc: <stable@kernel.org> Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-09-01Merge tag 'master-2014-08-25' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless John W. Linville says: ==================== pull request: wireless 2014-08-28 Please pull this batch of fixes intended for the 3.17 stream. For the Bluetooth/6LowPAN/802.15.4 bits, Johan says: 'It contains a connection reference counting fix for LE where a connection might stay up even though it should get disconnected. The other 802.15.4 6LoWPAN related patches were sent to the bluetooth tree by Alexander Aring and described as follows by him: " these patches contains patches for the bluetooth branch. This series includes memory leak fixes and an errno value fix. Also there are two patches for sending and receiving 1280 6LoWPAN packets, which makes the IEEE 802.15.4 6LoWPAN stack more RFC compliant. "' Along with that... Alexey Khoroshilov fixes a use-after-free bug on at76c50x-usb. Hauke Mehrtens adds a PCI ID to bcma. Himangi Saraogi fixes a silly "A || A" test in rtlwifi. Larry Finger adds a device ID to rtl8192cu. Maks Naumov fixes a strncmp argument in ath9k. Álvaro Fernández Rojas adds a PCI ID to ssb. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-02ACPI / EC: Add msi quirk for Clevo W350etqLan Tianyu
Clevo W350etq's EC will not produce GPE interrupt some time after booting. The ACPI notify event won't trigger when the issue takes place. After debugging, adding msi quirk for the machine can fix the issue. This patch is to add msi quirk for the machine. Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431 Reported-and-tested-by: qbanin@gmail.com Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02ACPI / video: Disable native_backlight on HP ENVY 15 Notebook PCHans de Goede
Link: https://bugs.freedesktop.org/show_bug.cgi?id=81515 Reported-and-tested-by: Hohahiu <rakothedin@gmail.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02ACPI / video: Add a disable_native_backlight quirkHans de Goede
Some laptops have a working acpi_video backlight control, and using native backlight on these causes a regression where backlight control does not work when userspace is not handling brightness key events. Disable native_backlight on these to fix this. Link: https://bugzilla.kernel.org/show_bug.cgi?id=81691 Reported-and-tested-by: Andre Müller <andre.muller@web.de> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02ACPI / video: Fix use_native_backlight selection logicHans de Goede
Commit 751109aad583 ("ACPI / video: Change the default for video.use_native_backlight to 1") has changed the default for use_native_backlight from 0 to 1, but instead of changing use_native_backlight_dmi to true, and leaving use_native_backlight_param at -1, it has changed use_native_backlight_param to 1. This causes acpi_video_use_native_backlight() to always think that a value was specified through the param, making it impossible to add a dmi based quirk to force 0 now that the default is 1. This fixes this by restoring the use_native_backlight_param default to -1, and instead setting the use_native_backlight_dmi default to true. Fixes: 751109aad583 (ACPI / video: Change the default for video.use_native_backlight to 1) Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-02ACPICA: ACPI 5.1: Add support for runtime validation of _DSD package.Mika Westerberg
Adds ACPICA kernel runtime support to validate contents/format of the _DSD package, similar to the iASL support. Ported by Mika Westerberg. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-01Merge branch 'irq-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq handling fixlet from Thomas Gleixner: "Just an export for an interrupt flow handler which is now used in gpio modules" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irq: Export handle_fasteoi_irq
2014-09-01spi: dw: Don't use devm_kzalloc in master->setup callbackAxel Lin
device_add() expects that any memory allocated via devm_* API is only done in the device's probe function. Fix below boot warning: WARNING: CPU: 1 PID: 1 at drivers/base/dd.c:286 driver_probe_device+0x2b4/0x2f4() Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.16.0-10474-g835c90b-dirty #160 [<c0016364>] (unwind_backtrace) from [<c001251c>] (show_stack+0x20/0x24) [<c001251c>] (show_stack) from [<c04eaefc>] (dump_stack+0x7c/0x98) [<c04eaefc>] (dump_stack) from [<c0023d4c>] (warn_slowpath_common+0x78/0x9c) [<c0023d4c>] (warn_slowpath_common) from [<c0023d9c>] (warn_slowpath_null+0x2c/0x34) [<c0023d9c>] (warn_slowpath_null) from [<c0302c60>] (driver_probe_device+0x2b4/0x2f4) [<c0302c60>] (driver_probe_device) from [<c0302d90>] (__device_attach+0x50/0x54) [<c0302d90>] (__device_attach) from [<c0300e60>] (bus_for_each_drv+0x54/0x9c) [<c0300e60>] (bus_for_each_drv) from [<c0302958>] (device_attach+0x84/0x90) [<c0302958>] (device_attach) from [<c0301f10>] (bus_probe_device+0x94/0xb8) [<c0301f10>] (bus_probe_device) from [<c03000c0>] (device_add+0x434/0x4fc) [<c03000c0>] (device_add) from [<c0342dd4>] (spi_add_device+0x98/0x164) [<c0342dd4>] (spi_add_device) from [<c03444a4>] (spi_register_master+0x598/0x768) [<c03444a4>] (spi_register_master) from [<c03446b4>] (devm_spi_register_master+0x40/0x80) [<c03446b4>] (devm_spi_register_master) from [<c0346214>] (dw_spi_add_host+0x1a8/0x258) [<c0346214>] (dw_spi_add_host) from [<c0346920>] (dw_spi_mmio_probe+0x1d4/0x294) [<c0346920>] (dw_spi_mmio_probe) from [<c0304560>] (platform_drv_probe+0x3c/0x6c) [<c0304560>] (platform_drv_probe) from [<c0302a98>] (driver_probe_device+0xec/0x2f4) [<c0302a98>] (driver_probe_device) from [<c0302d3c>] (__driver_attach+0x9c/0xa0) [<c0302d3c>] (__driver_attach) from [<c0300f0c>] (bus_for_each_dev+0x64/0x98) [<c0300f0c>] (bus_for_each_dev) from [<c0302518>] (driver_attach+0x2c/0x30) [<c0302518>] (driver_attach) from [<c0302134>] (bus_add_driver+0xdc/0x1f4) [<c0302134>] (bus_add_driver) from [<c03035c8>] (driver_register+0x88/0x104) [<c03035c8>] (driver_register) from [<c030445c>] (__platform_driver_register+0x58/0x6c) [<c030445c>] (__platform_driver_register) from [<c0700f00>] (dw_spi_mmio_driver_init+0x18/0x20) [<c0700f00>] (dw_spi_mmio_driver_init) from [<c0008914>] (do_one_initcall+0x90/0x1d4) [<c0008914>] (do_one_initcall) from [<c06d7d90>] (kernel_init_freeable+0x178/0x248) [<c06d7d90>] (kernel_init_freeable) from [<c04e687c>] (kernel_init+0x18/0xfc) [<c04e687c>] (kernel_init) from [<c000ecd8>] (ret_from_fork+0x14/0x20) Reported-by: Thor Thayer <tthayer@opensource.altera.com> Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2014-09-01ASoC: simple-card: Fix bug of wrong decrement DT node's refcountXiubo Li
DAI links's cpu_of_node's and codec_of_node's refcounts shouldn't be decremented immediately at the end of the probe() fucntion. Because we will still use them before the audio card is removed. Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-09-01iommu/arm-smmu: remove pgtable_page_{c,d}tor()Vladimir Murzin
If split page table lock for PTE tables is enabled (CONFIG_SPLIT_PTLOCK_CPUS <=NR_CPUS) pgtable_page_ctor() leads to non-atomic allocation for ptlock with a spinlock held, resulting in: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 466 at kernel/locking/lockdep.c:2742 lockdep_trace_alloc+0xd8/0xf4() DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) Modules linked in: CPU: 0 PID: 466 Comm: dma0chan0-copy0 Not tainted 3.16.0-3d47efb-clean-pl330-dma_test-ve-a15-a32-slr-m c-on-3+ #55 [<80014748>] (unwind_backtrace) from [<80011640>] (show_stack+0x10/0x14) [<80011640>] (show_stack) from [<802bf864>] (dump_stack+0x80/0xb4) [<802bf864>] (dump_stack) from [<8002385c>] (warn_slowpath_common+0x64/0x88) [<8002385c>] (warn_slowpath_common) from [<80023914>] (warn_slowpath_fmt+0x30/0x40) [<80023914>] (warn_slowpath_fmt) from [<8005d818>] (lockdep_trace_alloc+0xd8/0xf4) [<8005d818>] (lockdep_trace_alloc) from [<800d3d78>] (kmem_cache_alloc+0x24/0x144) [<800d3d78>] (kmem_cache_alloc) from [<800bfae4>] (ptlock_alloc+0x18/0x2c) [<800bfae4>] (ptlock_alloc) from [<802b1ec0>] (arm_smmu_handle_mapping+0x4c0/0x690) [<802b1ec0>] (arm_smmu_handle_mapping) from [<802b0cd8>] (iommu_map+0xe0/0x148) [<802b0cd8>] (iommu_map) from [<80019098>] (arm_coherent_iommu_map_page+0x160/0x278) [<80019098>] (arm_coherent_iommu_map_page) from [<801f4d78>] (dmatest_func+0x60c/0x1098) [<801f4d78>] (dmatest_func) from [<8003f8ac>] (kthread+0xcc/0xe8) [<8003f8ac>] (kthread) from [<8000e868>] (ret_from_fork+0x14/0x2c) ---[ end trace ce0d27e6f434acf8 ]-- Split page tables lock is not used in the driver. In fact, page tables are guarded with domain lock, so remove calls to pgtable_page_{c,d}tor(). Cc: <stable@vger.kernel.org> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-09-01iommu/arm-smmu: fix programming of SMMU_CBn_TCR for stage 1Olav Haugan
Stage-1 context banks do not have the SMMU_CBn_TCR[SL0] field since it is only applicable to stage-2 context banks. This patch ensures that we don't set the reserved TCR bits for stage-1 translations. Cc: <stable@vger.kernel.org> Signed-off-by: Olav Haugan <ohaugan@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-09-01iommu/arm-smmu: avoid calling request_irq in atomic contextMitchel Humpherys
request_irq shouldn't be called from atomic context since it might sleep, but we're calling it with a spinlock held, resulting in: [ 9.172202] BUG: sleeping function called from invalid context at kernel/mm/slub.c:926 [ 9.182989] in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper/0 [ 9.189762] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 3.10.40-gbc1b510b-38437-g55831d3bd9-dirty #97 [ 9.199757] [<c020c448>] (unwind_backtrace+0x0/0x11c) from [<c02097d0>] (show_stack+0x10/0x14) [ 9.208346] [<c02097d0>] (show_stack+0x10/0x14) from [<c0301d74>] (kmem_cache_alloc_trace+0x3c/0x210) [ 9.217543] [<c0301d74>] (kmem_cache_alloc_trace+0x3c/0x210) from [<c0276a48>] (request_threaded_irq+0x88/0x11c) [ 9.227702] [<c0276a48>] (request_threaded_irq+0x88/0x11c) from [<c0931ca4>] (arm_smmu_attach_dev+0x188/0x858) [ 9.237686] [<c0931ca4>] (arm_smmu_attach_dev+0x188/0x858) from [<c0212cd8>] (arm_iommu_attach_device+0x18/0xd0) [ 9.247837] [<c0212cd8>] (arm_iommu_attach_device+0x18/0xd0) from [<c093314c>] (arm_smmu_test_probe+0x68/0xd4) [ 9.257823] [<c093314c>] (arm_smmu_test_probe+0x68/0xd4) from [<c05aadd0>] (driver_probe_device+0x12c/0x330) [ 9.267629] [<c05aadd0>] (driver_probe_device+0x12c/0x330) from [<c05ab080>] (__driver_attach+0x68/0x8c) [ 9.277090] [<c05ab080>] (__driver_attach+0x68/0x8c) from [<c05a92d4>] (bus_for_each_dev+0x70/0x84) [ 9.286118] [<c05a92d4>] (bus_for_each_dev+0x70/0x84) from [<c05aa3b0>] (bus_add_driver+0x100/0x244) [ 9.295233] [<c05aa3b0>] (bus_add_driver+0x100/0x244) from [<c05ab5d0>] (driver_register+0x9c/0x124) [ 9.304347] [<c05ab5d0>] (driver_register+0x9c/0x124) from [<c0933088>] (arm_smmu_test_init+0x14/0x38) [ 9.313635] [<c0933088>] (arm_smmu_test_init+0x14/0x38) from [<c0200618>] (do_one_initcall+0xb8/0x160) [ 9.322926] [<c0200618>] (do_one_initcall+0xb8/0x160) from [<c1200b7c>] (kernel_init_freeable+0x108/0x1cc) [ 9.332564] [<c1200b7c>] (kernel_init_freeable+0x108/0x1cc) from [<c0b924b0>] (kernel_init+0xc/0xe4) [ 9.341675] [<c0b924b0>] (kernel_init+0xc/0xe4) from [<c0205e38>] (ret_from_fork+0x14/0x3c) Fix this by moving the request_irq out of the critical section. This should be okay since smmu_domain->smmu is still being protected by the critical section. Also, we still don't program the Stream Match Register until after registering our interrupt handler so we shouldn't be missing any interrupts. Cc: <stable@vger.kernel.org> Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org> [will: code cleanup and fixed request_irq token parameter] Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-09-01Revert "arm64: cpuinfo: print info for all CPUs"Will Deacon
It turns out that vendors are relying on the format of /proc/cpuinfo, and we've even spotted out-of-tree hacks attempting to make it look identical to the format used by arch/arm/. That means we can't afford to churn this interface in mainline, so revert the recent reformatting of the file for arm64 pending discussions on the list to find out what people actually want. This reverts commit d7a49086f263164a2c4c178eb76412d48cd671d7. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-09-01drm/i915: handle G45/GM45 pulse detection connected state.Dave Airlie
In the HPD pulse handler we check for long pulses if the port is actually connected, however we do that for IBX, but we use the pulse handling code on GM45 systems as well, so we need to use a diffent check. This patch refactors the digital port connected check out of the g4x detection path and reuses it in the hpd pulse path. Fixes: http://lkml.kernel.org/r/1409382202.5141.36.camel@marge.simpson.net Reported-by: Mike Galbraith <umgwanakikbuti@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-09-01ata: Disabling the async PM for JMicron chip 363/361Chuansheng Liu
After enabled the PM feature that supporting async noirq(76569faa62 (PM / sleep: Asynchronous threads for resume_noirq)), Jay hit the system resuming issue, that one of the JMicron controller can not be powered up. His device tree is like below: +-1c.4-[02]--+-00.0 JMicron Technology Corp. JMB363 SATA/IDE Controller | \-00.1 JMicron Technology Corp. JMB363 SATA/IDE Controller After investigation, we found the the Micron chip 363 included one SATA controller(0000:02:00.0) and one PATA controller(0000:02:00.1), these two controllers do not have parent-children relationship, but the PATA controller only can be powered on after the SATA controller has finished the powering on. If we enabled the async noirq(), then the below error is hit during noirq phase: pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3 Here for JMicron chip 363/361, we need forcedly to disable the async method. Bug detail: https://bugzilla.kernel.org/show_bug.cgi?id=81551 Reported-by: Jay <MyMailClone@t-online.de> Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2014-09-01ALSA: hda - Fix digital mic on Acer Aspire 3830TGTakashi Iwai
Acer Aspire 3830TG with CX20588 codec has a digital built-in mic that has the same problem like many others, the inverted signal in stereo. Apply the same fixup to this machine, too. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-09-01PM / genirq: Document rules related to system suspend and interruptsRafael J. Wysocki
Add a document describing how IRQs are managed during system suspend and resume, how wakeup interrupts work and what the IRQF_NO_SUSPEND flag is supposed to be used for. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-01arm64: fix bug for reloading FPSIMD state after cpu power offLeo Yan
Now arm64 defers reloading FPSIMD state, but this optimization also introduces the bug after cpu resume back from low power mode. The reason is after the cpu has been powered off, s/w need set the cpu's fpsimd_last_state to NULL so that it will force to reload FPSIMD state for the thread, otherwise there has the chance to meet the condition for both the task's fpsimd_state.cpu field contains the id of the current cpu, and the cpu's fpsimd_last_state per-cpu variable points to the task's fpsimd_state, so finally kernel will skip to reload the context during it return back to userland. Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Leo Yan <leoy@marvell.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-09-01PCI / PM: Make PCIe PME interrupts wake up from suspend-to-idleRafael J. Wysocki
To make PCIe PME interrupts wake up the system from suspend to idle, make the PME driver use enable_irq_wake() on the IRQ during system suspend (if there are any wakeup devices below the given PCIe port) without disabling PME interrupts. This way, an interrupt will still trigger if a wakeup event happens and the system will be woken up (or system suspend in progress will be aborted) by means of the new mechanics introduced previously. This change allows Wake-on-LAN to be used for wakeup from suspend-to-idle on my MSI Wind tesbed netbook. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-01x86 / PM: Set IRQCHIP_SKIP_SET_WAKE for IOAPIC IRQ chip objectsRafael J. Wysocki
Set the IRQCHIP_SKIP_SET_WAKE for IOAPIC IRQ chip objects so that interrupts from them can work as wakeup interrupts for suspend-to-idle. After this change, running enable_irq_wake() on one of the IRQs in question will succeed and IRQD_WAKEUP_STATE will be set for it, so all of the suspend-to-idle wakeup mechanics introduced previously will work for it automatically. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-01genirq: Simplify wakeup mechanismThomas Gleixner
Currently we suspend wakeup interrupts by lazy disabling them and check later whether the interrupt has fired, but that's not sufficient for suspend to idle as there is no way to check that once we transitioned into the CPU idle state. So we change the mechanism in the following way: 1) Leave the wakeup interrupts enabled across suspend 2) Add a check to irq_may_run() which is called at the beginning of each flow handler whether the interrupt is an armed wakeup source. This check is basically free as it just extends the existing check for IRQD_IRQ_INPROGRESS. So no new conditional in the hot path. If the IRQD_WAKEUP_ARMED flag is set, then the interrupt is disabled, marked as pending/suspended and the pm core is notified about the wakeup event. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [ rjw: syscore.c and put irq_pm_check_wakeup() into pm.c ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-01genirq: Mark wakeup sources as armed on suspendThomas Gleixner
This allows us to utilize this information in the irq_may_run() check without adding another conditional to the fast path. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-01genirq: Create helper for flow handler entry checkThomas Gleixner
All flow handlers - except the per cpu ones - check for an interrupt in progress and an eventual concurrent polling on another cpu. Create a helper function for the repeated code pattern. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-01genirq: Distangle edge handler entryThomas Gleixner
If the interrupt is disabled or has no action, then we should not call the poll check. Separate the checks. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-01genirq: Avoid double loop on suspendThomas Gleixner
We can synchronize the suspended interrupts right away. No need for an extra loop. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-01genirq: Move MASK_ON_SUSPEND handling into suspend_device_irqs()Thomas Gleixner
There is no reason why we should delay the masking of interrupts whose interrupt chip requests MASK_ON_SUSPEND to the point where we check the wakeup interrupts. We can do it right at the point where we mark the interrupt as suspended. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-01genirq: Make use of pm misfeature accountingThomas Gleixner
Use the accounting fields which got introduced for snity checking for the various PM options. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-01genirq: Add sanity checks for PM options on shared interrupt linesThomas Gleixner
Account the IRQF_NO_SUSPEND and IRQF_RESUME_EARLY actions on shared interrupt lines and yell loudly if there is a mismatch. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-01genirq: Move suspend/resume logic into irq/pm codeThomas Gleixner
No functional change. Preparatory patch for cleaning up the suspend abort functionality. Update the comments while at it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-01PM / sleep: Mechanism for aborting system suspends unconditionallyRafael J. Wysocki
It sometimes may be necessary to abort a system suspend in progress or wake up the system from suspend-to-idle even if the pm_wakeup_event()/pm_stay_awake() mechanism is not enabled. For this purpose, introduce a new global variable pm_abort_suspend and make pm_wakeup_pending() check its value. Also add routines for manipulating that variable. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>