<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v6.11.8</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.11.8</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.11.8'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-11-14T12:21:15+00:00</updated>
<entry>
<title>drm/xe/guc/tlb: Flush g2h worker in case of tlb timeout</title>
<updated>2024-11-14T12:21:15+00:00</updated>
<author>
<name>Nirmoy Das</name>
<email>nirmoy.das@intel.com</email>
</author>
<published>2024-10-29T12:01:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0f32c5ae605ad0fda2023e53b947f6c8ac345180'/>
<id>urn:sha1:0f32c5ae605ad0fda2023e53b947f6c8ac345180</id>
<content type='text'>
[ Upstream commit 1491efb39acee3848b61fcb3e5cc4be8de304352 ]

Flush the g2h worker explicitly if TLB timeout happens which is
observed on LNL and that points to the recent scheduling issue with
E-cores on LNL.

This is similar to the recent fix:
commit e51527233804 ("drm/xe/guc/ct: Flush g2h worker in case of g2h
response timeout") and should be removed once there is E core
scheduling fix.

v2: Add platform check(Himal)
v3: Remove gfx platform check as the issue related to cpu
    platform(John)
    Use the common WA macro(John) and print when the flush
    resolves timeout(Matt B)
v4: Remove the resolves log and do the flush before taking
    pending_lock(Matt A)

Cc: Badal Nilawar &lt;badal.nilawar@intel.com&gt;
Cc: Matthew Brost &lt;matthew.brost@intel.com&gt;
Cc: Matthew Auld &lt;matthew.auld@intel.com&gt;
Cc: John Harrison &lt;John.C.Harrison@Intel.com&gt;
Cc: Himal Prasad Ghimiray &lt;himal.prasad.ghimiray@intel.com&gt;
Cc: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
Cc: stable@vger.kernel.org # v6.11+
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2687
Signed-off-by: Nirmoy Das &lt;nirmoy.das@intel.com&gt;
Reviewed-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20241029120117.449694-3-nirmoy.das@intel.com
Signed-off-by: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
(cherry picked from commit e1f6fa55664a0eeb0a641f497e1adfcf6672e995)
Signed-off-by: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/xe/ufence: Flush xe ordered_wq in case of ufence timeout</title>
<updated>2024-11-14T12:21:15+00:00</updated>
<author>
<name>Nirmoy Das</name>
<email>nirmoy.das@intel.com</email>
</author>
<published>2024-10-29T12:01:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0e5d84d173e34d95c16e3cf28143450a08ac99e0'/>
<id>urn:sha1:0e5d84d173e34d95c16e3cf28143450a08ac99e0</id>
<content type='text'>
[ Upstream commit 7d1e2580ed166f36949b468373b468d188880cd3 ]

Flush xe ordered_wq in case of ufence timeout which is observed
on LNL and that points to recent scheduling issue with E-cores.

This is similar to the recent fix:
commit e51527233804 ("drm/xe/guc/ct: Flush g2h worker in case of g2h
response timeout") and should be removed once there is a E-core
scheduling fix for LNL.

v2: Add platform check(Himal)
    s/__flush_workqueue/flush_workqueue(Jani)
v3: Remove gfx platform check as the issue related to cpu
    platform(John)
v4: Use the Common macro(John) and print when the flush resolves
    timeout(Matt B)

Cc: Badal Nilawar &lt;badal.nilawar@intel.com&gt;
Cc: Matthew Auld &lt;matthew.auld@intel.com&gt;
Cc: John Harrison &lt;John.C.Harrison@Intel.com&gt;
Cc: Himal Prasad Ghimiray &lt;himal.prasad.ghimiray@intel.com&gt;
Cc: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
Cc: stable@vger.kernel.org # v6.11+
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2754
Suggested-by: Matthew Brost &lt;matthew.brost@intel.com&gt;
Signed-off-by: Nirmoy Das &lt;nirmoy.das@intel.com&gt;
Reviewed-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20241029120117.449694-2-nirmoy.das@intel.com
Signed-off-by: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
(cherry picked from commit 38c4c8722bd74452280951edc44c23de47612001)
Signed-off-by: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/xe: Move LNL scheduling WA to xe_device.h</title>
<updated>2024-11-14T12:21:15+00:00</updated>
<author>
<name>Nirmoy Das</name>
<email>nirmoy.das@intel.com</email>
</author>
<published>2024-10-29T12:01:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e22aa8c056a5e5b47dc144295f032c3c84c76e24'/>
<id>urn:sha1:e22aa8c056a5e5b47dc144295f032c3c84c76e24</id>
<content type='text'>
[ Upstream commit 55e8a3f37e54eb1c7b914d6d5565a37282ec1978 ]

Move LNL scheduling WA to xe_device.h so this can be used in other
places without needing keep the same comment about removal of this WA
in the future. The WA, which flushes work or workqueues, is now wrapped
in macros and can be reused wherever needed.

Cc: Badal Nilawar &lt;badal.nilawar@intel.com&gt;
Cc: Matthew Auld &lt;matthew.auld@intel.com&gt;
Cc: Matthew Brost &lt;matthew.brost@intel.com&gt;
Cc: Himal Prasad Ghimiray &lt;himal.prasad.ghimiray@intel.com&gt;
Cc: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
cc: stable@vger.kernel.org # v6.11+
Suggested-by: John Harrison &lt;John.C.Harrison@Intel.com&gt;
Signed-off-by: Nirmoy Das &lt;nirmoy.das@intel.com&gt;
Reviewed-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20241029120117.449694-1-nirmoy.das@intel.com
Signed-off-by: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
(cherry picked from commit cbe006a6492c01a0058912ae15d473f4c149896c)
Signed-off-by: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout</title>
<updated>2024-11-14T12:21:15+00:00</updated>
<author>
<name>Badal Nilawar</name>
<email>badal.nilawar@intel.com</email>
</author>
<published>2024-10-17T11:14:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=85e4d92870c85ccccf5a0e26290fe4d8e5478f13'/>
<id>urn:sha1:85e4d92870c85ccccf5a0e26290fe4d8e5478f13</id>
<content type='text'>
[ Upstream commit 22ef43c78647dd37b0dafe2182b8650b99dbbe59 ]

In case if g2h worker doesn't get opportunity to within specified
timeout delay then flush the g2h worker explicitly.

v2:
  - Describe change in the comment and add TODO (Matt B/John H)
  - Add xe_gt_warn on fence done after G2H flush (John H)
v3:
  - Updated the comment with root cause
  - Clean up xe_gt_warn message (John H)

Closes: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1620
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2902
Signed-off-by: Badal Nilawar &lt;badal.nilawar@intel.com&gt;
Cc: Matthew Brost &lt;matthew.brost@intel.com&gt;
Cc: Matthew Auld &lt;matthew.auld@intel.com&gt;
Cc: John Harrison &lt;John.C.Harrison@Intel.com&gt;
Cc: Himal Prasad Ghimiray &lt;himal.prasad.ghimiray@intel.com&gt;
Reviewed-by: Himal Prasad Ghimiray &lt;himal.prasad.ghimiray@intel.com&gt;
Acked-by: Matthew Brost &lt;matthew.brost@intel.com&gt;
Signed-off-by: Matthew Brost &lt;matthew.brost@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20241017111410.2553784-2-badal.nilawar@intel.com
(cherry picked from commit e5152723380404acb8175e0777b1cea57f319a01)
Signed-off-by: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
Stable-dep-of: 55e8a3f37e54 ("drm/xe: Move LNL scheduling WA to xe_device.h")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>firmware: qcom: scm: suppress download mode error</title>
<updated>2024-11-14T12:21:14+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan+linaro@kernel.org</email>
</author>
<published>2024-10-02T10:01:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a70638760015accb1494fe69ea16a9cfbf2413dd'/>
<id>urn:sha1:a70638760015accb1494fe69ea16a9cfbf2413dd</id>
<content type='text'>
[ Upstream commit d67907154808745b0fae5874edc7b0f78d33991c ]

Stop spamming the logs with errors about missing mechanism for setting
the so called download (or dump) mode for users that have not requested
that feature to be enabled in the first place.

This avoids the follow error being logged on boot as well as on
shutdown when the feature it not available and download mode has not
been enabled on the kernel command line:

	qcom_scm firmware:scm: No available mechanism for setting download mode

Fixes: 79cb2cb8d89b ("firmware: qcom: scm: Disable SDI and write no dump to dump mode")
Fixes: 781d32d1c970 ("firmware: qcom_scm: Clear download bit during reboot")
Cc: Mukesh Ojha &lt;quic_mojha@quicinc.com&gt;
Cc: stable@vger.kernel.org	# 6.4
Signed-off-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Reviewed-by: Mukesh Ojha &lt;quic_mojha@quicinc.com&gt;
Link: https://lore.kernel.org/r/20241002100122.18809-2-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>firmware: qcom: scm: Refactor code to support multiple dload mode</title>
<updated>2024-11-14T12:21:14+00:00</updated>
<author>
<name>Mukesh Ojha</name>
<email>quic_mojha@quicinc.com</email>
</author>
<published>2024-07-15T15:56:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f82ed58b14e9d2c16877379efb76457bae9d52b4'/>
<id>urn:sha1:f82ed58b14e9d2c16877379efb76457bae9d52b4</id>
<content type='text'>
[ Upstream commit c802b0a2ed0f67fcec8cc0cac685c8fd0dd0aa6f ]

Currently on Qualcomm SoC, download_mode is enabled if
CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT is selected or
passed a boolean value from command line.

Refactor the code such that it supports multiple download
modes and drop CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT config
instead, give interface to set the download mode from
module parameter while being backword compatible at the
same time.

Signed-off-by: Mukesh Ojha &lt;quic_mojha@quicinc.com&gt;
Link: https://lore.kernel.org/r/20240715155655.1811178-1-quic_mojha@quicinc.com
Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;
Stable-dep-of: d67907154808 ("firmware: qcom: scm: suppress download mode error")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>irqchip/gic-v3: Force propagation of the active state with a read-back</title>
<updated>2024-11-14T12:21:14+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2024-11-06T08:44:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8e8ab8e554e8cf6a1fc762774147516c0d16eed7'/>
<id>urn:sha1:8e8ab8e554e8cf6a1fc762774147516c0d16eed7</id>
<content type='text'>
commit 464cb98f1c07298c4c10e714ae0c36338d18d316 upstream.

Christoffer reports that on some implementations, writing to
GICR_ISACTIVER0 (and similar GICD registers) can race badly with a guest
issuing a deactivation of that interrupt via the system register interface.

There are multiple reasons to this:

 - this uses an early write-acknoledgement memory type (nGnRE), meaning
   that the write may only have made it as far as some interconnect
   by the time the store is considered "done"

 - the GIC itself is allowed to buffer the write until it decides to
   take it into account (as long as it is in finite time)

The effects are that the activation may not have taken effect by the time
the kernel enters the guest, forcing an immediate exit, or that a guest
deactivation occurs before the interrupt is active, doing nothing.

In order to guarantee that the write to the ISACTIVER register has taken
effect, read back from it, forcing the interconnect to propagate the write,
and the GIC to process the write before returning the read.

Reported-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Christoffer Dall &lt;christoffer.dall@arm.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20241106084418.3794612-1-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation</title>
<updated>2024-11-14T12:21:14+00:00</updated>
<author>
<name>Umang Jain</name>
<email>umang.jain@ideasonboard.com</email>
</author>
<published>2024-10-16T13:02:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e216957b89a1f859732d46fdd20be833d2323156'/>
<id>urn:sha1:e216957b89a1f859732d46fdd20be833d2323156</id>
<content type='text'>
commit 404b739e895522838f1abdc340c554654d671dde upstream.

The struct vchiq_arm_state 'platform_state' is currently allocated
dynamically using kzalloc(). Unfortunately, it is never freed and is
subjected to memory leaks in the error handling paths of the probe()
function.

To address the issue, use device resource management helper
devm_kzalloc(), to ensure cleanup after its allocation.

Fixes: 71bad7f08641 ("staging: add bcm2708 vchiq driver")
Cc: stable@vger.kernel.org
Signed-off-by: Umang Jain &lt;umang.jain@ideasonboard.com&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Link: https://lore.kernel.org/r/20241016130225.61024-2-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>staging: vchiq_arm: Use devm_kzalloc() for drv_mgmt allocation</title>
<updated>2024-11-14T12:21:14+00:00</updated>
<author>
<name>Umang Jain</name>
<email>umang.jain@ideasonboard.com</email>
</author>
<published>2024-10-16T13:02:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a5f8442d4e02d992ce47491e9c60a50cb6f392d8'/>
<id>urn:sha1:a5f8442d4e02d992ce47491e9c60a50cb6f392d8</id>
<content type='text'>
commit 807babf69027b4f1c55e72b06879658e83830880 upstream.

The struct drv_mgmt 'mgmt' is currently allocated dynamically using
kzalloc(). Unfortunately, it is subjected to memory leaks in the error
handling paths of the probe() function.

To address this issue, use device resource management
helper devm_kzalloc(), to ensure cleanup after the allocation.

Cc: stable@vger.kernel.org
Fixes: 1c9e16b73166 ("staging: vc04_services: vchiq_arm: Split driver static and runtime data")
Signed-off-by: Umang Jain &lt;umang.jain@ideasonboard.com&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Link: https://lore.kernel.org/r/20241016130225.61024-3-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>thunderbolt: Fix connection issue with Pluggable UD-4VPD dock</title>
<updated>2024-11-14T12:21:14+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2024-11-05T07:19:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cfaa2922896867b76e2d6ca5d874fcee53883a6e'/>
<id>urn:sha1:cfaa2922896867b76e2d6ca5d874fcee53883a6e</id>
<content type='text'>
commit bd646c768a934d28e574ee940d6759c7954a024d upstream.

Rick reported that his Pluggable USB4 dock does not work anymore after
upgrading to v6.10 kernel.

It looks like commit c6ca1ac9f472 ("thunderbolt: Increase sideband
access polling delay") makes the device router enumeration happen later
than what might be expected by the dock (although there is no such limit
in the USB4 spec) which probably makes it assume there is something
wrong with the high-speed link and reset it. After the link is reset the
same issue happens again and again.

For this reason lower the sideband access delay from 5ms to 1ms. This
seems to work fine according to Rick's testing.

Reported-by: Rick Lahaye &lt;rick@581238.xyz&gt;
Closes: https://lore.kernel.org/linux-usb/000f01db247b$d10e1520$732a3f60$@581238.xyz/
Tested-by: Rick Lahaye &lt;rick@581238.xyz&gt;
Fixes: c6ca1ac9f472 ("thunderbolt: Increase sideband access polling delay")
Cc: stable@vger.kernel.org
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
