summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* skd_main: switch to using blk_queue_write_cache()Jens Axboe2016-04-121-1/+1
| | | | | Signed-off-by: Jens Axboe <axboe@fb.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
* osdblk: switch to using blk_queue_write_cache()Jens Axboe2016-04-121-1/+1
| | | | | Signed-off-by: Jens Axboe <axboe@fb.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
* nbd: switch to using blk_queue_write_cache()Jens Axboe2016-04-121-2/+2
| | | | | Signed-off-by: Jens Axboe <axboe@fb.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
* mtip32xx: remove call to blk_queue_flush()Jens Axboe2016-04-121-6/+0
| | | | | | | | The driver calls it with 0 for flags, since it doesn't have a writeback cache. Just remove the call, as it's a no-op right now. Signed-off-by: Jens Axboe <axboe@fb.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
* loop: switch to using blk_queue_write_cache()Jens Axboe2016-04-121-1/+1
| | | | | Signed-off-by: Jens Axboe <axboe@fb.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
* drbd: switch to using blk_queue_write_cache()Jens Axboe2016-04-121-1/+1
| | | | | Signed-off-by: Jens Axboe <axboe@fb.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
* NVMe: switch to using blk_queue_write_cache()Jens Axboe2016-04-121-2/+5
| | | | | Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com>
* sd: switch to using blk_queue_write_cache()Jens Axboe2016-04-121-4/+4
| | | | | | | | | Switch to the newer interface, instead of using blk_queue_flush() directly. Signed-off-by: Jens Axboe <axboe@fb.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
* Merge branch 'for-4.7/core' into for-4.7/driversJens Axboe2016-04-124-0/+77
|\
| * block: add ability to flag write back caching on a deviceJens Axboe2016-04-124-0/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | Add an internal helper and flag for setting whether a queue has write back caching, or write through (or none). Add a sysfs file to show this as well, and make it changeable from user space. This will replace the (awkward) blk_queue_flush() interface that drivers currently use to inform the block layer of write cache state and capabilities. Signed-off-by: Jens Axboe <axboe@fb.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
* | blk-mq: Make blk_mq_all_tag_busy_iter staticSagi Grimberg2016-04-122-5/+2
| | | | | | | | | | | | | | | | | | | | No caller outside the blk-mq code so we can settle with it static. Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Jens Axboe <axboe@fb.com>
* | mtip32xx: Convert to use blk_mq_tagset_busy_iterKeith Busch2016-04-121-3/+3
| | | | | | | | | | | | | | | | | | | | Only a single tags array anyway. Signed-off-by: Keith Busch <keith.busch@intel.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com>
* | nvme: Use blk-mq helper for IO terminationSagi Grimberg2016-04-121-14/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | blk-mq offers a tagset iterator so let's use that instead of using nvme_clear_queues. Note, we changed nvme_queue_cancel_ios name to nvme_cancel_io as there is no concept of a queue now in this function (we also lost the print). Signed-off-by: Sagi Grimberg <sagig@mellanox.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Keith Busch <keith.busch@intel.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Jens Axboe <axboe@fb.com>
* | NVMe: Skip async events for degraded controllersKeith Busch2016-04-121-2/+10
| | | | | | | | | | | | | | | | | | | | | | If the controller is degraded, the driver should stay out of the way so the user can recover the drive. This patch skips driver initiated async event requests when the drive is in this state. Signed-off-by: Keith Busch <keith.busch@intel.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com>
* | nvme: add helper nvme_setup_cmd()Ming Lin2016-04-123-97/+108
| | | | | | | | | | | | | | | | | | | | | | This moves nvme_setup_{flush,discard,rw} calls into a common nvme_setup_cmd() helper. So we can eventually hide all the command setup in the core module and don't even need to update the fabrics drivers for any specific command type. Signed-off-by: Ming Lin <ming.l@ssi.samsung.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com>
* | nvme: rewrite discard supportMing Lin2016-04-121-29/+39
| | | | | | | | | | | | | | | | | | This rewrites nvme_setup_discard() with blk_add_request_payload(). It allocates only the necessary amount(16 bytes) for the payload. Signed-off-by: Ming Lin <ming.l@ssi.samsung.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com>
* | nvme: add helper nvme_map_len()Ming Lin2016-04-122-8/+13
| | | | | | | | | | | | | | | | | | The helper returns the number of bytes that need to be mapped using PRPs/SGL entries. Signed-off-by: Ming Lin <ming.l@ssi.samsung.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com>
* | nvme: add missing lock nesting notationMing Lin2016-04-121-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When unloading driver, nvme_disable_io_queues() calls nvme_delete_queue() that sends nvme_admin_delete_cq command to admin sq. So when the command completed, the lock acquired by nvme_irq() actually belongs to admin queue. While the lock that nvme_del_cq_end() trying to acquire belongs to io queue. So it will not deadlock. This patch adds lock nesting notation to fix following report. [ 109.840952] ============================================= [ 109.846379] [ INFO: possible recursive locking detected ] [ 109.851806] 4.5.0+ #180 Tainted: G E [ 109.856533] --------------------------------------------- [ 109.861958] swapper/0/0 is trying to acquire lock: [ 109.866771] (&(&nvmeq->q_lock)->rlock){-.....}, at: [<ffffffffc0820bc6>] nvme_del_cq_end+0x26/0x70 [nvme] [ 109.876535] [ 109.876535] but task is already holding lock: [ 109.882398] (&(&nvmeq->q_lock)->rlock){-.....}, at: [<ffffffffc0820c2b>] nvme_irq+0x1b/0x50 [nvme] [ 109.891547] [ 109.891547] other info that might help us debug this: [ 109.898107] Possible unsafe locking scenario: [ 109.898107] [ 109.904056] CPU0 [ 109.906515] ---- [ 109.908974] lock(&(&nvmeq->q_lock)->rlock); [ 109.913381] lock(&(&nvmeq->q_lock)->rlock); [ 109.917787] [ 109.917787] *** DEADLOCK *** [ 109.917787] [ 109.923738] May be due to missing lock nesting notation [ 109.923738] [ 109.930558] 1 lock held by swapper/0/0: [ 109.934413] #0: (&(&nvmeq->q_lock)->rlock){-.....}, at: [<ffffffffc0820c2b>] nvme_irq+0x1b/0x50 [nvme] [ 109.944010] [ 109.944010] stack backtrace: [ 109.948389] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G E 4.5.0+ #180 [ 109.955734] Hardware name: Dell Inc. OptiPlex 7010/0YXT71, BIOS A15 08/12/2013 [ 109.962989] 0000000000000000 ffff88011e203c38 ffffffff81383d9c ffffffff81c13540 [ 109.970478] ffffffff826711d0 ffff88011e203ce8 ffffffff810bb429 0000000000000046 [ 109.977964] 0000000000000046 0000000000000000 0000000000b2e597 ffffffff81f4cb00 [ 109.985453] Call Trace: [ 109.987911] <IRQ> [<ffffffff81383d9c>] dump_stack+0x85/0xc9 [ 109.993711] [<ffffffff810bb429>] __lock_acquire+0x19b9/0x1c60 [ 109.999575] [<ffffffff810b6d1d>] ? trace_hardirqs_off+0xd/0x10 [ 110.005524] [<ffffffff810b386d>] ? complete+0x3d/0x50 [ 110.010688] [<ffffffff810bb760>] lock_acquire+0x90/0xf0 [ 110.016029] [<ffffffffc0820bc6>] ? nvme_del_cq_end+0x26/0x70 [nvme] [ 110.022418] [<ffffffff81772afb>] _raw_spin_lock_irqsave+0x4b/0x60 [ 110.028632] [<ffffffffc0820bc6>] ? nvme_del_cq_end+0x26/0x70 [nvme] [ 110.035019] [<ffffffffc0820bc6>] nvme_del_cq_end+0x26/0x70 [nvme] [ 110.041232] [<ffffffff8135b485>] blk_mq_end_request+0x35/0x60 [ 110.047095] [<ffffffffc0821ad8>] nvme_complete_rq+0x68/0x190 [nvme] [ 110.053481] [<ffffffff8135b53f>] __blk_mq_complete_request+0x8f/0x130 [ 110.060043] [<ffffffff8135b611>] blk_mq_complete_request+0x31/0x40 [ 110.066343] [<ffffffffc08209e3>] __nvme_process_cq+0x83/0x240 [nvme] [ 110.072818] [<ffffffffc0820c35>] nvme_irq+0x25/0x50 [nvme] [ 110.078419] [<ffffffff810cdb66>] handle_irq_event_percpu+0x36/0x110 [ 110.084804] [<ffffffff810cdc77>] handle_irq_event+0x37/0x60 [ 110.090491] [<ffffffff810d0ea3>] handle_edge_irq+0x93/0x150 [ 110.096180] [<ffffffff81012306>] handle_irq+0xa6/0x130 [ 110.101431] [<ffffffff81011abe>] do_IRQ+0x5e/0x120 [ 110.106333] [<ffffffff8177384c>] common_interrupt+0x8c/0x8c Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Ming Lin <ming.l@ssi.samsung.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Jens Axboe <axboe@fb.com>
* | NVMe: Always use MSI/MSI-x interruptsKeith Busch2016-04-121-10/+15
|/ | | | | | | | | | | | | | | | | | | | | Multiple users have reported device initialization failure due the driver not receiving legacy PCI interrupts. This is not unique to any particular controller, but has been observed on multiple platforms. There have been no issues reported or observed when with message signaled interrupts, so this patch attempts to use MSI-x during initialization, falling back to MSI. If that fails, legacy would become the default. The setup_io_queues error handling had to change as a result: the admin queue's msix_entry used to be initialized to the legacy IRQ. The case where nr_io_queues is 0 would fail request_irq when setting up the admin queue's interrupt since re-enabling MSI-x fails with 0 vectors, leaving the admin queue's msix_entry invalid. Instead, return success immediately. Reported-by: Tim Muhlemmer <muhlemmer@gmail.com> Reported-by: Jon Derrick <jonathan.derrick@intel.com> Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Jens Axboe <axboe@fb.com>
* blk-mq: Export tagset iter functionSagi Grimberg2016-04-122-0/+14
| | | | | | | | | | | Its useful to iterate on all the active tags in cases where we will need to fail all the queues IO. Signed-off-by: Sagi Grimberg <sagig@mellanox.com> [hch: carefully check for valid tagsets] Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Jens Axboe <axboe@fb.com>
* block: add offset in blk_add_request_payload()Ming Lin2016-04-124-5/+6
| | | | | | | | We could kmalloc() the payload, so need the offset in page. Signed-off-by: Ming Lin <ming.l@ssi.samsung.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com>
* writeback: Fix performance regression in wb_over_bg_thresh()Howard Cochran2016-04-121-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 947e9762a8dd ("writeback: update wb_over_bg_thresh() to use wb_domain aware operations") unintentionally changed this function's meaning from "are there more dirty pages than the background writeback threshold" to "are there more dirty pages than the writeback threshold". The background writeback threshold is typically half of the writeback threshold, so this had the effect of raising the number of dirty pages required to cause a writeback worker to perform background writeout. This can cause a very severe performance regression when a BDI uses BDI_CAP_STRICTLIMIT because balance_dirty_pages() and the writeback worker can now disagree on whether writeback should be initiated. For example, in a system having 1GB of RAM, a single spinning disk, and a "pass-through" FUSE filesystem mounted over the disk, application code mmapped a 128MB file on the disk and was randomly dirtying pages in that mapping. Because FUSE uses strictlimit and has a default max_ratio of only 1%, in balance_dirty_pages, thresh is ~200, bg_thresh is ~100, and the dirty_freerun_ceiling is the average of those, ~150. So, it pauses the dirtying processes when we have 151 dirty pages and wakes up a background writeback worker. But the worker tests the wrong threshold (200 instead of 100), so it does not initiate writeback and just returns. Thus, balance_dirty_pages keeps looping, sleeping and then waking up the worker who will do nothing. It remains stuck in this state until the few dirty pages that we have finally expire and we write them back for that reason. Then the whole process repeats, resulting in near-zero throughput through the FUSE BDI. The fix is to call the parameterized variant of wb_calc_thresh, so that the worker will do writeback if the bg_thresh is exceeded which was the bahavior before the referenced commit. Fixes: 947e9762a8dd ("writeback: update wb_over_bg_thresh() to use wb_domain aware operations") Signed-off-by: Howard Cochran <hcochran@kernelspring.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@fb.com>
* Linux 4.6-rc3v4.6-rc3Linus Torvalds2016-04-101-1/+1
|
* Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-armLinus Torvalds2016-04-105-7/+13
|\ | | | | | | | | | | | | | | | | | | | | Pull ARM fixes from Russell King: "A couple of small fixes, and wiring up the new syscalls which appeared during the merge window" * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: ARM: 8550/1: protect idiv patching against undefined gcc behavior ARM: wire up preadv2 and pwritev2 syscalls ARM: SMP enable of cache maintanence broadcast
| * ARM: 8550/1: protect idiv patching against undefined gcc behaviorNicolas Pitre2016-04-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was reported that a kernel with CONFIG_ARM_PATCH_IDIV=y stopped booting when compiled with the upcoming gcc 6. Turns out that turning a function address into a writable array is undefined and gcc 6 decided it was OK to omit the store to the first word of the function while still preserving the store to the second word. Even though gcc 6 is now fixed to behave more coherently, it is a mystery that gcc 4 and gcc 5 actually produce wanted code in the kernel. And in fact the reduced test case to illustrate the issue does indeed break with gcc < 6 as well. In any case, let's guard the kernel against undefined compiler behavior by hiding the nature of the array location as suggested by gcc developers. Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70128 Signed-off-by: Nicolas Pitre <nico@linaro.org> Reported-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: stable@vger.kernel.org # v4.5 Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * ARM: wire up preadv2 and pwritev2 syscallsRussell King2016-04-073-2/+6
| | | | | | | | | | | | Wire up the preadv2 and pwritev2 syscalls for ARM. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * ARM: SMP enable of cache maintanence broadcastRussell King2016-04-011-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Masahiro Yamada reports that we can fail to set the FW bit in the auxiliary control register, which enables broadcasting the cache maintanence operations. This occurs because we only check that the SMP/nAMP bit is set, rather than checking whether all the bits we want to be set are set. Rearrange the code to ensure that all desired bits are set, and only update the register if we discover some required bits are not set. Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* | Merge tag 'mmc-v4.6-rc1' of git://git.linaro.org/people/ulf.hansson/mmcLinus Torvalds2016-04-105-9/+84
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull MMC fixes from Ulf Hansson: "Here are a couple of mmc fixes intended for v4.6 rc3: MMC host: - sdhci: Fix regression setting power on Trats2 board - sdhci-pci: Add support and PCI IDs for more Broxton host controllers" * tag 'mmc-v4.6-rc1' of git://git.linaro.org/people/ulf.hansson/mmc: mmc: sdhci-pci: Add support and PCI IDs for more Broxton host controllers mmc: sdhci: Fix regression setting power on Trats2 board
| * | mmc: sdhci-pci: Add support and PCI IDs for more Broxton host controllersAdrian Hunter2016-04-052-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support and PCI IDs for more Broxton host controllers Other BXT IDs were added in v4.4 so cc'ing stable. This patch is dependent on commit 163cbe31e516 ("mmc: sdhci-pci: Fix card detect race for Intel BXT/APL") but that is already in stable since v4.4.4. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v4.4+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
| * | mmc: sdhci: Fix regression setting power on Trats2 boardAdrian Hunter2016-03-293-9/+56
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several commits relating to setting power have been introducing problems by putting driver-specific rules into generic SDHCI code. Krzysztof Kozlowski reported that after commit 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via external regulator") on Trats2 board there are warnings for invalid VDD value (2.8V): [ 3.119656] ------------[ cut here ]------------ [ 3.119666] WARNING: CPU: 3 PID: 90 at ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0 [ 3.119669] mmc0: Invalid vdd 0x10 [ 3.119673] Modules linked in: [ 3.119679] CPU: 3 PID: 90 Comm: kworker/3:1 Tainted: G W 4.5.0-next-20160324 #23 [ 3.119681] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 3.119690] Workqueue: events_freezable mmc_rescan [ 3.119708] [<c010e0ac>] (unwind_backtrace) from [<c010ae10>] (show_stack+0x10/0x14) [ 3.119719] [<c010ae10>] (show_stack) from [<c0323260>] (dump_stack+0x88/0x9c) [ 3.119728] [<c0323260>] (dump_stack) from [<c011b754>] (__warn+0xe8/0x100) [ 3.119734] [<c011b754>] (__warn) from [<c011b7a4>] (warn_slowpath_fmt+0x38/0x48) [ 3.119740] [<c011b7a4>] (warn_slowpath_fmt) from [<c0527d28>] (sdhci_do_set_ios+0x4cc/0x5e0) [ 3.119748] [<c0527d28>] (sdhci_do_set_ios) from [<c0528018>] (sdhci_runtime_resume_host+0x60/0x114) [ 3.119758] [<c0528018>] (sdhci_runtime_resume_host) from [<c0402570>] (__rpm_callback+0x2c/0x60) [ 3.119767] [<c0402570>] (__rpm_callback) from [<c04025c4>] (rpm_callback+0x20/0x80) [ 3.119773] [<c04025c4>] (rpm_callback) from [<c04034b8>] (rpm_resume+0x36c/0x558) [ 3.119780] [<c04034b8>] (rpm_resume) from [<c04036f0>] (__pm_runtime_resume+0x4c/0x64) [ 3.119788] [<c04036f0>] (__pm_runtime_resume) from [<c0512728>] (__mmc_claim_host+0x170/0x1b0) [ 3.119795] [<c0512728>] (__mmc_claim_host) from [<c0514e2c>] (mmc_rescan+0x54/0x348) [ 3.119807] [<c0514e2c>] (mmc_rescan) from [<c0130dac>] (process_one_work+0x120/0x3f4) [ 3.119815] [<c0130dac>] (process_one_work) from [<c01310b8>] (worker_thread+0x38/0x554) [ 3.119823] [<c01310b8>] (worker_thread) from [<c01365a4>] (kthread+0xdc/0xf4) [ 3.119831] [<c01365a4>] (kthread) from [<c0107878>] (ret_from_fork+0x14/0x3c) [ 3.119834] ---[ end trace a22d652aa3276886 ]--- Fix by adding a 'set_power' callback and restoring the default behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via external regulator"). The desired behaviour of that commit is gotten by having sdhci-pxav3 provide its own set_power callback. Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Link: http://lkml.kernel.org/r/CAJKOXPcGDnPm-Ykh6wHqV1YxfTaov5E8iVqBoBn4OJc7BnhgEQ@mail.gmail.com Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...) Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v4.5+ Reviewed-by: Jisheng Zhang <jszhang@marvell.com> Tested-by: Jisheng Zhang <jszhang@marvell.com> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Tested-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* | Merge branch 'i2c/for-current' of ↵Linus Torvalds2016-04-104-36/+49
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Some bugfixes from I2C: - fix a uevent triggered boot problem by removing a useless debug print - fix sysfs-attributes of the new i2c-demux-pinctrl driver to follow standard kernel behaviour - fix a potential division-by-zero error (needed two takes)" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: jz4780: really prevent potential division by zero Revert "i2c: jz4780: prevent potential division by zero" i2c: jz4780: prevent potential division by zero i2c: mux: demux-pinctrl: Update docs to new sysfs-attributes i2c: mux: demux-pinctrl: Clean up sysfs attributes i2c: prevent endless uevent loop with CONFIG_I2C_DEBUG_CORE
| * | i2c: jz4780: really prevent potential division by zeroWolfram Sang2016-04-091-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | Make sure we avoid a division-by-zero OOPS in case clock-frequency is set too low in DT. Add missing '\n' while we are here. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Axel Lin <axel.lin@ingics.com>
| * | Revert "i2c: jz4780: prevent potential division by zero"Wolfram Sang2016-04-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 34cf2acdafaa31a13821e45de5ee896adcd307b1. 'ret' is not set when bailing out. Also, there is a better place to check for 0. Reported-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | i2c: jz4780: prevent potential division by zeroWolfram Sang2016-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | Make sure we don't OOPS in case clock-frequency is set to 0 in a DT. The variable set here is later used as a divisor. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | i2c: mux: demux-pinctrl: Update docs to new sysfs-attributesWolfram Sang2016-04-071-17/+12
| | | | | | | | | | | | | | | | | | | | | | | | Update the docs according to the recent code changes, too. Fixes: c0c508a418f9da ("i2c: mux: demux-pinctrl: Clean up sysfs attributes") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | i2c: mux: demux-pinctrl: Clean up sysfs attributesBen Hutchings2016-04-011-10/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sysfs attributes should use the same format for reads and writes, rather than pretty-printing on read. * Make the "cur_master" attribute read back as just the name of the master * Expose the list of all masters as a read-only "available_masters" attribute, using space separators as in similar attributes of other devices Also, spell out "cur_master" in full as "current_master". Fixes: 50a5ba876908 ("i2c: mux: demux-pinctrl: add driver") Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | i2c: prevent endless uevent loop with CONFIG_I2C_DEBUG_COREWolfram Sang2016-03-301-8/+2
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jan reported this: === After enabling CONFIG_I2C_DEBUG_CORE my system was broken (no network, console login not possible). System log was flooded with the this message: ... [ 608.052077] rtc-ds1307 0-0068: uevent [ 608.052500] rtc-ds1307 0-0068: uevent [ 608.052925] rtc-ds1307 0-0068: uevent ... The culprit is the dev_dbg printk in the i2c uevent handler. If this is activated (for instance by CONFIG_I2C_DEBUG_CORE) it results in an endless loop with systemd-journald. This happens if user-space scans the system log and reads the uevent file to get information about a newly created device, which seems fair use to me. Unfortunately reading the "uevent" file uses the same function that runs for creating the uevent for a new device, generating the next syslog entry. Ideally user-space would implement a recursion detection and after reading the same device file for the 1000th time call it a day, but nevertheless I think we should avoid this problem by removing the debug print completely or using another print variant. The same problem seems to be reported here: https://bugs.freedesktop.org/show_bug.cgi?id=76886 === His patch converted the message to pr_debug, but I think the debug can simply go. We have other means to see code paths these days. This enables us to clean up the function some more while we are here. Reported-by: Jan Glauber <jglauber@cavium.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Tested-by: Jan Glauber <jglauber@cavium.com>
* | Revert "ext4: allow readdir()'s of large empty directories to be interrupted"Linus Torvalds2016-04-102-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 1028b55bafb7611dda1d8fed2aeca16a436b7dff. It's broken: it makes ext4 return an error at an invalid point, causing the readdir wrappers to write the the position of the last successful directory entry into the position field, which means that the next readdir will now return that last successful entry _again_. You can only return fatal errors (that terminate the readdir directory walk) from within the filesystem readdir functions, the "normal" errors (that happen when the readdir buffer fills up, for example) happen in the iterorator where we know the position of the actual failing entry. I do have a very different patch that does the "signal_pending()" handling inside the iterator function where it is allowable, but while that one passes all the sanity checks, I screwed up something like four times while emailing it out, so I'm not going to commit it today. So my track record is not good enough, and the stars will have to align better before that one gets committed. And it would be good to get some review too, of course, since celestial alignments are always an iffy debugging model. IOW, let's just revert the commit that caused the problem for now. Reported-by: Greg Thelen <gthelen@google.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge branch 'parisc-4.6-3' of ↵Linus Torvalds2016-04-097-11/+29
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fixes from Helge Deller: "Since commit 0de798584bde ("parisc: Use generic extable search and sort routines") module loading is boken on parisc, because the parisc module loader wasn't prepared for the new R_PARISC_PCREL32 relocations. In addition, due to that breakage, Mikulas Patocka noticed that handling exceptions from modules probably never worked on parisc. It was just masked by the fact that exceptions from modules don't happen during normal use. This patch series fixes those issues and survives the tests of the lib/test_user_copy kernel module test. Some patches are tagged for stable" * 'parisc-4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Update comment regarding relative extable support parisc: Unbreak handling exceptions from kernel modules parisc: Fix kernel crash with reversed copy_from_user() parisc: Avoid function pointers for kernel exception routines parisc: Handle R_PARISC_PCREL32 relocations in kernel modules
| * | parisc: Update comment regarding relative extable supportHelge Deller2016-04-081-6/+4
| | | | | | | | | | | | | | | | | | | | | Update the comment to reflect the changes of commit 0de7985 (parisc: Use generic extable search and sort routines). Signed-off-by: Helge Deller <deller@gmx.de>
| * | parisc: Unbreak handling exceptions from kernel modulesHelge Deller2016-04-084-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Handling exceptions from modules never worked on parisc. It was just masked by the fact that exceptions from modules don't happen during normal use. When a module triggers an exception in get_user() we need to load the main kernel dp value before accessing the exception_data structure, and afterwards restore the original dp value of the module on exit. Noticed-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org
| * | parisc: Fix kernel crash with reversed copy_from_user()Helge Deller2016-04-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel module testcase (lib/test_user_copy.c) exhibited a kernel crash on parisc if the parameters for copy_from_user were reversed ("illegal reversed copy_to_user" testcase). Fix this potential crash by checking the fault handler if the faulting address is in the exception table. Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org Cc: Kees Cook <keescook@chromium.org>
| * | parisc: Avoid function pointers for kernel exception routinesHelge Deller2016-04-081-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to avoid the kernel module loader to create function pointers for the kernel fixup routines of get_user() and put_user(). Changing the external reference from function type to int type fixes this. This unbreaks exception handling for get_user() and put_user() when called from a kernel module. Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org
| * | parisc: Handle R_PARISC_PCREL32 relocations in kernel modulesHelge Deller2016-04-081-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 0de7985 (parisc: Use generic extable search and sort routines) changed the exception tables to use 32bit relative offsets. This patch now adds support to the kernel module loader to handle such R_PARISC_PCREL32 relocations for 32- and 64-bit modules. Signed-off-by: Helge Deller <deller@gmx.de>
* | | Merge branch 'libnvdimm-fixes' of ↵Linus Torvalds2016-04-095-32/+53
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull libnvdimm fixes from Dan Williams: "Three fixes, the first two are tagged for -stable: - The ndctl utility/library gained expanded unit tests illuminating a long standing bug in the libnvdimm SMART data retrieval implementation. It has been broken since its initial implementation, now fixed. - Another one line fix for the detection of stale info blocks. Without this change userspace can get into a situation where it is unable to reconfigure a namespace. - Fix the badblock initialization path in the presence of the new (in v4.6-rc1) section alignment workarounds. Without this change badblocks will be reported at the wrong offset. These have received a build success report from the kbuild robot and have appeared in -next with no reported issues" * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: libnvdimm, pfn: fix nvdimm_namespace_add_poison() vs section alignment libnvdimm, pfn: fix uuid validation libnvdimm: fix smart data retrieval
| * | | libnvdimm, pfn: fix nvdimm_namespace_add_poison() vs section alignmentDan Williams2016-04-073-30/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When section alignment padding is in effect we need to shift / truncate the range that is queried for poison by the 'start_pad' or 'end_trunc' reservations. It's easiest if we just pass in an adjusted resource range rather than deriving it from the passed in namespace. With the resource range resolution pushed out to the caller we can also push the namespace-to-region lookup to the caller and drop the implicit pmem-type assumption about the passed in namespace object. Cc: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * | | libnvdimm, pfn: fix uuid validationDan Williams2016-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we detect a namespace has a stale info block in the init path, we should overwrite with the latest configuration. In fact, we already return -ENODEV when the parent uuid is invalid, the same should be done for the 'self' uuid. Otherwise we can get into a condition where userspace is unable to reconfigure the pfn-device without directly / manually invalidating the info block. Cc: <stable@vger.kernel.org> Reported-by: Jeff Moyer <jmoyer@redhat.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * | | libnvdimm: fix smart data retrievalDan Williams2016-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It appears that smart data retrieval has been broken the since the initial implementation. Fix the payload size to be 128-bytes per the specification. Cc: <stable@vger.kernel.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
* | | | Merge tag 'gpio-v4.6-3' of ↵Linus Torvalds2016-04-093-45/+95
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "Here is a set of four GPIO fixes. The two fixes to the core are serious as they are regressing minor architectures. Core fixes: - Defer GPIO device setup until after gpiolib is initialized. It turns out that a few very tightly integrated GPIO platform drivers initialize so early (befor core_initcall()) so that the gpiolib isn't even initialized itself. That limits what the library can do, and we cannot reference uninitialized fields until later. Defer some of the initialization until right after the gpiolib is initialized in these (rare) cases. - As a consequence: do not use devm_* resources when allocating the states in the initial set-up of the gpiochip. Driver fixes: - In ACPI retrieveal: ignore GpioInt when looking for output GPIOs. - Fix legacy builds on the PXA without a backing pin controller. - Use correct datatype on pca953x register writes" * tag 'gpio-v4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: pca953x: Use correct u16 value for register word write gpiolib: Defer gpio device setup until after gpiolib initialization gpiolib: Do not use devm functions when registering gpio chip gpio: pxa: fix legacy non pinctrl aware builds gpio / ACPI: ignore GpioInt() GPIOs when requesting GPIO_OUT_*
| * | | | gpio: pca953x: Use correct u16 value for register word writeYong Li2016-04-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current implementation only uses the first byte in val, the second byte is always 0. Change it to use cpu_to_le16 to write the two bytes into the register Cc: stable@vger.kernel.org Signed-off-by: Yong Li <sdliyong@gmail.com> Reviewed-by: Phil Reid <preid@electromag.com.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
OpenPOWER on IntegriCloud