- 06 Apr, 2016 40 commits
-
-
Flora Cui authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Change-Id: I2ae9bb4a929f7c0c8783e0be563ae04be77596e2 Signed-off-by:
Flora Cui <Flora.Cui@amd.com> Reviewed-by:
Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit abdfb850) Signed-off-by:
Alberto Milone <alberto.milone@canonical.com> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Flora Cui authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Use default value as a base. Signed-off-by:
-
Flora Cui authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Otherwise FW cannot see the RLC ACK for the memory clean request It's for Stoney. Signed-off-by:
-
Chunming Zhou authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Allows us to set priorities in the scheduler. Signed-off-by:
Chunming Zhou <David1.Zhou@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Junwei Zhang <Jerry.Zhang@amd.com> (cherry picked from commit d033a6de) Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 This adds EDC support for CZ. EDC = Error Correction and Detection This code properly initializes the EDC hardware and resets the error counts. This is done in late_init since it requires the IB pool which is not initialized during hw_init. v2: fix the IB size as noted by Felix, fix shader pgm register programming v3: use the IB for the shaders as suggested by Christian Reviewed-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 EDC is a RAS feature for on chip memory. Reviewed-by:
-
Daniel Vetter authored
BugLink: http://bugs.launchpad.net/bugs/1546572 For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check locking in drm_gem_object_unreference Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Daniel Vetter authored
BugLink: http://bugs.launchpad.net/bugs/1546572 For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check locking in drm_gem_object_unreference Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
-
monk.liu authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Read the vbios directly from the rom. In some cases, e.g., virtualization, the rom is not available via the BAR or other means. Access it directly. This is an updated version of Monks original patch which uses family specific callbacks and unifies some of the validation checking. Reviewed-by:
Monk Liu <Monk.Liu@amd.com> Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Read the vbios image directly from the rom. Reviewed-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Read the vbios image directly from the rom. Reviewed-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 This is necessary when the vbios image is not directly accessible via the rom BAR or legacy vga location. Reviewed-by:
-
Julia Lawall authored
BugLink: http://bugs.launchpad.net/bugs/1546572 The radeon_asic_ring structures are never modified, so declare them as const. Done with the help of Coccinelle. Reviewed-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Jammy Zhou authored
BugLink: http://bugs.launchpad.net/bugs/1546572 This can solve the path problem when compile amdgpu with DKMS. v2: agd: rebase on current drm-next Signed-off-by:
-
Alberto Milone authored
BugLink: http://bugs.launchpad.net/bugs/1546572Signed-off-by:
-
Huy Nguyen authored
BugLink: http://bugs.launchpad.net/bugs/1552632 problem description: The current code sets UAR page size equal to system page size. The ConnectX-3 and ConnectX-3 Pro HWs require minimum 128 UAR pages. The mlx4 kernel drivers are not loaded if there is less than 128 UAR pages. solution: Always set UAR page to 4KB. This allows more UAR pages if the OS has PAGE_SIZE larger than 4KB. For example, PowerPC kernel use 64KB system page size, with 4MB uar region, there are 4MB/2/64KB = 32 uars (half for uar, half for blueflame). This does not meet minimum 128 UAR pages requirement. With 4KB UAR page, there are 4MB/2/4KB = 512 uars which meet the minimum requirement. Note that only codes in mlx4_core that deal with firmware know that uar page size is 4KB. Codes that deal with usr page in cq and qp context (mlx4_ib, mlx4_en and part of mlx4_core) still have the same assumption that uar page size equals to system page size. Note that with this implementation, on 64KB system page size kernel, there are 16 uars per system page but only one uars is used. The other 15 uars are ignored because of the above assumption. Regarding SR-IOV, mlx4_core in hypervisor will set the uar page size to 4KB and mlx4_core code in virtual OS will obtain the uar page size from firmware. Regarding backward compatibility in SR-IOV, if hypervisor has this new code, the virtual OS must be updated. If hypervisor has old code, and the virtual OS has this new code, the new code will be backward compatible with the old code. If the uar size is big enough, this new code in VF continues to work with 64 KB uar page size (on PowerPc kernel). If the uar size does not meet 128 uars requirement, this new code not loaded in VF and print the same error message as the old code in Hypervisor. Signed-off-by:
Huy Nguyen <huyn@mellanox.com> Reviewed-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 85743f1e) Signed-off-by:
-
Tim Gardner authored
Ignore: yes Signed-off-by: -
Tim Gardner authored
Signed-off-by: -
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1553179Signed-off-by:
-
Stefan Bader authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 8d16ce54 upstream. Added a safeguard in the shutdown case. At least while not being attached it is also possible to trigger a kernel bug by writing into writeback_running. This change adds the same check before trying to wake up the thread for that case. Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Cc: Kent Overstreet <kent.overstreet@gmail.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 This reverts commit 6ac65b6e. Revert in favor of upstream stable. Signed-off-by:
-
Luca Coelho authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 5e56276e upstream. The firmware can perform a scheduled scan with not matchsets passed, but it can't send notification that results were found. Since the userspace then cannot know when we got new results and the firmware wouldn't trigger a wake in case we are sleeping, it's better not to allow scans without matchsets. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=110831Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Oren Givon authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 006bda75 upstream. Update and fix some 7265 PCI IDs entries. Signed-off-by:
Oren Givon <oren.givon@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 62d7476d upstream. 8000 device family has a new debug engine that needs to be configured differently than 7000's. The debug engine's DMA works in chunks of memory and the size of the buffer really means the start of the last chunk. Since one chunk is 256-byte long, we should configure the device to write to buffer_size - 256. This fixes a situation were the device would write to memory it is not allowed to access. Signed-off-by:
-
Emmanuel Grumbach authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit a1cdb1c5 upstream. My commit below introduced a mutex in the transport to prevent concurrent operations. To do so, it added a flag (is_down) to make sure the transport is in the right state. This uncoverred an bug that didn't cause any harm until now: iwldvm calls stop_device and then starts the firmware without calling start_hw in between. While this flow is fine from the device configuration point of view (register, etc...), it is now forbidden by the new is_down flag. This led to this error to appear: iwlwifi 0000:05:00.0: Can't start_fw since the HW hasn't been started and the suspend would fail. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=109591Reported-by:
Bogdan Bogush <bogdan.s.bogush@gmail.com> Fixes=fa9f3281 ("iwlwifi: pcie: lock start_hw / start_fw / stop_device") Signed-off-by:
-
Matan Barak authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 64936773 upstream. cma_validate_port wrongly assumed that Ethernet devices are RoCE devices and thus their ndev should be matched in the GID table. This broke the iWarp support. Fixing that matching the ndev only if we work on a RoCE port. Cc: <stable@vger.kernel.org> # 4.4.x- Fixes: abae1b71 ('IB/cma: cma_validate_port should verify the port and netdevice') Reported-by:
Hariprasad Shenai <hariprasad@chelsio.com> Tested-by:
Matan Barak <matanb@mellanox.com> Reviewed-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 98229aa3 upstream. We still can end up with a stale vector due to the following: CPU0 CPU1 CPU2 lock_vector() data->move_in_progress=0 sendIPI() unlock_vector() set_affinity() assign_irq_vector() lock_vector() handle_IPI move_in_progress = 1 lock_vector() unlock_vector() move_in_progress == 1 So we need to serialize the vector assignment against a pending cleanup. The solution is rather simple now. We not only check for the move_in_progress flag in assign_irq_vector(), we also check whether there is still a cleanup pending in the old_domain cpumask. If so, we return -EBUSY to the caller and let him deal with it. Though we have to be careful in the cpu unplug case. If the cleanout has not yet completed then the following setaffinity() call would return -EBUSY. Add code which prevents this. Full context is here: http://lkml.kernel.org/r/5653B688.4050809@stratus.comReported-and-tested-by:
Joe Lawrence <joe.lawrence@stratus.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
Borislav Petkov <bp@alien8.de> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Jeremiah Mahler <jmmahler@gmail.com> Cc: andy.shevchenko@gmail.com Cc: Guenter Roeck <linux@roeck-us.net> Link: http://lkml.kernel.org/r/20151231160107.207265407@linutronix.deSigned-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 90a2282e upstream. First of all there is no point in looking up the irq descriptor again, but we also need the descriptor for the final cleanup race fix in the next patch. Make that change seperate. No functional difference. Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 56d7d2f4 upstream. We want to synchronize new vector assignments with a pending cleanup. Remove a dying cpu from a pending cleanup mask. Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 5da0c121 upstream. There is no need to allocate a new cpumask for sending the cleanup vector. The old_domain mask is now protected by the vector_lock, so we can safely remove the offline cpus from it and send the IPI with the resulting mask. Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit c1684f50 upstream. send_cleanup_vector() fiddles with the old_domain mask unprotected because it relies on the protection by the move_in_progress flag. But this is fatal, as the flag is reset after the IPI has been sent. So a cpu which receives the IPI can still see the flag set and therefor ignores the cleanup request. If no other cleanup request happens then the vector stays stale on that cpu and in case of an irq removal the vector still persists. That can lead to use after free when the next cleanup IPI happens. Protect the code with vector_lock and clear move_in_progress before sending the IPI. This does not plug the race which Joe reported because: CPU0 CPU1 CPU2 lock_vector() data->move_in_progress=0 sendIPI() unlock_vector() set_affinity() assign_irq_vector() lock_vector() handle_IPI move_in_progress = 1 lock_vector() unlock_vector() move_in_progress == 1 The full fix comes with a later patch. Reported-and-tested-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 847667ef upstream. No point of keeping offline cpus in the cleanup mask. Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit ab25ac02 upstream. Reusing an existing vector and assigning a new vector has duplicated code. Consolidate it. This is also a preparatory patch for finally plugging the cleanup race. Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 9ac15b7a upstream. In the case that the new vector mask is a subset of the existing mask there is no point to do a AND operation of currentmask & newmask. The result is newmask. So we can simply copy the new mask to the current mask and be done with it. Preparatory patch for further consolidation. Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 3716fd27 upstream. __assign_irq_vector() uses the vector_cpumask which is assigned by apic->vector_allocation_domain() without doing basic sanity checks. That can result in a situation where the final assignement of a newly found vector fails in apic->cpu_mask_to_apicid_and(). So we have to do rollbacks for no reason. apic->cpu_mask_to_apicid_and() only fails if vector_cpumask & requested_cpumask & cpu_online_mask is empty. Check for this condition right away and if the result is empty try immediately the next possible cpu in the requested mask. So in case of a failure the old setting is unchanged and we can remove the rollback code. Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 95ffeb4b upstream. Split out the code which advances the target cpu for the search so we can reuse it for the next patch which adds an early validation check for the vectormask which we get from the apic. Add comments while at it. Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 433cbd57 upstream. Use an explicit goto for the cases where we have success in the search/update and return -ENOSPC if the search loop ends due to no space. Preparatory patch for fixes. No functional change. Signed-off-by:
-
Jiang Liu authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 8a580f70 upstream. Function __assign_irq_vector() makes use of apic_chip_data.old_domain as a temporary buffer, which is in the way of using apic_chip_data.old_domain for synchronizing the vector cleanup with the vector assignement code. Use a proper temporary cpumask for this. [ tglx: Renamed the mask to searched_cpumask for clarity ] Signed-off-by:
Jiang Liu <jiang.liu@linux.intel.com> Tested-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 36f34c8c upstream. In fixup_irqs() we unconditionally dereference the irq chip of an irq descriptor. The descriptor might still be valid, but already cleaned up, i.e. the chip removed. Add a check for this condition. Signed-off-by:
-
Jiang Liu authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 111abeba upstream. There's a race condition between x86_vector_free_irqs() { free_apic_chip_data(irq_data->chip_data); xxxxx //irq_data->chip_data has been freed, but the pointer //hasn't been reset yet irq_domain_reset_irq_data(irq_data); } and smp_irq_move_cleanup_interrupt() { raw_spin_lock(&vector_lock); data = apic_chip_data(irq_desc_get_irq_data(desc)); access data->xxxx // may access freed memory raw_spin_unlock(&desc->lock); } which may cause smp_irq_move_cleanup_interrupt() to access freed memory. Call irq_domain_reset_irq_data(), which clears the pointer with vector lock held. [ tglx: Free memory outside of lock held region. ] Signed-off-by:
-
