<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers, branch v6.9.9</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.9.9</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.9.9'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2024-07-11T10:51:24Z</updated>
<entry>
<title>null_blk: Do not allow runt zone with zone capacity smaller then zone size</title>
<updated>2024-07-11T10:51:24Z</updated>
<author>
<name>Damien Le Moal</name>
<email>dlemoal@kernel.org</email>
</author>
<published>2024-05-30T05:40:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=165634c02d8584984f8a2dc8ab70e27e6890e581'/>
<id>urn:sha1:165634c02d8584984f8a2dc8ab70e27e6890e581</id>
<content type='text'>
[ Upstream commit b164316808ec5de391c3e7b0148ec937d32d280d ]

A zoned device with a smaller last zone together with a zone capacity
smaller than the zone size does make any sense as that does not
correspond to any possible setup for a real device:
1) For ZNS and zoned UFS devices, all zones are always the same size.
2) For SMR HDDs, all zones always have the same capacity.
In other words, if we have a smaller last runt zone, then this zone
capacity should always be equal to the zone size.

Add a check in null_init_zoned_dev() to prevent a configuration to have
both a smaller zone size and a zone capacity smaller than the zone size.

Signed-off-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Reviewed-by: Niklas Cassel &lt;cassel@kernel.org&gt;
Reviewed-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Link: https://lore.kernel.org/r/20240530054035.491497-2-dlemoal@kernel.org
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>hwmon: (dell-smm) Add Dell G15 5511 to fan control whitelist</title>
<updated>2024-07-11T10:51:23Z</updated>
<author>
<name>Armin Wolf</name>
<email>W_Armin@gmx.de</email>
</author>
<published>2024-05-22T21:08:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c4fa046a97a6079b9606e4c16880a0c37ef801a8'/>
<id>urn:sha1:c4fa046a97a6079b9606e4c16880a0c37ef801a8</id>
<content type='text'>
[ Upstream commit fa0bc8f297b29126b5ae983406e9bc76d48a9a8e ]

A user reported that he needs to disable BIOS fan control on his
Dell G15 5511 in order to be able to control the fans.

Closes: https://github.com/Wer-Wolf/i8kutils/issues/5
Signed-off-by: Armin Wolf &lt;W_Armin@gmx.de&gt;
Acked-by: Pali Rohár &lt;pali@kernel.org&gt;
Link: https://lore.kernel.org/r/20240522210809.294488-1-W_Armin@gmx.de
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: silence UBSAN warning</title>
<updated>2024-07-11T10:51:23Z</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2024-05-16T13:51:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fccdf39502b5deab8c8170e3aa5cc94b58b0985c'/>
<id>urn:sha1:fccdf39502b5deab8c8170e3aa5cc94b58b0985c</id>
<content type='text'>
[ Upstream commit 05d9e24ddb15160164ba6e917a88c00907dc2434 ]

Convert a variable sized array from [1] to [].

Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: cadence: Ensure data lines set to low during dummy-cycle period</title>
<updated>2024-07-11T10:51:23Z</updated>
<author>
<name>Witold Sadowski</name>
<email>wsadowski@marvell.com</email>
</author>
<published>2024-05-29T07:40:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ae5db98a264809819dc3c8ee2ab3271a8b872dfd'/>
<id>urn:sha1:ae5db98a264809819dc3c8ee2ab3271a8b872dfd</id>
<content type='text'>
[ Upstream commit 4a69c1264ff41bc5bf7c03101ada0454fbf08868 ]

During dummy-cycles xSPI will switch GPIO into Hi-Z mode. In that dummy
period voltage on data lines will slowly drop, what can cause
unintentional modebyte transmission. Value send to SPI memory chip will
depend on last address, and clock frequency.
To prevent unforeseen consequences of that behaviour, force send
single modebyte(0x00).
Modebyte will be send only if number of dummy-cycles is not equal
to 0. Code must also reduce dummycycle byte count by one - as one byte
is send as modebyte.

Signed-off-by: Witold Sadowski &lt;wsadowski@marvell.com&gt;
Link: https://msgid.link/r/20240529074037.1345882-2-wsadowski@marvell.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>nfc/nci: Add the inconsistency check between the input data length and count</title>
<updated>2024-07-11T10:51:23Z</updated>
<author>
<name>Edward Adam Davis</name>
<email>eadavis@qq.com</email>
</author>
<published>2024-05-28T03:12:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=22a72c1c10f43ca645a98725e0faff34592f4d08'/>
<id>urn:sha1:22a72c1c10f43ca645a98725e0faff34592f4d08</id>
<content type='text'>
[ Upstream commit 068648aab72c9ba7b0597354ef4d81ffaac7b979 ]

write$nci(r0, &amp;(0x7f0000000740)=ANY=[@ANYBLOB="610501"], 0xf)

Syzbot constructed a write() call with a data length of 3 bytes but a count value
of 15, which passed too little data to meet the basic requirements of the function
nci_rf_intf_activated_ntf_packet().

Therefore, increasing the comparison between data length and count value to avoid
problems caused by inconsistent data length and count.

Reported-and-tested-by: syzbot+71bfed2b2bcea46c98f2@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis &lt;eadavis@qq.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvmet: fix a possible leak when destroy a ctrl during qp establishment</title>
<updated>2024-07-11T10:51:23Z</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagi@grimberg.me</email>
</author>
<published>2024-05-27T19:38:52Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=818004f2a380420c19872171be716174d4985e33'/>
<id>urn:sha1:818004f2a380420c19872171be716174d4985e33</id>
<content type='text'>
[ Upstream commit c758b77d4a0a0ed3a1292b3fd7a2aeccd1a169a4 ]

In nvmet_sq_destroy we capture sq-&gt;ctrl early and if it is non-NULL we
know that a ctrl was allocated (in the admin connect request handler)
and we need to release pending AERs, clear ctrl-&gt;sqs and sq-&gt;ctrl
(for nvme-loop primarily), and drop the final reference on the ctrl.

However, a small window is possible where nvmet_sq_destroy starts (as
a result of the client giving up and disconnecting) concurrently with
the nvme admin connect cmd (which may be in an early stage). But *before*
kill_and_confirm of sq-&gt;ref (i.e. the admin connect managed to get an sq
live reference). In this case, sq-&gt;ctrl was allocated however after it was
captured in a local variable in nvmet_sq_destroy.
This prevented the final reference drop on the ctrl.

Solve this by re-capturing the sq-&gt;ctrl after all inflight request has
completed, where for sure sq-&gt;ctrl reference is final, and move forward
based on that.

This issue was observed in an environment with many hosts connecting
multiple ctrls simoutanuosly, creating a delay in allocating a ctrl
leading up to this race window.

Reported-by: Alex Turin &lt;alex@vastdata.com&gt;
Signed-off-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/x86: touchscreen_dmi: Add info for the EZpad 6s Pro</title>
<updated>2024-07-11T10:51:22Z</updated>
<author>
<name>hmtheboy154</name>
<email>buingoc67@gmail.com</email>
</author>
<published>2024-05-27T09:14:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=946cbb3115fe96e8e5421ed6eb9d5f61e91e4da0'/>
<id>urn:sha1:946cbb3115fe96e8e5421ed6eb9d5f61e91e4da0</id>
<content type='text'>
[ Upstream commit 3050052613790e75b5e4a8536930426b0a8b0774 ]

The "EZpad 6s Pro" uses the same touchscreen as the "EZpad 6 Pro B",
unlike the "Ezpad 6 Pro" which has its own touchscreen.

Signed-off-by: hmtheboy154 &lt;buingoc67@gmail.com&gt;
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Link: https://lore.kernel.org/r/20240527091447.248849-3-hdegoede@redhat.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/x86: touchscreen_dmi: Add info for GlobalSpace SolT IVW 11.6" tablet</title>
<updated>2024-07-11T10:51:22Z</updated>
<author>
<name>hmtheboy154</name>
<email>buingoc67@gmail.com</email>
</author>
<published>2024-05-27T09:14:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ed4daf66a329f4ced59ec7bd9710a1750234704e'/>
<id>urn:sha1:ed4daf66a329f4ced59ec7bd9710a1750234704e</id>
<content type='text'>
[ Upstream commit 7c8639aa41343fd7b3dbe09baf6b0791fcc407a1 ]

This is a tablet created by GlobalSpace Technologies Limited
which uses an Intel Atom x5-Z8300, 4GB of RAM &amp; 64GB of storage.

Link: https://web.archive.org/web/20171102141952/http://globalspace.in/11.6-device.html
Signed-off-by: hmtheboy154 &lt;buingoc67@gmail.com&gt;
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Link: https://lore.kernel.org/r/20240527091447.248849-2-hdegoede@redhat.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap-i2c: Subtract reg size from max_write</title>
<updated>2024-07-11T10:51:22Z</updated>
<author>
<name>Jim Wylder</name>
<email>jwylder@google.com</email>
</author>
<published>2024-05-23T21:14:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=010c0de852c61c9b105d59de2e70daeb4fb8ee41'/>
<id>urn:sha1:010c0de852c61c9b105d59de2e70daeb4fb8ee41</id>
<content type='text'>
[ Upstream commit 611b7eb19d0a305d4de00280e4a71a1b15c507fc ]

Currently, when an adapter defines a max_write_len quirk,
the data will be chunked into data sizes equal to the
max_write_len quirk value.  But the payload will be increased by
the size of the register address before transmission.  The
resulting value always ends up larger than the limit set
by the quirk.

Avoid this error by setting regmap's max_write to the quirk's
max_write_len minus the number of bytes for the register and
padding.  This allows the chunking to work correctly for this
limited case without impacting other use-cases.

Signed-off-by: Jim Wylder &lt;jwylder@google.com&gt;
Link: https://msgid.link/r/20240523211437.2839942-1-jwylder@google.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>nvme: adjust multiples of NVME_CTRL_PAGE_SIZE in offset</title>
<updated>2024-07-11T10:51:22Z</updated>
<author>
<name>Kundan Kumar</name>
<email>kundan.kumar@samsung.com</email>
</author>
<published>2024-05-23T11:31:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9205fa26ca32241162a33dec934ba3a75e0e3ef3'/>
<id>urn:sha1:9205fa26ca32241162a33dec934ba3a75e0e3ef3</id>
<content type='text'>
[ Upstream commit 1bd293fcf3af84674e82ed022c049491f3768840 ]

bio_vec start offset may be relatively large particularly when large
folio gets added to the bio. A bigger offset will result in avoiding the
single-segment mapping optimization and end up using expensive
mempool_alloc further.

Rather than using absolute value, adjust bv_offset by
NVME_CTRL_PAGE_SIZE while checking if segment can be fitted into one/two
PRP entries.

Suggested-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Kundan Kumar &lt;kundan.kumar@samsung.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
