summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* iommu/amd: Allow NULL pointer parameter for domain_flush_complete()Joerg Roedel2016-07-131-1/+1
| | | | | | | If domain == NULL is passed to the function, it will queue a completion-wait command on all IOMMUs in the system. Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/amd: Set up data structures for flush queueJoerg Roedel2016-07-131-1/+39
| | | | | | | | The flush queue is the equivalent to defered-flushing in the Intel VT-d driver. This patch sets up the data structures needed for this. Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/amd: Remove align-parameter from __map_single()Joerg Roedel2016-07-131-10/+3
| | | | | | | This parameter is not required anymore because the iova-allocations are always aligned to its size. Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/amd: Remove other remains of old address allocatorJoerg Roedel2016-07-131-311/+5
| | | | | | | There are other remains in the code from the old allocatore. Remove them all. Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/amd: Make use of the generic IOVA allocatorJoerg Roedel2016-07-131-157/+26
| | | | | | | | Remove the old address allocation code and make use of the generic IOVA allocator that is also used by other dma-ops implementations. Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/amd: Remove special mapping code for dma_ops pathJoerg Roedel2016-07-131-93/+14
| | | | | | | | Use the iommu-api map/unmap functions instead. This will be required anyway when IOVA code is used for address allocation. Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/amd: Pass gfp-flags to iommu_map_page()Joerg Roedel2016-07-131-3/+4
| | | | | | | Make this function ready to be used in the DMA-API path. Reorder parameters a bit while at it. Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/amd: Implement apply_dm_region call-backJoerg Roedel2016-07-131-0/+15
| | | | | | It is used to reserve the dm-regions in the iova-tree. Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/amd: Create a list of reserved iova addressesJoerg Roedel2016-07-131-0/+69
| | | | | | | | | | Put the MSI-range, the HT-range and the MMIO ranges of PCI devices into that range, so that these addresses are not allocated for DMA. Copy this address list into every created dma_ops_domain. Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/amd: Allocate iova_domain for dma_ops_domainJoerg Roedel2016-07-131-1/+19
| | | | | | Use it later for allocating the IO virtual addresses. Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/amd: Select IOMMU_IOVA for AMD IOMMUJoerg Roedel2016-07-131-0/+1
| | | | | | | Include the generic IOVA code to make use of it in the AMD IOMMU driver too. Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu: Add apply_dm_region call-back to iommu-opsJoerg Roedel2016-07-132-0/+6
| | | | | | | | | | | This new call-back will be used by the iommu driver to do reserve the given dm_region in its iova space before the mapping is created. The call-back is temporary until the dma-ops implementation is part of the common iommu code. Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/amd: Init unity mappings only for dma_ops domainsJoerg Roedel2016-07-131-2/+4
| | | | | | | | | | | The default domain for a device might also be identity-mapped. In this case the kernel would crash when unity mappings are defined for the device. Fix that by making sure the domain is a dma_ops domain. Fixes: 0bb6e243d7fb ('iommu/amd: Support IOMMU_DOMAIN_DMA type allocation') Cc: stable@vger.kernel.org # v4.2+ Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/amd: Remove create_workqueueBhaktipriya Shridhar2016-06-211-1/+1
| | | | | | | | | | | | | | | alloc_workqueue replaces deprecated create_workqueue(). A dedicated workqueue has been used since the workitem (viz &fault->work), is involved in IO page-fault handling. WQ_MEM_RECLAIM has been set to guarantee forward progress under memory pressure, which is a requirement here. Since there are only a fixed number of work items, explicit concurrency limit is unnecessary. Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* iommu/amd: Set AMD iommu callbacks for platform bus driverWan Zongshun2016-06-151-0/+4
| | | | | | | | | | | | | | AMD has more drivers will use ACPI to platform bus driver later, all those devices need iommu support, for example: eMMC driver. For latest AMD eMMC controller, it will utilize sdhci-acpi.c driver, which will rely on platform bus to match device and driver, where we will set 'dev' of struct platform_device as map_sg parameter passing to iommu driver for DMA request, so the iommu-ops are needed on the platform bus. Signed-off-by: Wan Zongshun <Vincent.Wan@amd.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
* Linux 4.7-rc3v4.7-rc3Linus Torvalds2016-06-121-1/+1
|
* Merge branch 'for-rc' of ↵Linus Torvalds2016-06-122-8/+10
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux Pull thermal management fixes from Zhang Rui: - fix an ordering issue in cpu cooling that cooling device is registered before it's ready (freq_table being populated). (Lukasz Luba) - fix a missing comment update (Caesar Wang) * 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: thermal: add the note for set_trip_temp thermal: cpu_cooling: fix improper order during initialization
| * thermal: add the note for set_trip_tempCaesar Wang2016-06-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | Fixes commit 60f9ce3ada53 ("thermal: of-thermal: allow setting trip_temp on hardware") Signed-off-by: Caesar Wang <wxt@rock-chips.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: linux-pm@vger.kernel.org Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| * thermal: cpu_cooling: fix improper order during initializationLukasz Luba2016-06-011-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The freq_table array is not populated before calling thermal_of_cooling_register. The code which populates the freq table was introduced in commit f6859014. This should be done before registering new thermal cooling device. The log shows effects of this wrong decision. [ 2.172614] cpu cpu1: Failed to get voltage for frequency 1984518656000: -34 [ 2.220863] cpu cpu0: Failed to get voltage for frequency 1984524416000: -34 Cc: <stable@vger.kernel.org> # 3.19+ Fixes: f6859014c7e7 ("thermal: cpu_cooling: Store frequencies in descending order") Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Javi Merino <javi.merino@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
* | Merge branch 'for-linus' of git://git.kernel.dk/linux-blockLinus Torvalds2016-06-116-37/+59
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull block layer fixes from Jens Axboe: "A small collection of fixes for the current series. This contains: - Two fixes for xen-blkfront, from Bob Liu. - A bug fix for NVMe, releasing only the specific resources we requested. - Fix for a debugfs flags entry for nbd, from Josef. - Plug fix from Omar, fixing up a case of code being switched between two functions. - A missing bio_put() for the new discard callers of submit_bio_wait(), fixing a regression causing a leak of the bio. From Shaun. - Improve dirty limit calculation precision in the writeback code, fixing a case where setting a limit lower than 1% of memory would end up being zero. From Tejun" * 'for-linus' of git://git.kernel.dk/linux-block: NVMe: Only release requested regions xen-blkfront: fix resume issues after a migration xen-blkfront: don't call talk_to_blkback when already connected to blkback nbd: pass the nbd pointer for flags debugfs block: missing bio_put following submit_bio_wait blk-mq: really fix plug list flushing for nomerge queues writeback: use higher precision calculation in domain_dirty_limits()
| * | NVMe: Only release requested regionsJohannes Thumshirn2016-06-091-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | The NVMe driver only requests the PCIe device's memory regions but releases all possible regions (including eventual I/O regions). This leads to a stale warning entry in dmesg about freeing non existent resources. Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Jens Axboe <axboe@fb.com>
| * | Merge branch 'stable/for-jens-4.7' of ↵Jens Axboe2016-06-091-13/+22
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen into for-linus Konrad writes: Thishas two fixes for a guest migrating from host that has multi-queue to one without it (and vice-versa).
| | * | xen-blkfront: fix resume issues after a migrationBob Liu2016-06-081-12/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After a migrate to another host (which may not have multiqueue support), the number of rings (block hardware queues) may be changed and the ring info structure will also be reallocated. This patch fixes two related bugs: * call blk_mq_update_nr_hw_queues() to make blk-core know the number of hardware queues have been changed. * Don't store rinfo pointer to hctx->driver_data, because rinfo may be reallocated so use hctx->queue_num to get the rinfo structure instead. Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
| | * | xen-blkfront: don't call talk_to_blkback when already connected to blkbackBob Liu2016-06-081-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes blkfront may twice receive blkback_changed() notification (XenbusStateConnected) after migration, which will cause talk_to_blkback() to be called twice too and confuse xen-blkback. The flow is as follow: blkfront blkback blkfront_resume() > talk_to_blkback() > Set blkfront to XenbusStateInitialised front changed() > Connect() > Set blkback to XenbusStateConnected blkback_changed() > Skip talk_to_blkback() because frontstate == XenbusStateInitialised > blkfront_connect() > Set blkfront to XenbusStateConnected ----- And here we get another XenbusStateConnected notification leading to: ----- blkback_changed() > because now frontstate != XenbusStateInitialised talk_to_blkback() is also called again > blkfront state changed from XenbusStateConnected to XenbusStateInitialised (Which is not correct!) front_changed(): > Do nothing because blkback already in XenbusStateConnected Now blkback is in XenbusStateConnected but blkfront is still in XenbusStateInitialised - leading to no disks. Poking of the XenbusStateConnected state is allowed (to deal with block disk change) and has to be dealt with. The most likely cause of this bug are custom udev scripts hooking up the disks and then validating the size. Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
| * | | nbd: pass the nbd pointer for flags debugfsJosef Bacik2016-06-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were passing in &nbd for the private data in debugfs_create_file() for the flags entry. We expect it to just be nbd, fix this so we get proper output from this debugfs entry. Signed-off-by: Josef Bacik <jbacik@fb.com> Signed-off-by: Jens Axboe <axboe@fb.com>
| * | | block: missing bio_put following submit_bio_waitShaun Tancheff2016-06-071-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | submit_bio_wait() gives the caller an opportunity to examine struct bio and so expects the caller to issue the put_bio() This fixes a memory leak reported by a few people in 4.7-rc2 kmemleak report after 9082e87bfbf8 ("block: remove struct bio_batch") Signed-off-by: Shaun Tancheff <shaun.tancheff@seagate.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Larry Finger@lwfinger.net Tested-by: David Drysdale <drysdale@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com>
| * | | blk-mq: really fix plug list flushing for nomerge queuesOmar Sandoval2016-06-021-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 0809e3ac6231 ("block: fix plug list flushing for nomerge queues") updated blk_mq_make_request() to set request_count even when blk_queue_nomerges() returns true. However, blk_mq_make_request() only does limited plugging and doesn't use request_count; blk_sq_make_request() is the one that should have been fixed. Do that and get rid of the unnecessary work in the mq version. Fixes: 0809e3ac6231 ("block: fix plug list flushing for nomerge queues") Signed-off-by: Omar Sandoval <osandov@fb.com> Reviewed-by: Ming Lei <tom.leiming@gmail.com> Reviewed-by: Jeff Moyer <jmoyer@redhat.com> Signed-off-by: Jens Axboe <axboe@fb.com>
| * | | writeback: use higher precision calculation in domain_dirty_limits()Tejun Heo2016-05-301-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As vm.dirty_[background_]bytes can't be applied verbatim to multiple cgroup writeback domains, they get converted to percentages in domain_dirty_limits() and applied the same way as vm.dirty_[background]ratio. However, if the specified bytes is lower than 1% of available memory, the calculated ratios become zero and the writeback domain gets throttled constantly. Fix it by using per-PAGE_SIZE instead of percentage for ratio calculations. Also, the updated DIV_ROUND_UP() usages now should yield 1/4096 (0.0244%) as the minimum ratio as long as the specified bytes are above zero. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Miao Xie <miaoxie@huawei.com> Link: http://lkml.kernel.org/g/57333E75.3080309@huawei.com Cc: stable@vger.kernel.org # v4.2+ Fixes: 9fc3a43e1757 ("writeback: separate out domain_dirty_limits()") Reviewed-by: Jan Kara <jack@suse.cz> Adjusted comment based on Jan's suggestion. Signed-off-by: Jens Axboe <axboe@fb.com>
* | | | Merge tag 'gpio-v4.7-3' of ↵Linus Torvalds2016-06-116-7/+16
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "A new bunch of GPIO fixes for v4.7. This time I am very grateful that Ricardo Ribalda Delgado went in and fixed my stupid refcounting mistakes in the removal path for GPIO chips. I had a feeling something was wrong here and so it was. It exploded on OMAP and it fixes their problem. Now it should be (more) solid. The rest i compilation, Kconfig and driver fixes. Some tagged for stable. Summary: - Fix a NULL pointer dereference when we are searching the GPIO device list but one of the devices have been removed (struct gpio_chip pointer is NULL). - Fix unaligned reference counters: we were ending on +3 after all said and done. It should be 0. Remove an extraneous get_device(), and call cdev_del() followed by device_del() in gpiochip_remove() instead and the count goes to zero and calls the release() function properly. - Fix a compile warning due to a missing #include in the OF/device tree portions. - Select ANON_INODES for GPIOLIB, we're using that for our character device. Some randconfig tests disclosed the problem. - Make sure the Zynq driver clock runs also without CONFIG_PM enabled - Fix an off-by-one error in the 104-DIO-48E driver - Fix warnings in bcm_kona_gpio_reset()" * tag 'gpio-v4.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: bcm-kona: fix bcm_kona_gpio_reset() warnings gpio: select ANON_INODES gpio: include <linux/io-mapping.h> in gpiolib-of gpiolib: Fix unaligned used of reference counters gpiolib: Fix NULL pointer deference gpio: zynq: initialize clock even without CONFIG_PM gpio: 104-dio-48e: Fix control port offset computation off-by-one error
| * | | | gpio: bcm-kona: fix bcm_kona_gpio_reset() warningsBen Dooks2016-06-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bcm_kona_gpio_reset() calls bcm_kona_gpio_write_lock_regs() with what looks like the wrong parameter. The write_lock_regs function takes a pointer to the registers, not the bcm_kona_gpio structure. Fix the warning, and probably bug by changing the function to pass reg_base instead of kona_gpio, fixing the following warning: drivers/gpio/gpio-bcm-kona.c:550:47: warning: incorrect type in argument 1 (different address spaces) expected void [noderef] <asn:2>*reg_base got struct bcm_kona_gpio *kona_gpio warning: incorrect type in argument 1 (different address spaces) expected void [noderef] <asn:2>*reg_base got struct bcm_kona_gpio *kona_gpio Cc: stable@vger.kernel.org Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Ray Jui <ray.jui@broadcom.com> Reviewed-by: Markus Mayer <mmayer@broadcom.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | | gpio: select ANON_INODESLinus Walleij2016-06-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The build servers found that gpiolib is using ANON_INODES but has forgotten to select it. Fix this. Reported-by: kbuild test robot <fengguang.wu@intel.com> Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | | gpio: include <linux/io-mapping.h> in gpiolib-ofLinus Walleij2016-06-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When enabling the gpiolib for all archs a build robot came up with this: All errors (new ones prefixed by >>): drivers/gpio/gpiolib-of.c: In function 'of_mm_gpiochip_add_data': >> drivers/gpio/gpiolib-of.c:317:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration] iounmap(mm_gc->regs); ^~~~~~~ cc1: some warnings being treated as errors Fix this by including <linux/io-mapping.h> explicitly. Fixes: 296ad4acb8ef ("gpio: remove deps on ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB") Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | | gpiolib: Fix unaligned used of reference countersRicardo Ribalda Delgado2016-06-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gpiolib relies on the reference counters to clean up the gpio_device structure. Although the number of get/put is properly aligned on gpiolib.c itself, it does not take into consideration how the referece counters are affected by other external functions such as cdev_add and device_add. Because of this, after the last call to put_device, the reference counter has a value of +3, therefore never calling gpiodevice_release. Due to the fact that some of the device has already been cleaned on gpiochip_remove, the library will end up OOPsing the kernel (e.g. a call to of_gpiochip_find_and_xlate). Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | | gpiolib: Fix NULL pointer deferenceRicardo Ribalda Delgado2016-06-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under some circumstances, a gpiochip might be half cleaned from the gpio_device list. This patch makes sure that the chip pointer is still valid, before calling the match function. [ 104.088296] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 [ 104.089772] IP: [<ffffffff813d2045>] of_gpiochip_find_and_xlate+0x15/0x80 [ 104.128273] Call Trace: [ 104.129802] [<ffffffff813d2030>] ? of_parse_own_gpio+0x1f0/0x1f0 [ 104.131353] [<ffffffff813cd910>] gpiochip_find+0x60/0x90 [ 104.132868] [<ffffffff813d21ba>] of_get_named_gpiod_flags+0x9a/0x120 ... [ 104.141586] [<ffffffff8163d12b>] gpio_led_probe+0x11b/0x360 Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | | gpio: zynq: initialize clock even without CONFIG_PMHelmut Grohne2016-06-081-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the PM initialization was moved in the commit referenced below, the code enabling the clock was removed from the probe function. On CONFIG_PM=y kernels, this is not a problem as the pm resume hook enables the clock, but when power management is disabled, all those pm_* functions are noops and the clock is never enabled resulting in a dysfunctional gpio controller. Put the clock initialization back to support CONFIG_PM=n. Cc: stable@vger.kernel.org Signed-off-by: Helmut Grohne <h.grohne@intenta.de> Fixes: 3773c195d387 ("gpio: zynq: Do PM initialization earlier to support gpio hogs") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | | gpio: 104-dio-48e: Fix control port offset computation off-by-one errorWilliam Breathitt Gray2016-06-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are only two control ports, each controlling three distinct I/O ports. To compute the control port address offset for a respective I/O port, the I/O port address offset should be divided by 3; dividing by 2 may result in not only the wrong address offset but possibly also an out-of-bounds array memory access for a non-existent third control port. Fixes: 1b06d64f7374 ("gpio: Add GPIO support for the ACCES 104-DIO-48E") Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | | | | Merge tag 'scsi-fixes' of ↵Linus Torvalds2016-06-113-4/+10
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Two current fixes: - one affects Qemu CD ROM emulation, which stopped working after the updates in SCSI to require VPD pages from all conformant devices. Fix temporarily by blacklisting Qemu (we can relax later when they come into compliance). - The other is a fix to the optimal transfer size. We set up a minefield for ourselves by being confused about whether the limits are in bytes or sectors (SCSI optimal is in blocks and the queue parameter is in bytes). This tries to fix the problem (wrong setting for queue limits max_sectors) and make the problem more obvious by introducing a wrapper function" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: sd: Fix rw_max for devices that report an optimal xfer size scsi: Add QEMU CD-ROM to VPD Inquiry Blacklist
| * \ \ \ \ Merge remote-tracking branch 'mkp-scsi/4.7/scsi-fixes' into fixesJames Bottomley2016-06-043-4/+10
| |\ \ \ \ \ | | |_|/ / / | |/| | | |
| | * | | | sd: Fix rw_max for devices that report an optimal xfer sizeMartin K. Petersen2016-06-012-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For historic reasons, io_opt is in bytes and max_sectors in block layer sectors. This interface inconsistency is error prone and should be fixed. But for 4.4--4.7 let's make the unit difference explicit via a wrapper function. Fixes: d0eb20a863ba ("sd: Optimal I/O size is in bytes, not sectors") Cc: stable@vger.kernel.org # 4.4+ Reported-by: Fam Zheng <famz@redhat.com> Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Tested-by: Andrew Patterson <andrew.patterson@hpe.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| | * | | | scsi: Add QEMU CD-ROM to VPD Inquiry BlacklistEwan D. Milne2016-05-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux fails to boot as a guest with a QEMU CD-ROM: [ 4.439488] ata2.00: ATAPI: QEMU CD-ROM, 0.8.2, max UDMA/100 [ 4.443649] ata2.00: configured for MWDMA2 [ 4.450267] scsi 1:0:0:0: CD-ROM QEMU QEMU CD-ROM 0.8. PQ: 0 ANSI: 5 [ 4.464317] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 4.464319] ata2.00: BMDMA stat 0x5 [ 4.464339] ata2.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 0 dma 16640 in [ 4.464339] Inquiry 12 01 00 00 ff 00res 48/20:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation) [ 4.464341] ata2.00: status: { DRDY DRQ } [ 4.465864] ata2: soft resetting link [ 4.625971] ata2.00: configured for MWDMA2 [ 4.628290] ata2: EH complete [ 4.646670] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 4.646671] ata2.00: BMDMA stat 0x5 [ 4.646683] ata2.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 0 dma 16640 in [ 4.646683] Inquiry 12 01 00 00 ff 00res 48/20:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation) [ 4.646685] ata2.00: status: { DRDY DRQ } [ 4.648193] ata2: soft resetting link ... Fix this by suppressing VPD inquiry for this device. Signed-off-by: Ewan D. Milne <emilne@redhat.com> Reported-by: Jan Stancek <jstancek@redhat.com> Tested-by: Jan Stancek <jstancek@redhat.com> Cc: <stable@vger.kernel.org> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
* | | | | | Merge branch 'i2c/for-current' of ↵Linus Torvalds2016-06-118-21/+119
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: - a bigger fix for i801 to finally be able to be loaded on some machines again - smaller driver fixes - documentation update because of a renamed file * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: mux: reg: Provide of_match_table i2c: mux: refer to i2c-mux.txt i2c: octeon: Avoid printk after too long SMBUS message i2c: octeon: Missing AAK flag in case of I2C_M_RECV_LEN i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR
| * | | | | | i2c: mux: reg: Provide of_match_tableLukasz Gemborowski2016-06-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of_match_table was not filled which prevents device to be instantiated from device tree node. Signed-off-by: Lukasz Gemborowski <lukasz.gemborowski@nokia.com> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | | | | | i2c: mux: refer to i2c-mux.txtSimon Horman2016-06-095-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Correct references to i2c-mux.txt which was previously mux.txt. Also correct the spelling of relevant. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Acked-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | | | | | i2c: octeon: Avoid printk after too long SMBUS messageJan Glauber2016-06-091-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the warning about a too long SMBUS message because the ipmi_ssif driver triggers this warning too frequently so it spams the message log. Signed-off-by: Jan Glauber <jglauber@cavium.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | | | | | i2c: octeon: Missing AAK flag in case of I2C_M_RECV_LENJan Glauber2016-06-091-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During receive the controller requires the AAK flag for all bytes but the final one. This was wrong in case of I2C_M_RECV_LEN, where the decision if the final byte is to be transmitted happened before adding the additional received length byte. Set the AAK flag if additional bytes are to be received. Signed-off-by: Jan Glauber <jglauber@cavium.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | | | | | i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BARMika Westerberg2016-06-091-3/+96
| | |_|/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many Intel systems the BIOS declares a SystemIO OpRegion below the SMBus PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 900: Device (SBUS) { OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10) Field (SMBI, ByteAcc, NoLock, Preserve) { HSTS, 8, Offset (0x02), HCON, 8, HCOM, 8, TXSA, 8, DAT0, 8, DAT1, 8, HBDR, 8, PECR, 8, RXSA, 8, SDAT, 16 } There are also bunch of AML methods that that the BIOS can use to access these fields. Most of the systems in question AML methods accessing the SMBI OpRegion are never used. Now, because of this SMBI OpRegion many systems fail to load the SMBus driver with an error looking like one below: ACPI Warning: SystemIO range 0x0000000000003040-0x000000000000305F conflicts with OpRegion 0x0000000000003040-0x000000000000304F (\_SB.PCI0.SBUS.SMBI) (20160108/utaddress-255) ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver The reason is that this SMBI OpRegion conflicts with the PCI BAR used by the SMBus driver. It turns out that we can install a custom SystemIO address space handler for the SMBus device to intercept all accesses through that OpRegion. This allows us to share the PCI BAR with the AML code if it for some reason is using it. We do not expect that this OpRegion handler will ever be called but if it is we print a warning and prevent all access from the SMBus driver itself. Link: https://bugzilla.kernel.org/show_bug.cgi?id=110041 Reported-by: Andy Lutomirski <luto@kernel.org> Reported-by: Pali Rohár <pali.rohar@gmail.com> Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Pali Rohár <pali.rohar@gmail.com> Tested-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@vger.kernel.org
* | | | | | Merge tag 'devicetree-fixes-for-4.7' of ↵Linus Torvalds2016-06-119-24/+49
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull DeviceTree fixes from Rob Herring: - fix unflatten_dt_nodes when dad parameter is set. - add vendor prefixes for TechNexion and UniWest - documentation fix for Marvell BT - OF IRQ kerneldoc fixes - restrict CMA alignment adjustments to non dma-coherent - a couple of warning fixes in reserved-memory code - DT maintainers updates * tag 'devicetree-fixes-for-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: drivers: of: add definition of early_init_dt_alloc_reserved_memory_arch drivers/of: Fix depth for sub-tree blob in unflatten_dt_nodes() drivers: of: Fix of_pci.h header guard dt-bindings: Add vendor prefix for TechNexion of: add vendor prefix for UniWest dt: bindings: fix documentation for MARVELL's bt-sd8xxx wireless device of: add missing const for of_parse_phandle_with_args() in !CONFIG_OF of: silence warnings due to max() usage drivers: of: of_reserved_mem: fixup the CMA alignment not to affect dma-coherent of: irq: fix of_irq_get[_byname]() kernel-doc MAINTAINERS: DeviceTree maintainer updates
| * | | | | | drivers: of: add definition of early_init_dt_alloc_reserved_memory_archBen Dooks2016-06-091-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function early_init_dt_alloc_reserved_memory_arch is defined in drivers/of/of_reserved_mem.c but is not declared in any of the header files. Add the declaration of this to avoid the warning: drivers/of/of_reserved_mem.c:31:19: warning: symbol 'early_init_dt_alloc_reserved_memory_arch' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> [robh: drop extern from declaration] Signed-off-by: Rob Herring <robh@kernel.org>
| * | | | | | drivers/of: Fix depth for sub-tree blob in unflatten_dt_nodes()Gavin Shan2016-06-091-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function is unflattening device sub-tree blob if @dad passed to the function is valid. Currently, this functionality is used by PPC PowerNV PCI hotplug driver only. There are possibly multiple nodes in the first level of depth, fdt_next_node() bails immediately when @depth becomes negative before the second device node can be probed successfully. It leads to the device nodes except the first one won't be unflattened successfully. This fixes the issue by setting the initial depth (@inital_depth) to 1 when this function is called to unflatten device sub-tree blob. No logic changes when this function is used to unflatten non-sub-tree blob. Cc: Rhyland Klein <rklein@nvidia.com> Fixes: 78c44d910 ("drivers/of: Fix depth when unflattening devicetree") Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Tested-by: Rhyland Klein <rklein@nvidia.com> Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Rob Herring <robh@kernel.org>
| * | | | | | drivers: of: Fix of_pci.h header guardRobin Murphy2016-06-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The compilation of of_pci.c is governed by CONFIG_OF_PCI, but the corresponding declarations in of_pci.h are inconsistently guarded by CONFIG_OF, with the result that if CONFIG_PCI is disabled for an OF platform, the dangling external declarations are still active and the inline stub definitions not. So far this has managed to go unnoticed since it happens that the only references to these functions are from code which itself depends on CONFIG_PCI or CONFIG_OF_PCI. Fix this with the appropriate config guard so that any new callers outside PCI-specific code don't start unexpectedly breaking under certain configs. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Rob Herring <robh@kernel.org>
OpenPOWER on IntegriCloud