aboutsummaryrefslogtreecommitdiffstats
path: root/drivers (follow)
AgeCommit message (Collapse)AuthorFilesLines
2014-12-04ahci: disable MSI on SAMSUNG 0xa800 SSDTejun Heo1-0/+1
Just like 0x1600 which got blacklisted by 66a7cbc303f4 ("ahci: disable MSI instead of NCQ on Samsung pci-e SSDs on macbooks"), 0xa800 chokes on NCQ commands if MSI is enabled. Disable MSI. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Dominik Mierzejewski <dominik@greysector.net> Link: https://bugzilla.kernel.org/show_bug.cgi?id=89171 Cc: stable@vger.kernel.org
2014-12-04Merge tag 'at91-cleanup5' of git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91 into next/cleanupArnd Bergmann1-32/+0
Pull "Fifth batch of cleanup/SoC for 3.19" from Nicolas Ferre: - removal of now dead code and AT91-specific driver - removal of !DT initialization in some core AT91 drivers - simplification of Kconfig DT board file selection: now automatic * tag 'at91-cleanup5' of git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91: ARM: at91: remove unused board.h file ARM: at91: remove unneeded header files ARM: at91/clocksource: remove !DT PIT initializations ARM: at91: at91rm9200 ST initialization is now DT only ARM: at91: remove old AT91-specific drivers ARM: at91: cleanup initilisation code by removing dead code ARM: at91/Kconfig: select board files automatically Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-12-04Merge tag 'tegra-for-3.19-iommu' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/driversArnd Bergmann29-1487/+3913
Pull "ARM: tegra: IOMMU support for v3.19" from Thierry Reding: This adds the driver pieces required for IOMMU support on Tegra30, Tegra114 and Tegra124. * tag 'tegra-for-3.19-iommu' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: memory: Add NVIDIA Tegra memory controller support of: Add NVIDIA Tegra memory controller binding ARM: tegra: Move AHB Kconfig to drivers/amba amba: Add Kconfig file clk: tegra: Implement memory-controller clock powerpc/iommu: Rename iommu_[un]map_sg functions iommu: Improve error handling when setting bus iommu iommu: Do more input validation in iommu_map_sg() iommu: Add iommu_map_sg() function Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-12-04soc: integrator: Add terminating entry for integrator_cm_matchAxel Lin1-0/+1
The of_device_id table is supposed to be zero-terminated. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-12-04Merge tag 'reset-for-3.19-2' of git://git.pengutronix.de/git/pza/linux into next/driversArnd Bergmann5-0/+193
Pull "Reset controller changes for v3.19" from Philipp Zabel: This adds a new driver for the sti soc family, and creates a reset_control_status interface, which is added to the existing drivers. * tag 'reset-for-3.19-2' of git://git.pengutronix.de/git/pza/linux: reset: add socfpga_reset_status reset: sti: Document sti-picophyreset controllers bindings. reset: stih407: Add softreset, powerdown and picophy controllers reset: stih407: Add reset controllers DT bindings reset: add reset_control_status helper function Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-12-04Merge tag 'mvebu-soc-suspend-3.19' of git://git.infradead.org/linux-mvebu into next/socArnd Bergmann4-6/+283
Pull "mvebu SoC suspend changes for v3.19" from Jason Cooper: - Armada 370/XP suspend/resume support - mvebu SoC driver suspend/resume support - irqchip - clocksource - mbus - clk * tag 'mvebu-soc-suspend-3.19' of git://git.infradead.org/linux-mvebu: ARM: mvebu: add SDRAM controller description for Armada XP ARM: mvebu: adjust mbus controller description on Armada 370/XP ARM: mvebu: add suspend/resume DT information for Armada XP GP ARM: mvebu: synchronize secondary CPU clocks on resume ARM: mvebu: make sure MMU is disabled in armada_370_xp_cpu_resume ARM: mvebu: Armada XP GP specific suspend/resume code ARM: mvebu: reserve the first 10 KB of each memory bank for suspend/resume ARM: mvebu: implement suspend/resume support for Armada XP clk: mvebu: add suspend/resume for gatable clocks bus: mvebu-mbus: provide a mechanism to save SDRAM window configuration bus: mvebu-mbus: suspend/resume support clocksource: time-armada-370-xp: add suspend/resume support irqchip: armada-370-xp: Add suspend/resume support Documentation: dt-bindings: minimal documentation for MVEBU SDRAM controller Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-12-04Merge tag 'arm-soc/for-3.19/brcmstb-drivers' of https://github.com/brcm/linux into next/driversArnd Bergmann2-20/+100
This pull request contains the following changes to the Broadcom GISB bus arbiter from Kevin Cernekee: - Extend brcmstb GISB bus driver to work on MIPS (currently ARM-only) and support 65nm and 40nm MIPS-based chips such as: BCM7038, BCM7400 and BCM7435 * tag 'arm-soc/for-3.19/brcmstb-drivers' of https://github.com/brcm/linux: bus: brcmstb_gisb: Add register offset tables for older chips bus: brcmstb_gisb: Look up register offsets in a table bus: brcmstb_gisb: Introduce wrapper functions for MMIO accesses bus: brcmstb_gisb: Make the driver buildable on MIPS Conflicts: drivers/bus/brcmstb_gisb.c Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-12-04memory: Add NVIDIA Tegra memory controller supportThierry Reding12-1482/+3801
The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-12-03Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds2-6/+6
Pull i2c bugfixes from Wolfram Sang: "A few driver bugfixes for 3.18" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: omap: fix i207 errata handling i2c: designware: prevent early stop on TX FIFO empty i2c: omap: fix NACK and Arbitration Lost irq handling
2014-12-03Merge tag 'pci-v3.18-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pciLinus Torvalds1-8/+20
Pull PCI fix from Bjorn Helgaas: "This fixes a Tegra20 regression that we introduced during the v3.18 merge window" * tag 'pci-v3.18-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: tegra: Use physical range for I/O mapping
2014-12-03Merge tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linuxLinus Torvalds1-2/+0
Pull devicetree bugfix from Grant Likely: "One more bug fix for v3.18. I debated whether or not to send you this merge request because we're at such a late rc. The bug isn't critical in that there is only one system known to be affected and the patch is easy to backport. The codepath is used by pretty much every DT based system, so there is risk a of regression (it /should/ be safe, but I've been bitten by stuff that should be safe before). I've had it in linux-next for a week and haven't received any complaints. I think it probably should just be merged right away rather than waiting for the merge window and backporting. It does fix a real bug and the code is theoretically safer after the change. I can't think of any situation where it would be dangerous to reserve the DT memory an extra time. Summary from tag: Single bugfix for boot failure seen in the wild. The memory reserve code tries to be clever about reserving the FDT, but it should just go ahead and reserve it unconditionally to avoid the problem of partial overlap described in the patch" * tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux: of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap
2014-12-03Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds10-45/+88
Pull drm fixes from Dave Airlie: "Radeon and Nouveau fixes: So nouveau had a few regression introduced, Ben and Maarten finally tracked down the one that was causing problems on my MacBookPro, also nvidia gave some info on the an engine we were using incorrectly, so disable our use of it, and one regresion with pci hotplug affecting optimus users. Radeon has an oops fixs, sync fix, and one workaround to avoid broken functionality on 32-bit x86, this needs better root causing and a better fix, but the bandaid is a lot safer at this point" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6 drm/radeon: Ignore RADEON_GEM_GTT_WC on 32-bit x86 drm/radeon: sync all BOs involved in a CS v2 nouveau: move the hotplug ignore to correct place. drm/nouveau/gf116: remove copy1 engine drm/nouveau: prevent stale fence->channel pointers, and protect with rcu drm/nouveau/fifo/g84-: ack non-stall interrupt before handling it
2014-12-03Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds6-67/+72
Pull networking fixes from David Miller: 1) Fill in ethtool link parameters for all link types in cxgb4, from Hariprasad Shenai. 2) Fix probe regressions in stmmac driver, from Huacai Chen. 3) Network namespace leaks on errirs in rtnetlink, from Nicolas Dichtel. 4) Remove erroneous BUG check which can actually trigger legitimately, in xen-netfront. From Seth Forshee. 5) Validate length of IFLA_BOND_ARP_IP_TARGET netlink attributes, from Thomas Grag. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: cxgb4: Fill in supported link mode for SFP modules xen-netfront: Remove BUGs on paged skb data which crosses a page boundary sh_eth: Fix sleeping function called from invalid context stmmac: platform: Move plat_dat checking earlier sh_eth: Fix skb alloc size and alignment adjust rule. rtnetlink: release net refcnt on error in do_setlink() bond: Check length of IFLA_BOND_ARP_IP_TARGET attributes
2014-12-03drivers/input/evdev.c: don't kfree() a vmalloc addressAndrew Morton1-1/+1
If kzalloc() failed and then evdev_open_device() fails, evdev_open() will pass a vmalloc'ed pointer to kfree. This might fix https://bugzilla.kernel.org/show_bug.cgi?id=88401, where there was a crash in kfree(). Reported-by: Christian Casteyde <casteyde.christian@free.fr> Belatedly-Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Henrik Rydberg <rydberg@euromail.se> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-03ARM: at91/clocksource: remove !DT PIT initializationsArnd Bergmann1-32/+0
As AT91 !DT code is now removed, cleanup the PIT clocksource driver. Signed-off-by: Arnd Bergmann <arnd@arndb.de> [nicolas.ferre@atmel.com: split patch] Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Boris BREZILLON <boris.brezillon@free-electrons.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
2014-12-02cxgb4: Fill in supported link mode for SFP modulesHariprasad Shenai1-2/+6
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-02xen-netfront: Remove BUGs on paged skb data which crosses a page boundarySeth Forshee1-5/+0
These BUGs can be erroneously triggered by frags which refer to tail pages within a compound page. The data in these pages may overrun the hardware page while still being contained within the compound page, but since compound_order() evaluates to 0 for tail pages the assertion fails. The code already iterates through subsequent pages correctly in this scenario, so the BUGs are unnecessary and can be removed. Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit") Cc: <stable@vger.kernel.org> # 3.7+ Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-02drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6Petr Mladek1-0/+2
I was unable too boot 3.18.0-rc6 because of the following kernel panic in drm_calc_vbltimestamp_from_scanoutpos(): [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). [drm] register mmio base: 0xC8400000 [drm] register mmio size: 65536 radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 16bits DDR [TTM] Zone kernel: Available graphics memory: 3829346 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator [drm] radeon: 16M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] PCI GART of 512M enabled (table at 0x0000000037880000). radeon 0000:0b:01.0: WB disabled radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] Loading R100 Microcode radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2 radeon_cp: Failed to load firmware "radeon/R100_cp.bin" [drm:r100_cp_init] *ERROR* Failed to load firmware! radeon 0000:0b:01.0: failed initializing CP (-2). radeon 0000:0b:01.0: Disabling GPU acceleration [drm] radeon: cp finalized BUG: unable to handle kernel NULL pointer dereference at 000000000000025c IP: [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 PGD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649 Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006 task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000 RIP: 0010:[<ffffffff8150423b>] [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 RSP: 0000:ffff880234da7918 EFLAGS: 00010086 RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48 RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000 RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0 R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000 FS: 0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0 Stack: ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480 ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58 Call Trace: [<ffffffff8151b51d>] ? drm_vma_offset_remove+0x1d/0x110 [<ffffffff8152dc98>] radeon_get_vblank_timestamp_kms+0x38/0x60 [<ffffffff8152076a>] ? ttm_bo_release_list+0xba/0x180 [<ffffffff81503751>] drm_get_last_vbltimestamp+0x41/0x70 [<ffffffff81503933>] vblank_disable_and_save+0x73/0x1d0 [<ffffffff81106b2f>] ? try_to_del_timer_sync+0x4f/0x70 [<ffffffff81505245>] drm_vblank_cleanup+0x65/0xa0 [<ffffffff815604fa>] radeon_irq_kms_fini+0x1a/0x70 [<ffffffff8156c07e>] r100_init+0x26e/0x410 [<ffffffff8152ae3e>] radeon_device_init+0x7ae/0xb50 [<ffffffff8152d57f>] radeon_driver_load_kms+0x8f/0x210 [<ffffffff81506965>] drm_dev_register+0xb5/0x110 [<ffffffff8150998f>] drm_get_pci_dev+0x8f/0x200 [<ffffffff815291cd>] radeon_pci_probe+0xad/0xe0 [<ffffffff8141a365>] local_pci_probe+0x45/0xa0 [<ffffffff8141b741>] pci_device_probe+0xd1/0x130 [<ffffffff81633dad>] driver_probe_device+0x12d/0x3e0 [<ffffffff8163413b>] __driver_attach+0x9b/0xa0 [<ffffffff816340a0>] ? __device_attach+0x40/0x40 [<ffffffff81631cd3>] bus_for_each_dev+0x63/0xa0 [<ffffffff8163378e>] driver_attach+0x1e/0x20 [<ffffffff81633390>] bus_add_driver+0x180/0x240 [<ffffffff81634914>] driver_register+0x64/0xf0 [<ffffffff81419cac>] __pci_register_driver+0x4c/0x50 [<ffffffff81509bf5>] drm_pci_init+0xf5/0x120 [<ffffffff821dc871>] ? ttm_init+0x6a/0x6a [<ffffffff821dc908>] radeon_init+0x97/0xb5 [<ffffffff810002fc>] do_one_initcall+0xbc/0x1f0 [<ffffffff810e3278>] ? __wake_up+0x48/0x60 [<ffffffff8218e256>] kernel_init_freeable+0x18a/0x215 [<ffffffff8218d983>] ? initcall_blacklist+0xc0/0xc0 [<ffffffff818a78f0>] ? rest_init+0x80/0x80 [<ffffffff818a78fe>] kernel_init+0xe/0xf0 [<ffffffff818c0c3c>] ret_from_fork+0x7c/0xb0 [<ffffffff818a78f0>] ? rest_init+0x80/0x80 Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60 RIP [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 RSP <ffff880234da7918> CR2: 000000000000025c ---[ end trace ad2c0aadf48e2032 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 It has helped me to add a NULL pointer check that was suggested at http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html I am not familiar with the code. But the change looks sane and we need something fast at this stage of 3.18 development. Suggested-by: Helge Deller <deller@gmx.de> Signed-off-by: Petr Mladek <pmladek@suse.cz> Tested-by: Petr Mladek <pmladek@suse.cz> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2014-12-02drm/radeon: Ignore RADEON_GEM_GTT_WC on 32-bit x86Michel Dänzer1-0/+7
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84627 Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2014-12-02drm/radeon: sync all BOs involved in a CS v2Christian König1-10/+7
Not just the userspace relocs, otherwise we won't wait for a swapped out page tables to be swapped in again. v2: rebased on Alex current drm-fixes-3.18 Signed-off-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-02sata_fsl: fix error handling of irq_of_parse_and_mapDmitry Torokhov1-1/+1
irq_of_parse_and_map() returns 0 on error (the result is unsigned int), so testing for negative result never works. Signed-off-by: Dmitry Torokhov <dtor@chromium.org> Signed-off-by: Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org
2014-12-02AHCI: Add DeviceIDs for Sunrise Point-LP SATA controllerDevin Ryles1-0/+3
This patch adds DeviceIDs for Sunrise Point-LP. Signed-off-by: Devin Ryles <devin.ryles@intel.com> Signed-off-by: Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org
2014-12-02scsi: set fmt to NULL scsi_extd_sense_format() by defaultDan Carpenter1-0/+3
One of the two callers passes an unintialized pointer as "fmt" and expects it to be set to NULL if there is no format string. Let's make this function work as expected. Fixes: d811b848ebb7 ('scsi: use sdev as argument for sense code printing') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2014-12-02dm crypt: use memzero_explicit for on-stack bufferMilan Broz1-1/+1
Use memzero_explicit to cleanup sensitive data allocated on stack to prevent the compiler from optimizing and removing memset() calls. Signed-off-by: Milan Broz <gmazyland@gmail.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org
2014-12-02dm space map metadata: fix sm_bootstrap_get_count()Joe Thornber1-1/+3
Must set 'result' accordingly rather than return it. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2014-12-02hwmon: (lm95234) Add support for LM95233Guenter Roeck2-29/+68
LM95233 is similar to LM95234, but it only supports two instead of four external temperature sensors. Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2014-12-02drm/i915: Unlock panel even when LVDS is disabledDaniel Vetter1-11/+11
Otherwise we'll have backtraces in assert_panel_unlocked because the BIOS locks the register. In the reporter's case this regression was introduced in commit c31407a3672aaebb4acddf90944a114fa5c8af7b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Oct 18 21:07:01 2012 +0100 drm/i915: Add no-lvds quirk for Supermicro X7SPA-H Reported-by: Alexey Orishko <alexey.orishko@gmail.com> Cc: Alexey Orishko <alexey.orishko@gmail.com> Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Francois Tigeot <ftigeot@wolfpond.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Tested-by: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-02regulator: sky81452: Modify Device Tree structureGyungoh Yoo1-36/+9
Signed-off-by: Gyungoh Yoo <jack.yoo@skyworksinc.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-12-02hwmon: (lm95245) Add support for LM95235Guenter Roeck2-16/+30
LM95235 is register compatible to LM95245. Also update link to LM95245 data sheet, and drop the link to the datasheet from the driver source to simplify code maintenance. Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2014-12-02mmc: sdhci-acpi: Add two host capabilities for IntelAdrian Hunter1-2/+5
Intel host controllers are capable of doing the bus width test and of waiting while busy, so add the capability flags. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-12-02mmc: sdhci-pci: Add two host capabilities for BYTAdrian Hunter1-2/+8
BYT host controllers are capable of doing the bus width test and of waiting while busy, so add the capability flags. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-12-02mmc: sdhci-acpi: Add SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESCAdrian Hunter1-1/+4
SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC actually causes standard-compliant behaviour by causing the flagging of the last DMA transfer descriptor as the end instead of there being an additional nop descriptor which is flagged as the end. Consequently, it is better to have the quirk. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-12-02mmc: sdhci-pci: Add SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC to BYTAdrian Hunter1-0/+3
SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC actually causes standard-compliant behaviour by causing the flagging of the last DMA transfer descriptor as the end instead of there being an additional nop descriptor which is flagged as the end. Consequently, it is better to have the quirk. Add it for BYT. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-12-02mmc: atmel-mci: use probe deferring if dma controller is not ready yetludovic.desroches@atmel.com1-24/+24
Return probe defer if requesting a dma channel without a dma controller probed. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-12-02mmc: atmel-mci: stop using specific initcallludovic.desroches@atmel.com1-13/+2
No more use late initcall to manage probing order. Use probe deferring if needed. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-12-02mmc: atmel-mci: remove __init/__exit attributesludovic.desroches@atmel.com1-5/+5
Using __init/__exit attributes can cause several breakages so remove them. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-12-02mmc: atmel-mci: remove useless DMA stuff for non-dt devicesludovic.desroches@atmel.com1-8/+0
All devices with a DMA controller are DT compliant and legacy support has been removed. For those reasons, some DMA stuff is useless. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-12-02drm/i915: More cautious with pch fifo underrunsDaniel Vetter1-2/+0
Apparently PCH fifo underruns are tricky, we have plenty reports that we see the occasional underrun (especially at boot-up). So for a change let's see what happens when we don't re-enable pch fifo underrun reporting when the pipe is disabled. This means that the kernel can't catch pch fifo underruns when they happen (except when all pipes are on on the pch). But we'll still catch underruns when disabling the pipe again. So not a terrible reduction in test coverage. Since the DRM_ERROR is new and hence a regression plan B would be to revert it back to a debug output. Which would be a lot worse than this hack for underrun test coverage in the wild. See the referenced discussions for more. References: http://mid.gmane.org/CA+gsUGRfGe3t4NcjdeA=qXysrhLY3r4CEu7z4bjTwxi1uOfy+g@mail.gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85898 References: https://bugs.freedesktop.org/show_bug.cgi?id=85898 References: https://bugs.freedesktop.org/show_bug.cgi?id=86233 References: https://bugs.freedesktop.org/show_bug.cgi?id=86478 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Tested-by: lu hua <huax.lu@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-02nouveau: move the hotplug ignore to correct place.Dave Airlie1-1/+1
Introduced in b440bde74f, however it was added to the wrong function in nouveau. https://bugzilla.kernel.org/show_bug.cgi?id=86011 Cc: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.15+ Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-12-02Merge branch 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixesDave Airlie6-34/+71
Just a couple of fixes for the fallout from the fence rework. * 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: drm/nouveau/gf116: remove copy1 engine drm/nouveau: prevent stale fence->channel pointers, and protect with rcu drm/nouveau/fifo/g84-: ack non-stall interrupt before handling it
2014-12-02drm/nouveau/gf116: remove copy1 engineIlia Mirkin1-1/+0
Indications are that no GF116's actually have a copy engine there, but actually have the decompression engine. This engine can be made to do copies, but that should be done separately. Unclear why this didn't turn up on all GF116's, but perhaps the non-mobile ones came with enough VRAM to not trigger ttm migrations in test scenarios. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=85465 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59168 Cc: stable@vger.kernel.org Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-12-02drm/nouveau: prevent stale fence->channel pointers, and protect with rcuMaarten Lankhorst2-29/+67
Tested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-12-02drm/nouveau/fifo/g84-: ack non-stall interrupt before handling itBen Skeggs3-4/+4
Closes a very unlikely race that can occur if another NonStallInterrupt method passes between checking fences and acking the previous interrupt. With this change, the interrupt will re-fire under such conditions. Tested-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-12-01PCI: tegra: Use physical range for I/O mappingThierry Reding1-8/+20
Commit 0b0b0893d49b ("of/pci: Fix the conversion of IO ranges into IO resources") changed how I/O resources are parsed from DT. Rather than containing the physical address of the I/O region, the addresses will now be in I/O address space. On Tegra the union of all ranges is used to expose a top-level memory- mapped resource for the PCI host bridge. This helps to make /proc/iomem more readable. Combining both of the above, the union would now include the I/O space region. This causes a regression on Tegra20, where the physical base address of the PCIe controller (and therefore of the union) is located at physical address 0x80000000. Since I/O space starts at 0, the union will now include all of system RAM which starts at 0x00000000. This commit fixes this by keeping two copies of the I/O range: one that represents the range in the CPU's physical address space, the other for the range in the I/O address space. This allows the translation setup within the driver to reuse the physical addresses. The code registering the I/O region with the PCI core uses both ranges to establish the mapping. Fixes: 0b0b0893d49b ("of/pci: Fix the conversion of IO ranges into IO resources") Reported-by: Marc Zyngier <marc.zyngier@arm.com> Tested-by: Marc Zyngier <marc.zyngier@arm.com> Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
2014-12-01of: Rename "poweroff-source" property to "system-power-controller"Romain Perier1-1/+1
It reverts commit a4b4e0461ec5 ("of: Add standard property for poweroff capability"). As discussed on the mailing list, it makes more sense to rename back to the old established property name, without the vendor prefix. Problem being that the word "source" usually tends to be used for inputs and that is out of control of the OS. The poweroff capability is an output which simply turns the system-power off. Also, this property might be used by drivers which power-off the system and power back on subsequent RTC alarms. This seems to suggest to remove "poweroff" from the property name and to choose "system-power-controller" as the more generic name. This patchs adds the required renaming changes and defines an helper function which checks if this property is set. Signed-off-by: Romain Perier <romain.perier@gmail.com> Acked-by: Grant Likely <grant.likely@linaro.org> Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-12-01dm space map metadata: fix sm_bootstrap_get_nr_blocks()Dan Carpenter1-1/+3
This function isn't right and it causes a static checker warning: drivers/md/dm-thin.c:3016 maybe_resize_data_dev() error: potentially using uninitialized 'sb_data_size'. It should set "*count" and return zero on success the same as the sm_metadata_get_nr_blocks() function does earlier. Fixes: 3241b1d3e0aa ('dm: add persistent data library') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2014-12-01dm bufio: fix memleak when using a dm_buffer's inline bioDarrick J. Wong1-1/+19
When dm-bufio sets out to use the bio built into a struct dm_buffer to issue an IO, it needs to call bio_reset after it's done with the bio so that we can free things attached to the bio such as the integrity payload. Therefore, inject our own endio callback to take care of the bio_reset after calling submit_io's end_io callback. Test case: 1. modprobe scsi_debug delay=0 dif=1 dix=199 ato=1 dev_size_mb=300 2. Set up a dm-bufio client, e.g. dm-verity, on the scsi_debug device 3. Repeatedly read metadata and watch kmalloc-192 leak! Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org
2014-12-01dm cache: fix spurious cell_defer when dealing with partial block at end of deviceJoe Thornber1-2/+2
We never bother caching a partial block that is at the back end of the origin device. No cell ever gets locked, but the calling code was assuming it was and trying to release it. Now the code only releases if the cell has been set to a non NULL value. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org
2014-12-01dm cache: dirty flag was mistakenly being cleared when promoting via overwriteJoe Thornber1-3/+7
If the incoming bio is a WRITE and completely covers a block then we don't bother to do any copying for a promotion operation. Once this is done the cache block and origin block will be different, so we need to set it to 'dirty'. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org
2014-12-01dm cache: only use overwrite optimisation for promotion when in writeback modeJoe Thornber1-1/+2
Overwrite causes the cache block and origin blocks to diverge, which is only allowed in writeback mode. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org