commit c8bde72f9af412de57f0ceae218d648640118b0b Author: Greg Kroah-Hartman Date: Tue Jul 21 10:10:33 2015 -0700 Linux 4.1.3 commit 7890602ea4fa5793f5ecad24bcca0049fa7ca06d Author: Frodo Lai Date: Tue Jun 16 15:03:53 2015 -0700 Input: pixcir_i2c_ts - fix receive error commit 469d7d22cea146e40efe8c330e5164b4d8f13934 upstream. The i2c_master_recv() uses readsize to receive data from i2c but compares to size of rdbuf which is always 27. This would cause problem when the max_fingers is not 5. Change the comparison value to readsize instead. Fixes: 36874c7e219 ("Input: pixcir_i2c_ts - support up to 5 fingers and hardware tracking IDs:) Signed-off-by: Frodo Lai Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d389ad7c0e6c02efaa3fe7992efb2452022e4b63 Author: Zhichang Yuan Date: Fri Apr 24 17:05:09 2015 +0800 of/pci: Fix pci_address_to_pio() conversion of CPU address to I/O port commit 5dbb4c6167229c8d4f528e8ec26699a7305000a3 upstream. 41f8bba7f555 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()") added support for systems with several I/O ranges described by OF bindings. It modified pci_address_to_pio() look up the io_range for a given CPU physical address, but the conversion was wrong. Fix the conversion of address to I/O port. [bhelgaas: changelog] Fixes: 41f8bba7f555 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()") Signed-off-by: Zhichang Yuan Signed-off-by: Bjorn Helgaas Acked-by: Liviu Dudau Signed-off-by: Greg Kroah-Hartman commit 5224e2a708f617fb69ea7cb56613838af40af188 Author: Alex Williamson Date: Mon Jun 8 17:10:50 2015 -0600 PCI: pciehp: Wait for hotplug command completion where necessary commit a5dd4b4b0570b3bf880d563969b245dfbd170c1e upstream. The commit referenced below deferred waiting for command completion until the start of the next command, allowing hardware to do the latching asynchronously. Unfortunately, being ready to accept a new command is the only indication we have that the previous command is completed. In cases where we need that state change to be enabled, we must still wait for completion. For instance, pciehp_reset_slot() attempts to disable anything that might generate a surprise hotplug on slots that support presence detection. If we don't wait for those settings to latch before the secondary bus reset, we negate any value in attempting to prevent the spurious hotplug. Create a base function with optional wait and helper functions so that pcie_write_cmd() turns back into the "safe" interface which waits before and after issuing a command and add pcie_write_cmd_nowait(), which eliminates the trailing wait for asynchronous completion. The following functions are returned to their previous behavior: pciehp_power_on_slot pciehp_power_off_slot pcie_disable_notification pciehp_reset_slot The rationale is that pciehp_power_on_slot() enables the link and therefore relies on completion of power-on. pciehp_power_off_slot() and pcie_disable_notification() need a wait because data structures may be freed after these calls and continued signaling from the device would be unexpected. And, of course, pciehp_reset_slot() needs to wait for the scenario outlined above. Fixes: 3461a068661c ("PCI: pciehp: Wait for hotplug command completion lazily") Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 30e8a1821385dbd85830b407103f28d989764911 Author: Yinghai Lu Date: Wed May 27 17:23:51 2015 -0700 PCI: Add pci_bus_addr_t commit 3a9ad0b4fdcd57f775d3615004c8c64c021a9e7d upstream. David Ahern reported that d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream windows") fails to boot on sparc/T5-8: pci 0000:06:00.0: reg 0x184: can't handle BAR above 4GB (bus address 0x110204000) The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA addresses, i.e., bus addresses returned via the DMA API (dma_map_single(), etc.), while the PCI core assumed dma_addr_t could hold *any* bus address, including raw BAR values. On sparc64, all DMA addresses fit in 32 bits, so dma_addr_t is a 32-bit type. However, BAR values can be 64 bits wide, so they don't fit in a dma_addr_t. d63e2e1f3df9 added new checking that tripped over this mismatch. Add pci_bus_addr_t, which is wide enough to hold any PCI bus address, including both raw BAR values and DMA addresses. This will be 64 bits on 64-bit platforms and on platforms with a 64-bit dma_addr_t. Then dma_addr_t only needs to be wide enough to hold addresses from the DMA API. [bhelgaas: changelog, bugzilla, Kconfig to ensure pci_bus_addr_t is at least as wide as dma_addr_t, documentation] Fixes: d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream windows") Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB") Link: http://lkml.kernel.org/r/CAE9FiQU1gJY1LYrxs+ma5LCTEEe4xmtjRG0aXJ9K_Tsu+m9Wuw@mail.gmail.com Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=96231 Reported-by: David Ahern Tested-by: David Ahern Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas Acked-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7044198591216ee701f98eeefecabc9d0ad6c2ef Author: Rafael J. Wysocki Date: Mon Apr 13 16:23:36 2015 +0200 PCI: Propagate the "ignore hotplug" setting to parent commit 0824965140fff1bf640a987dc790d1594a8e0699 upstream. Refine the mechanism introduced by commit f244d8b623da ("ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug") to propagate the ignore_hotplug setting of the device to its parent bridge in case hotplug notifications related to the graphics adapter switching are given for the bridge rather than for the device itself (they need to be ignored in both cases). Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891 Link: https://bugs.freedesktop.org/show_bug.cgi?id=88927 Fixes: b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device") Reported-and-tested-by: tiagdtd-lava Signed-off-by: Rafael J. Wysocki Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 4aa339cddbcc05b7f8ff4f0960550929aa77213e Author: Uwe Kleine-König Date: Thu May 28 10:22:10 2015 +0200 mtd: dc21285: use raw spinlock functions for nw_gpio_lock commit e5babdf928e5d0c432a8d4b99f20421ce14d1ab6 upstream. Since commit bd31b85960a7 (which is in 3.2-rc1) nw_gpio_lock is a raw spinlock that needs usage of the corresponding raw functions. This fixes: drivers/mtd/maps/dc21285.c: In function 'nw_en_write': drivers/mtd/maps/dc21285.c:41:340: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type spin_lock_irqsave(&nw_gpio_lock, flags); In file included from include/linux/seqlock.h:35:0, from include/linux/time.h:5, from include/linux/stat.h:18, from include/linux/module.h:10, from drivers/mtd/maps/dc21285.c:8: include/linux/spinlock.h:299:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *' static inline raw_spinlock_t *spinlock_check(spinlock_t *lock) ^ drivers/mtd/maps/dc21285.c:43:25: warning: passing argument 1 of 'spin_unlock_irqrestore' from incompatible pointer type spin_unlock_irqrestore(&nw_gpio_lock, flags); ^ In file included from include/linux/seqlock.h:35:0, from include/linux/time.h:5, from include/linux/stat.h:18, from include/linux/module.h:10, from drivers/mtd/maps/dc21285.c:8: include/linux/spinlock.h:370:91: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *' static inline void spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags) Fixes: bd31b85960a7 ("locking, ARM: Annotate low level hw locks as raw") Signed-off-by: Uwe Kleine-König Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit 857814ee65dbc942b18b2dc713124ffff043035e Author: Brian Norris Date: Thu May 7 17:55:16 2015 -0700 mtd: fix: avoid race condition when accessing mtd->usecount commit 073db4a51ee43ccb827f54a4261c0583b028d5ab upstream. On A MIPS 32-cores machine a BUG_ON was triggered because some acesses to mtd->usecount were done without taking mtd_table_mutex. kernel: Call Trace: kernel: [] __put_mtd_device+0x20/0x50 kernel: [] blktrans_release+0x8c/0xd8 kernel: [] __blkdev_put+0x1a8/0x200 kernel: [] blkdev_close+0x1c/0x30 kernel: [] __fput+0xac/0x250 kernel: [] task_work_run+0xd8/0x120 kernel: [] work_notifysig+0x10/0x18 kernel: kernel: Code: 2442ffff ac8202d8 000217fe <00020336> dc820128 10400003 00000000 0040f809 00000000 kernel: ---[ end trace 080fbb4579b47a73 ]--- Fixed by taking the mutex in blktrans_open and blktrans_release. Note that this locking is already suggested in include/linux/mtd/blktrans.h: struct mtd_blktrans_ops { ... /* Called with mtd_table_mutex held; no race with add/remove */ int (*open)(struct mtd_blktrans_dev *dev); void (*release)(struct mtd_blktrans_dev *dev); ... }; But we weren't following it. Originally reported by (and patched by) Zhang and Giuseppe, independently. Improved and rewritten. Reported-by: Zhang Xingcai Reported-by: Giuseppe Cantavenera Tested-by: Giuseppe Cantavenera Acked-by: Alexander Sverdlin Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit 2c6f129c8fcf59946e62216792e162b9d9f0dc8e Author: Grygorii Strashko Date: Fri Apr 24 14:57:10 2015 +0300 leds / PM: fix hibernation on arm when gpio-led used with CPU led trigger commit 084609bf727981c7a2e6e69aefe0052c9d793300 upstream. Setting a dev_pm_ops suspend/resume pair of callbacks but not a set of hibernation callbacks means those pm functions will not be called upon hibernation - that leads to system crash on ARM during freezing if gpio-led is used in combination with CPU led trigger. It may happen after freeze_noirq stage (GPIO is suspended) and before syscore_suspend stage (CPU led trigger is suspended) - usually when disable_nonboot_cpus() is called. Log: PM: noirq freeze of devices complete after 1.425 msecs Disabling non-boot CPUs ... ^ system may crash or stuck here with message (TI AM572x) WARNING: CPU: 0 PID: 3100 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x22c/0x370() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access CPU1: shutdown ^ or here Fix this by using SIMPLE_DEV_PM_OPS, which appropriately assigns the suspend and hibernation callbacks and move led_suspend/led_resume under CONFIG_PM_SLEEP to avoid build warnings. Fixes: 73e1ab41a80d (leds: Convert led class driver from legacy pm ops to dev_pm_ops) Signed-off-by: Grygorii Strashko Acked-by: Jacek Anaszewski Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ab12dcd70c11074e6ed28b0304f059a075e33db0 Author: Liu Ying Date: Fri Apr 3 12:51:05 2015 +0800 video: mxsfb: Make sure axi clock is enabled when accessing registers commit 2fa3b4c4a78a5db3502ab9e32630ea660ff923d0 upstream. The LCDIF engines embedded in i.MX6sl and i.MX6sx SoCs need the axi clock as the engine's system clock. The clock should be enabled when accessing LCDIF registers, otherwise the kernel would hang up. We should also keep the clock enabled when the engine is being active to scan out frames from memory. This patch makes sure the axi clock is enabled when accessing registers so that the kernel hang up issue can be fixed. Reported-by: Peter Chen Tested-by: Peter Chen Signed-off-by: Liu Ying Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman commit 25d8f169eee423940158a0ab33ed5dd1dd995cf9 Author: Axel Lin Date: Mon May 11 17:02:58 2015 +0800 genirq: devres: Fix testing return value of request_any_context_irq() commit 63781394c540dd9e666a6b21d70b64dd52bce76e upstream. request_any_context_irq() returns a negative value on failure. It returns either IRQC_IS_HARDIRQ or IRQC_IS_NESTED on success. So fix testing return value of request_any_context_irq(). Also fixup the return value of devm_request_any_context_irq() to make it consistent with request_any_context_irq(). Fixes: 0668d3065128 ("genirq: Add devm_request_any_context_irq()") Signed-off-by: Axel Lin Reviewed-by: Stephen Boyd Link: http://lkml.kernel.org/r/1431334978.17783.4.camel@ingics.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit b14524edc36d494d75c760743cc9435ef4c12a2f Author: Bart Van Assche Date: Mon May 18 13:24:17 2015 +0200 IB/srp: Fix reconnection failure handling commit a44074f14ba1ea0747ea737026eb929b81993dc3 upstream. Although it is possible to let SRP I/O continue if a reconnect results in a reduction of the number of channels, the current code does not handle this scenario correctly. Instead of making the reconnect code more complex, consider this as a reconnection failure. Signed-off-by: Bart Van Assche Cc: Sagi Grimberg Cc: Sebastian Parschauer Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit c1ab680046ba170050e91ec49577699de1a24e1a Author: Bart Van Assche Date: Mon May 18 13:23:57 2015 +0200 IB/srp: Fix connection state tracking commit c014c8cd31b161e12deb81c0f7f477811bd1eddc upstream. Reception of a DREQ message only causes the state of a single channel to change. Hence move the 'connected' member variable from the target to the channel data structure. This patch avoids that following false positive warning can be reported by srp_destroy_qp(): WARNING: at drivers/infiniband/ulp/srp/ib_srp.c:617 srp_destroy_qp+0xa6/0x120 [ib_srp]() Call Trace: [] warn_slowpath_common+0x7f/0xc0 [] warn_slowpath_null+0x1a/0x20 [] srp_destroy_qp+0xa6/0x120 [ib_srp] [] srp_free_ch_ib+0x82/0x1e0 [ib_srp] [] srp_create_target+0x7ab/0x998 [ib_srp] [] dev_attr_store+0x20/0x30 [] sysfs_write_file+0xef/0x170 [] vfs_write+0xc8/0x190 [] sys_write+0x51/0x90 Signed-off-by: Bart Van Assche Cc: Sagi Grimberg Cc: Sebastian Parschauer Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 86e4f5b10e79205f5eb254a3c60d111931f2a274 Author: Bart Van Assche Date: Mon May 18 13:23:36 2015 +0200 IB/srp: Fix a connection setup race commit 8de9fe3a1d4ac8c3e4953fa4b7d81f863f5196ad upstream. Avoid that receiving a DREQ while RDMA channels are being established causes target->qp_in_error to be reset. Signed-off-by: Bart Van Assche Cc: Sagi Grimberg Cc: Sebastian Parschauer Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 5e72c7cc287d9415debd623e96ac275f20d37645 Author: Bart Van Assche Date: Mon May 18 13:23:14 2015 +0200 IB/srp: Remove an extraneous scsi_host_put() from an error path commit fb49c8bbaae70b14fea2b4590a90a21539f88526 upstream. Fix a scsi_get_host() / scsi_host_put() imbalance in the error path of srp_create_target(). See also patch "IB/srp: Avoid that I/O hangs due to a cable pull during LUN scanning" (commit ID 34aa654ecb8e). Signed-off-by: Bart Van Assche Reviewed-by: Sagi Grimberg Cc: Sebastian Parschauer Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 3646ac368739a302008cc7bf33a985da2cfa1a17 Author: Bart Van Assche Date: Mon May 18 13:22:44 2015 +0200 scsi_transport_srp: Fix a race condition commit 535fb906225fb7436cb658144d0c0cea14a26f3e upstream. Avoid that srp_terminate_io() can get invoked while srp_queuecommand() is in progress. This patch avoids that an I/O timeout can trigger the following kernel warning: WARNING: at drivers/infiniband/ulp/srp/ib_srp.c:1447 srp_terminate_io+0xef/0x100 [ib_srp]() Call Trace: [] dump_stack+0x4e/0x68 [] warn_slowpath_common+0x81/0xa0 [] warn_slowpath_null+0x1a/0x20 [] srp_terminate_io+0xef/0x100 [ib_srp] [] __rport_fail_io_fast+0xba/0xc0 [scsi_transport_srp] [] rport_fast_io_fail_timedout+0xe0/0xf0 [scsi_transport_srp] [] process_one_work+0x1db/0x780 [] worker_thread+0x11b/0x450 [] kthread+0xe4/0x100 [] ret_from_fork+0x7c/0xb0 See also patch "scsi_transport_srp: Add transport layer error handling" (commit ID 29c17324803c). Signed-off-by: Bart Van Assche Cc: James Bottomley Cc: Sagi Grimberg Cc: Sebastian Parschauer Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 3705ac339307a3f6b5a84e48cb82be0167b4e633 Author: Bart Van Assche Date: Mon May 18 13:22:19 2015 +0200 scsi_transport_srp: Introduce srp_wait_for_queuecommand() commit be34c62ddf39d1931780b07a6f4241393e4ba2ee upstream. Introduce the helper function srp_wait_for_queuecommand(). Move the definition of scsi_request_fn_active(). Add a comment above srp_wait_for_queuecommand() that support for scsi-mq needs to be added. This patch does not change any functionality. A second call to srp_wait_for_queuecommand() will be introduced in the next patch. Signed-off-by: Bart Van Assche Cc: James Bottomley Cc: Sagi Grimberg Cc: Sebastian Parschauer Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit bcd201e2ae1c3e431a89a02a48c05112f19eb65e Author: Ezequiel Garcia Date: Mon May 11 12:20:18 2015 -0300 spi: pl022: Specify 'num-cs' property as required in devicetree binding commit ea6055c46eda1e19e02209814955e13f334bbe1b upstream. Since commit 39a6ac11df65 ("spi/pl022: Devicetree support w/o platform data") the 'num-cs' parameter cannot be passed through platform data when probing with devicetree. Instead, it's a required devicetree property. Fix the binding documentation so the property is properly specified. Fixes: 39a6ac11df65 ("spi/pl022: Devicetree support w/o platform data") Signed-off-by: Ezequiel Garcia Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 46afcceeebddd0f6e1d328c9c9c93059adffdf08 Author: Gregory CLEMENT Date: Tue May 26 11:44:42 2015 +0200 spi: orion: Fix maximum baud rates for Armada 370/XP commit ce2f6ea1cbd41d78224f703af980a6ceeb0eb56a upstream. The commit df59fa7f4bca "spi: orion: support armada extended baud rates" was too optimistic for the maximum baud rate that the Armada SoCs can support. According to the hardware datasheet the maximum frequency supported by the Armada 370 SoC is tclk/4. But for the Armada XP, Armada 38x and Armada 39x SoCs the limitation is 50MHz and for the Armada 375 it is tclk/15. Currently the armada-370-spi compatible is only used by the Armada 370 and the Armada XP device tree. On Armada 370, tclk cannot be higher than 200MHz. In order to be able to handle both SoCs, we can take the minimum of 50MHz and tclk/4. A proper solution is adding a compatible string for each SoC, but it can't be done as a fix for compatibility reason (we can't modify device tree that have been already released) and it will be part of a separate patch. Fixes: df59fa7f4bca (spi: orion: support armada extended baud rates) Reported-by: Kostya Porotchkin Signed-off-by: Gregory CLEMENT Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 927973d93be4524ad25518e0e3412cd27d425e29 Author: Martin Sperl Date: Sun May 10 07:50:45 2015 +0000 spi: fix race freeing dummy_tx/rx before it is unmapped commit 8e76ef88f607174082023f50b87fe12dcdbe5db5 upstream. Fix a race (with some kernel configurations) where a queued master->pump_messages runs and frees dummy_tx/rx before spi_unmap_msg is running (or is finished). This results in the following messages: BUG: Bad page state in process page:db7ba030 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x200(arch_1) page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set ... Reported-by: Noralf Trønnes Suggested-by: Noralf Trønnes Tested-by: Noralf Trønnes Signed-off-by: Martin Sperl Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 9da8e034daa3670221442392ce9ea17474591c34 Author: Miroslav Benes Date: Mon Jun 1 17:48:37 2015 +0200 livepatch: add module locking around kallsyms calls commit 9a1bd63cdae4b623494c4ebaf723a91c35ec49fb upstream. The list of loaded modules is walked through in module_kallsyms_on_each_symbol (called by kallsyms_on_each_symbol). The module_mutex lock should be acquired to prevent potential corruptions in the list. This was uncovered with new lockdep asserts in module code introduced by the commit 0be964be0d45 ("module: Sanitize RCU usage and locking") in recent next- trees. Signed-off-by: Miroslav Benes Acked-by: Josh Poimboeuf Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit c17210c30c65355713afb618da1e24b970fa69c8 Author: Stefan Wahren Date: Tue Jun 9 20:09:42 2015 +0000 regulator: core: fix constraints output buffer commit a7068e3932eee8268c4ce4e080a338ee7b8a27bf upstream. The buffer for condtraints debug isn't big enough to hold the output in all cases. So fix this issue by increasing the buffer. Signed-off-by: Stefan Wahren Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1a9850fbeb65734827a7dd0088ea357b0f22a242 Author: Joe Perches Date: Mon May 18 10:01:03 2015 -0700 regulator: max77686: fix gpio_enabled shift wrapping bug commit c53403a37cf083ce85da720f18918f73580d0064 upstream. The code should handle more than 32 bits here because "id" can be a value up to MAX77686_REGULATORS (currently 34). Convert the gpio_enabled type to DECLARE_BITMAP and use test_bit/set_bit. Fixes: 3307e9025d29 ("regulator: max77686: Add GPIO control") Reported-by: Dan Carpenter Signed-off-by: Joe Perches Reviewed-by: Krzysztof Kozlowski Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6489f7a496378983980e8219dfaeaf66d581590b Author: Maxime Coquelin Date: Tue Jun 16 13:53:19 2015 +0200 regmap: Fix possible shift overflow in regmap_field_init() commit 921cc29473a0d7c109105c1876ddb432f4a4be7d upstream. The way the mask is generated in regmap_field_init() is wrong. Indeed, a field initialized with msb = 31 and lsb = 0 provokes a shift overflow while calculating the mask field. On some 32 bits architectures, such as x86, the generated mask is 0, instead of the expected 0xffffffff. This patch uses GENMASK() to fix the problem, as this macro is already safe regarding shift overflow. Signed-off-by: Maxime Coquelin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 88822cdb258714ce2fdc9a6eed87e7dd7d205a6b Author: Arun Chandran Date: Mon Jun 15 15:59:02 2015 +0530 regmap: Fix regmap_bulk_read in BE mode commit 15b8d2c41fe5839582029f65c5f7004db451cc2b upstream. In big endian mode regmap_bulk_read gives incorrect data for byte reads. This is because memcpy of a single byte from an address after full word read gives different results when endianness differs. ie. we get little-end in LE and big-end in BE. Signed-off-by: Arun Chandran Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1021c97205005db4f101e7fa55095ec13118ac03 Author: Vlastimil Babka Date: Wed Jun 24 16:58:48 2015 -0700 mm, thp: respect MPOL_PREFERRED policy with non-local node commit 0867a57c4f80a566dda1bac975b42fcd857cb489 upstream. Since commit 077fcf116c8c ("mm/thp: allocate transparent hugepages on local node"), we handle THP allocations on page fault in a special way - for non-interleave memory policies, the allocation is only attempted on the node local to the current CPU, if the policy's nodemask allows the node. This is motivated by the assumption that THP benefits cannot offset the cost of remote accesses, so it's better to fallback to base pages on the local node (which might still be available, while huge pages are not due to fragmentation) than to allocate huge pages on a remote node. The nodemask check prevents us from violating e.g. MPOL_BIND policies where the local node is not among the allowed nodes. However, the current implementation can still give surprising results for the MPOL_PREFERRED policy when the preferred node is different than the current CPU's local node. In such case we should honor the preferred node and not use the local node, which is what this patch does. If hugepage allocation on the preferred node fails, we fall back to base pages and don't try other nodes, with the same motivation as is done for the local node hugepage allocations. The patch also moves the MPOL_INTERLEAVE check around to simplify the hugepage specific test. The difference can be demonstrated using in-tree transhuge-stress test on the following 2-node machine where half memory on one node was occupied to show the difference. > numactl --hardware available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 24 25 26 27 28 29 30 31 32 33 34 35 node 0 size: 7878 MB node 0 free: 3623 MB node 1 cpus: 12 13 14 15 16 17 18 19 20 21 22 23 36 37 38 39 40 41 42 43 44 45 46 47 node 1 size: 8045 MB node 1 free: 7818 MB node distances: node 0 1 0: 10 21 1: 21 10 Before the patch: > numactl -p0 -C0 ./transhuge-stress transhuge-stress: 2.197 s/loop, 0.276 ms/page, 7249.168 MiB/s 7962 succeed, 0 failed, 1786 different pages > numactl -p0 -C12 ./transhuge-stress transhuge-stress: 2.962 s/loop, 0.372 ms/page, 5376.172 MiB/s 7962 succeed, 0 failed, 3873 different pages Number of successful THP allocations corresponds to free memory on node 0 in the first case and node 1 in the second case, i.e. -p parameter is ignored and cpu binding "wins". After the patch: > numactl -p0 -C0 ./transhuge-stress transhuge-stress: 2.183 s/loop, 0.274 ms/page, 7295.516 MiB/s 7962 succeed, 0 failed, 1760 different pages > numactl -p0 -C12 ./transhuge-stress transhuge-stress: 2.878 s/loop, 0.361 ms/page, 5533.638 MiB/s 7962 succeed, 0 failed, 1750 different pages > numactl -p1 -C0 ./transhuge-stress transhuge-stress: 4.628 s/loop, 0.581 ms/page, 3440.893 MiB/s 7962 succeed, 0 failed, 3918 different pages The -p parameter is respected regardless of cpu binding. > numactl -C0 ./transhuge-stress transhuge-stress: 2.202 s/loop, 0.277 ms/page, 7230.003 MiB/s 7962 succeed, 0 failed, 1750 different pages > numactl -C12 ./transhuge-stress transhuge-stress: 3.020 s/loop, 0.379 ms/page, 5273.324 MiB/s 7962 succeed, 0 failed, 3916 different pages Without -p parameter, hugepage restriction to CPU-local node works as before. Fixes: 077fcf116c8c ("mm/thp: allocate transparent hugepages on local node") Signed-off-by: Vlastimil Babka Cc: Aneesh Kumar K.V Acked-by: David Rientjes Cc: Kirill A. Shutemov Cc: Andrea Arcangeli Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 03445a4c2324f4adddd6b6c9b92879c1c754238a Author: Larry Finger Date: Wed Jun 24 16:58:51 2015 -0700 mm: kmemleak_alloc_percpu() should follow the gfp from per_alloc() commit 8a8c35fadfaf55629a37ef1a8ead1b8fb32581d2 upstream. Beginning at commit d52d3997f843 ("ipv6: Create percpu rt6_info"), the following INFO splat is logged: =============================== [ INFO: suspicious RCU usage. ] 4.1.0-rc7-next-20150612 #1 Not tainted ------------------------------- kernel/sched/core.c:7318 Illegal context switch in RCU-bh read-side critical section! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 3 locks held by systemd/1: #0: (rtnl_mutex){+.+.+.}, at: [] rtnetlink_rcv+0x1f/0x40 #1: (rcu_read_lock_bh){......}, at: [] ipv6_add_addr+0x62/0x540 #2: (addrconf_hash_lock){+...+.}, at: [] ipv6_add_addr+0x184/0x540 stack backtrace: CPU: 0 PID: 1 Comm: systemd Not tainted 4.1.0-rc7-next-20150612 #1 Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20 04/17/2014 Call Trace: dump_stack+0x4c/0x6e lockdep_rcu_suspicious+0xe7/0x120 ___might_sleep+0x1d5/0x1f0 __might_sleep+0x4d/0x90 kmem_cache_alloc+0x47/0x250 create_object+0x39/0x2e0 kmemleak_alloc_percpu+0x61/0xe0 pcpu_alloc+0x370/0x630 Additional backtrace lines are truncated. In addition, the above splat is followed by several "BUG: sleeping function called from invalid context at mm/slub.c:1268" outputs. As suggested by Martin KaFai Lau, these are the clue to the fix. Routine kmemleak_alloc_percpu() always uses GFP_KERNEL for its allocations, whereas it should follow the gfp from its callers. Reviewed-by: Catalin Marinas Reviewed-by: Kamalesh Babulal Acked-by: Martin KaFai Lau Signed-off-by: Larry Finger Cc: Martin KaFai Lau Cc: Catalin Marinas Cc: Tejun Heo Cc: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3baf726f001b69454f3eb18a589c508992622be9 Author: Catalin Marinas Date: Wed Jun 24 16:58:26 2015 -0700 mm: kmemleak: allow safe memory scanning during kmemleak disabling commit c5f3b1a51a591c18c8b33983908e7fdda6ae417e upstream. The kmemleak scanning thread can run for minutes. Callbacks like kmemleak_free() are allowed during this time, the race being taken care of by the object->lock spinlock. Such lock also prevents a memory block from being freed or unmapped while it is being scanned by blocking the kmemleak_free() -> ... -> __delete_object() function until the lock is released in scan_object(). When a kmemleak error occurs (e.g. it fails to allocate its metadata), kmemleak_enabled is set and __delete_object() is no longer called on freed objects. If kmemleak_scan is running at the same time, kmemleak_free() no longer waits for the object scanning to complete, allowing the corresponding memory block to be freed or unmapped (in the case of vfree()). This leads to kmemleak_scan potentially triggering a page fault. This patch separates the kmemleak_free() enabling/disabling from the overall kmemleak_enabled nob so that we can defer the disabling of the object freeing tracking until the scanning thread completed. The kmemleak_free_part() is deliberately ignored by this patch since this is only called during boot before the scanning thread started. Signed-off-by: Catalin Marinas Reported-by: Vignesh Radhakrishnan Tested-by: Vignesh Radhakrishnan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e3334dca73de24e5798759b14ed9e4f58e241fbd Author: Will Deacon Date: Fri Jun 19 13:56:33 2015 +0100 arm64: vdso: work-around broken ELF toolchains in Makefile commit 6f1a6ae87c0c60d7c462ef8fd071f291aa7a9abb upstream. When building the kernel with a bare-metal (ELF) toolchain, the -shared option may not be passed down to collect2, resulting in silent corruption of the vDSO image (in particular, the DYNAMIC section is omitted). The effect of this corruption is that the dynamic linker fails to find the vDSO symbols and libc is instead used for the syscalls that we intended to optimise (e.g. gettimeofday). Functionally, there is no issue as the sigreturn trampoline is still intact and located by the kernel. This patch fixes the problem by explicitly passing -shared to the linker when building the vDSO. Reported-by: Szabolcs Nagy Reported-by: James Greenlaigh Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit da8de4cde423fcd62233467ff9c067137beda0e8 Author: Dave P Martin Date: Tue Jun 16 17:38:47 2015 +0100 arm64: mm: Fix freeing of the wrong memmap entries with !SPARSEMEM_VMEMMAP commit b9bcc919931611498e856eae9bf66337330d04cc upstream. The memmap freeing code in free_unused_memmap() computes the end of each memblock by adding the memblock size onto the base. However, if SPARSEMEM is enabled then the value (start) used for the base may already have been rounded downwards to work out which memmap entries to free after the previous memblock. This may cause memmap entries that are in use to get freed. In general, you're not likely to hit this problem unless there are at least 2 memblocks and one of them is not aligned to a sparsemem section boundary. Note that carve-outs can increase the number of memblocks by splitting the regions listed in the device tree. This problem doesn't occur with SPARSEMEM_VMEMMAP, because the vmemmap code deals with freeing the unused regions of the memmap instead of requiring the arch code to do it. This patch gets the memblock base out of the memblock directly when computing the block end address to ensure the correct value is used. Signed-off-by: Dave Martin Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit f6b01e505aa5785eaeda028fc0f151599f90b557 Author: Mark Rutland Date: Mon Jun 15 16:40:27 2015 +0100 arm64: entry: fix context tracking for el0_sp_pc commit 46b0567c851cf85d6ba6f23eef385ec9111d09bc upstream. Commit 6c81fe7925cc4c42 ("arm64: enable context tracking") did not update el0_sp_pc to use ct_user_exit, but this appears to have been unintentional. In commit 6ab6463aeb5fbc75 ("arm64: adjust el0_sync so that a function can be called") we made x0 available, and in the return to userspace we call ct_user_enter in the kernel_exit macro. Due to this, we currently don't correctly inform RCU of the user->kernel transition, and may erroneously account for time spent in the kernel as if we were in an extended quiescent state when CONFIG_CONTEXT_TRACKING is enabled. As we do record the kernel->user transition, a userspace application making accesses from an unaligned stack pointer can demonstrate the imbalance, provoking the following warning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3660 at kernel/context_tracking.c:75 context_tracking_enter+0xd8/0xe4() Modules linked in: CPU: 2 PID: 3660 Comm: a.out Not tainted 4.1.0-rc7+ #8 Hardware name: ARM Juno development board (r0) (DT) Call trace: [] dump_backtrace+0x0/0x124 [] show_stack+0x10/0x1c [] dump_stack+0x84/0xc8 [] warn_slowpath_common+0x98/0xd0 [] warn_slowpath_null+0x14/0x20 [] context_tracking_enter+0xd4/0xe4 [] preempt_schedule_irq+0xd4/0x114 [] el1_preempt+0x4/0x28 [] exit_files+0x38/0x4c [] do_exit+0x430/0x978 [] do_group_exit+0x40/0xd4 [] get_signal+0x23c/0x4f4 [] do_signal+0x1ac/0x518 [] do_notify_resume+0x5c/0x68 ---[ end trace 963c192600337066 ]--- This patch adds the missing ct_user_exit to the el0_sp_pc entry path, correcting the context tracking for this case. Signed-off-by: Mark Rutland Acked-by: Will Deacon Fixes: 6c81fe7925cc ("arm64: enable context tracking") Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit eeac30f17f468292f1141c6f5d95afc38a18260f Author: Catalin Marinas Date: Fri Jun 12 11:24:41 2015 +0100 arm64: Do not attempt to use init_mm in reset_context() commit 565630d503ef24e44c252bed55571b3a0d68455f upstream. After secondary CPU boot or hotplug, the active_mm of the idle thread is &init_mm. The init_mm.pgd (swapper_pg_dir) is only meant for TTBR1_EL1 and must not be set in TTBR0_EL1. Since when active_mm == &init_mm the TTBR0_EL1 is already set to the reserved value, there is no need to perform any context reset. Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 6bc62fd9b8493bd6a07bb73a5d63ed28fea40b78 Author: Tomas Winkler Date: Tue Apr 14 10:27:26 2015 +0300 mei: txe: reduce suspend/resume time commit fe292283c23329218e384bffc6cb4bfa3fd92277 upstream. HW has to be in known state before the initialisation sequence is started. The polling step for settling aliveness was set to 200ms while in practise this can be done in up to 30msecs. Signed-off-by: Tomas Winkler Signed-off-by: Barak Yoresh Signed-off-by: Greg Kroah-Hartman commit 5acb6674291b15ea45d5bd65baff96a896f11ec6 Author: Alexander Usyskin Date: Sat Jun 13 08:51:17 2015 +0300 mei: me: wait for power gating exit confirmation commit 3dc196eae1db548f05e53e5875ff87b8ff79f249 upstream. Fix the hbm power gating state machine so it will wait till it receives confirmation interrupt for the PG_ISOLATION_EXIT message. In process of the suspend flow the devices first have to exit from the power gating state (runtime pm resume). If we do not handle the confirmation interrupt after sending PG_ISOLATION_EXIT message, we may receive it already after the suspend flow has changed the device state and interrupt will be interpreted as a spurious event, consequently link reset will be invoked which will prevent the device from completing the suspend flow kernel: [6603] mei_reset:136: mei_me 0000:00:16.0: powering down: end of reset kernel: [476] mei_me_irq_thread_handler:643: mei_me 0000:00:16.0: function called after ISR to handle the interrupt processing. kernel: mei_me 0000:00:16.0: FW not ready: resetting Cc: Gabriele Mazzotta Link: https://bugzilla.kernel.org/show_bug.cgi?id=86241 Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770397 Tested-by: Gabriele Mazzotta Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit f6795f11a4dfb7fbbd4b34668271a553141c0aa7 Author: Krzysztof Kozlowski Date: Tue May 19 16:13:02 2015 +0900 power_supply: Fix possible NULL pointer dereference on early uevent commit 7f1a57fdd6cb6e7be2ed31878a34655df38e1861 upstream. Don't call the power_supply_changed() from power_supply_register() when parent is still probing because it may lead to accessing parent too early. In bq27x00_battery this caused NULL pointer exception because uevent of power_supply_changed called back the the get_property() method provided by the driver. The get_property() method accessed pointer which should be returned by power_supply_register(). Starting from bq27x00_battery_probe(): di->bat = power_supply_register() power_supply_changed() kobject_uevent() power_supply_uevent() power_supply_show_property() power_supply_get_property() bq27x00_battery_get_property() dereference of di->bat which is NULL here The dereference of di->bat (value returned by power_supply_register()) is the currently visible problem. However calling back the methods provided by driver before ending the probe may lead to accessing other driver-related data which is not yet initialized. The call to power_supply_changed() is postponed till probing ends - mutex of parent device is released. Reported-by: H. Nikolaus Schaller Signed-off-by: Krzysztof Kozlowski Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core") Tested-By: Dr. H. Nikolaus Schaller Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 9f8e1f603600b300906e695d106a0e5cc39dcf82 Author: Krzysztof Kozlowski Date: Tue May 19 16:13:01 2015 +0900 power_supply: Fix NULL pointer dereference during bq27x00_battery probe commit 8e59c7f23410d5ca6b350a178b861a3d68c49edf upstream. Power supply is often registered during probe of a driver. The power_supply_register() returns pointer to newly allocated structure as return value. However before returning the power_supply_register() calls back the get_property() method provided by the driver through uevent. In that time the driver probe is still in progress and driver did not assigned pointer to power supply to its local variables. This leads to NULL pointer dereference from get_property() function. Starting from bq27x00_battery_probe(): di->bat = power_supply_register() device_add() kobject_uevent() power_supply_uevent() power_supply_show_property() power_supply_get_property() bq27x00_battery_get_property() dereference of (di->bat) which is NULL here The first uevent of power supply (the one coming from device creation) should not call back to the driver. To prevent that from happening, increment the atomic use counter at the end of power_supply_register(). This means that power_supply_get_property() will return -ENODEV. IMPORTANT: The patch has impact on this first uevent sent from power supply because it will not contain properties from power supply. The uevent with properties will be sent later after indicating that power supply has changed. This also has a race now, but will be fixed in other patches. Reported-by: H. Nikolaus Schaller Signed-off-by: Krzysztof Kozlowski Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core") Tested-By: Dr. H. Nikolaus Schaller Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 16e860b30b2c3703d92a6cd701a6e602d897f481 Author: Max Filippov Date: Sun Jun 14 02:09:06 2015 +0300 arc: fix use of uninitialized arc_pmu commit 7002f77541f877a5590615ceb3da32b114f14b62 upstream. static arc_pmu in the arch/arc/kernel/perf_event.c is not initialized as it's shadowed by a local variable of the same name in the arc_pmu_device_probe. Signed-off-by: Max Filippov Fixes: 03c94fcf954d "ARC: perf: make @arc_pmu static global" Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 3e43ff498fb1a9f8a58c7746c207b8ffd9a9a87d Author: Vineet Gupta Date: Thu Nov 13 15:54:01 2014 +0530 ARC: add compiler barrier to LLSC based cmpxchg commit d57f727264f1425a94689bafc7e99e502cb135b5 upstream. When auditing cmpxchg call sites, Chuck noted that gcc was optimizing away some of the desired LDs. | do { | new = old = *ipi_data_ptr; | new |= 1U << msg; | } while (cmpxchg(ipi_data_ptr, old, new) != old); was generating to below | 8015cef8: ld r2,[r4,0] <-- First LD | 8015cefc: bset r1,r2,r1 | | 8015cf00: llock r3,[r4] <-- atomic op | 8015cf04: brne r3,r2,8015cf10 | 8015cf08: scond r1,[r4] | 8015cf0c: bnz 8015cf00 | | 8015cf10: brne r3,r2,8015cf00 <-- Branch doesn't go to orig LD Although this was fixed by adding a ACCESS_ONCE in this call site, it seems safer (for now at least) to add compiler barrier to LLSC based cmpxchg Reported-by: Chuck Jordan Acked-by: Peter Zijlstra (Intel) Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit eb1eecd100ce48d4f8368a0c475ecb937abd40ec Author: Vineet Gupta Date: Thu Nov 20 15:42:09 2014 +0530 ARC: add smp barriers around atomics per Documentation/atomic_ops.txt commit 2576c28e3f623ed401db7e6197241865328620ef upstream. - arch_spin_lock/unlock were lacking the ACQUIRE/RELEASE barriers Since ARCv2 only provides load/load, store/store and all/all, we need the full barrier - LLOCK/SCOND based atomics, bitops, cmpxchg, which return modified values were lacking the explicit smp barriers. - Non LLOCK/SCOND varaints don't need the explicit barriers since that is implicity provided by the spin locks used to implement the critical section (the spin lock barriers in turn are also fixed in this commit as explained above Cc: Paul E. McKenney Acked-by: Peter Zijlstra (Intel) Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit f3ff4345ef597115869a227dbf738dde157f8521 Author: Arnaldo Carvalho de Melo Date: Thu May 14 16:55:18 2015 -0300 tools selftests: Fix 'clean' target with make 3.81 commit 60df4642a83546fa6ea8286f5094ce8c0906c3ec upstream. Make 3.81 doesn't have the 'undefine' command. Using undefine to clear LDFLAGS fails when make version 3.81 is used. Fix it to use override to clear LDFLAGS. Tested-by: Shuah Khan Cc: David Ahern Cc: Ingo Molnar Cc: Michael Ellerman Link: http://lkml.kernel.org/r/20150514151225.GH23588@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Shuah Khan Cc: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 8841d6439b1d6504d9c7498ebfdee1408e09460e Author: Antonio Ospite Date: Mon May 4 11:13:03 2015 +0200 iio: accel: kxcjk-1013: add the "KXCJ9000" ACPI id commit 61e2c70da9cfc79e8485eafa0f98b5919b04bbe1 upstream. This id has been seen in the DSDT of the Teclast X98 Air 3G tablet based on Intel Bay Trail. Signed-off-by: Antonio Ospite Cc: Bastien Nocera Reviewed-by: Daniel Baluta Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c75c95bb4bb656d1d2914caf17d71317941100f2 Author: Rafael J. Wysocki Date: Thu Jun 18 18:32:02 2015 +0200 ACPI / PNP: Avoid conflicting resource reservations commit 0f1b414d190724617eb1cdd615592fa8cd9d0b50 upstream. Commit b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()" overlooked the fact that the memory and/or I/O regions reserved by acpi_reserve_resources() may conflict with those reserved by the PNP "system" driver. If that conflict actually takes place, it causes the reservations made by the "system" driver to fail while before commit b9a5e5e18fbf all reservations made by it and by acpi_reserve_resources() would be successful. In turn, that allows the resources that haven't been reserved by the "system" driver to be used by others (e.g. PCI) which sometimes leads to functional problems (up to and including boot failures). To fix that issue, introduce a common resource reservation routine, acpi_reserve_region(), to be used by both acpi_reserve_resources() and the "system" driver, that will track all resources reserved by it and avoid making conflicting requests. Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831 Link: http://marc.info/?t=143389402600001&r=1&w=2 Fixes: b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()" Reported-by: Roland Dreier Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 5ab4a6010600c24c37f5178d6da981e18cbb090a Author: Rafael J. Wysocki Date: Wed Jun 10 01:32:38 2015 +0200 ACPI / PM: Add missing pm_generic_complete() invocation commit 3d56402d3fa8d10749eeb36293dd1992bd5ad0c3 upstream. Add missing invocation of pm_generic_complete() to acpi_subsys_complete() to allow ->complete callbacks provided by the drivers of devices using the ACPI PM domain to be executed during system resume. Fixes: f25c0ae2b4c4 (ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend) Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 9e6004867b1a9e4ededb8d56edb827de67073291 Author: Rafael J. Wysocki Date: Wed Jun 10 01:33:36 2015 +0200 ACPI / init: Switch over platform to the ACPI mode later commit b064a8fa77dfead647564c46ac8fc5b13bd1ab73 upstream. Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()" moved the ACPI subsystem initialization, including the ACPI mode enabling, to an earlier point in the initialization sequence, to allow the timekeeping subsystem use ACPI early. Unfortunately, that resulted in boot regressions on some systems and the early ACPI initialization was moved toward its original position in the kernel initialization code by commit c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later". However, that turns out to be insufficient, as boot is still broken on the Tyan S8812 mainboard. To fix that issue, split the ACPI early initialization code into two pieces so the majority of it still located in acpi_early_init() and the part switching over the platform into the ACPI mode goes into a new function, acpi_subsystem_init(), executed at the original early ACPI initialization spot. That fixes the Tyan S8812 boot problem, but still allows ACPI tables to be loaded earlier which is useful to the EFI code in efi_enter_virtual_mode(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141 Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()" Reported-and-tested-by: Marius Tolzmann Signed-off-by: Rafael J. Wysocki Acked-by: Toshi Kani Reviewed-by: Hanjun Guo Reviewed-by: Lee, Chun-Yi Signed-off-by: Greg Kroah-Hartman commit 13e888e7678c544cf4460eb997f6b9f660193563 Author: Takashi Iwai Date: Mon Jun 29 10:56:53 2015 +0200 ALSA: hda - Add a fixup for Dell E7450 commit 4275554dccdf0afac07b2b638ba7456095629558 upstream. Dell E7450 [0128:062e] needs the same quirk as other E7xx models. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100571 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f367c3b94b1a20a27eb51a2646d7409a1da2d761 Author: Takashi Iwai Date: Mon Jun 29 08:38:02 2015 +0200 ALSA: hda - Fix the dock headphone output on Fujitsu Lifebook E780 commit 4df3fd1700abbb53bd874143dfd1f9ac9e7cbf4b upstream. Fujitsu Lifebook E780 sets the sequence number 0x0f to only only of the two headphones, thus the driver tries to assign another as the line-out, and this results in the inconsistent mapping between the created jack ctl and the actual I/O. Due to this, PulseAudio doesn't handle it properly and gets the silent output. The fix is to ignore the non-HP sequencer checks. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=99681 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4b461d112cdbca4183f4b2f0d67a081a650269ab Author: Takashi Iwai Date: Sat Jun 27 10:21:13 2015 +0200 ALSA: hda - Add headset support to Acer Aspire V5 commit 7819717b11346b8a5420b223b46600e394049c66 upstream. Acer Aspire V5 with ALC282 codec needs the similar quirk like Dell laptops to support the headset mic. The headset mic pin is 0x19 and it's not exposed by BIOS, thus we need to fix the pincfg as well. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96201 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d097fff2c1fbeef22c20f0d6a9a9ed236baabba7 Author: Hui Wang Date: Fri Jun 26 12:35:17 2015 +0800 ALSA: hda - restore the MIC FIXUP for some Dell machines commit 831bfdf9520e389357cfeee42a6174a73ce7bdb7 upstream. Those FIXUPs were applied to the machines through pin quirks, but recently the PCI_QUIRK makes them can't apply to the machines. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=99851 Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c69c5674d87690f87e48a4267bc68e62fc605d9c Author: Takashi Iwai Date: Thu Jun 25 08:48:54 2015 +0200 ALSA: hda - Disable widget power-save for VIA codecs commit 735c75cf4d434862e38c01dcfb2ce8d2fcb9035f upstream. The widget power-save that was enabled in 4.1 kernel seems resulting in the silent output on VIA codecs by some reason. Some widgets get wrong power states. As a quick fix, turn this flag off while keeping power_down_unused flag. This will bring back to the state of 4.0.x. Fixes: 688b12cc3ca8 ('ALSA: hda - Use the new power control for VIA codecs') Reported-and-tested-by: Harald Dunkel Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 167bdde510b17d86767b71282c91036ab671340f Author: Alex Deucher Date: Wed Jun 24 14:37:18 2015 -0400 ALSA: hda - set proper caps for newer AMD hda audio in KB/KV commit 650474fb737c3e0ea0f6ab8e43c2cd161080ce5c upstream. Fixes audio problems on newer asics. Noticed by: Kelly Anderson Signed-off-by: Alex Deucher Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 704ffc4cf721867e35cb922b12cae3210d6f7e67 Author: David Henningsson Date: Wed Jun 24 10:46:33 2015 +0200 ALSA: hda - Fix Dock Headphone on Thinkpad X250 seen as a Line Out commit ec56af67a10a0d82b79027878a81fce08d002d50 upstream. Thinkpad X250, when attached to a dock, has two headphone outs but no line out. Make sure we don't try to turn this into one headphone and one line out (since that disables the headphone amp on the dock). Alsa-info at http://www.alsa-project.org/db/?f=36f8764e1d782397928feec715d0ef90dfddd4c1 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 08e394684b82b0987295d96201071f52504c83f5 Author: Takashi Iwai Date: Tue Jun 23 11:56:22 2015 +0200 ALSA: pcm: Fix pcm_class sysfs output commit 60b93030b44a8c2cd015cebe5624fd7552ec67ec upstream. The pcm_class sysfs of each PCM substream gives only "none" since the recent code change to embed the struct device. Fix the code to point directly to the embedded device object properly. Fixes: ef46c7af93f9 ('ALSA: pcm: Embed struct device') Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 37100f76f93236e99a89c0f0c5531eff03920725 Author: Ryan Underwood Date: Sun Jan 25 16:07:09 2015 -0800 Disable write buffering on Toshiba ToPIC95 commit 2fb22a8042fe96b4220843f79241c116d90922c4 upstream. Disable write buffering on the Toshiba ToPIC95 if it is enabled by somebody (it is not supposed to be a power-on default according to the datasheet). On the ToPIC95, practically no 32-bit Cardbus card will work under heavy load without locking up the whole system if this is left enabled. I tried about a dozen. It does not affect 16-bit cards. This is similar to the O2 bugs in early controller revisions it seems. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55961 Signed-off-by: Ryan C. Underwood Signed-off-by: Dominik Brodowski Signed-off-by: Greg Kroah-Hartman commit 77d10175396e764488886923eeaec58c3ff1fb7b Author: Brian King Date: Wed May 13 08:50:27 2015 -0500 ipr: Increase default adapter init stage change timeout commit 45c44b5ff9caa743ed9c2bfd44307c536c9caf1e upstream. Increase the default init stage change timeout from 15 seconds to 30 seconds. This resolves issues we have seen with some adapters not transitioning to the first init stage within 15 seconds, which results in adapter initialization failures. Signed-off-by: Brian King Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit a6556a506ea1c737e8adafd59015786448ffbf3f Author: Paul E. McKenney Date: Mon May 11 11:13:05 2015 -0700 rcu: Correctly handle non-empty Tiny RCU callback list with none ready commit 6e91f8cb138625be96070b778d9ba71ce520ea7e upstream. If, at the time __rcu_process_callbacks() is invoked, there are callbacks in Tiny RCU's callback list, but none of them are ready to be invoked, the current list-management code will knit the non-ready callbacks out of the list. This can result in hangs and possibly worse. This commit therefore inserts a check for there being no callbacks that can be invoked immediately. This bug is unlikely to occur -- you have to get a new callback between the time rcu_sched_qs() or rcu_bh_qs() was called, but before we get to __rcu_process_callbacks(). It was detected by the addition of RCU-bh testing to rcutorture, which in turn was instigated by Iftekhar Ahmed's mutation testing. Although this bug was made much more likely by 915e8a4fe45e (rcu: Remove fastpath from __rcu_process_callbacks()), this did not cause the bug, but rather made it much more probable. That said, it takes more than 40 hours of rcutorture testing, on average, for this bug to appear, so this fix cannot be considered an emergency. Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman commit 9b553d64d949da26b63759e4ae9af863676bad37 Author: Geert Uytterhoeven Date: Thu May 21 13:21:37 2015 +0200 gpio: rcar: Check for irq_set_irq_wake() failures commit 501ef0f95a57e7c32138733c468394a52244c85b upstream. If an interrupt controller doesn't support wake-up configuration, irq_set_irq_wake() returns an error code. Then any subsequent call trying to deconfigure wake-up will cause an imbalance, and a warning will be printed: WARNING: CPU: 1 PID: 1341 at kernel/irq/manage.c:540 irq_set_irq_wake+0x9c/0xf8() Unbalanced IRQ 26 wake disable To fix this, refrain from any further parent interrupt controller (de)configuration if irq_set_irq_wake() failed. Alternative fixes would be: - calling "gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE)" from the platform code, - setting "gic_chip.flags = IRQCHIP_SKIP_SET_WAKE" in the GIC driver code, but these were withheld as the GIC hardware doesn't really support wake-up interrupts. Fixes: ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable when wake-up is enabled") Signed-off-by: Geert Uytterhoeven Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 03c29ef2e86669e356493153d80b5c4ed0fc2f84 Author: Aaron Lu Date: Thu May 28 10:58:49 2015 +0800 gpio: crystalcove: set IRQCHIP_SKIP_SET_WAKE for the irqchip commit 61e749d7e1627d375156553ea0ae83c4f6bb5a9b upstream. The CrystalCove GPIO irqchip doesn't have irq_set_wake callback defined so we should set IRQCHIP_SKIP_SET_WAKE for it or it would cause an irq desc's wake_depth unbalanced warning during system resume phase from the gpio_keys driver, which is the driver for the power button of the ASUS T100 laptop. Signed-off-by: Aaron Lu Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 51c2c47ef6349d49e49002054f8c0d11d3b5646e Author: Eric W. Biederman Date: Fri May 8 23:49:47 2015 -0500 mnt: Modify fs_fully_visible to deal with locked ro nodev and atime commit 8c6cf9cc829fcd0b179b59f7fe288941d0e31108 upstream. Ignore an existing mount if the locked readonly, nodev or atime attributes are less permissive than the desired attributes of the new mount. On success ensure the new mount locks all of the same readonly, nodev and atime attributes as the old mount. The nosuid and noexec attributes are not checked here as this change is destined for stable and enforcing those attributes causes a regression in lxc and libvirt-lxc where those applications will not start and there are no known executables on sysfs or proc and no known way to create exectuables without code modifications Fixes: e51db73532955 ("userns: Better restrictions on when proc and sysfs can be mounted") Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit b5eb51f2ee063044401492650e9e01bb35974870 Author: Eric W. Biederman Date: Fri May 8 23:22:29 2015 -0500 mnt: Refactor the logic for mounting sysfs and proc in a user namespace commit 1b852bceb0d111e510d1a15826ecc4a19358d512 upstream. Fresh mounts of proc and sysfs are a very special case that works very much like a bind mount. Unfortunately the current structure can not preserve the MNT_LOCK... mount flags. Therefore refactor the logic into a form that can be modified to preserve those lock bits. Add a new filesystem flag FS_USERNS_VISIBLE that requires some mount of the filesystem be fully visible in the current mount namespace, before the filesystem may be mounted. Move the logic for calling fs_fully_visible from proc and sysfs into fs/namespace.c where it has greater access to mount namespace state. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 8e7c56b6f14d1388d5aa2feb5b28dd6360199cef Author: Eric W. Biederman Date: Wed May 13 20:51:09 2015 -0500 mnt: Update fs_fully_visible to test for permanently empty directories commit 7236c85e1be51a9e25ba0f6e087a66ca89605a49 upstream. fs_fully_visible attempts to make fresh mounts of proc and sysfs give the mounter no more access to proc and sysfs than if they could have by creating a bind mount. One aspect of proc and sysfs that makes this particularly tricky is that there are other filesystems that typically mount on top of proc and sysfs. As those filesystems are mounted on empty directories in practice it is safe to ignore them. However testing to ensure filesystems are mounted on empty directories has not been something the in kernel data structures have supported so the current test for an empty directory which checks to see if nlink <= 2 is a bit lacking. proc and sysfs have recently been modified to use the new empty_dir infrastructure to create all of their dedicated mount points. Instead of testing for S_ISDIR(inode->i_mode) && i_nlink <= 2 to see if a directory is empty, test for is_empty_dir_inode(inode). That small change guaranteess mounts found on proc and sysfs really are safe to ignore, because the directories are not only empty but nothing can ever be added to them. This guarantees there is nothing to worry about when mounting proc and sysfs. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 28dd1f346b2f0fc2ab8285046ed0bd91e9b808d3 Author: Eric W. Biederman Date: Wed May 13 17:35:41 2015 -0500 sysfs: Create mountpoints with sysfs_create_mount_point commit f9bb48825a6b5d02f4cabcc78967c75db903dcdc upstream. This allows for better documentation in the code and it allows for a simpler and fully correct version of fs_fully_visible to be written. The mount points converted and their filesystems are: /sys/hypervisor/s390/ s390_hypfs /sys/kernel/config/ configfs /sys/kernel/debug/ debugfs /sys/firmware/efi/efivars/ efivarfs /sys/fs/fuse/connections/ fusectl /sys/fs/pstore/ pstore /sys/kernel/tracing/ tracefs /sys/fs/cgroup/ cgroup /sys/kernel/security/ securityfs /sys/fs/selinux/ selinuxfs /sys/fs/smackfs/ smackfs Acked-by: Greg Kroah-Hartman Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 9924f6e89823a41bfd272ab759636276b9f9ee9c Author: Eric W. Biederman Date: Wed May 13 16:31:40 2015 -0500 sysfs: Add support for permanently empty directories to serve as mount points. commit 87d2846fcf88113fae2341da1ca9a71f0d916f2c upstream. Add two functions sysfs_create_mount_point and sysfs_remove_mount_point that hang a permanently empty directory off of a kobject or remove a permanently emptpy directory hanging from a kobject. Export these new functions so modular filesystems can use them. Acked-by: Greg Kroah-Hartman Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 80c298105bf80e33ae494eaeba51f00352b5373c Author: Eric W. Biederman Date: Wed May 13 16:09:29 2015 -0500 kernfs: Add support for always empty directories. commit ea015218f2f7ace2dad9cedd21ed95bdba2886d7 upstream. Add a new function kernfs_create_empty_dir that can be used to create directory that can not be modified. Update the code to use make_empty_dir_inode when reporting a permanently empty directory to the vfs. Update the code to not allow adding to permanently empty directories. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit a2020b02c1ec4fffddb77785773dff533428f814 Author: Eric W. Biederman Date: Mon May 11 16:44:25 2015 -0500 proc: Allow creating permanently empty directories that serve as mount points commit eb6d38d5427b3ad42f5268da0f1dd31bb0af1264 upstream. Add a new function proc_create_mount_point that when used to creates a directory that can not be added to. Add a new function is_empty_pde to test if a function is a mount point. Update the code to use make_empty_dir_inode when reporting a permanently empty directory to the vfs. Update the code to not allow adding to permanently empty directories. Update /proc/openprom and /proc/fs/nfsd to be permanently empty directories. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit bdbdf7ee9d561da7b4b840435c963344061953d6 Author: Eric W. Biederman Date: Sat May 9 22:09:14 2015 -0500 sysctl: Allow creating permanently empty directories that serve as mountpoints. commit f9bd6733d3f11e24f3949becf277507d422ee1eb upstream. Add a magic sysctl table sysctl_mount_point that when used to create a directory forces that directory to be permanently empty. Update the code to use make_empty_dir_inode when accessing permanently empty directories. Update the code to not allow adding to permanently empty directories. Update /proc/sys/fs/binfmt_misc to be a permanently empty directory. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit c2f633b99857d27333de18f53d123a180672c52b Author: Eric W. Biederman Date: Sat May 9 15:54:49 2015 -0500 fs: Add helper functions for permanently empty directories. commit fbabfd0f4ee2e8847bf56edf481249ad1bb8c44d upstream. To ensure it is safe to mount proc and sysfs I need to check if filesystems that are mounted on top of them are mounted on truly empty directories. Given that some directories can gain entries over time, knowing that a directory is empty right now is insufficient. Therefore add supporting infrastructure for permantently empty directories that proc and sysfs can use when they create mount points for filesystems and fs_fully_visible can use to test for permanently empty directories to ensure that nothing will be gained by mounting a fresh copy of proc or sysfs. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman