<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v5.4.127</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.127</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.127'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-06-18T07:58:59+00:00</updated>
<entry>
<title>drm/amd/display: Allow bandwidth validation for 0 streams.</title>
<updated>2021-06-18T07:58:59+00:00</updated>
<author>
<name>Bindu Ramamurthy</name>
<email>bindu.r@amd.com</email>
</author>
<published>2021-05-20T14:06:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=12fa0fdbcd0fb02b51d488f321439979eb72565b'/>
<id>urn:sha1:12fa0fdbcd0fb02b51d488f321439979eb72565b</id>
<content type='text'>
[ Upstream commit ba8e59773ae59818695d1e20b8939282da80ec8c ]

[Why]
Bandwidth calculations are triggered for non zero streams, and
in case of 0 streams, these calculations were skipped with
pstate status not being updated.

[How]
As the pstate status is applicable for non zero streams, check
added for allowing 0 streams inline with dcn internal bandwidth
validations.

Signed-off-by: Bindu Ramamurthy &lt;bindu.r@amd.com&gt;
Reviewed-by: Roman Li &lt;Roman.Li@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>nvme-loop: check for NVME_LOOP_Q_LIVE in nvme_loop_destroy_admin_queue()</title>
<updated>2021-06-18T07:58:59+00:00</updated>
<author>
<name>Hannes Reinecke</name>
<email>hare@suse.de</email>
</author>
<published>2021-05-26T15:23:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c8e4a72b255e402ff3292330a0894904bdb391cd'/>
<id>urn:sha1:c8e4a72b255e402ff3292330a0894904bdb391cd</id>
<content type='text'>
[ Upstream commit 4237de2f73a669e4f89ac0aa2b44fb1a1d9ec583 ]

We need to check the NVME_LOOP_Q_LIVE flag in
nvme_loop_destroy_admin_queue() to protect against duplicate
invocations eg during concurrent reset and remove calls.

Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Chaitanya Kulkarni &lt;chaitanya.kulkarni@wdc.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme-loop: clear NVME_LOOP_Q_LIVE when nvme_loop_configure_admin_queue() fails</title>
<updated>2021-06-18T07:58:59+00:00</updated>
<author>
<name>Hannes Reinecke</name>
<email>hare@suse.de</email>
</author>
<published>2021-05-26T15:23:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=655d4dc10a231f1fc7abaff870c1f35fab764a86'/>
<id>urn:sha1:655d4dc10a231f1fc7abaff870c1f35fab764a86</id>
<content type='text'>
[ Upstream commit 1c5f8e882a05de5c011e8c3fbeceb0d1c590eb53 ]

When the call to nvme_enable_ctrl() in nvme_loop_configure_admin_queue()
fails the NVME_LOOP_Q_LIVE flag is not cleared.

Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Chaitanya Kulkarni &lt;chaitanya.kulkarni@wdc.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme-loop: reset queue count to 1 in nvme_loop_destroy_io_queues()</title>
<updated>2021-06-18T07:58:59+00:00</updated>
<author>
<name>Hannes Reinecke</name>
<email>hare@suse.de</email>
</author>
<published>2021-05-26T15:23:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ed4bee6e1bb7419311b72ad464e5a383aff69a40'/>
<id>urn:sha1:ed4bee6e1bb7419311b72ad464e5a383aff69a40</id>
<content type='text'>
[ Upstream commit a6c144f3d2e230f2b3ac5ed8c51e0f0391556197 ]

The queue count is increased in nvme_loop_init_io_queues(), so we
need to reset it to 1 at the end of nvme_loop_destroy_io_queues().
Otherwise the function is not re-entrant safe, and crash will happen
during concurrent reset and remove calls.

Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Chaitanya Kulkarni &lt;chaitanya.kulkarni@wdc.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: scsi_devinfo: Add blacklist entry for HPE OPEN-V</title>
<updated>2021-06-18T07:58:59+00:00</updated>
<author>
<name>Ewan D. Milne</name>
<email>emilne@redhat.com</email>
</author>
<published>2021-06-01T17:52:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=31ac5531110ace7c1e35709f1c9ac5b9bc5443d3'/>
<id>urn:sha1:31ac5531110ace7c1e35709f1c9ac5b9bc5443d3</id>
<content type='text'>
[ Upstream commit e57f5cd99ca60cddf40201b0f4ced9f1938e299c ]

Apparently some arrays are now returning "HPE" as the vendor.

Link: https://lore.kernel.org/r/20210601175214.25719-1-emilne@redhat.com
Signed-off-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: qedf: Do not put host in qedf_vport_create() unconditionally</title>
<updated>2021-06-18T07:58:59+00:00</updated>
<author>
<name>Daniel Wagner</name>
<email>dwagner@suse.de</email>
</author>
<published>2021-05-21T14:34:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4791b8948741bd6da73f57a41d0cb2724bf7d488'/>
<id>urn:sha1:4791b8948741bd6da73f57a41d0cb2724bf7d488</id>
<content type='text'>
[ Upstream commit 79c932cd6af9829432888c4a0001d01793a09f12 ]

Do not drop reference count on vn_port-&gt;host in qedf_vport_create()
unconditionally. Instead drop the reference count in qedf_vport_destroy().

Link: https://lore.kernel.org/r/20210521143440.84816-1-dwagner@suse.de
Reported-by: Javed Hasan &lt;jhasan@marvell.com&gt;
Signed-off-by: Daniel Wagner &lt;dwagner@suse.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ethernet: myri10ge: Fix missing error code in myri10ge_probe()</title>
<updated>2021-06-18T07:58:59+00:00</updated>
<author>
<name>Jiapeng Chong</name>
<email>jiapeng.chong@linux.alibaba.com</email>
</author>
<published>2021-06-01T11:04:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8034fc4ee9ef7f86cea34998ea42ec72be6a6a9c'/>
<id>urn:sha1:8034fc4ee9ef7f86cea34998ea42ec72be6a6a9c</id>
<content type='text'>
[ Upstream commit f336d0b93ae978f12c5e27199f828da89b91e56a ]

The error code is missing in this code scenario, add the error code
'-EINVAL' to the return value 'status'.

Eliminate the follow smatch warning:

drivers/net/ethernet/myricom/myri10ge/myri10ge.c:3818 myri10ge_probe()
warn: missing error code 'status'.

Reported-by: Abaci Robot &lt;abaci@linux.alibaba.com&gt;
Signed-off-by: Jiapeng Chong &lt;jiapeng.chong@linux.alibaba.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>scsi: target: core: Fix warning on realtime kernels</title>
<updated>2021-06-18T07:58:59+00:00</updated>
<author>
<name>Maurizio Lombardi</name>
<email>mlombard@redhat.com</email>
</author>
<published>2021-05-31T12:13:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ea4a9a34c9b2bdb91053f7edaa0713ff481c7bc6'/>
<id>urn:sha1:ea4a9a34c9b2bdb91053f7edaa0713ff481c7bc6</id>
<content type='text'>
[ Upstream commit 515da6f4295c2c42b8c54572cce3d2dd1167c41e ]

On realtime kernels, spin_lock_irq*(spinlock_t) do not disable the
interrupts, a call to irqs_disabled() will return false thus firing a
warning in __transport_wait_for_tasks().

Remove the warning and also replace assert_spin_locked() with
lockdep_assert_held()

Link: https://lore.kernel.org/r/20210531121326.3649-1-mlombard@redhat.com
Reviewed-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: gt683r: add missing MODULE_DEVICE_TABLE</title>
<updated>2021-06-18T07:58:58+00:00</updated>
<author>
<name>Bixuan Cui</name>
<email>cuibixuan@huawei.com</email>
</author>
<published>2021-05-08T03:14:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e58f4b5046e0ef37b5d3398c577ab0e80642c62b'/>
<id>urn:sha1:e58f4b5046e0ef37b5d3398c577ab0e80642c62b</id>
<content type='text'>
[ Upstream commit a4b494099ad657f1cb85436d333cf38870ee95bc ]

This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.

Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Bixuan Cui &lt;cuibixuan@huawei.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/tegra: sor: Do not leak runtime PM reference</title>
<updated>2021-06-18T07:58:58+00:00</updated>
<author>
<name>Pavel Machek (CIP)</name>
<email>pavel@denx.de</email>
</author>
<published>2021-04-06T11:54:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e4c3f7a6a3b241aab8aaebe50b7dbf11b5d8a5ee'/>
<id>urn:sha1:e4c3f7a6a3b241aab8aaebe50b7dbf11b5d8a5ee</id>
<content type='text'>
[ Upstream commit 73a395c46704304b96bc5e2ee19be31124025c0c ]

It's theoretically possible for the runtime PM reference to leak if the
code fails anywhere between the pm_runtime_resume_and_get() and
pm_runtime_put() calls, so make sure to release the runtime PM reference
in that case.

Practically this will never happen because none of the functions will
fail on Tegra, but it's better for the code to be pedantic in case these
assumptions will ever become wrong.

Signed-off-by: Pavel Machek (CIP) &lt;pavel@denx.de&gt;
[treding@nvidia.com: add commit message]
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
