<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/gpu/drm/msm, branch linux-5.10.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>drm/msm: Fix dma_free_attrs() buffer size</title>
<updated>2026-04-18T08:31:00+00:00</updated>
<author>
<name>Thomas Fourier</name>
<email>fourier.thomas@gmail.com</email>
</author>
<published>2026-03-18T16:06:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fc1f99295165f7ec5f851d33986b1d4be73348e4'/>
<id>fc1f99295165f7ec5f851d33986b1d4be73348e4</id>
<content type='text'>
[ Upstream commit e4eb6e4dd6348dd00e19c2275e3fbaed304ca3bd ]

The gpummu-&gt;table buffer is alloc'd with size TABLE_SIZE + 32 in
a2xx_gpummu_new() but freed with size TABLE_SIZE in
a2xx_gpummu_destroy().

Change the free size to match the allocation.

Fixes: c2052a4e5c99 ("drm/msm: implement a2xx mmu")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Thomas Fourier &lt;fourier.thomas@gmail.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/707340/
Message-ID: &lt;20260226095714.12126-2-fourier.thomas@gmail.com&gt;
Signed-off-by: Rob Clark &lt;robin.clark@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&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>
[ Upstream commit e4eb6e4dd6348dd00e19c2275e3fbaed304ca3bd ]

The gpummu-&gt;table buffer is alloc'd with size TABLE_SIZE + 32 in
a2xx_gpummu_new() but freed with size TABLE_SIZE in
a2xx_gpummu_destroy().

Change the free size to match the allocation.

Fixes: c2052a4e5c99 ("drm/msm: implement a2xx mmu")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Thomas Fourier &lt;fourier.thomas@gmail.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/707340/
Message-ID: &lt;20260226095714.12126-2-fourier.thomas@gmail.com&gt;
Signed-off-by: Rob Clark &lt;robin.clark@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm/a6xx: Fix out of bound IO access in a6xx_get_gmu_registers</title>
<updated>2026-01-19T12:11:59+00:00</updated>
<author>
<name>Akhil P Oommen</name>
<email>akhilpo@oss.qualcomm.com</email>
</author>
<published>2025-11-18T08:50:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=96fa4c8c3b31bcc2967d68b82a128cce14ea789e'/>
<id>96fa4c8c3b31bcc2967d68b82a128cce14ea789e</id>
<content type='text'>
commit 779b68a5bf2764c8ed3aa800e41ba0d5d007e1e7 upstream.

REG_A6XX_GMU_AO_AHB_FENCE_CTRL register falls under GMU's register
range. So, use gmu_write() routines to write to this register.

Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state")
Cc: stable@vger.kernel.org
Signed-off-by: Akhil P Oommen &lt;akhilpo@oss.qualcomm.com&gt;
Reviewed-by: Konrad Dybcio &lt;konrad.dybcio@oss.qualcomm.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/688993/
Message-ID: &lt;20251118-kaana-gpu-support-v4-1-86eeb8e93fb6@oss.qualcomm.com&gt;
Signed-off-by: Rob Clark &lt;robin.clark@oss.qualcomm.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 779b68a5bf2764c8ed3aa800e41ba0d5d007e1e7 upstream.

REG_A6XX_GMU_AO_AHB_FENCE_CTRL register falls under GMU's register
range. So, use gmu_write() routines to write to this register.

Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state")
Cc: stable@vger.kernel.org
Signed-off-by: Akhil P Oommen &lt;akhilpo@oss.qualcomm.com&gt;
Reviewed-by: Konrad Dybcio &lt;konrad.dybcio@oss.qualcomm.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/688993/
Message-ID: &lt;20251118-kaana-gpu-support-v4-1-86eeb8e93fb6@oss.qualcomm.com&gt;
Signed-off-by: Rob Clark &lt;robin.clark@oss.qualcomm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm/a6xx: Fix GMU firmware parser</title>
<updated>2025-12-06T21:08:07+00:00</updated>
<author>
<name>Akhil P Oommen</name>
<email>akhilpo@oss.qualcomm.com</email>
</author>
<published>2025-09-10T20:44:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6aad8747e20f7baa29647c625986fc12f6797faf'/>
<id>6aad8747e20f7baa29647c625986fc12f6797faf</id>
<content type='text'>
[ Upstream commit b4789aac9d3441d9f830f0a4022d8dc122d6cab3 ]

Current parser logic for GMU firmware assumes a dword aligned payload
size for every block. This is not true for all GMU firmwares. So, fix
this by using correct 'size' value in the calculation for the offset
for the next block's header.

Fixes: c6ed04f856a4 ("drm/msm/a6xx: A640/A650 GMU firmware path")
Signed-off-by: Akhil P Oommen &lt;akhilpo@oss.qualcomm.com&gt;
Acked-by: Konrad Dybcio &lt;konrad.dybcio@oss.qualcomm.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/674040/
Message-ID: &lt;20250911-assorted-sept-1-v2-2-a8bf1ee20792@oss.qualcomm.com&gt;
Signed-off-by: Rob Clark &lt;robin.clark@oss.qualcomm.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 b4789aac9d3441d9f830f0a4022d8dc122d6cab3 ]

Current parser logic for GMU firmware assumes a dword aligned payload
size for every block. This is not true for all GMU firmwares. So, fix
this by using correct 'size' value in the calculation for the offset
for the next block's header.

Fixes: c6ed04f856a4 ("drm/msm/a6xx: A640/A650 GMU firmware path")
Signed-off-by: Akhil P Oommen &lt;akhilpo@oss.qualcomm.com&gt;
Acked-by: Konrad Dybcio &lt;konrad.dybcio@oss.qualcomm.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/674040/
Message-ID: &lt;20250911-assorted-sept-1-v2-2-a8bf1ee20792@oss.qualcomm.com&gt;
Signed-off-by: Rob Clark &lt;robin.clark@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>minmax: add in_range() macro</title>
<updated>2025-10-29T13:01:15+00:00</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2025-10-17T09:04:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e1fade4cc73c1ccd78c210b5ca0266a63370d978'/>
<id>e1fade4cc73c1ccd78c210b5ca0266a63370d978</id>
<content type='text'>
[ Upstream commit f9bff0e31881d03badf191d3b0005839391f5f2b ]

Patch series "New page table range API", v6.

This patchset changes the API used by the MM to set up page table entries.
The four APIs are:

    set_ptes(mm, addr, ptep, pte, nr)
    update_mmu_cache_range(vma, addr, ptep, nr)
    flush_dcache_folio(folio)
    flush_icache_pages(vma, page, nr)

flush_dcache_folio() isn't technically new, but no architecture
implemented it, so I've done that for them.  The old APIs remain around
but are mostly implemented by calling the new interfaces.

The new APIs are based around setting up N page table entries at once.
The N entries belong to the same PMD, the same folio and the same VMA, so
ptep++ is a legitimate operation, and locking is taken care of for you.
Some architectures can do a better job of it than just a loop, but I have
hesitated to make too deep a change to architectures I don't understand
well.

One thing I have changed in every architecture is that PG_arch_1 is now a
per-folio bit instead of a per-page bit when used for dcache clean/dirty
tracking.  This was something that would have to happen eventually, and it
makes sense to do it now rather than iterate over every page involved in a
cache flush and figure out if it needs to happen.

The point of all this is better performance, and Fengwei Yin has measured
improvement on x86.  I suspect you'll see improvement on your architecture
too.  Try the new will-it-scale test mentioned here:
https://lore.kernel.org/linux-mm/20230206140639.538867-5-fengwei.yin@intel.com/
You'll need to run it on an XFS filesystem and have
CONFIG_TRANSPARENT_HUGEPAGE set.

This patchset is the basis for much of the anonymous large folio work
being done by Ryan, so it's received quite a lot of testing over the last
few months.

This patch (of 38):

Determine if a value lies within a range more efficiently (subtraction +
comparison vs two comparisons and an AND).  It also has useful (under some
circumstances) behaviour if the range exceeds the maximum value of the
type.  Convert all the conflicting definitions of in_range() within the
kernel; some can use the generic definition while others need their own
definition.

Link: https://lkml.kernel.org/r/20230802151406.3735276-1-willy@infradead.org
Link: https://lkml.kernel.org/r/20230802151406.3735276-2-willy@infradead.org
Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Eliav Farber &lt;farbere@amazon.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>
[ Upstream commit f9bff0e31881d03badf191d3b0005839391f5f2b ]

Patch series "New page table range API", v6.

This patchset changes the API used by the MM to set up page table entries.
The four APIs are:

    set_ptes(mm, addr, ptep, pte, nr)
    update_mmu_cache_range(vma, addr, ptep, nr)
    flush_dcache_folio(folio)
    flush_icache_pages(vma, page, nr)

flush_dcache_folio() isn't technically new, but no architecture
implemented it, so I've done that for them.  The old APIs remain around
but are mostly implemented by calling the new interfaces.

The new APIs are based around setting up N page table entries at once.
The N entries belong to the same PMD, the same folio and the same VMA, so
ptep++ is a legitimate operation, and locking is taken care of for you.
Some architectures can do a better job of it than just a loop, but I have
hesitated to make too deep a change to architectures I don't understand
well.

One thing I have changed in every architecture is that PG_arch_1 is now a
per-folio bit instead of a per-page bit when used for dcache clean/dirty
tracking.  This was something that would have to happen eventually, and it
makes sense to do it now rather than iterate over every page involved in a
cache flush and figure out if it needs to happen.

The point of all this is better performance, and Fengwei Yin has measured
improvement on x86.  I suspect you'll see improvement on your architecture
too.  Try the new will-it-scale test mentioned here:
https://lore.kernel.org/linux-mm/20230206140639.538867-5-fengwei.yin@intel.com/
You'll need to run it on an XFS filesystem and have
CONFIG_TRANSPARENT_HUGEPAGE set.

This patchset is the basis for much of the anonymous large folio work
being done by Ryan, so it's received quite a lot of testing over the last
few months.

This patch (of 38):

Determine if a value lies within a range more efficiently (subtraction +
comparison vs two comparisons and an AND).  It also has useful (under some
circumstances) behaviour if the range exceeds the maximum value of the
type.  Convert all the conflicting definitions of in_range() within the
kernel; some can use the generic definition while others need their own
definition.

Link: https://lkml.kernel.org/r/20230802151406.3735276-1-willy@infradead.org
Link: https://lkml.kernel.org/r/20230802151406.3735276-2-willy@infradead.org
Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Eliav Farber &lt;farbere@amazon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm/dpu: don't select single flush for active CTL blocks</title>
<updated>2025-06-27T10:04:17+00:00</updated>
<author>
<name>Dmitry Baryshkov</name>
<email>dmitry.baryshkov@linaro.org</email>
</author>
<published>2025-03-07T06:24:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=58df2f3fedc42732b2701d79e5d0246e700da048'/>
<id>58df2f3fedc42732b2701d79e5d0246e700da048</id>
<content type='text'>
[ Upstream commit e93eee524bb78f3ee4b78654d0083382f98b3d23 ]

In case of ACTIVE CTLs, a single CTL is being used for flushing all INTF
blocks. Don't skip programming the CTL on those targets.

Tested-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt; # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/641585/
Link: https://lore.kernel.org/r/20250307-dpu-active-ctl-v3-5-5d20655f10ca@linaro.org
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.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 e93eee524bb78f3ee4b78654d0083382f98b3d23 ]

In case of ACTIVE CTLs, a single CTL is being used for flushing all INTF
blocks. Don't skip programming the CTL on those targets.

Tested-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt; # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/641585/
Link: https://lore.kernel.org/r/20250307-dpu-active-ctl-v3-5-5d20655f10ca@linaro.org
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm/a6xx: Increase HFI response timeout</title>
<updated>2025-06-27T10:04:16+00:00</updated>
<author>
<name>Akhil P Oommen</name>
<email>quic_akhilpo@quicinc.com</email>
</author>
<published>2025-04-19T14:51:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d60dd3b429400d8e1e9a23ac1e32628300b31c88'/>
<id>d60dd3b429400d8e1e9a23ac1e32628300b31c88</id>
<content type='text'>
[ Upstream commit 5f02f5e78ec9688e29b6857813185b1181796abe ]

When ACD feature is enabled, it triggers some internal calibrations
which result in a pretty long delay during the first HFI perf vote.
So, increase the HFI response timeout to match the downstream driver.

Signed-off-by: Akhil P Oommen &lt;quic_akhilpo@quicinc.com&gt;
Tested-by: Maya Matuszczyk &lt;maccraft123mc@gmail.com&gt;
Tested-by: Anthony Ruhier &lt;aruhier@mailbox.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/649344/
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&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 5f02f5e78ec9688e29b6857813185b1181796abe ]

When ACD feature is enabled, it triggers some internal calibrations
which result in a pretty long delay during the first HFI perf vote.
So, increase the HFI response timeout to match the downstream driver.

Signed-off-by: Akhil P Oommen &lt;quic_akhilpo@quicinc.com&gt;
Tested-by: Maya Matuszczyk &lt;maccraft123mc@gmail.com&gt;
Tested-by: Anthony Ruhier &lt;aruhier@mailbox.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/649344/
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm/hdmi: add runtime PM calls to DDC transfer function</title>
<updated>2025-06-27T10:04:16+00:00</updated>
<author>
<name>Dmitry Baryshkov</name>
<email>dmitry.baryshkov@linaro.org</email>
</author>
<published>2025-05-05T00:14:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=75195e6cc6686f87d4b05fbc15580331750eecf7'/>
<id>75195e6cc6686f87d4b05fbc15580331750eecf7</id>
<content type='text'>
[ Upstream commit 531b4e2c206e5f7dead04d9da84dfa693ac57481 ]

We must be sure that the HDMI controller is powered on, while performing
the DDC transfer. Add corresponding runtime PM calls to
msm_hdmi_i2c_xfer().

Reviewed-by: Jessica Zhang &lt;quic_jesszhan@quicinc.com&gt;
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/651727/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-8-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.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 531b4e2c206e5f7dead04d9da84dfa693ac57481 ]

We must be sure that the HDMI controller is powered on, while performing
the DDC transfer. Add corresponding runtime PM calls to
msm_hdmi_i2c_xfer().

Reviewed-by: Jessica Zhang &lt;quic_jesszhan@quicinc.com&gt;
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/651727/
Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-8-48541f76318c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm/dpu: cast crtc_clk calculation to u64 in _dpu_core_perf_calc_clk()</title>
<updated>2024-12-14T18:47:54+00:00</updated>
<author>
<name>Zichen Xie</name>
<email>zichenxie0106@gmail.com</email>
</author>
<published>2024-10-29T19:42:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=59362f51f4c2cf3b7738293d8a90e62253f0587a'/>
<id>59362f51f4c2cf3b7738293d8a90e62253f0587a</id>
<content type='text'>
[ Upstream commit 20c7b42d9dbd048019bfe0af39229e3014007a98 ]

There may be a potential integer overflow issue in
_dpu_core_perf_calc_clk(). crtc_clk is defined as u64, while
mode-&gt;vtotal, mode-&gt;hdisplay, and drm_mode_vrefresh(mode) are defined as
a smaller data type. The result of the calculation will be limited to
"int" in this case without correct casting. In screen with high
resolution and high refresh rate, integer overflow may happen.
So, we recommend adding an extra cast to prevent potential
integer overflow.

Fixes: c33b7c0389e1 ("drm/msm/dpu: add support for clk and bw scaling for display")
Signed-off-by: Zichen Xie &lt;zichenxie0106@gmail.com&gt;
Reviewed-by: Abhinav Kumar &lt;quic_abhinavk@quicinc.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/622206/
Link: https://lore.kernel.org/r/20241029194209.23684-1-zichenxie0106@gmail.com
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&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 20c7b42d9dbd048019bfe0af39229e3014007a98 ]

There may be a potential integer overflow issue in
_dpu_core_perf_calc_clk(). crtc_clk is defined as u64, while
mode-&gt;vtotal, mode-&gt;hdisplay, and drm_mode_vrefresh(mode) are defined as
a smaller data type. The result of the calculation will be limited to
"int" in this case without correct casting. In screen with high
resolution and high refresh rate, integer overflow may happen.
So, we recommend adding an extra cast to prevent potential
integer overflow.

Fixes: c33b7c0389e1 ("drm/msm/dpu: add support for clk and bw scaling for display")
Signed-off-by: Zichen Xie &lt;zichenxie0106@gmail.com&gt;
Reviewed-by: Abhinav Kumar &lt;quic_abhinavk@quicinc.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/622206/
Link: https://lore.kernel.org/r/20241029194209.23684-1-zichenxie0106@gmail.com
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq()</title>
<updated>2024-12-14T18:47:53+00:00</updated>
<author>
<name>Jinjie Ruan</name>
<email>ruanjinjie@huawei.com</email>
</author>
<published>2024-09-12T08:30:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e5e10c00610db654f5c012876ca8fb410d47a7d9'/>
<id>e5e10c00610db654f5c012876ca8fb410d47a7d9</id>
<content type='text'>
[ Upstream commit 394679f322649d06fea3c646ba65f5a0887f52c3 ]

disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable when request IRQ.

Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Signed-off-by: Jinjie Ruan &lt;ruanjinjie@huawei.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/614075/
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&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 394679f322649d06fea3c646ba65f5a0887f52c3 ]

disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable when request IRQ.

Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Signed-off-by: Jinjie Ruan &lt;ruanjinjie@huawei.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/614075/
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation</title>
<updated>2024-11-08T15:21:57+00:00</updated>
<author>
<name>Jonathan Marek</name>
<email>jonathan@marek.ca</email>
</author>
<published>2024-10-07T05:01:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2c7dd3ca6be9065e6124a0834475a8ff9569655b'/>
<id>2c7dd3ca6be9065e6124a0834475a8ff9569655b</id>
<content type='text'>
[ Upstream commit 358b762400bd94db2a14a72dfcef74c7da6bd845 ]

When (mode-&gt;clock * 1000) is larger than (1&lt;&lt;31), int to unsigned long
conversion will sign extend the int to 64 bits and the pclk_rate value
will be incorrect.

Fix this by making the result of the multiplication unsigned.

Note that above (1&lt;&lt;32) would still be broken and require more changes, but
its unlikely anyone will need that anytime soon.

Fixes: c4d8cfe516dc ("drm/msm/dsi: add implementation for helper functions")
Signed-off-by: Jonathan Marek &lt;jonathan@marek.ca&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reviewed-by: Abhinav Kumar &lt;quic_abhinavk@quicinc.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/618434/
Link: https://lore.kernel.org/r/20241007050157.26855-2-jonathan@marek.ca
Signed-off-by: Abhinav Kumar &lt;quic_abhinavk@quicinc.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 358b762400bd94db2a14a72dfcef74c7da6bd845 ]

When (mode-&gt;clock * 1000) is larger than (1&lt;&lt;31), int to unsigned long
conversion will sign extend the int to 64 bits and the pclk_rate value
will be incorrect.

Fix this by making the result of the multiplication unsigned.

Note that above (1&lt;&lt;32) would still be broken and require more changes, but
its unlikely anyone will need that anytime soon.

Fixes: c4d8cfe516dc ("drm/msm/dsi: add implementation for helper functions")
Signed-off-by: Jonathan Marek &lt;jonathan@marek.ca&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reviewed-by: Abhinav Kumar &lt;quic_abhinavk@quicinc.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/618434/
Link: https://lore.kernel.org/r/20241007050157.26855-2-jonathan@marek.ca
Signed-off-by: Abhinav Kumar &lt;quic_abhinavk@quicinc.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
