<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers, branch v5.6.6</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>scsi: target: iscsi: calling iscsit_stop_session() inside iscsit_close_session() has no effect</title>
<updated>2020-04-21T07:08:16+00:00</updated>
<author>
<name>Maurizio Lombardi</name>
<email>mlombard@redhat.com</email>
</author>
<published>2020-03-13T17:06:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=30855683a7b593c0fbc2d7a6debcfb879c6a5250'/>
<id>30855683a7b593c0fbc2d7a6debcfb879c6a5250</id>
<content type='text'>
[ Upstream commit 626bac73371eed79e2afa2966de393da96cf925e ]

iscsit_close_session() can only be called when nconn is zero (otherwise a
kernel panic is triggered). If nconn is zero then iscsit_stop_session()
does nothing and exits, so calling it makes no sense.

We still need to call iscsit_check_session_usage_count() because this
function will sleep if the session's refcount is not zero and we don't want
to destroy the session structure if it's still being referenced.

Link: https://lore.kernel.org/r/20200313170656.9716-4-mlombard@redhat.com
Tested-by: Rahul Kundu &lt;rahul.kundu@chelsio.com&gt;
Signed-off-by: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 626bac73371eed79e2afa2966de393da96cf925e ]

iscsit_close_session() can only be called when nconn is zero (otherwise a
kernel panic is triggered). If nconn is zero then iscsit_stop_session()
does nothing and exits, so calling it makes no sense.

We still need to call iscsit_check_session_usage_count() because this
function will sleep if the session's refcount is not zero and we don't want
to destroy the session structure if it's still being referenced.

Link: https://lore.kernel.org/r/20200313170656.9716-4-mlombard@redhat.com
Tested-by: Rahul Kundu &lt;rahul.kundu@chelsio.com&gt;
Signed-off-by: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>irqchip/ti-sci-inta: Fix processing of masked irqs</title>
<updated>2020-04-21T07:08:14+00:00</updated>
<author>
<name>Grygorii Strashko</name>
<email>grygorii.strashko@ti.com</email>
</author>
<published>2020-04-08T19:15:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f26cb6f6ded5af397b3a5c6e2782f7bcfbe786d6'/>
<id>f26cb6f6ded5af397b3a5c6e2782f7bcfbe786d6</id>
<content type='text'>
commit 3688b0db5c331f4ec3fa5eb9f670a4b04f530700 upstream.

The ti_sci_inta_irq_handler() does not take into account INTA IRQs state
(masked/unmasked) as it uses INTA_STATUS_CLEAR_j register to get INTA IRQs
status, which provides raw status value.
This causes hard IRQ handlers to be called or threaded handlers to be
scheduled many times even if corresponding INTA IRQ is masked.
Above, first of all, affects the LEVEL interrupts processing and causes
unexpected behavior up the system stack or crash.

Fix it by using the Interrupt Masked Status INTA_STATUSM_j register which
provides masked INTA IRQs status.

Fixes: 9f1463b86c13 ("irqchip/ti-sci-inta: Add support for Interrupt Aggregator driver")
Signed-off-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Reviewed-by: Lokesh Vutla &lt;lokeshvutla@ti.com&gt;
Link: https://lore.kernel.org/r/20200408191532.31252-1-grygorii.strashko@ti.com
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3688b0db5c331f4ec3fa5eb9f670a4b04f530700 upstream.

The ti_sci_inta_irq_handler() does not take into account INTA IRQs state
(masked/unmasked) as it uses INTA_STATUS_CLEAR_j register to get INTA IRQs
status, which provides raw status value.
This causes hard IRQ handlers to be called or threaded handlers to be
scheduled many times even if corresponding INTA IRQ is masked.
Above, first of all, affects the LEVEL interrupts processing and causes
unexpected behavior up the system stack or crash.

Fix it by using the Interrupt Masked Status INTA_STATUSM_j register which
provides masked INTA IRQs status.

Fixes: 9f1463b86c13 ("irqchip/ti-sci-inta: Add support for Interrupt Aggregator driver")
Signed-off-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Reviewed-by: Lokesh Vutla &lt;lokeshvutla@ti.com&gt;
Link: https://lore.kernel.org/r/20200408191532.31252-1-grygorii.strashko@ti.com
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915/perf: Do not clear pollin for small user read buffers</title>
<updated>2020-04-21T07:08:13+00:00</updated>
<author>
<name>Ashutosh Dixit</name>
<email>ashutosh.dixit@intel.com</email>
</author>
<published>2020-04-08T23:42:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=634781fc6f75bd185907607bd22d275ed49d82f8'/>
<id>634781fc6f75bd185907607bd22d275ed49d82f8</id>
<content type='text'>
commit bcad588dea538a4fc173d16a90a005536ec8dbf2 upstream.

It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead to data loss when the
buffer size used is smaller than the available data.

This change fixes this issue and allows user space to read all OA data
even when using a buffer size smaller than the available data using
multiple non-blocking reads rather than staying blocked in poll till
the next timer interrupt.

v2: Fix ret value for blocking reads (Umesh)
v3: Mistake during patch send (Ashutosh)
v4: Remove -EAGAIN from comment (Umesh)
v5: Improve condition for clearing pollin and return (Lionel)
v6: Improve blocking read loop and other cleanups (Lionel)
v7: Added Cc stable

Testcase: igt/perf/polling-small-buf
Reviewed-by: Lionel Landwerlin &lt;lionel.g.landwerlin@intel.com&gt;
Signed-off-by: Ashutosh Dixit &lt;ashutosh.dixit@intel.com&gt;
Cc: Umesh Nerlige Ramappa &lt;umesh.nerlige.ramappa@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200403010120.3067-1-ashutosh.dixit@intel.com
(cherry-picked from commit 6352219c39c04ed3f9a8d1cf93f87c21753a213e)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bcad588dea538a4fc173d16a90a005536ec8dbf2 upstream.

It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead to data loss when the
buffer size used is smaller than the available data.

This change fixes this issue and allows user space to read all OA data
even when using a buffer size smaller than the available data using
multiple non-blocking reads rather than staying blocked in poll till
the next timer interrupt.

v2: Fix ret value for blocking reads (Umesh)
v3: Mistake during patch send (Ashutosh)
v4: Remove -EAGAIN from comment (Umesh)
v5: Improve condition for clearing pollin and return (Lionel)
v6: Improve blocking read loop and other cleanups (Lionel)
v7: Added Cc stable

Testcase: igt/perf/polling-small-buf
Reviewed-by: Lionel Landwerlin &lt;lionel.g.landwerlin@intel.com&gt;
Signed-off-by: Ashutosh Dixit &lt;ashutosh.dixit@intel.com&gt;
Cc: Umesh Nerlige Ramappa &lt;umesh.nerlige.ramappa@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200403010120.3067-1-ashutosh.dixit@intel.com
(cherry-picked from commit 6352219c39c04ed3f9a8d1cf93f87c21753a213e)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/nouveau/sec2/gv100-: add missing MODULE_FIRMWARE()</title>
<updated>2020-04-21T07:08:13+00:00</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2020-04-16T05:26:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5e69e5904b9c19a48c3b3bf24a8395f0144027bc'/>
<id>5e69e5904b9c19a48c3b3bf24a8395f0144027bc</id>
<content type='text'>
commit 92f673a12d14b5393138d2b1cfeb41d72b47362d upstream.

ASB was failing to load on Turing GPUs when firmware is being loaded
from initramfs, leaving the GPU in an odd state and causing suspend/
resume to fail.

Add missing MODULE_FIRMWARE() lines for initramfs generators.

Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 5.6
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 92f673a12d14b5393138d2b1cfeb41d72b47362d upstream.

ASB was failing to load on Turing GPUs when firmware is being loaded
from initramfs, leaving the GPU in an odd state and causing suspend/
resume to fail.

Add missing MODULE_FIRMWARE() lines for initramfs generators.

Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 5.6
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: designware: platdrv: Remove DPM_FLAG_SMART_SUSPEND flag on BYT and CHT</title>
<updated>2020-04-21T07:08:13+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2020-04-07T18:11:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=befc8b9a5ef1814de24373f81ed40bf1414aa6e0'/>
<id>befc8b9a5ef1814de24373f81ed40bf1414aa6e0</id>
<content type='text'>
commit d79294d0de12ddd1420110813626d691f440b86f upstream.

We already set DPM_FLAG_SMART_PREPARE, so we completely skip all
callbacks (other then prepare) where possible, quoting from
dw_i2c_plat_prepare():

        /*
         * If the ACPI companion device object is present for this device, it
         * may be accessed during suspend and resume of other devices via I2C
         * operation regions, so tell the PM core and middle layers to avoid
         * skipping system suspend/resume callbacks for it in that case.
         */
        return !has_acpi_companion(dev);

Also setting the DPM_FLAG_SMART_SUSPEND will cause acpi_subsys_suspend()
to leave the controller runtime-suspended even if dw_i2c_plat_prepare()
returned 0.

Leaving the controller runtime-suspended normally, when the I2C controller
is suspended during the suspend_late phase, is not an issue because
the pm_runtime_get_sync() done by i2c_dw_xfer() will (runtime-)resume it.

But for dw I2C controllers on Bay- and Cherry-Trail devices acpi_lpss.c
leaves the controller alive until the suspend_noirq phase, because it may
be used by the _PS3 ACPI methods of PCI devices and PCI devices are left
powered on until the suspend_noirq phase.

Between the suspend_late and resume_early phases runtime-pm is disabled.
So for any ACPI I2C OPRegion accesses done after the suspend_late phase,
the pm_runtime_get_sync() done by i2c_dw_xfer() is a no-op and the
controller is left runtime-suspended.

i2c_dw_xfer() has a check to catch this condition (rather then waiting
for the I2C transfer to timeout because the controller is suspended).
acpi_subsys_suspend() leaving the controller runtime-suspended in
combination with an ACPI I2C OPRegion access done after the suspend_late
phase triggers this check, leading to the following error being logged
on a Bay Trail based Lenovo Thinkpad 8 tablet:

[   93.275882] i2c_designware 80860F41:00: Transfer while suspended
[   93.275993] WARNING: CPU: 0 PID: 412 at drivers/i2c/busses/i2c-designware-master.c:429 i2c_dw_xfer+0x239/0x280
...
[   93.276252] Workqueue: kacpi_notify acpi_os_execute_deferred
[   93.276267] RIP: 0010:i2c_dw_xfer+0x239/0x280
...
[   93.276340] Call Trace:
[   93.276366]  __i2c_transfer+0x121/0x520
[   93.276379]  i2c_transfer+0x4c/0x100
[   93.276392]  i2c_acpi_space_handler+0x219/0x510
[   93.276408]  ? up+0x40/0x60
[   93.276419]  ? i2c_acpi_notify+0x130/0x130
[   93.276433]  acpi_ev_address_space_dispatch+0x1e1/0x252
...

So since on BYT and CHT platforms we want ACPI I2c OPRegion accesses
to work until the suspend_noirq phase, we need the controller to be
runtime-resumed during the suspend phase if it is runtime-suspended
suspended at that time. This means that we must not set the
DPM_FLAG_SMART_SUSPEND on these platforms.

On BYT and CHT we already have a special ACCESS_NO_IRQ_SUSPEND flag
to make sure the controller stays functional until the suspend_noirq
phase. This commit makes the driver not set the DPM_FLAG_SMART_SUSPEND
flag when that flag is set.

Cc: stable@vger.kernel.org
Fixes: b30f2f65568f ("i2c: designware: Set IRQF_NO_SUSPEND flag for all BYT and CHT controllers")
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Acked-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@the-dreams.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d79294d0de12ddd1420110813626d691f440b86f upstream.

We already set DPM_FLAG_SMART_PREPARE, so we completely skip all
callbacks (other then prepare) where possible, quoting from
dw_i2c_plat_prepare():

        /*
         * If the ACPI companion device object is present for this device, it
         * may be accessed during suspend and resume of other devices via I2C
         * operation regions, so tell the PM core and middle layers to avoid
         * skipping system suspend/resume callbacks for it in that case.
         */
        return !has_acpi_companion(dev);

Also setting the DPM_FLAG_SMART_SUSPEND will cause acpi_subsys_suspend()
to leave the controller runtime-suspended even if dw_i2c_plat_prepare()
returned 0.

Leaving the controller runtime-suspended normally, when the I2C controller
is suspended during the suspend_late phase, is not an issue because
the pm_runtime_get_sync() done by i2c_dw_xfer() will (runtime-)resume it.

But for dw I2C controllers on Bay- and Cherry-Trail devices acpi_lpss.c
leaves the controller alive until the suspend_noirq phase, because it may
be used by the _PS3 ACPI methods of PCI devices and PCI devices are left
powered on until the suspend_noirq phase.

Between the suspend_late and resume_early phases runtime-pm is disabled.
So for any ACPI I2C OPRegion accesses done after the suspend_late phase,
the pm_runtime_get_sync() done by i2c_dw_xfer() is a no-op and the
controller is left runtime-suspended.

i2c_dw_xfer() has a check to catch this condition (rather then waiting
for the I2C transfer to timeout because the controller is suspended).
acpi_subsys_suspend() leaving the controller runtime-suspended in
combination with an ACPI I2C OPRegion access done after the suspend_late
phase triggers this check, leading to the following error being logged
on a Bay Trail based Lenovo Thinkpad 8 tablet:

[   93.275882] i2c_designware 80860F41:00: Transfer while suspended
[   93.275993] WARNING: CPU: 0 PID: 412 at drivers/i2c/busses/i2c-designware-master.c:429 i2c_dw_xfer+0x239/0x280
...
[   93.276252] Workqueue: kacpi_notify acpi_os_execute_deferred
[   93.276267] RIP: 0010:i2c_dw_xfer+0x239/0x280
...
[   93.276340] Call Trace:
[   93.276366]  __i2c_transfer+0x121/0x520
[   93.276379]  i2c_transfer+0x4c/0x100
[   93.276392]  i2c_acpi_space_handler+0x219/0x510
[   93.276408]  ? up+0x40/0x60
[   93.276419]  ? i2c_acpi_notify+0x130/0x130
[   93.276433]  acpi_ev_address_space_dispatch+0x1e1/0x252
...

So since on BYT and CHT platforms we want ACPI I2c OPRegion accesses
to work until the suspend_noirq phase, we need the controller to be
runtime-resumed during the suspend phase if it is runtime-suspended
suspended at that time. This means that we must not set the
DPM_FLAG_SMART_SUSPEND on these platforms.

On BYT and CHT we already have a special ACCESS_NO_IRQ_SUSPEND flag
to make sure the controller stays functional until the suspend_noirq
phase. This commit makes the driver not set the DPM_FLAG_SMART_SUSPEND
flag when that flag is set.

Cc: stable@vger.kernel.org
Fixes: b30f2f65568f ("i2c: designware: Set IRQF_NO_SUSPEND flag for all BYT and CHT controllers")
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Acked-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@the-dreams.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu: fix the hw hang during perform system reboot and reset</title>
<updated>2020-04-21T07:08:12+00:00</updated>
<author>
<name>Prike Liang</name>
<email>Prike.Liang@amd.com</email>
</author>
<published>2020-04-13T13:41:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=76b17a574d89e0da56725729c437dee9aef153a0'/>
<id>76b17a574d89e0da56725729c437dee9aef153a0</id>
<content type='text'>
commit b2a7e9735ab2864330be9d00d7f38c961c28de5d upstream.

The system reboot failed as some IP blocks enter power gate before perform
hw resource destory. Meanwhile use unify interface to set device CGPG to ungate
state can simplify the amdgpu poweroff or reset ungate guard.

Fixes: 487eca11a321ef ("drm/amdgpu: fix gfx hang during suspend with video playback (v2)")
Signed-off-by: Prike Liang &lt;Prike.Liang@amd.com&gt;
Tested-by: Mengbing Wang &lt;Mengbing.Wang@amd.com&gt;
Tested-by: Paul Menzel &lt;pmenzel@molgen.mpg.de&gt;
Acked-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b2a7e9735ab2864330be9d00d7f38c961c28de5d upstream.

The system reboot failed as some IP blocks enter power gate before perform
hw resource destory. Meanwhile use unify interface to set device CGPG to ungate
state can simplify the amdgpu poweroff or reset ungate guard.

Fixes: 487eca11a321ef ("drm/amdgpu: fix gfx hang during suspend with video playback (v2)")
Signed-off-by: Prike Liang &lt;Prike.Liang@amd.com&gt;
Tested-by: Mengbing Wang &lt;Mengbing.Wang@amd.com&gt;
Tested-by: Paul Menzel &lt;pmenzel@molgen.mpg.de&gt;
Acked-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amdgpu/gfx9: add gfxoff quirk</title>
<updated>2020-04-21T07:08:12+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2020-04-09T13:40:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0321ce45e382f7bfaaf26d8a753049411a890788'/>
<id>0321ce45e382f7bfaaf26d8a753049411a890788</id>
<content type='text'>
commit 974229db7e6c1f2ff83ceaf3022d5128bf62caca upstream.

Fix screen corruption with firefox.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=207171
Reviewed-by: Huang Rui &lt;ray.huang@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 974229db7e6c1f2ff83ceaf3022d5128bf62caca upstream.

Fix screen corruption with firefox.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=207171
Reviewed-by: Huang Rui &lt;ray.huang@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/amd/powerplay: force the trim of the mclk dpm_levels if OD is enabled</title>
<updated>2020-04-21T07:08:12+00:00</updated>
<author>
<name>Sergei Lopatin</name>
<email>magist3r@gmail.com</email>
</author>
<published>2019-06-26T09:56:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=eee7960b8c06b2df8faf116ceedfb0b7e771285b'/>
<id>eee7960b8c06b2df8faf116ceedfb0b7e771285b</id>
<content type='text'>
commit 8c7f0a44b4b4ef16df8f44fbaee6d1f5d1593c83 upstream.

Should prevent flicker if PP_OVERDRIVE_MASK is set.

bug: https://bugs.freedesktop.org/show_bug.cgi?id=102646
bug: https://bugs.freedesktop.org/show_bug.cgi?id=108941
bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1088
bug: https://gitlab.freedesktop.org/drm/amd/-/issues/628

Signed-off-by: Sergei Lopatin &lt;magist3r@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8c7f0a44b4b4ef16df8f44fbaee6d1f5d1593c83 upstream.

Should prevent flicker if PP_OVERDRIVE_MASK is set.

bug: https://bugs.freedesktop.org/show_bug.cgi?id=102646
bug: https://bugs.freedesktop.org/show_bug.cgi?id=108941
bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1088
bug: https://gitlab.freedesktop.org/drm/amd/-/issues/628

Signed-off-by: Sergei Lopatin &lt;magist3r@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>net/mlx5e: Use preactivate hook to set the indirection table</title>
<updated>2020-04-21T07:08:12+00:00</updated>
<author>
<name>Maxim Mikityanskiy</name>
<email>maximmi@mellanox.com</email>
</author>
<published>2019-11-04T10:02:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=34025776c98cf2e8a01db61411df7576278cb85e'/>
<id>34025776c98cf2e8a01db61411df7576278cb85e</id>
<content type='text'>
[ Upstream commit fe867cac9e1967c553e4ac2aece5fc8675258010 ]

mlx5e_ethtool_set_channels updates the indirection table before
switching to the new channels. If the switch fails, the indirection
table is new, but the channels are old, which is wrong. Fix it by using
the preactivate hook of mlx5e_safe_switch_channels to update the
indirection table at the stage when nothing can fail anymore.

As the code that updates the indirection table is now encapsulated into
a new function, use that function in the attach flow when the driver has
to reduce the number of channels, and prepare the code for the next
commit.

Fixes: 85082dba0a ("net/mlx5e: Correctly handle RSS indirection table when changing number of channels")
Signed-off-by: Maxim Mikityanskiy &lt;maximmi@mellanox.com&gt;
Reviewed-by: Tariq Toukan &lt;tariqt@mellanox.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@mellanox.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit fe867cac9e1967c553e4ac2aece5fc8675258010 ]

mlx5e_ethtool_set_channels updates the indirection table before
switching to the new channels. If the switch fails, the indirection
table is new, but the channels are old, which is wrong. Fix it by using
the preactivate hook of mlx5e_safe_switch_channels to update the
indirection table at the stage when nothing can fail anymore.

As the code that updates the indirection table is now encapsulated into
a new function, use that function in the attach flow when the driver has
to reduce the number of channels, and prepare the code for the next
commit.

Fixes: 85082dba0a ("net/mlx5e: Correctly handle RSS indirection table when changing number of channels")
Signed-off-by: Maxim Mikityanskiy &lt;maximmi@mellanox.com&gt;
Reviewed-by: Tariq Toukan &lt;tariqt@mellanox.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@mellanox.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net/mlx5e: Rename hw_modify to preactivate</title>
<updated>2020-04-21T07:08:11+00:00</updated>
<author>
<name>Maxim Mikityanskiy</name>
<email>maximmi@mellanox.com</email>
</author>
<published>2019-10-31T07:39:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cac3244d18a9ddcb79640a51ba2688e801160842'/>
<id>cac3244d18a9ddcb79640a51ba2688e801160842</id>
<content type='text'>
[ Upstream commit dca147b3dce5abb5284ff747211960fd2db5ec2e ]

mlx5e_safe_switch_channels accepts a callback to be called before
activating new channels. It is intended to configure some hardware
parameters in cases where channels are recreated because some
configuration has changed.

Recently, this callback has started being used to update the driver's
internal MLX5E_STATE_XDP_OPEN flag, and the following patches also
intend to use this callback for software preparations. This patch
renames the hw_modify callback to preactivate, so that the name fits
better.

Signed-off-by: Maxim Mikityanskiy &lt;maximmi@mellanox.com&gt;
Reviewed-by: Tariq Toukan &lt;tariqt@mellanox.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@mellanox.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit dca147b3dce5abb5284ff747211960fd2db5ec2e ]

mlx5e_safe_switch_channels accepts a callback to be called before
activating new channels. It is intended to configure some hardware
parameters in cases where channels are recreated because some
configuration has changed.

Recently, this callback has started being used to update the driver's
internal MLX5E_STATE_XDP_OPEN flag, and the following patches also
intend to use this callback for software preparations. This patch
renames the hw_modify callback to preactivate, so that the name fits
better.

Signed-off-by: Maxim Mikityanskiy &lt;maximmi@mellanox.com&gt;
Reviewed-by: Tariq Toukan &lt;tariqt@mellanox.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@mellanox.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
