summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2016-01-04bnxt_en: Re-structure ring indexing and mapping.Michael Chan
In order to support dedicated or shared completion rings, the ring indexing and mapping are re-structured as below: 1. bp->grp_info[] array index is 1:1 with bp->bnapi[] array index and completion ring index. 2. rx rings 0 to n will be mapped to completion rings 0 to n. 3. If tx and rx rings share completion rings, then tx rings 0 to m will be mapped to completion rings 0 to m. 4. If tx and rx rings use dedicated completion rings, then tx rings 0 to m will be mapped to completion rings n + 1 to n + m. 5. Each tx or rx ring will use the corresponding completion ring index for doorbell mapping and MSIX mapping. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-04bnxt_en: Check for NULL rx or tx ring.Michael Chan
Each bnxt_napi structure may no longer be having both an rx ring and a tx ring. Check for a valid ring before using it. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-04bnxt_en: Separate bnxt_{rx|tx}_ring_info structs from bnxt_napi struct.Michael Chan
Currently, an rx and a tx ring are always paired with a completion ring. We want to restructure it so that it is possible to have a dedicated completion ring for tx or rx only. The bnxt hardware uses a completion ring for rx and tx events. The driver has to process the completion ring entries sequentially for the rx and tx events. Using a dedicated completion ring for rx only or tx only has these benefits: 1. A burst of rx packets can cause delay in processing tx events if the completion ring is shared. If tx queue is stopped by BQL, this can cause delay in re-starting the tx queue. 2. A completion ring is sized according to the rx and tx ring size rounded up to the nearest power of 2. When the completion ring is shared, it is sized by adding the rx and tx ring sizes and then rounded to the next power of 2, often with a lot of wasted space. 3. Using dedicated completion ring, we can adjust the tx and rx coalescing parameters independently for rx and tx. The first step is to separate the rx and tx ring structures from the bnxt_napi struct. In this patch, an rx ring and a tx ring will point to the same bnxt_napi struct to share the same completion ring. No change in ring assignment and mapping yet. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-04bnxt_en: Refactor bnxt_dbg_dump_states().Michael Chan
By adding 3 separate functions to dump the different ring states. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-04vfio/iommu_type1: make use of info.flagsPierre Morel
The flags entry is there to tell the user that some optional information is available. Since we report the iova_pgsizes signal it to the user by setting the flags to VFIO_IOMMU_INFO_PGSIZES. Signed-off-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-01-04Input: xpad - update Xbox One Force Feedback SupportPierre-Loup A. Griffais
There's apparently a serial number woven into both input and output packets; neglecting to specify a valid serial number causes the controller to ignore the rumble packets. The scale of the rumble was also apparently halved in the packets. The initialization packet had to be changed to allow force feedback to work. see https://github.com/paroj/xpad/issues/7 for details. Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2016-01-04Input: xpad - correctly handle concurrent LED and FF requestsPavel Rojtberg
Track the status of the irq_out URB to prevent submission iof new requests while current one is active. Failure to do so results in the "URB submitted while active" warning/stack trace. Store pending brightness and FF effect in the driver structure and replace it with the latest requests until the device is ready to process next request. Alternate serving LED vs FF requests to make sure one does not starve another. See [1] for discussion. Inspired by patch of Sarah Bessmer [2]. [1]: http://www.spinics.net/lists/linux-input/msg40708.html [2]: http://www.spinics.net/lists/linux-input/msg31450.html Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2016-01-04i2c: designware: Add support for AMD Seattle I2CSuravee Suthikulpanit
Add device HID AMDI0510 to match the I2C controlers on AMD Seattle platform Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-01-04i2c: imx: Remove unneeded commentsFabio Estevam
These multi-lines comments do not follow the standard kernel coding style. In fact, they are not useful comments, so get rid of them. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-01-04mtd: fix cmdlinepart parser, early naming for auto-filled MTDBrian Norris
Commit 807f16d4db95 ("mtd: core: set some defaults when dev.parent is set") attempted to provide some default settings for MTDs that (a) assign the parent device and (b) don't provide their own name or owner However, this isn't a perfect drop-in replacement for the boilerplate found in some drivers, because the MTD name is used by partition parsers like cmdlinepart, but the name isn't set until add_mtd_device(), after the parsing is completed. This means cmdlinepart sees a NULL name and therefore will not work properly. Fix this by moving the default name and owner assignment to be first in the MTD registration process. [Note: this does not fix all reported issues, particularly with NAND drivers. Will require an additional fix for drivers/mtd/nand/] Fixes: 807f16d4db95 ("mtd: core: set some defaults when dev.parent is set") Reported-by: Heiko Schocher <hs@denx.de> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Cc: Heiko Schocher <hs@denx.de> Cc: Frans Klaver <fransklaver@gmail.com>
2016-01-04Bluetooth: btmrvl: fix hung task warning dumpChin-Ran Lo
It's been observed that when bluetooth driver fails to activate the firmware, below hung task warning dump is displayed after 120 seconds. [ 36.461022] Bluetooth: vendor=0x2df, device=0x912e, class=255, fn=2 [ 56.512128] Bluetooth: FW failed to be active in time! [ 56.517264] Bluetooth: Downloading firmware failed! [ 240.252176] INFO: task kworker/3:2:129 blocked for more than 120 seconds. [ 240.258931] Not tainted 3.18.0 #254 [ 240.262972] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.270751] kworker/3:2 D ffffffc000205760 0 129 2 0x00000000 [ 240.277825] Workqueue: events request_firmware_work_func [ 240.283134] Call trace: [ 240.285581] [<ffffffc000205760>] __switch_to+0x80/0x8c [ 240.290693] [<ffffffc00088dae0>] __schedule+0x540/0x7b8 [ 240.295921] [<ffffffc00088ddd0>] schedule+0x78/0x84 [ 240.300764] [<ffffffc0006dfd48>] __mmc_claim_host+0xe8/0x1c8 [ 240.306395] [<ffffffc0006edd6c>] sdio_claim_host+0x74/0x84 [ 240.311840] [<ffffffbffc163d08>] 0xffffffbffc163d08 [ 240.316685] [<ffffffbffc165104>] 0xffffffbffc165104 [ 240.321524] [<ffffffbffc130cf8>] mwifiex_dnld_fw+0x98/0x110 [mwifiex] [ 240.327918] [<ffffffbffc12ee88>] mwifiex_remove_card+0x2c4/0x5fc [mwifiex] [ 240.334741] [<ffffffc000596780>] request_firmware_work_func+0x44/0x80 [ 240.341127] [<ffffffc00023b934>] process_one_work+0x2ec/0x50c [ 240.346831] [<ffffffc00023c6a0>] worker_thread+0x350/0x470 [ 240.352272] [<ffffffc0002419bc>] kthread+0xf0/0xfc [ 240.357019] 2 locks held by kworker/3:2/129: [ 240.361248] #0: ("events"){.+.+.+}, at: [<ffffffc00023b840>] process_one_work+0x1f8/0x50c [ 240.369562] #1: ((&fw_work->work)){+.+.+.}, at: [<ffffffc00023b840>] process_one_work+0x1f8/0x50c [ 240.378589] task PC stack pid father [ 240.384501] kworker/1:1 D ffffffc000205760 0 40 2 0x00000000 [ 240.391524] Workqueue: events mtk_atomic_work [ 240.395884] Call trace: [ 240.398317] [<ffffffc000205760>] __switch_to+0x80/0x8c [ 240.403448] [<ffffffc00027279c>] lock_acquire+0x128/0x164 [ 240.408821] kworker/3:2 D ffffffc000205760 0 129 2 0x00000000 [ 240.415867] Workqueue: events request_firmware_work_func [ 240.421138] Call trace: [ 240.423589] [<ffffffc000205760>] __switch_to+0x80/0x8c [ 240.428688] [<ffffffc00088dae0>] __schedule+0x540/0x7b8 [ 240.433886] [<ffffffc00088ddd0>] schedule+0x78/0x84 [ 240.438732] [<ffffffc0006dfd48>] __mmc_claim_host+0xe8/0x1c8 [ 240.444361] [<ffffffc0006edd6c>] sdio_claim_host+0x74/0x84 [ 240.449801] [<ffffffbffc163d08>] 0xffffffbffc163d08 [ 240.454649] [<ffffffbffc165104>] 0xffffffbffc165104 [ 240.459486] [<ffffffbffc130cf8>] mwifiex_dnld_fw+0x98/0x110 [mwifiex] [ 240.465882] [<ffffffbffc12ee88>] mwifiex_remove_card+0x2c4/0x5fc [mwifiex] [ 240.472705] [<ffffffc000596780>] request_firmware_work_func+0x44/0x80 [ 240.479090] [<ffffffc00023b934>] process_one_work+0x2ec/0x50c [ 240.484794] [<ffffffc00023c6a0>] worker_thread+0x350/0x470 [ 240.490231] [<ffffffc0002419bc>] kthread+0xf0/0xfc This patch adds missing sdio_release_host() call so that wlan driver thread can claim sdio host. Fixes: 4863e4cc31d647e1 ("Bluetooth: btmrvl: release sdio bus after firmware is up") Signed-off-by: Chin-Ran Lo <crlo@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2016-01-04Bluetooth: hci_bcm: new ACPI IDsHeikki Krogerus
These are used at least by Acer with BCM43241. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2016-01-04Bluetooth: hci_bcm: move all Broadcom ACPI IDs to BCM HCI driverHeikki Krogerus
The IDs should all be for Broadcom BCM43241 module, and hci_bcm is now the proper driver for them. This removes one of two different ways of handling PM with the module. Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2016-01-04drm/radeon: Drop unnecessary unsigned int < 0 checkThierry Reding
Unsigned integers can never be negative, so drop this check. Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-01-04xen/blkfront: Fix crash if backend doesn't follow the right states.Konrad Rzeszutek Wilk
We have split the setting up of all the resources in two steps: 1) talk_to_blkback - which figures out the num_ring_pages (from the default value of zero), sets up shadow and so 2) blkfront_connect - does the real part of filling out the internal structures. The problem is if we bypass the 1) step and go straight to 2) and call blkfront_setup_indirect where we use the macro BLK_RING_SIZE - which returns an negative value (because sz is zero - since num_ring_pages is zero - since it has never been set). We can fix this by making sure that we always have called talk_to_blkback before going to blkfront_connect. Or we could set in blkfront_probe info->nr_ring_pages = 1 to have a default value. But that looks odd - as we haven't actually negotiated any ring size. This patch changes XenbusStateConnected state to detect if we haven't done the initial handshake - and if so continue on as if were in XenbusStateInitWait state. We also roll the error recovery (freeing the structure) into talk_to_blkback error path - which is safe since that function is only called from blkback_changed. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen/blkback: Fix two memory leaks.Bob Liu
This patch fixs two memleaks: backtrace: [<ffffffff817ba5e8>] kmemleak_alloc+0x28/0x50 [<ffffffff81205e3b>] kmem_cache_alloc+0xbb/0x1d0 [<ffffffff81534028>] xen_blkbk_probe+0x58/0x230 [<ffffffff8146adb6>] xenbus_dev_probe+0x76/0x130 [<ffffffff81511716>] driver_probe_device+0x166/0x2c0 [<ffffffff815119bc>] __device_attach_driver+0xac/0xb0 [<ffffffff8150fa57>] bus_for_each_drv+0x67/0x90 [<ffffffff81511ab7>] __device_attach+0xc7/0x120 [<ffffffff81511b23>] device_initial_probe+0x13/0x20 [<ffffffff8151059a>] bus_probe_device+0x9a/0xb0 [<ffffffff8150f0a1>] device_add+0x3b1/0x5c0 [<ffffffff8150f47e>] device_register+0x1e/0x30 [<ffffffff8146a9e8>] xenbus_probe_node+0x158/0x170 [<ffffffff8146abaf>] xenbus_dev_changed+0x1af/0x1c0 [<ffffffff8146b1bb>] backend_changed+0x1b/0x20 [<ffffffff81468ca6>] xenwatch_thread+0xb6/0x160 unreferenced object 0xffff880007ba8ef8 (size 224): backtrace: [<ffffffff817ba5e8>] kmemleak_alloc+0x28/0x50 [<ffffffff81205c73>] __kmalloc+0xd3/0x1e0 [<ffffffff81534d87>] frontend_changed+0x2c7/0x580 [<ffffffff8146af12>] xenbus_otherend_changed+0xa2/0xb0 [<ffffffff8146b2c0>] frontend_changed+0x10/0x20 [<ffffffff81468ca6>] xenwatch_thread+0xb6/0x160 [<ffffffff810d3e97>] kthread+0xd7/0xf0 [<ffffffff817c4a9f>] ret_from_fork+0x3f/0x70 [<ffffffffffffffff>] 0xffffffffffffffff unreferenced object 0xffff8800048dcd38 (size 224): The first leak is caused by not put() the be->blkif reference which we had gotten in xen_blkif_alloc(), while the second is us not freeing blkif->rings in the right place. Signed-off-by: Bob Liu <bob.liu@oracle.com> Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen/blkback: make st_ statistics per ringBob Liu
Make st_* statistics per ring and the VBD sysfs would iterate over all the rings. Note: xenvbd_sysfs_delif() is called in xen_blkbk_remove() before all rings are torn down, so it's safe. Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- v2: Aligned the variables on the same column.
2016-01-04xen/blkfront: Handle non-indirect grant with 64KB pagesJulien Grall
The minimal size of request in the block framework is always PAGE_SIZE. It means that when 64KB guest is support, the request will at least be 64KB. Although, if the backend doesn't support indirect descriptor (such as QDISK in QEMU), a ring request is only able to accommodate 11 segments of 4KB (i.e 44KB). The current frontend is assuming that an I/O request will always fit in a ring request. This is not true any more when using 64KB page granularity and will therefore crash during boot. On ARM64, the ABI is completely neutral to the page granularity used by the domU. The guest has the choice between different page granularity supported by the processors (for instance on ARM64: 4KB, 16KB, 64KB). This can't be enforced by the hypervisor and therefore it's possible to run guests using different page granularity. So we can't mandate the block backend to support indirect descriptor when the frontend is using 64KB page granularity and have to fix it properly in the frontend. The solution exposed below is based on modifying directly the frontend guest rather than asking the block framework to support smaller size (i.e < PAGE_SIZE). This is because the change is the block framework are not trivial as everything seems to relying on a struct *page (see [1]). Although, it may be possible that someone succeed to do it in the future and we would therefore be able to use it. Given that a block request may not fit in a single ring request, a second request is introduced for the data that cannot fit in the first one. This means that the second ring request should never be used on Linux if the page size is smaller than 44KB. To achieve the support of the extra ring request, the block queue size is divided by two. Therefore, the ring will always contain enough space to accommodate 2 ring requests. While this will reduce the overall performance, it will make the implementation more contained. The way forward to get better performance is to implement in the backend either indirect descriptor or multiple grants ring. Note that the parameters blk_queue_max_* helpers haven't been updated. The block code will set the mimimum size supported and we may be able to support directly any change in the block framework that lower down the minimal size of a request. [1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg02200.html Signed-off-by: Julien Grall <julien.grall@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen-blkfront: Introduce blkif_ring_get_requestJulien Grall
The code to get a request is always the same. Therefore we can factorize it in a single function. Signed-off-by: Julien Grall <julien.grall@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen-blkback: clear PF_NOFREEZE for xen_blkif_schedule()Jiri Kosina
xen_blkif_schedule() kthread calls try_to_freeze() at the beginning of every attempt to purge the LRU. This operation can't ever succeed though, as the kthread hasn't marked itself as freezable. Before (hopefully eventually) kthread freezing gets converted to fileystem freezing, we'd rather mark xen_blkif_schedule() freezable (as it can generate I/O during suspend). Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen/blkback: Free resources if connect_ring failed.Konrad Rzeszutek Wilk
With the multi-queue support we could fail at setting up some of the rings and fail the connection. That meant that all resources tied to rings[0..n-1] (where n is the ring that failed to be setup). Eventually the frontend will switch to the states and we will call xen_blkif_disconnect. However we do not want to be at the mercy of the frontend deciding when to change states. This allows us to do the cleanup right away and freeing resources. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen/blocks: Return -EXX instead of -1Konrad Rzeszutek Wilk
Lets return sensible values instead of -1. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen/blkback: make pool of persistent grants and free pages per-queueBob Liu
Make pool of persistent grants and free pages per-queue/ring instead of per-device to get better scalability. Test was done based on null_blk driver: dom0: v4.2-rc8 16vcpus 10GB "modprobe null_blk" domu: v4.2-rc8 16vcpus 10GB [test] rw=read direct=1 ioengine=libaio bs=4k time_based runtime=30 filename=/dev/xvdb numjobs=16 iodepth=64 iodepth_batch=64 iodepth_batch_complete=64 group_reporting Results: iops1: After patch "xen/blkfront: make persistent grants per-queue". iops2: After this patch. Queues: 1 4 8 16 Iops orig(k): 810 1064 780 700 Iops1(k): 810 1230(~20%) 1024(~20%) 850(~20%) Iops2(k): 810 1410(~35%) 1354(~75%) 1440(~100%) With 4 queues after this commit we can get ~75% increase in IOPS, and performance won't drop if increasing queue numbers. Please find the respective chart in this link: https://www.dropbox.com/s/agrcy2pbzbsvmwv/iops.png?dl=0 Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen/blkback: get the number of hardware queues/rings from blkfrontBob Liu
Backend advertises "multi-queue-max-queues" to front, also get the negotiated number from "multi-queue-num-queues" written by blkfront. Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen/blkback: pseudo support for multi hardware queues/ringsKonrad Rzeszutek Wilk
Preparatory patch for multiple hardware queues (rings). The number of rings is unconditionally set to 1, larger number will be enabled in "xen/blkback: get the number of hardware queues/rings from blkfront". Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com> Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- v2: Align variables in the structures.
2016-01-04xen/blkback: separate ring information out of struct xen_blkifBob Liu
Split per ring information to an new structure "xen_blkif_ring", so that one vbd device can be associated with one or more rings/hardware queues. Introduce 'pers_gnts_lock' to protect the pool of persistent grants since we may have multi backend threads. This patch is a preparation for supporting multi hardware queues/rings. Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com> Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- v2: Align the variables in the structure.
2016-01-04xen/blkfront: correct setting for xen_blkif_max_ring_orderPeng Fan
According to this piece code: " pr_info("Invalid max_ring_order (%d), will use default max: %d.\n", xen_blkif_max_ring_order, XENBUS_MAX_RING_GRANT_ORDER); " if xen_blkif_max_ring_order is bigger that XENBUS_MAX_RING_GRANT_ORDER, need to set xen_blkif_max_ring_order using XENBUS_MAX_RING_GRANT_ORDER, but not 0. Signed-off-by: Peng Fan <van.freenix@gmail.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: "Roger Pau Monné" <roger.pau@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen/blkfront: make persistent grants pool per-queueBob Liu
Make persistent grants per-queue/ring instead of per-device, so that we can drop the 'dev_lock' and get better scalability. Test was done based on null_blk driver: dom0: v4.2-rc8 16vcpus 10GB "modprobe null_blk" domu: v4.2-rc8 16vcpus 10GB [test] rw=read direct=1 ioengine=libaio bs=4k time_based runtime=30 filename=/dev/xvdb numjobs=16 iodepth=64 iodepth_batch=64 iodepth_batch_complete=64 group_reporting Queues: 1 4 8 16 Iops orig(k): 810 1064 780 700 Iops patched(k): 810 1230(~20%) 1024(~20%) 850(~20%) Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen/blkfront: Remove duplicate setting of ->xbdev.Bob Liu
We do the same exact operations a bit earlier in the function. Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen/blkfront: Cleanup of comments, fix unaligned variables, and syntax errors.Konrad Rzeszutek Wilk
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen/blkfront: negotiate number of queues/rings to be used with backendBob Liu
The max number of hardware queues for xen/blkfront is set by parameter 'max_queues'(default 4), while it is also capped by the max value that the xen/blkback exposes through XenStore key 'multi-queue-max-queues'. The negotiated number is the smaller one and would be written back to xenstore as "multi-queue-num-queues", blkback needs to read this negotiated number. Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen/blkfront: split per device io_lockBob Liu
After patch "xen/blkfront: separate per ring information out of device info", per-ring data is protected by a per-device lock ('io_lock'). This is not a good way and will effect the scalability, so introduce a per-ring lock ('ring_lock'). The old 'io_lock' is renamed to 'dev_lock' which protects the ->grants list and ->persistent_gnts_c which are shared by all rings. Note that in 'blkfront_probe' the 'blkfront_info' is setup via kzalloc so setting ->persistent_gnts_c to zero is not needed. Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04xen/blkfront: pseudo support for multi hardware queues/ringsBob Liu
Preparatory patch for multiple hardware queues (rings). The number of rings is unconditionally set to 1, larger number will be enabled in patch "xen/blkfront: negotiate number of queues/rings to be used with backend" so as to make review easier. Note that blkfront_gather_backend_features does not call blkfront_setup_indirect anymore (as that needs to be done per ring). That means that in blkif_recover/blkif_connect we have to do it in a loop (bounded by nr_rings). Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04drm/dp/mst: fix in RAD element accessMykola Lysenko
This is needed to receive correct port number from RAD, so MSTB could be found Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2016-01-04drm/dp/mst: fix in MSTB RAD initializationMykola Lysenko
This fix is needed to support more then two branch displays, so RAD address consist at least of 2 elements Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2016-01-04drm/dp/mst: always send reply for UP requestMykola Lysenko
We should always send reply for UP request in order to make downstream device clean-up resources appropriately. Issue was that reply for UP request was sent only once. Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2016-01-04drm/dp/mst: process broadcast messages correctlyMykola Lysenko
In case broadcast message received in UP request, RAD cannot be used to identify message originator. Message should be parsed, originator should be found by GUID from parsed message. Also reply with broadcast in case broadcast message received (for now it is always broadcast) Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2016-01-04hwmon: (ibmaem) constify aem_rw_sensor_template and aem_ro_sensor_template ↵Julia Lawall
structures The aem_rw_sensor_template and aem_ro_sensor_template structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2016-01-04ARM: 8481/2: drivers: psci: replace psci firmware callsJens Wiklander
Switch to use a generic interface for issuing SMC/HVC based on ARM SMC Calling Convention. Removes now the now unused psci-call.S. Acked-by: Will Deacon <will.deacon@arm.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2016-01-04ARM: 8478/2: arm/arm64: add arm-smcccJens Wiklander
Adds helpers to do SMC and HVC based on ARM SMC Calling Convention. CONFIG_HAVE_ARM_SMCCC is enabled for architectures that may support the SMC or HVC instruction. It's the responsibility of the caller to know if the SMC instruction is supported by the platform. This patch doesn't provide an implementation of the declared functions. Later patches will bring in implementations and set CONFIG_HAVE_ARM_SMCCC for ARM and ARM64 respectively. Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2016-01-04drm: powerplay: use div64_s64 instead of do_divArnd Bergmann
The newly added code for Fiji creates a correct compiler warning about invalid use of the do_div macro: In file included from powerplay/hwmgr/ppatomctrl.c:31:0: drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppevvmath.h: In function 'fDivide': drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppevvmath.h:382:89: warning: comparison of distinct pointer types lacks a cast do_div(longlongX, longlongY); /*Q(32,32) divided by Q(16,16) = Q(16,16) Back to original format */ do_div() divides an unsigned 64-bit number by an unsigned 32-bit number. The code instead wants to divide two signed 64-bit numbers, which is done using the div64_s64 function. Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 770911a3cfbb ("drm/amd/powerplay: add/update headers for Fiji SMU and DPM") Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-01-04md: more open-coded offset_in_page()Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-01-04dm-bufio: virt_to_phys() doesn't change remainder modulo PAGE_SIZEAl Viro
... so virt_to_phys(p) & (PAGE_SIZE - 1) is a very odd way to spell offset_in_page(p). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-01-04drivers/mtd/maps/pcmciamtd.c: __iomem annotationsAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-01-04cciss: switch to memdup_user_nul()Al Viro
all we do to buffer is strncmp()... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-01-04switch wireless debugfs ->write() instances to memdup_user_nul()Al Viro
again, it only parses the contents of the copied buffer, so get_zeroed_page() might as well had been kmalloc(), which makes it open-coded memdup_user_nul() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-01-04convert a bunch of open-coded instances of memdup_user_nul()Al Viro
A _lot_ of ->write() instances were open-coding it; some are converted to memdup_user_nul(), a lot more remain... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-01-04Merge branch 'memdup_user_nul' into work.miscAl Viro
2016-01-04xen/blkfront: separate per ring information out of device infoBob Liu
Split per ring information to a new structure "blkfront_ring_info". A ring is the representation of a hardware queue, every vbd device can associate with one or more rings depending on how many hardware queues/rings to be used. This patch is a preparation for supporting real multi hardware queues/rings. We also add a backpointer to 'struct blkfront_info' (dev_info) which is not needed (we could use containers_of) but further patch ("xen/blkfront: pseudo support for multi hardware queues/rings") will make allocation of 'blkfront_ring_info' dynamic. Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com> Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-01-04Merge tag 'arm32-efi-for-v4.5' of ↵Russell King
git://git.linaro.org/people/ard.biesheuvel/linux-arm into devel-stable This implements UEFI kernel support for 32-bit ARM, based on the existing arm64 support and existing generic early ioremap support. It is based on commit f7d924894265 ("arm64/efi: refactor EFI init and runtime code for reuse by 32-bit ARM"), which was pulled from the arm64 repo [1] as branch 'aarch64/efi' [1] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git