<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v6.10.6</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.10.6</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.10.6'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2024-08-19T04:05:40Z</updated>
<entry>
<title>Linux 6.10.6</title>
<updated>2024-08-19T04:05:40Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2024-08-19T04:05:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7ba498d9d1bb67bcbc2a79f19a9054cdc8b95098'/>
<id>urn:sha1:7ba498d9d1bb67bcbc2a79f19a9054cdc8b95098</id>
<content type='text'>
Link: https://lore.kernel.org/r/20240815131831.265729493@linuxfoundation.org
Tested-by: Ronald Warsow &lt;rwarsow@gmx.de&gt;
Tested-By: Kevin Holm &lt;kevin@holm.dev&gt;
Tested-by: Justin M. Forbes &lt;jforbes@fedoraproject.org&gt;
Tested-by: Markus Reichelt &lt;lkt+2023@mareichelt.com&gt;
Tested-by: Peter Schneider &lt;pschneider1968@googlemail.com&gt;
Tested-by: Pavel Machek (CIP) &lt;pavel@denx.de&gt;                              =
Tested-by: Salvatore Bonaccorso &lt;carnil@debian.org&gt;
Tested-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Tested-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Tested-by: Christian Heusel &lt;christian@heusel.eu&gt;
Link: https://lore.kernel.org/r/20240816085226.888902473@linuxfoundation.org
Tested-by: Ronald Warsow &lt;rwarsow@gmx.de&gt;
Tested-by: Mark Brown &lt;broonie@kernel.org&gt;
Tested-by: Markus Reichelt &lt;lkt+2023@mareichelt.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Ron Economos &lt;re@w6rz.net&gt;
Tested-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Tested-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Tested-by: Peter Schneider &lt;pschneider1968@googlemail.com&gt;
Tested-by: Allen Pais &lt;apais@linux.microsoft.com&gt;
Link: https://lore.kernel.org/r/20240817085406.129098889@linuxfoundation.org
Tested-by: Ronald Warsow &lt;rwarsow@gmx.de&gt;
Tested-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "drm/amd/display: Refactor function dm_dp_mst_is_port_support_mode()"</title>
<updated>2024-08-19T04:05:40Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2024-08-17T08:39:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4676556ae4a152e4eb779106d8e81b89d6435e2b'/>
<id>urn:sha1:4676556ae4a152e4eb779106d8e81b89d6435e2b</id>
<content type='text'>
This reverts commit 6b2fb172853261829229237766d078638267042f which is
commit fa57924c76d995e87ca3533ec60d1d5e55769a27 upstream.

It breaks the build on arm64 and arm systems, and trying to unwind the
ifdef mess to fix it up was not simple at all.  So revert it and wait
for a fixed change to come back.

Cc: Jerry Zuo &lt;jerry.zuo@amd.com&gt;
Cc: Zaeem Mohamed &lt;zaeem.mohamed@amd.com&gt;
Cc: Wayne Lin &lt;wayne.lin@amd.com&gt;
Cc: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: Kevin Holm &lt;kevin@holm.dev&gt;
Reported-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Link: https://lore.kernel.org/r/b27c5434-f1b1-4697-985b-91bb3e9a22df@roeck-us.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "ata: libata-scsi: Honor the D_SENSE bit for CK_COND=1 and no error"</title>
<updated>2024-08-19T04:05:40Z</updated>
<author>
<name>Niklas Cassel</name>
<email>cassel@kernel.org</email>
</author>
<published>2024-08-13T13:19:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=64cd57692a29679a61ec43f3c7c07735d6bdbc31'/>
<id>urn:sha1:64cd57692a29679a61ec43f3c7c07735d6bdbc31</id>
<content type='text'>
commit fa0db8e568787c665384430eaf2221b299b85367 upstream.

This reverts commit 28ab9769117ca944cb6eb537af5599aa436287a4.

Sense data can be in either fixed format or descriptor format.

SAT-6 revision 1, "10.4.6 Control mode page", defines the D_SENSE bit:
"The SATL shall support this bit as defined in SPC-5 with the following
exception: if the D_ SENSE bit is set to zero (i.e., fixed format sense
data), then the SATL should return fixed format sense data for ATA
PASS-THROUGH commands."

The libata SATL has always kept D_SENSE set to zero by default. (It is
however possible to change the value using a MODE SELECT SG_IO command.)

Failed ATA PASS-THROUGH commands correctly respected the D_SENSE bit,
however, successful ATA PASS-THROUGH commands incorrectly returned the
sense data in descriptor format (regardless of the D_SENSE bit).

Commit 28ab9769117c ("ata: libata-scsi: Honor the D_SENSE bit for
CK_COND=1 and no error") fixed this bug for successful ATA PASS-THROUGH
commands.

However, after commit 28ab9769117c ("ata: libata-scsi: Honor the D_SENSE
bit for CK_COND=1 and no error"), there were bug reports that hdparm,
hddtemp, and udisks were no longer working as expected.

These applications incorrectly assume the returned sense data is in
descriptor format, without even looking at the RESPONSE CODE field in the
returned sense data (to see which format the returned sense data is in).

Considering that there will be broken versions of these applications around
roughly forever, we are stuck with being bug compatible with older kernels.

Cc: stable@vger.kernel.org # 4.19+
Reported-by: Stephan Eisvogel &lt;eisvogel@seitics.de&gt;
Reported-by: Christian Heusel &lt;christian@heusel.eu&gt;
Closes: https://lore.kernel.org/linux-ide/0bf3f2f0-0fc6-4ba5-a420-c0874ef82d64@heusel.eu/
Fixes: 28ab9769117c ("ata: libata-scsi: Honor the D_SENSE bit for CK_COND=1 and no error")
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Link: https://lore.kernel.org/r/20240813131900.1285842-2-cassel@kernel.org
Signed-off-by: Niklas Cassel &lt;cassel@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>media: Revert "media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()"</title>
<updated>2024-08-19T04:05:40Z</updated>
<author>
<name>Sean Young</name>
<email>sean@mess.org</email>
</author>
<published>2024-08-08T08:35:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=bebe9a9c9c025d273b6218d8b8483f98630adfae'/>
<id>urn:sha1:bebe9a9c9c025d273b6218d8b8483f98630adfae</id>
<content type='text'>
commit 0c84bde4f37ba27d50e4c70ecacd33fe4a57030d upstream.

This reverts commit 2052138b7da52ad5ccaf74f736d00f39a1c9198c.

This breaks the TeVii s480 dual DVB-S2 S660. The device has a bulk in
endpoint but no corresponding out endpoint, so the device does not pass
the "has both receive and send bulk endpoint" test.

Seemingly this device does not use dvb_usb_generic_rw() so I have tried
removing the generic_bulk_ctrl_endpoint entry, but this resulted in
different problems.

As we have no explanation yet, revert.

$ dmesg | grep -i -e dvb -e dw21 -e usb\ 4
[    0.999122] usb 1-1: new high-speed USB device number 2 using ehci-pci
[    1.023123] usb 4-1: new high-speed USB device number 2 using ehci-pci
[    1.130247] usb 1-1: New USB device found, idVendor=9022, idProduct=d482,
+bcdDevice= 0.01
[    1.130257] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.152323] usb 4-1: New USB device found, idVendor=9022, idProduct=d481,
+bcdDevice= 0.01
[    1.152329] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    6.701033] dvb-usb: found a 'TeVii S480.2 USB' in cold state, will try to
+load a firmware
[    6.701178] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw'
[    6.701179] dw2102: start downloading DW210X firmware
[    6.703715] dvb-usb: found a 'Microsoft Xbox One Digital TV Tuner' in cold
+state, will try to load a firmware
[    6.703974] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw'
[    6.756432] usb 1-1: USB disconnect, device number 2
[    6.862119] dvb-usb: found a 'TeVii S480.2 USB' in warm state.
[    6.862194] dvb-usb: TeVii S480.2 USB error while loading driver (-22)
[    6.862209] dvb-usb: found a 'TeVii S480.1 USB' in cold state, will try to
+load a firmware
[    6.862244] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw'
[    6.862245] dw2102: start downloading DW210X firmware
[    6.914811] usb 4-1: USB disconnect, device number 2
[    7.014131] dvb-usb: found a 'TeVii S480.1 USB' in warm state.
[    7.014487] dvb-usb: TeVii S480.1 USB error while loading driver (-22)
[    7.014538] usbcore: registered new interface driver dw2102

Closes: https://lore.kernel.org/stable/20240801165146.38991f60@mir/

Fixes: 2052138b7da5 ("media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()")
Reported-by: Stefan Lippers-Hollmann &lt;s.l-h@gmx.de&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu/display: Fix null pointer dereference in dc_stream_program_cursor_position</title>
<updated>2024-08-19T04:05:40Z</updated>
<author>
<name>Srinivasan Shanmugam</name>
<email>srinivasan.shanmugam@amd.com</email>
</author>
<published>2024-05-22T15:24:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1cb249cf1c9bf043b042956888230db145250059'/>
<id>urn:sha1:1cb249cf1c9bf043b042956888230db145250059</id>
<content type='text'>
commit fa4c500ce93f4f933c38e6d6388970e121e27b21 upstream.

The fix involves adding a null check for 'stream' at the beginning of
the function. If 'stream' is NULL, the function immediately returns
false. This ensures that 'stream' is not NULL when we dereference it to
access 'ctx' in 'dc = stream-&gt;ctx-&gt;dc;' the function.

Fixes the below:
	drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:398 dc_stream_program_cursor_position()
	error: we previously assumed 'stream' could be null (see line 397)

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c
    389 bool dc_stream_program_cursor_position(
    390         struct dc_stream_state *stream,
    391         const struct dc_cursor_position *position)
    392 {
    393         struct dc *dc;
    394         bool reset_idle_optimizations = false;
    395         const struct dc_cursor_position *old_position;
    396
    397         old_position = stream ? &amp;stream-&gt;cursor_position : NULL;
                               ^^^^^^^^
The patch adds a NULL check

--&gt; 398         dc = stream-&gt;ctx-&gt;dc;
                     ^^^^^^^^
The old code didn't check

    399
    400         if (dc_stream_set_cursor_position(stream, position)) {
    401                 dc_z10_restore(dc);
    402
    403                 /* disable idle optimizations if enabling cursor */
    404                 if (dc-&gt;idle_optimizations_allowed &amp;&amp;
    405                     (!old_position-&gt;enable || dc-&gt;debug.exit_idle_opt_for_cursor_updates) &amp;&amp;
    406                     position-&gt;enable) {
    407                         dc_allow_idle_optimizations(dc, false);

Fixes: f63f86b5affc ("drm/amd/display: Separate setting and programming of cursor")
Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Cc: Harry Wentland &lt;harry.wentland@amd.com&gt;
Cc: Tom Chung &lt;chiahsuan.chung@amd.com&gt;
Cc: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Cc: Roman Li &lt;roman.li@amd.com&gt;
Cc: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Srinivasan Shanmugam &lt;srinivasan.shanmugam@amd.com&gt;
Reviewed-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Solve mst monitors blank out problem after resume</title>
<updated>2024-08-19T04:05:39Z</updated>
<author>
<name>Wayne Lin</name>
<email>Wayne.Lin@amd.com</email>
</author>
<published>2024-05-23T04:18:07Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2c1dcfccf988cde5887edd954ea6d288cd0e9ada'/>
<id>urn:sha1:2c1dcfccf988cde5887edd954ea6d288cd0e9ada</id>
<content type='text'>
commit e33697141bac18906345ea46533a240f1ad3cd21 upstream.

[Why]
In dm resume, we firstly restore dc state and do the mst resume for topology
probing thereafter. If we change dpcd DP_MSTM_CTRL value after LT in mst reume,
it will cause light up problem on the hub.

[How]
Revert commit 202dc359adda ("drm/amd/display: Defer handling mst up request in resume").
And adjust the reason to trigger dc_link_detect by DETECT_REASON_RESUMEFROMS3S4.

Cc: stable@vger.kernel.org
Fixes: 202dc359adda ("drm/amd/display: Defer handling mst up request in resume")
Signed-off-by: Wayne Lin &lt;Wayne.Lin@amd.com&gt;
Reviewed-by: Fangzhi Zuo &lt;jerry.zuo@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>binfmt_flat: Fix corruption when not offsetting data start</title>
<updated>2024-08-19T04:05:39Z</updated>
<author>
<name>Kees Cook</name>
<email>kees@kernel.org</email>
</author>
<published>2024-08-07T19:51:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9350ba06ee61db392c486716ac68ecc20e030f7c'/>
<id>urn:sha1:9350ba06ee61db392c486716ac68ecc20e030f7c</id>
<content type='text'>
[ Upstream commit 3eb3cd5992f7a0c37edc8d05b4c38c98758d8671 ]

Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start")
introduced a RISC-V specific variant of the FLAT format which does
not allocate any space for the (obsolete) array of shared library
pointers. However, it did not disable the code which initializes the
array, resulting in the corruption of sizeof(long) bytes before the DATA
segment, generally the end of the TEXT segment.

Introduce MAX_SHARED_LIBS_UPDATE which depends on the state of
CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of
the shared library pointer region so that it will only be initialized
if space is reserved for it.

Fixes: 04d82a6d0881 ("binfmt_flat: allow not offsetting data start")
Co-developed-by: Stefan O'Rear &lt;sorear@fastmail.com&gt;
Signed-off-by: Stefan O'Rear &lt;sorear@fastmail.com&gt;
Reviewed-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Acked-by: Greg Ungerer &lt;gerg@linux-m68k.org&gt;
Link: https://lore.kernel.org/r/20240807195119.it.782-kees@kernel.org
Signed-off-by: Kees Cook &lt;kees@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/x86: ideapad-laptop: add a mutex to synchronize VPC commands</title>
<updated>2024-08-19T04:05:39Z</updated>
<author>
<name>Gergo Koteles</name>
<email>soyer@irl.hu</email>
</author>
<published>2024-07-25T09:21:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d38574ff500b94c5e0f6dacdbab01b975a0e88fd'/>
<id>urn:sha1:d38574ff500b94c5e0f6dacdbab01b975a0e88fd</id>
<content type='text'>
[ Upstream commit 7cc06e729460a209b84d3db4db56c9f85f048cc2 ]

Calling VPC commands consists of several VPCW and VPCR ACPI calls.
These calls and their results can get mixed up if they are called
simultaneously from different threads, like acpi notify handler,
sysfs, debugfs, notification chain.

The commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on
all CPUs") made the race issues much worse than before it but some
races were possible even before that commit.

Add a mutex to synchronize VPC commands.

Fixes: e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs")
Fixes: e82882cdd241 ("platform/x86: Add driver for Yoga Tablet Mode switch")
Signed-off-by: Gergo Koteles &lt;soyer@irl.hu&gt;
Link: https://lore.kernel.org/r/f26782fa1194ad11ed5d9ba121a804e59b58b026.1721898747.git.soyer@irl.hu
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/x86: ideapad-laptop: move ymc_trigger_ec from lenovo-ymc</title>
<updated>2024-08-19T04:05:39Z</updated>
<author>
<name>Gergo Koteles</name>
<email>soyer@irl.hu</email>
</author>
<published>2024-07-25T09:21:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fc6c6bb34f5dad28c1edba0625f1249f272a89b2'/>
<id>urn:sha1:fc6c6bb34f5dad28c1edba0625f1249f272a89b2</id>
<content type='text'>
[ Upstream commit cde7886b35176d56e72bfc68dc104fa08e7b072c ]

Some models need to trigger the EC after each YMC event for the yoga
mode control to work properly. EC triggering consist of a VPC call from
the lenovo-ymc module. Except for this, all VPC calls are in the
ideapad-laptop module.

Since ideapad-laptop has a notification chain, a new YMC_EVENT action
can be added and triggered from the lenovo-ymc module. Then the
ideapad-laptop can trigger the EC.

If the triggering is in the ideapad-laptop module, then the ec_trigger
module parameter should be there as well.

Move the ymc_trigger_ec functionality and the ec_trigger module
parameter to the ideapad-laptop module.

Signed-off-by: Gergo Koteles &lt;soyer@irl.hu&gt;
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Link: https://lore.kernel.org/r/d980ab3ac32b5e554f456b0ff17279bfdbe2a203.1721898747.git.soyer@irl.hu
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Stable-dep-of: 7cc06e729460 ("platform/x86: ideapad-laptop: add a mutex to synchronize VPC commands")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/x86: ideapad-laptop: introduce a generic notification chain</title>
<updated>2024-08-19T04:05:39Z</updated>
<author>
<name>Gergo Koteles</name>
<email>soyer@irl.hu</email>
</author>
<published>2024-07-25T09:21:07Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c0d39578c35e1df980c1295ac7f8ad4493d7f08d'/>
<id>urn:sha1:c0d39578c35e1df980c1295ac7f8ad4493d7f08d</id>
<content type='text'>
[ Upstream commit 613e3900c24bb1379d994f44d75d31c3223cc263 ]

There are several cases where a notification chain can simplify Lenovo
WMI drivers.

Add a generic notification chain into ideapad-laptop.

Signed-off-by: Gergo Koteles &lt;soyer@irl.hu&gt;
Link: https://lore.kernel.org/r/c5a43efae8a32bd034c3d19c0a686941347575a7.1721898747.git.soyer@irl.hu
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Stable-dep-of: 7cc06e729460 ("platform/x86: ideapad-laptop: add a mutex to synchronize VPC commands")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
