- 29 Feb, 2016 40 commits
-
-
James Smart authored
BugLink: http://bugs.launchpad.net/bugs/1541592 Modularize, cleanup, add comments - for FDMI code in driver Note: I don't like the comments with leading # - but as we have a lot if present, I'm deferring to handle it in one big fix later. Signed-off-by:
Dick Kennedy <dick.kennedy@avagotech.com> Signed-off-by:
James Smart <james.smart@avagotech.com> Reviewed-by:
Hannes Reinicke <hare@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit 4258e98e) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
James Smart authored
BugLink: http://bugs.launchpad.net/bugs/1541592 Fix crash in fcp command completion path. Missed null check. Signed-off-by:
-
James Smart authored
BugLink: http://bugs.launchpad.net/bugs/1541592 Fix driver crash when module parameter lpfc_fcp_io_channel set to 16 Signed-off-by:
-
James Smart authored
BugLink: http://bugs.launchpad.net/bugs/1541592 Fix RegLogin failed error seen on Lancer FC during port bounce Fix the statemachine and ref counting. Signed-off-by:
-
James Smart authored
BugLink: http://bugs.launchpad.net/bugs/1541592 Fix the FLOGI discovery logic to comply with T11 standards We weren't properly setting fabric parameters, such as R_A_TOV and E_D_TOV, when we registered the vfi object in default configs and pt2pt configs. Revise to now pass service params with the values to the firmware and ensure they are reset on link bounce. Required reworking the call sequence in the discovery threads. Signed-off-by:
-
James Smart authored
BugLink: http://bugs.launchpad.net/bugs/1541592 Fix FCF Infinite loop in lpfc_sli4_fcf_rr_next_index_get. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1542296Signed-off-by:
-
Tim Gardner authored
Signed-off-by: -
dann frazier authored
On NUMA implementations of Cavium ThunderX, node1 memory addresses start with bit 40 set to 1, and therefore requires >= 41 bits of VA. A side effect of this is an increase from 3 to 4 page table levels. Note: The alternative way to increase VA bits w/o moving to 4 level page tables would be to adopt a larger page size. That would have a far more significant impact to memory usage, and is known to have issue with current Ubuntu userspace: https://lists.ubuntu.com/archives/ubuntu-devel/2014-December/038572.html http://bugs.launchpad.net/bugs/1520162Signed-off-by:
dann frazier <dann.frazier@canonical.com> Signed-off-by:
-
Uma Krishnan authored
Add support for future IBM Coherent Accelerator (CXL) device with ID of 0x0601. Signed-off-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Reviewed-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit 68adb7bf) Signed-off-by:
-
Brian Norris authored
Some developers really like to have -Werror enabled for their code, as it helps to ensure warning free code. Others don't want -Werror, as it (for example) can cause problems when newer (or older) compilers have different sets of warnings, or new warnings can appear just when turning up the warning level (e.g., make W=1 or W=2). Thus, it seems prudent to have the use of -Werror be configurable. It so happens that cxl is only built on PowerPC, and PowerPC already has a nice set of Kconfig options for this, under CONFIG_PPC_WERROR. So let's use that, and the world is a happy place again! (Note that PPC_WERROR defaults to =y, so the common case compile should still be enforcing -Werror.) Fixes: d3d73f4b ("cxl: Compile with -Werror") Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Brian Norris authored
GCC 4.6.3 does not support -Wno-unused-const-variable. Instead, use the kbuild infrastructure that checks if this options exists. Fixes: 2cd55c68 ("cxl: Fix build failure due to -Wunused-variable behaviour change") Suggested-by:
Michal Marek <mmarek@suse.com> Suggested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Manoj Kumar authored
This drop enables a future card with a device id of 0x0600 to be recognized by the cxlflash driver. As per the design, the Accelerator Function Unit (AFU) for this new IBM CXL Flash Adapter retains the same host interface as the previous generation. For the early prototypes of the new card, the driver with this change behaves exactly as the driver prior to this behaved with the earlier generation card. Therefore, no card specific programming has been added. These card specific changes can be staged in later if needed. Signed-off-by:
Manoj N. Kumar <manoj@linux.vnet.ibm.com> Acked-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by:
-
Manoj Kumar authored
If an async error interrupt is generated, and the error requires the FC link to be reset, it cannot be performed in the interrupt context. So a work element is scheduled to complete the link reset in a process context. If either an EEH event or an escalation occurs in between when the interrupt is generated and the scheduled work is started, the MMIO space may no longer be available. This will cause an oops in the worker thread. [ 606.806583] NIP kthread_data+0x28/0x40 [ 606.806633] LR wq_worker_sleeping+0x30/0x100 [ 606.806694] Call Trace: [ 606.806721] 0x50 (unreliable) [ 606.806796] wq_worker_sleeping+0x30/0x100 [ 606.806884] __schedule+0x69c/0x8a0 [ 606.806959] schedule+0x44/0xc0 [ 606.807034] do_exit+0x770/0xb90 [ 606.807109] die+0x300/0x460 [ 606.807185] bad_page_fault+0xd8/0x150 [ 606.807259] handle_page_fault+0x2c/0x30 [ 606.807338] wait_port_offline.constprop.12+0x60/0x130 [cxlflash] To prevent the problem space area from being unmapped, when there is pending work, a mapcount (using the kref mechanism) is held. The mapcount is released only when the work is completed. The last reference release is tied to the unmapping service. Signed-off-by:
-
Manoj Kumar authored
After a few iterations of resetting the card, either during EEH recovery, or a host_reset the following is seen in the logs. cxlflash 0008:00: cxlflash_queuecommand: could not get a free command At every reset of the card, the commands that are outstanding are being leaked. No effort is being made to reap these commands. A few more resets later, the above error message floods the logs and the card is rendered totally unusable as no free commands are available. Iterated through the 'cmd' queue and printed out the 'free' counter and found that on each reset certain commands were in-use and stayed in-use through subsequent resets. To resolve this issue, when the card is reset, reap all the commands that are active/outstanding. Signed-off-by:
-
Uma Krishnan authored
Having a date for the driver requires it to be updated quite often. Removing the date which is not necessary. Also made use of the existing symbol to print the driver name. Signed-off-by:
-
Vaibhav Jain authored
Presently when a user-space process issues CXL_IOCTL_START_WORK ioctl we store the pid of the current task_struct and use it to get pointer to the mm_struct of the process, while processing page or segment faults from the capi card. However this causes issues when the thread that had originally issued the start-work ioctl exits in which case the stored pid is no more valid and the cxl driver is unable to handle faults as the mm_struct corresponding to process is no more accessible. This patch fixes this issue by using the mm_struct of the next alive task in the thread group. This is done by iterating over all the tasks in the thread group starting from thread group leader and calling get_task_mm on each one of them. When a valid mm_struct is obtained the pid of the associated task is stored in the context replacing the exiting one for handling future faults. The patch introduces a new function named get_mem_context that checks if the current task pointed to by ctx->pid is dead? If yes it performs the steps described above. Also a new variable cxl_context.glpid is introduced which stores the pid of the thread group leader associated with the context owning task. Reported-by:
Frank Haverkamp <HAVERKAM@de.ibm.com> Suggested-by:
Ian Munsie <imunsie@au1.ibm.com> Signed-off-by:
Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Acked-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Reviewed-by:
-
Geliang Tang authored
IS_ERR_OR_NULL already contain an unlikely compiler flag. Drop it. Signed-off-by:
Geliang Tang <geliangtang@163.com> Acked-by:
-
Andrew Donnellan authored
When writing a value to config space, cxl_pcie_write_config() calls cxl_pcie_config_info() to obtain a mask and shift value, shifts the new value accordingly, then uses the mask to combine the shifted value with the existing value at the address as part of a read-modify-write pattern. Currently, we use a logical OR operator rather than a bitwise OR operator, which means any use of this function results in an incorrect value being written. Replace the logical OR operator with a bitwise OR operator so the value is written correctly. Reported-by:
-
Vaibhav Jain authored
An idr warning is reported when a context is release after the capi card is unbound from the cxl driver via sysfs. Below are the steps to reproduce: 1. Create multiple afu contexts in an user-space application using libcxl. 2. Unbind capi card from cxl using command of form echo <capi-card-pci-addr> > /sys/bus/pci/drivers/cxl-pci/unbind 3. Exit/kill the application owning afu contexts. After above steps a warning message is usually seen in the kernel logs of the form "idr_remove called for id=<context-id> which is not allocated." This is caused by the function cxl_release_afu which destroys the contexts_idr table. So when a context is release no entry for context pe is found in the contexts_idr table and idr code prints this warning. This patch fixes this issue by increasing & decreasing the ref-count on the afu device when a context is initialized or when its freed respectively. This prevents the afu from being released until all the afu contexts have been released. The patch introduces two new functions namely cxl_afu_get/put that manage the ref-count on the afu device. Also the patch removes code inside cxl_dev_context_init that increases ref on the afu device as its guaranteed to be alive during this function. Reported-by:
-
Tim Gardner authored
Ignore: yes Signed-off-by: -
Tim Gardner authored
Signed-off-by: -
Tim Gardner authored
Signed-off-by: -
K. Y. Srinivasan authored
For performance critical devices, we distribute the incoming channel interrupt load across available CPUs in the guest. Include Fibre channel devices in the set of devices for which we would distribute the interrupt load. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 879a650a) Signed-off-by:
-
Vitaly Kuznetsov authored
The return type of hvt_op_poll() is unsigned int and -EBADF is inappropriate, poll functions return POLL* statuses. Reported-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
-
Dexuan Cui authored
With the recent change af3ff643 (Drivers: hv: vmbus: Use uuid_le type consistently), we always get this warning: CC [M] drivers/input/serio/hyperv-keyboard.o drivers/input/serio/hyperv-keyboard.c:427:2: warning: missing braces around initializer [-Wmissing-braces] { HV_KBD_GUID, }, ^ drivers/input/serio/hyperv-keyboard.c:427:2: warning: (near initialization for .id_table[0].guid.b.) [-Wmissing-braces] The patch fixes the warning. Signed-off-by:
-
Andrey Smetanin authored
This struct is required for Hyper-V SynIC timers implementation inside KVM and for upcoming Hyper-V VMBus support by userspace(QEMU). So place it into Hyper-V UAPI header. Signed-off-by:
Andrey Smetanin <asmetanin@virtuozzo.com> CC: Gleb Natapov <gleb@kernel.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: "K. Y. Srinivasan" <kys@microsoft.com> CC: Haiyang Zhang <haiyangz@microsoft.com> CC: Vitaly Kuznetsov <vkuznets@redhat.com> CC: Roman Kagan <rkagan@virtuozzo.com> CC: Denis V. Lunev <den@openvz.org> CC: qemu-devel@nongnu.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit c71acc4c) Signed-off-by:
-
Andrey Smetanin authored
This struct is required for Hyper-V SynIC timers implementation inside KVM and for upcoming Hyper-V VMBus support by userspace(QEMU). So place it into Hyper-V UAPI header. Signed-off-by:
Roman Kagan <rkagan@virtuozzo.com> CC: Gleb Natapov <gleb@kernel.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: "K. Y. Srinivasan" <kys@microsoft.com> CC: Haiyang Zhang <haiyangz@microsoft.com> CC: Vitaly Kuznetsov <vkuznets@redhat.com> CC: Roman Kagan <rkagan@virtuozzo.com> CC: Denis V. Lunev <den@openvz.org> CC: qemu-devel@nongnu.org Signed-off-by:
-
Andrey Smetanin authored
This constant is required for Hyper-V SynIC timers MSR's support by userspace(QEMU). Signed-off-by:
-
Andrey Smetanin authored
enum hv_message_type inside struct hv_message, hv_post_message is not size portable. Replace enum by u32. Signed-off-by:
-
Vitaly Kuznetsov authored
Currently, there is only one user for hv_ringbuffer_read()/ hv_ringbuffer_peak() functions and the usage of these functions is: - insecure as we drop ring_lock between them, someone else (in theory only) can acquire it in between; - non-optimal as we do a number of things (acquire/release the above mentioned lock, calculate available space on the ring, ...) twice and this path is performance-critical. Remove hv_ringbuffer_peek() moving the logic from __vmbus_recvpacket() to hv_ringbuffer_read(). Signed-off-by:
-
Vitaly Kuznetsov authored
vmbus_recvpacket() and vmbus_recvpacket_raw() are almost identical but there are two discrepancies: 1) vmbus_recvpacket() doesn't propagate errors from hv_ringbuffer_read() which looks like it is not desired. 2) There is an error message printed in packetlen > bufferlen case in vmbus_recvpacket(). I'm removing it as it is usless for users to see such messages and /vmbus_recvpacket_raw() doesn't have it. Signed-off-by:
-
Vitaly Kuznetsov authored
hv_ringbuffer_peek() does the same as hv_ringbuffer_read() without advancing the read index. The only functional change this patch brings is moving hv_need_to_signal_on_read() call under the ring_lock but this function is just a couple of comparisons. Signed-off-by:
-
Vitaly Kuznetsov authored
smp_read_barrier_depends() does nothing on almost all arcitectures including x86 and having it in the beginning of hv_get_ringbuffer_availbytes() does not provide any guarantees anyway. Signed-off-by:
-
Vitaly Kuznetsov authored
Convert 6+-string comments repeating function names to normal kernel-style comments and fix a couple of other comment style issues. No textual or functional changes intended. Signed-off-by:
-
Vitaly Kuznetsov authored
The crash is observed when a service is being disabled host side while userspace daemon is connected to the device: [ 90.244859] general protection fault: 0000 [#1] SMP ... [ 90.800082] Call Trace: [ 90.800082] [<ffffffff81187008>] __fput+0xc8/0x1f0 [ 90.800082] [<ffffffff8118716e>] ____fput+0xe/0x10 ... [ 90.800082] [<ffffffff81015278>] do_signal+0x28/0x580 [ 90.800082] [<ffffffff81086656>] ? finish_task_switch+0xa6/0x180 [ 90.800082] [<ffffffff81443ebf>] ? __schedule+0x28f/0x870 [ 90.800082] [<ffffffffa01ebbaa>] ? hvt_op_read+0x12a/0x140 [hv_utils] ... The problem is that hvutil_transport_destroy() which does misc_deregister() freeing the appropriate device is reachable by two paths: module unload and from util_remove(). While module unload path is protected by .owner in struct file_operations util_remove() path is not. Freeing the device while someone holds an open fd for it is a show stopper. In general, it is not possible to revoke an fd from all users so the only way to solve the issue is to defer freeing the hvutil_transport structure. Signed-off-by:
-
Vitaly Kuznetsov authored
When Hyper-V host asks us to remove some util driver by closing the appropriate channel there is no easy way to force the current file descriptor holder to hang up but we can start to respond -EBADF to all operations asking it to exit gracefully. As we're setting hvt->mode from two separate contexts now we need to use a proper locking. Signed-off-by:
-
Vitaly Kuznetsov authored
As a preparation to reusing outmsg_lock to protect test-and-set openrations on 'mode' rename it the more general 'lock'. Signed-off-by:
-
Vitaly Kuznetsov authored
inmsg should be freed in case of on_msg() failure to avoid memory leak. Preserve the error code from on_msg(). Signed-off-by:
-
Dexuan Cui authored
Fix the write()'s argument in the daemon code. Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: "K. Y. Srinivasan" <kys@microsoft.com> Signed-off-by:
-
