<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v6.7.3</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.7.3</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.7.3'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-02-01T00:21:20+00:00</updated>
<entry>
<title>cxl/region：Fix overflow issue in alloc_hpa()</title>
<updated>2024-02-01T00:21:20+00:00</updated>
<author>
<name>Quanquan Cao</name>
<email>caoqq@fujitsu.com</email>
</author>
<published>2024-01-24T09:15:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=026de45cd745028ca0b06c904ffbb99d0c78521a'/>
<id>urn:sha1:026de45cd745028ca0b06c904ffbb99d0c78521a</id>
<content type='text'>
commit d76779dd3681c01a4c6c3cae4d0627c9083e0ee6 upstream.

Creating a region with 16 memory devices caused a problem. The div_u64_rem
function, used for dividing an unsigned 64-bit number by a 32-bit one,
faced an issue when SZ_256M * p-&gt;interleave_ways. The result surpassed
the maximum limit of the 32-bit divisor (4G), leading to an overflow
and a remainder of 0.
note: At this point, p-&gt;interleave_ways is 16, meaning 16 * 256M = 4G

To fix this issue, I replaced the div_u64_rem function with div64_u64_rem
and adjusted the type of the remainder.

Signed-off-by: Quanquan Cao &lt;caoqq@fujitsu.com&gt;
Reviewed-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Fixes: 23a22cd1c98b ("cxl/region: Allocate HPA capacity to regions")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>platform/x86/intel/ifs: Call release_firmware() when handling errors.</title>
<updated>2024-02-01T00:21:20+00:00</updated>
<author>
<name>Jithu Joseph</name>
<email>jithu.joseph@intel.com</email>
</author>
<published>2024-01-25T08:22:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e8931ebb0143dc4a3ad302be6f963ae375548bc0'/>
<id>urn:sha1:e8931ebb0143dc4a3ad302be6f963ae375548bc0</id>
<content type='text'>
[ Upstream commit 8c898ec07a2fc1d4694e81097a48e94a3816308d ]

Missing release_firmware() due to error handling blocked any future image
loading.

Fix the return code and release_fiwmare() to release the bad image.

Fixes: 25a76dbb36dd ("platform/x86/intel/ifs: Validate image size")
Reported-by: Pengfei Xu &lt;pengfei.xu@intel.com&gt;
Signed-off-by: Jithu Joseph &lt;jithu.joseph@intel.com&gt;
Signed-off-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Tested-by: Pengfei Xu &lt;pengfei.xu@intel.com&gt;
Reviewed-by: Tony Luck &lt;tony.luck@intel.com&gt;
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240125082254.424859-2-ashok.raj@intel.com
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm: bridge: samsung-dsim: Don't use FORCE_STOP_STATE</title>
<updated>2024-02-01T00:21:20+00:00</updated>
<author>
<name>Michael Walle</name>
<email>mwalle@kernel.org</email>
</author>
<published>2023-11-13T16:43:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=54ed6fed7cd7ee139dfd40d6818e40b1033e0643'/>
<id>urn:sha1:54ed6fed7cd7ee139dfd40d6818e40b1033e0643</id>
<content type='text'>
[ Upstream commit ff3d5d04db07e5374758baa7e877fde8d683ebab ]

The FORCE_STOP_STATE bit is unsuitable to force the DSI link into LP-11
mode. It seems the bridge internally queues DSI packets and when the
FORCE_STOP_STATE bit is cleared, they are sent in close succession
without any useful timing (this also means that the DSI lanes won't go
into LP-11 mode). The length of this gibberish varies between 1ms and
5ms. This sometimes breaks an attached bridge (TI SN65DSI84 in this
case). In our case, the bridge will fail in about 1 per 500 reboots.

The FORCE_STOP_STATE handling was introduced to have the DSI lanes in
LP-11 state during the .pre_enable phase. But as it turns out, none of
this is needed at all. Between samsung_dsim_init() and
samsung_dsim_set_display_enable() the lanes are already in LP-11 mode.
The code as it was before commit 20c827683de0 ("drm: bridge:
samsung-dsim: Fix init during host transfer") and 0c14d3130654 ("drm:
bridge: samsung-dsim: Fix i.MX8M enable flow to meet spec") was correct
in this regard.

This patch basically reverts both commits. It was tested on an i.MX8M
SoC with an SN65DSI84 bridge. The signals were probed and the DSI
packets were decoded during initialization and link start-up. After this
patch the first DSI packet on the link is a VSYNC packet and the timing
is correct.

Command mode between .pre_enable and .enable was also briefly tested by
a quick hack. There was no DSI link partner which would have responded,
but it was made sure the DSI packet was send on the link. As a side
note, the command mode seems to just work in HS mode. I couldn't find
that the bridge will handle commands in LP mode.

Fixes: 20c827683de0 ("drm: bridge: samsung-dsim: Fix init during host transfer")
Fixes: 0c14d3130654 ("drm: bridge: samsung-dsim: Fix i.MX8M enable flow to meet spec")
Signed-off-by: Michael Walle &lt;mwalle@kernel.org&gt;
Signed-off-by: Inki Dae &lt;inki.dae@samsung.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20231113164344.1612602-1-mwalle@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: fix finalize message on error return</title>
<updated>2024-02-01T00:21:20+00:00</updated>
<author>
<name>David Lechner</name>
<email>dlechner@baylibre.com</email>
</author>
<published>2024-01-25T20:53:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=19d73c253a444d2005a914d840822959eb5db8de'/>
<id>urn:sha1:19d73c253a444d2005a914d840822959eb5db8de</id>
<content type='text'>
[ Upstream commit 8c2ae772fe08e33f3d7a83849e85539320701abd ]

In __spi_pump_transfer_message(), the message was not finalized in the
first error return as it is in the other error return paths. Not
finalizing the message could cause anything waiting on the message to
complete to hang forever.

This adds the missing call to spi_finalize_current_message().

Fixes: ae7d2346dc89 ("spi: Don't use the message queue if possible in spi_sync")
Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
Link: https://msgid.link/r/20240125205312.3458541-2-dlechner@baylibre.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: spi-cadence: Reverse the order of interleaved write and read operations</title>
<updated>2024-02-01T00:21:20+00:00</updated>
<author>
<name>Amit Kumar Mahapatra</name>
<email>amit.kumar-mahapatra@amd.com</email>
</author>
<published>2023-12-18T09:06:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1bda88547390761e12a5609742819cca8dbd2e77'/>
<id>urn:sha1:1bda88547390761e12a5609742819cca8dbd2e77</id>
<content type='text'>
[ Upstream commit 633cd6fe6e1993ba80e0954c2db127a0b1a3e66f ]

In the existing implementation, when executing interleaved write and read
operations in the ISR for a transfer length greater than the FIFO size,
the TXFIFO write precedes the RXFIFO read. Consequently, the initially
received data in the RXFIFO is pushed out and lost, leading to a failure
in data integrity. To address this issue, reverse the order of interleaved
operations and conduct the RXFIFO read followed by the TXFIFO write.

Fixes: 6afe2ae8dc48 ("spi: spi-cadence: Interleave write of TX and read of RX FIFO")
Signed-off-by: Amit Kumar Mahapatra &lt;amit.kumar-mahapatra@amd.com&gt;
Link: https://msgid.link/r/20231218090652.18403-1-amit.kumar-mahapatra@amd.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: bcm-qspi: fix SFDP BFPT read by usig mspi read</title>
<updated>2024-02-01T00:21:20+00:00</updated>
<author>
<name>Kamal Dasu</name>
<email>kamal.dasu@broadcom.com</email>
</author>
<published>2024-01-09T21:00:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aa1408093e378d8d951550d8514b0b23a21d702a'/>
<id>urn:sha1:aa1408093e378d8d951550d8514b0b23a21d702a</id>
<content type='text'>
[ Upstream commit 574bf7bbe83794a902679846770f75a9b7f28176 ]

SFDP read shall use the mspi reads when using the bcm_qspi_exec_mem_op()
call. This fixes SFDP parameter page read failures seen with parts that
now use SFDP protocol to read the basic flash parameter table.

Fixes: 5f195ee7d830 ("spi: bcm-qspi: Implement the spi_mem interface")
Signed-off-by: Kamal Dasu &lt;kamal.dasu@broadcom.com&gt;
Tested-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Reviewed-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Link: https://msgid.link/r/20240109210033.43249-1-kamal.dasu@broadcom.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>cpufreq/amd-pstate: Fix setting scaling max/min freq values</title>
<updated>2024-02-01T00:21:20+00:00</updated>
<author>
<name>Mario Limonciello</name>
<email>mario.limonciello@amd.com</email>
</author>
<published>2024-01-19T11:33:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c794cc65bb3eef3142bbecd48f1fd43f1fa8d478'/>
<id>urn:sha1:c794cc65bb3eef3142bbecd48f1fd43f1fa8d478</id>
<content type='text'>
[ Upstream commit 22fb4f041999f5f16ecbda15a2859b4ef4cbf47e ]

Scaling min/max freq values were being cached and lagging a setting
each time.  Fix the ordering of the clamp call to ensure they work.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217931
Fixes: febab20caeba ("cpufreq/amd-pstate: Fix scaling_min_freq and scaling_max_freq update")
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Reviewed-by: Wyes Karny &lt;wkarny@gmail.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: anx7625: Ensure bridge is suspended in disable()</title>
<updated>2024-02-01T00:21:20+00:00</updated>
<author>
<name>Hsin-Yi Wang</name>
<email>hsinyi@chromium.org</email>
</author>
<published>2024-01-18T01:58:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c44ec974b4d15fcf426770f1f3a91a3f09a41594'/>
<id>urn:sha1:c44ec974b4d15fcf426770f1f3a91a3f09a41594</id>
<content type='text'>
[ Upstream commit 4d5b7daa3c610af3f322ad1e91fc0c752ff32f0e ]

Similar to commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge
is suspended in .post_disable()"). Add a mutex to ensure that aux transfer
won't race with atomic_disable by holding the PM reference and prevent
the bridge from suspend.

Also we need to use pm_runtime_put_sync_suspend() to suspend the bridge
instead of idle with pm_runtime_put_sync().

Fixes: 3203e497eb76 ("drm/bridge: anx7625: Synchronously run runtime suspend.")
Fixes: adca62ec370c ("drm/bridge: anx7625: Support reading edid through aux channel")
Signed-off-by: Hsin-Yi Wang &lt;hsinyi@chromium.org&gt;
Tested-by: Xuxin Xiong &lt;xuxinxiong@huaqin.corp-partner.google.com&gt;
Reviewed-by: Pin-yen Lin &lt;treapking@chromium.org&gt;
Reviewed-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240118015916.2296741-1-hsinyi@chromium.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: intel-pci: Remove Meteor Lake-S SoC PCI ID from the list</title>
<updated>2024-02-01T00:21:19+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2024-01-22T12:00:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=821acbb1dffbf830685e3333461b57cb4d849c7b'/>
<id>urn:sha1:821acbb1dffbf830685e3333461b57cb4d849c7b</id>
<content type='text'>
[ Upstream commit 6c314425b9ef6b247cefd0903e287eb072580c3b ]

Turns out this "SoC" side controller does not support certain commands,
such as reading chip JEDEC ID, so the controller is pretty much unusable
in Linux. We should be using the "PCH" side controller instead. For this
reason remove this PCI ID from the list.

Fixes: c2912d42e86e ("spi: intel-pci: Add support for Meteor Lake-S SPI serial flash")
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Link: https://msgid.link/r/20240122120034.2664812-2-mika.westerberg@linux.intel.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/mellanox: mlxbf-pmc: Fix offset calculation for crspace events</title>
<updated>2024-02-01T00:21:19+00:00</updated>
<author>
<name>Shravan Kumar Ramani</name>
<email>shravankr@nvidia.com</email>
</author>
<published>2024-01-17T10:01:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c34b46598069fa3439c253fdae756d6062c0f314'/>
<id>urn:sha1:c34b46598069fa3439c253fdae756d6062c0f314</id>
<content type='text'>
[ Upstream commit 732c35ce6d4892f7b07cc9aca61a6ad0fd400a26 ]

The event selector fields for 2 counters are contained in one
32-bit register and the current logic does not account for this.

Fixes: 423c3361855c ("platform/mellanox: mlxbf-pmc: Add support for BlueField-3")
Signed-off-by: Shravan Kumar Ramani &lt;shravankr@nvidia.com&gt;
Reviewed-by: David Thompson &lt;davthompson@nvidia.com&gt;
Reviewed-by: Vadim Pasternak &lt;vadimp@nvidia.com&gt;
Link: https://lore.kernel.org/r/8834cfa496c97c7c2fcebcfca5a2aa007e20ae96.1705485095.git.shravankr@nvidia.com
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
