<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/misc, branch linux-6.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>eeprom: digsy_mtc: Fix 93xx46 driver probe failure</title>
<updated>2024-09-18T17:25:13+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2024-05-08T18:46:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=556c31259cdd98865f4fd2a6ae9b0b685fc6a562'/>
<id>556c31259cdd98865f4fd2a6ae9b0b685fc6a562</id>
<content type='text'>
[ Upstream commit 2b82641ad0620b2d71dc05024b20f82db7e1c0b6 ]

The update to support other (bigger) types of EEPROMs broke
the driver loading due to removal of the default size.

Fix this by adding the respective (new) flag to the platform data.

Fixes: 14374fbb3f06 ("misc: eeprom_93xx46: Add new 93c56 and 93c66 compatible strings")
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240508184905.2102633-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.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 2b82641ad0620b2d71dc05024b20f82db7e1c0b6 ]

The update to support other (bigger) types of EEPROMs broke
the driver loading due to removal of the default size.

Fix this by adding the respective (new) flag to the platform data.

Fixes: 14374fbb3f06 ("misc: eeprom_93xx46: Add new 93c56 and 93c66 compatible strings")
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240508184905.2102633-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>VMCI: Fix use-after-free when removing resource in vmci_resource_remove()</title>
<updated>2024-09-12T09:13:07+00:00</updated>
<author>
<name>David Fernandez Gonzalez</name>
<email>david.fernandez.gonzalez@oracle.com</email>
</author>
<published>2024-08-28T15:43:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=00fe5292f081f8d773e572df8e03bf6e1855fe49'/>
<id>00fe5292f081f8d773e572df8e03bf6e1855fe49</id>
<content type='text'>
commit 48b9a8dabcc3cf5f961b2ebcd8933bf9204babb7 upstream.

When removing a resource from vmci_resource_table in
vmci_resource_remove(), the search is performed using the resource
handle by comparing context and resource fields.

It is possible though to create two resources with different types
but same handle (same context and resource fields).

When trying to remove one of the resources, vmci_resource_remove()
may not remove the intended one, but the object will still be freed
as in the case of the datagram type in vmci_datagram_destroy_handle().
vmci_resource_table will still hold a pointer to this freed resource
leading to a use-after-free vulnerability.

BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106
 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239
 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425
 kasan_report+0x38/0x51 mm/kasan/report.c:442
 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
 vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182
 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444
 kref_put include/linux/kref.h:65 [inline]
 vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]
 vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195
 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143
 __fput+0x261/0xa34 fs/file_table.c:282
 task_work_run+0xf0/0x194 kernel/task_work.c:164
 tracehook_notify_resume include/linux/tracehook.h:189 [inline]
 exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187
 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220
 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]
 syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313
 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x6e/0x0

This change ensures the type is also checked when removing
the resource from vmci_resource_table in vmci_resource_remove().

Fixes: bc63dedb7d46 ("VMCI: resource object implementation.")
Cc: stable@vger.kernel.org
Reported-by: George Kennedy &lt;george.kennedy@oracle.com&gt;
Signed-off-by: David Fernandez Gonzalez &lt;david.fernandez.gonzalez@oracle.com&gt;
Link: https://lore.kernel.org/r/20240828154338.754746-1-david.fernandez.gonzalez@oracle.com
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 48b9a8dabcc3cf5f961b2ebcd8933bf9204babb7 upstream.

When removing a resource from vmci_resource_table in
vmci_resource_remove(), the search is performed using the resource
handle by comparing context and resource fields.

It is possible though to create two resources with different types
but same handle (same context and resource fields).

When trying to remove one of the resources, vmci_resource_remove()
may not remove the intended one, but the object will still be freed
as in the case of the datagram type in vmci_datagram_destroy_handle().
vmci_resource_table will still hold a pointer to this freed resource
leading to a use-after-free vulnerability.

BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106
 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239
 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425
 kasan_report+0x38/0x51 mm/kasan/report.c:442
 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
 vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182
 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444
 kref_put include/linux/kref.h:65 [inline]
 vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]
 vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195
 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143
 __fput+0x261/0xa34 fs/file_table.c:282
 task_work_run+0xf0/0x194 kernel/task_work.c:164
 tracehook_notify_resume include/linux/tracehook.h:189 [inline]
 exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187
 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220
 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]
 syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313
 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x6e/0x0

This change ensures the type is also checked when removing
the resource from vmci_resource_table in vmci_resource_remove().

Fixes: bc63dedb7d46 ("VMCI: resource object implementation.")
Cc: stable@vger.kernel.org
Reported-by: George Kennedy &lt;george.kennedy@oracle.com&gt;
Signed-off-by: David Fernandez Gonzalez &lt;david.fernandez.gonzalez@oracle.com&gt;
Link: https://lore.kernel.org/r/20240828154338.754746-1-david.fernandez.gonzalez@oracle.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>misc: fastrpc: Fix double free of 'buf' in error path</title>
<updated>2024-09-12T09:13:07+00:00</updated>
<author>
<name>Sukrut Bellary</name>
<email>sukrut.bellary@linux.com</email>
</author>
<published>2024-09-02T14:14:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bfc1704d909dc9911a558b1a5833d3d61a43a1f2'/>
<id>bfc1704d909dc9911a558b1a5833d3d61a43a1f2</id>
<content type='text'>
commit e8c276d4dc0e19ee48385f74426aebc855b49aaf upstream.

smatch warning:
drivers/misc/fastrpc.c:1926 fastrpc_req_mmap() error: double free of 'buf'

In fastrpc_req_mmap() error path, the fastrpc buffer is freed in
fastrpc_req_munmap_impl() if unmap is successful.

But in the end, there is an unconditional call to fastrpc_buf_free().
So the above case triggers the double free of fastrpc buf.

Fixes: 72fa6f7820c4 ("misc: fastrpc: Rework fastrpc_req_munmap")
Reviewed-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Reviewed-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Signed-off-by: Sukrut Bellary &lt;sukrut.bellary@linux.com&gt;
Signed-off-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Cc: stable &lt;stable@kernel.org&gt;
Link: https://lore.kernel.org/r/20240902141409.70371-2-srinivas.kandagatla@linaro.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 e8c276d4dc0e19ee48385f74426aebc855b49aaf upstream.

smatch warning:
drivers/misc/fastrpc.c:1926 fastrpc_req_mmap() error: double free of 'buf'

In fastrpc_req_mmap() error path, the fastrpc buffer is freed in
fastrpc_req_munmap_impl() if unmap is successful.

But in the end, there is an unconditional call to fastrpc_buf_free().
So the above case triggers the double free of fastrpc buf.

Fixes: 72fa6f7820c4 ("misc: fastrpc: Rework fastrpc_req_munmap")
Reviewed-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Reviewed-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Signed-off-by: Sukrut Bellary &lt;sukrut.bellary@linux.com&gt;
Signed-off-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Cc: stable &lt;stable@kernel.org&gt;
Link: https://lore.kernel.org/r/20240902141409.70371-2-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "misc: fastrpc: Restrict untrusted app to attach to privileged PD"</title>
<updated>2024-08-29T15:35:34+00:00</updated>
<author>
<name>Griffin Kroah-Hartman</name>
<email>griffin@kroah.com</email>
</author>
<published>2024-08-15T09:49:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2eb973ee4770a26d9b5e292b58ad29822d321c7f'/>
<id>2eb973ee4770a26d9b5e292b58ad29822d321c7f</id>
<content type='text'>
commit 9bb5e74b2bf88fbb024bb15ded3b011e02c673be upstream.

This reverts commit bab2f5e8fd5d2f759db26b78d9db57412888f187.

Joel reported that this commit breaks userspace and stops sensors in
SDM845 from working. Also breaks other qcom SoC devices running postmarketOS.

Cc: stable &lt;stable@kernel.org&gt;
Cc: Ekansh Gupta &lt;quic_ekangupt@quicinc.com&gt;
Cc: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reported-by: Joel Selvaraj &lt;joelselvaraj.oss@gmail.com&gt;
Link: https://lore.kernel.org/r/9a9f5646-a554-4b65-8122-d212bb665c81@umsystem.edu
Signed-off-by: Griffin Kroah-Hartman &lt;griffin@kroah.com&gt;
Acked-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Fixes: bab2f5e8fd5d ("misc: fastrpc: Restrict untrusted app to attach to privileged PD")
Link: https://lore.kernel.org/r/20240815094920.8242-1-griffin@kroah.com
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 9bb5e74b2bf88fbb024bb15ded3b011e02c673be upstream.

This reverts commit bab2f5e8fd5d2f759db26b78d9db57412888f187.

Joel reported that this commit breaks userspace and stops sensors in
SDM845 from working. Also breaks other qcom SoC devices running postmarketOS.

Cc: stable &lt;stable@kernel.org&gt;
Cc: Ekansh Gupta &lt;quic_ekangupt@quicinc.com&gt;
Cc: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reported-by: Joel Selvaraj &lt;joelselvaraj.oss@gmail.com&gt;
Link: https://lore.kernel.org/r/9a9f5646-a554-4b65-8122-d212bb665c81@umsystem.edu
Signed-off-by: Griffin Kroah-Hartman &lt;griffin@kroah.com&gt;
Acked-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Fixes: bab2f5e8fd5d ("misc: fastrpc: Restrict untrusted app to attach to privileged PD")
Link: https://lore.kernel.org/r/20240815094920.8242-1-griffin@kroah.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>eeprom: ee1004: Call i2c_new_scanned_device to instantiate thermal sensor</title>
<updated>2024-08-03T07:00:14+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2024-06-29T17:37:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1f2ff6935b6dee494d1cbaad74418889c3388aac'/>
<id>1f2ff6935b6dee494d1cbaad74418889c3388aac</id>
<content type='text'>
[ Upstream commit 249b4deaff71cfc6ac9a8e436af876be6d84052b ]

Instantiating a device by calling i2c_new_client_device() assumes that the
device is not already instantiated. If that is not the case, it will return
an error and generate a misleading kernel log message.

i2c i2c-0: Failed to register i2c client jc42 at 0x18 (-16)

This can be reproduced by unloading the ee1004 driver and loading it again.

Avoid this by calling i2c_new_scanned_device() instead, which returns
silently if a device is already instantiated or does not exist.

Fixes: 393bd1000f81 ("eeprom: ee1004: add support for temperature sensor")
Cc: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Cc: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Link: https://lore.kernel.org/r/20240629173716.20389-1-linux@roeck-us.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.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 249b4deaff71cfc6ac9a8e436af876be6d84052b ]

Instantiating a device by calling i2c_new_client_device() assumes that the
device is not already instantiated. If that is not the case, it will return
an error and generate a misleading kernel log message.

i2c i2c-0: Failed to register i2c client jc42 at 0x18 (-16)

This can be reproduced by unloading the ee1004 driver and loading it again.

Avoid this by calling i2c_new_scanned_device() instead, which returns
silently if a device is already instantiated or does not exist.

Fixes: 393bd1000f81 ("eeprom: ee1004: add support for temperature sensor")
Cc: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Cc: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Link: https://lore.kernel.org/r/20240629173716.20389-1-linux@roeck-us.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mei: vsc: Fix spelling error</title>
<updated>2024-07-04T10:21:39+00:00</updated>
<author>
<name>Wentong Wu</name>
<email>wentong.wu@intel.com</email>
</author>
<published>2024-06-25T08:10:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=389637d4fb5fee40e8a0f2bfd31583f6768ef792'/>
<id>389637d4fb5fee40e8a0f2bfd31583f6768ef792</id>
<content type='text'>
Fix a spelling error in a comment.

Signed-off-by: Wentong Wu &lt;wentong.wu@intel.com&gt;
Tested-by: Jason Chen &lt;jason.z.chen@intel.com&gt;
Acked-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240625081047.4178494-6-wentong.wu@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix a spelling error in a comment.

Signed-off-by: Wentong Wu &lt;wentong.wu@intel.com&gt;
Tested-by: Jason Chen &lt;jason.z.chen@intel.com&gt;
Acked-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240625081047.4178494-6-wentong.wu@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mei: vsc: Enhance SPI transfer of IVSC ROM</title>
<updated>2024-07-04T10:21:39+00:00</updated>
<author>
<name>Wentong Wu</name>
<email>wentong.wu@intel.com</email>
</author>
<published>2024-06-25T08:10:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=43407254b8a36638bb2efa737a510c96e573aafd'/>
<id>43407254b8a36638bb2efa737a510c96e573aafd</id>
<content type='text'>
Before downloading firmware, a command response is required to
identify the silicon. However, when downloading IVSC firmware,
reading data from the SPI transfers with the IVSC ROM is not
necessary. Therefore, the rx buffer of SPI transfer command is
determined based on the specific request of the caller.

Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Signed-off-by: Wentong Wu &lt;wentong.wu@intel.com&gt;
Tested-by: Jason Chen &lt;jason.z.chen@intel.com&gt;
Acked-by: Tomas Winker &lt;tomas.winker@intel.com&gt;
Acked-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240625081047.4178494-5-wentong.wu@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before downloading firmware, a command response is required to
identify the silicon. However, when downloading IVSC firmware,
reading data from the SPI transfers with the IVSC ROM is not
necessary. Therefore, the rx buffer of SPI transfer command is
determined based on the specific request of the caller.

Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Signed-off-by: Wentong Wu &lt;wentong.wu@intel.com&gt;
Tested-by: Jason Chen &lt;jason.z.chen@intel.com&gt;
Acked-by: Tomas Winker &lt;tomas.winker@intel.com&gt;
Acked-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240625081047.4178494-5-wentong.wu@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mei: vsc: Utilize the appropriate byte order swap function</title>
<updated>2024-07-04T10:21:39+00:00</updated>
<author>
<name>Wentong Wu</name>
<email>wentong.wu@intel.com</email>
</author>
<published>2024-06-25T08:10:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a896a8a127f45d00fb69fa7536955aa9b2e5d610'/>
<id>a896a8a127f45d00fb69fa7536955aa9b2e5d610</id>
<content type='text'>
Switch from cpu_to_be32_array() to be32_to_cpu_array() for the
received ROM data.

Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Cc: stable@vger.kernel.org # for 6.8+
Signed-off-by: Wentong Wu &lt;wentong.wu@intel.com&gt;
Tested-by: Jason Chen &lt;jason.z.chen@intel.com&gt;
Acked-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240625081047.4178494-4-wentong.wu@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Switch from cpu_to_be32_array() to be32_to_cpu_array() for the
received ROM data.

Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Cc: stable@vger.kernel.org # for 6.8+
Signed-off-by: Wentong Wu &lt;wentong.wu@intel.com&gt;
Tested-by: Jason Chen &lt;jason.z.chen@intel.com&gt;
Acked-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240625081047.4178494-4-wentong.wu@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mei: vsc: Prevent timeout error with added delay post-firmware download</title>
<updated>2024-07-04T10:21:39+00:00</updated>
<author>
<name>Wentong Wu</name>
<email>wentong.wu@intel.com</email>
</author>
<published>2024-06-25T08:10:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a9e8fe38195ae6f8e5b32907a17b397ff3ce3e48'/>
<id>a9e8fe38195ae6f8e5b32907a17b397ff3ce3e48</id>
<content type='text'>
After completing the firmware download, the firmware requires some
time to become functional. This change introduces additional sleep
time before the first read operation to prevent a confusing timeout
error in vsc_tp_xfer().

Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Cc: stable@vger.kernel.org # for 6.8+
Signed-off-by: Wentong Wu &lt;wentong.wu@intel.com&gt;
Tested-by: Jason Chen &lt;jason.z.chen@intel.com&gt;
Acked-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240625081047.4178494-3-wentong.wu@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After completing the firmware download, the firmware requires some
time to become functional. This change introduces additional sleep
time before the first read operation to prevent a confusing timeout
error in vsc_tp_xfer().

Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Cc: stable@vger.kernel.org # for 6.8+
Signed-off-by: Wentong Wu &lt;wentong.wu@intel.com&gt;
Tested-by: Jason Chen &lt;jason.z.chen@intel.com&gt;
Acked-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240625081047.4178494-3-wentong.wu@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mei: vsc: Enhance IVSC chipset stability during warm reboot</title>
<updated>2024-07-04T10:21:39+00:00</updated>
<author>
<name>Wentong Wu</name>
<email>wentong.wu@intel.com</email>
</author>
<published>2024-06-25T08:10:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=07de60a46ae9c0583df1c644bae6d3b22d1d903d'/>
<id>07de60a46ae9c0583df1c644bae6d3b22d1d903d</id>
<content type='text'>
During system shutdown, incorporate reset logic to ensure the IVSC
chipset remains in a valid state. This adjustment guarantees that
the IVSC chipset operates in a known state following a warm reboot.

Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Cc: stable@vger.kernel.org # for 6.8+
Signed-off-by: Wentong Wu &lt;wentong.wu@intel.com&gt;
Tested-by: Jason Chen &lt;jason.z.chen@intel.com&gt;
Acked-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240625081047.4178494-2-wentong.wu@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
During system shutdown, incorporate reset logic to ensure the IVSC
chipset remains in a valid state. This adjustment guarantees that
the IVSC chipset operates in a known state following a warm reboot.

Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Cc: stable@vger.kernel.org # for 6.8+
Signed-off-by: Wentong Wu &lt;wentong.wu@intel.com&gt;
Tested-by: Jason Chen &lt;jason.z.chen@intel.com&gt;
Acked-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240625081047.4178494-2-wentong.wu@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
