<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers, branch linux-5.7.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.7.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.7.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2020-08-27T07:30:49Z</updated>
<entry>
<title>net: ena: Make missed_tx stat incremental</title>
<updated>2020-08-27T07:30:49Z</updated>
<author>
<name>Shay Agroskin</name>
<email>shayagr@amazon.com</email>
</author>
<published>2020-08-19T17:28:38Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c296f30ba8c39044002dd0d17fe15df33964e59a'/>
<id>urn:sha1:c296f30ba8c39044002dd0d17fe15df33964e59a</id>
<content type='text'>
[ Upstream commit ccd143e5150f24b9ba15145c7221b61dd9e41021 ]

Most statistics in ena driver are incremented, meaning that a stat's
value is a sum of all increases done to it since driver/queue
initialization.

This patch makes all statistics this way, effectively making missed_tx
statistic incremental.
Also added a comment regarding rx_drops and tx_drops to make it
clearer how these counters are calculated.

Fixes: 11095fdb712b ("net: ena: add statistics for missed tx packets")
Signed-off-by: Shay Agroskin &lt;shayagr@amazon.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "drm/amd/display: Improve DisplayPort monitor interop"</title>
<updated>2020-08-26T09:42:25Z</updated>
<author>
<name>Alex Deucher</name>
<email>alexdeucher@gmail.com</email>
</author>
<published>2020-08-24T16:10:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=813b2c197929540e700dc3d42b2c8136795c5d4c'/>
<id>urn:sha1:813b2c197929540e700dc3d42b2c8136795c5d4c</id>
<content type='text'>
This reverts commit 1adb2ff1f6b170cdbc3925a359c8f39d2215dc20.

This breaks display wake up in stable kernels (5.7.x and 5.8.x).

Note that there is no upstream equivalent to this
revert. This patch was targeted for stable by Sasha's stable
patch process. Presumably there are some other changes necessary
for this patch to work properly on stable kernels.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1266
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org # 5.7.x, 5.8.x
Cc: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xen: don't reschedule in preemption off sections</title>
<updated>2020-08-26T09:42:24Z</updated>
<author>
<name>Juergen Gross</name>
<email>jgross@suse.com</email>
</author>
<published>2020-08-20T06:59:08Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d2aca537d6d1637f11d7425b21cfc51d0a99c588'/>
<id>urn:sha1:d2aca537d6d1637f11d7425b21cfc51d0a99c588</id>
<content type='text'>
For support of long running hypercalls xen_maybe_preempt_hcall() is
calling cond_resched() in case a hypercall marked as preemptible has
been interrupted.

Normally this is no problem, as only hypercalls done via some ioctl()s
are marked to be preemptible. In rare cases when during such a
preemptible hypercall an interrupt occurs and any softirq action is
started from irq_exit(), a further hypercall issued by the softirq
handler will be regarded to be preemptible, too. This might lead to
rescheduling in spite of the softirq handler potentially having set
preempt_disable(), leading to splats like:

BUG: sleeping function called from invalid context at drivers/xen/preempt.c:37
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 20775, name: xl
INFO: lockdep is turned off.
CPU: 1 PID: 20775 Comm: xl Tainted: G D W 5.4.46-1_prgmr_debug.el7.x86_64 #1
Call Trace:
&lt;IRQ&gt;
dump_stack+0x8f/0xd0
___might_sleep.cold.76+0xb2/0x103
xen_maybe_preempt_hcall+0x48/0x70
xen_do_hypervisor_callback+0x37/0x40
RIP: e030:xen_hypercall_xen_version+0xa/0x20
Code: ...
RSP: e02b:ffffc900400dcc30 EFLAGS: 00000246
RAX: 000000000004000d RBX: 0000000000000200 RCX: ffffffff8100122a
RDX: ffff88812e788000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffffff83ee3ad0 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000246 R12: ffff8881824aa0b0
R13: 0000000865496000 R14: 0000000865496000 R15: ffff88815d040000
? xen_hypercall_xen_version+0xa/0x20
? xen_force_evtchn_callback+0x9/0x10
? check_events+0x12/0x20
? xen_restore_fl_direct+0x1f/0x20
? _raw_spin_unlock_irqrestore+0x53/0x60
? debug_dma_sync_single_for_cpu+0x91/0xc0
? _raw_spin_unlock_irqrestore+0x53/0x60
? xen_swiotlb_sync_single_for_cpu+0x3d/0x140
? mlx4_en_process_rx_cq+0x6b6/0x1110 [mlx4_en]
? mlx4_en_poll_rx_cq+0x64/0x100 [mlx4_en]
? net_rx_action+0x151/0x4a0
? __do_softirq+0xed/0x55b
? irq_exit+0xea/0x100
? xen_evtchn_do_upcall+0x2c/0x40
? xen_do_hypervisor_callback+0x29/0x40
&lt;/IRQ&gt;
? xen_hypercall_domctl+0xa/0x20
? xen_hypercall_domctl+0x8/0x20
? privcmd_ioctl+0x221/0x990 [xen_privcmd]
? do_vfs_ioctl+0xa5/0x6f0
? ksys_ioctl+0x60/0x90
? trace_hardirqs_off_thunk+0x1a/0x20
? __x64_sys_ioctl+0x16/0x20
? do_syscall_64+0x62/0x250
? entry_SYSCALL_64_after_hwframe+0x49/0xbe

Fix that by testing preempt_count() before calling cond_resched().

In kernel 5.8 this can't happen any more due to the entry code rework
(more than 100 patches, so not a candidate for backporting).

The issue was introduced in kernel 4.3, so this patch should go into
all stable kernels in [4.3 ... 5.7].

Reported-by: Sarah Newman &lt;srn@prgmr.com&gt;
Fixes: 0fa2f5cb2b0ecd8 ("sched/preempt, xen: Use need_resched() instead of should_resched()")
Cc: Sarah Newman &lt;srn@prgmr.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Tested-by: Chris Brannon &lt;cmb@prgmr.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>efi/libstub: Handle NULL cmdline</title>
<updated>2020-08-26T09:42:24Z</updated>
<author>
<name>Arvind Sankar</name>
<email>nivedita@alum.mit.edu</email>
</author>
<published>2020-07-29T19:33:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e460b7a2e4a40b7de6b6835f04a87d55243796e8'/>
<id>urn:sha1:e460b7a2e4a40b7de6b6835f04a87d55243796e8</id>
<content type='text'>
commit a37ca6a2af9df2972372b918f09390c9303acfbd upstream.

Treat a NULL cmdline the same as empty. Although this is unlikely to
happen in practice, the x86 kernel entry does check for NULL cmdline and
handles it, so do it here as well.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Arvind Sankar &lt;nivedita@alum.mit.edu&gt;
Link: https://lore.kernel.org/r/20200729193300.598448-1-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>efi/libstub: Stop parsing arguments at "--"</title>
<updated>2020-08-26T09:42:24Z</updated>
<author>
<name>Arvind Sankar</name>
<email>nivedita@alum.mit.edu</email>
</author>
<published>2020-07-25T15:59:16Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=afe431e20783e3d35a9420416cda61423650ba47'/>
<id>urn:sha1:afe431e20783e3d35a9420416cda61423650ba47</id>
<content type='text'>
commit 1fd9717d75df68e3c3509b8e7b1138ca63472f88 upstream.

Arguments after "--" are arguments for init, not for the kernel.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Arvind Sankar &lt;nivedita@alum.mit.edu&gt;
Link: https://lore.kernel.org/r/20200725155916.1376773-1-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>efi: add missed destroy_workqueue when efisubsys_init fails</title>
<updated>2020-08-26T09:42:24Z</updated>
<author>
<name>Li Heng</name>
<email>liheng40@huawei.com</email>
</author>
<published>2020-07-20T07:22:18Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f591a42b8f9a9d20e01d0462f4f55d2176ac52ec'/>
<id>urn:sha1:f591a42b8f9a9d20e01d0462f4f55d2176ac52ec</id>
<content type='text'>
commit 98086df8b70c06234a8f4290c46064e44dafa0ed upstream.

destroy_workqueue() should be called to destroy efi_rts_wq
when efisubsys_init() init resources fails.

Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Li Heng &lt;liheng40@huawei.com&gt;
Link: https://lore.kernel.org/r/1595229738-10087-1-git-send-email-liheng40@huawei.com
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>EDAC/{i7core,sb,pnd2,skx}: Fix error event severity</title>
<updated>2020-08-26T09:42:23Z</updated>
<author>
<name>Tony Luck</name>
<email>tony.luck@intel.com</email>
</author>
<published>2020-07-07T19:43:24Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7612d17646340f4a762fdb8dd8d8953ef7a8bee1'/>
<id>urn:sha1:7612d17646340f4a762fdb8dd8d8953ef7a8bee1</id>
<content type='text'>
commit 45bc6098a3e279d8e391d22428396687562797e2 upstream.

IA32_MCG_STATUS.RIPV indicates whether the return RIP value pushed onto
the stack as part of machine check delivery is valid or not.

Various drivers copied a code fragment that uses the RIPV bit to
determine the severity of the error as either HW_EVENT_ERR_UNCORRECTED
or HW_EVENT_ERR_FATAL, but this check is reversed (marking errors where
RIPV is set as "FATAL").

Reverse the tests so that the error is marked fatal when RIPV is not set.

Reported-by: Gabriele Paoloni &lt;gabriele.paoloni@intel.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lkml.kernel.org/r/20200707194324.14884-1-tony.luck@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>net: dsa: b53: check for timeout</title>
<updated>2020-08-26T09:42:23Z</updated>
<author>
<name>Tom Rix</name>
<email>trix@redhat.com</email>
</author>
<published>2020-08-21T13:56:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=58deff08c9a476f4d09c8f8d113c9ba062a560c9'/>
<id>urn:sha1:58deff08c9a476f4d09c8f8d113c9ba062a560c9</id>
<content type='text'>
[ Upstream commit 774d977abfd024e6f73484544b9abe5a5cd62de7 ]

clang static analysis reports this problem

b53_common.c:1583:13: warning: The left expression of the compound
  assignment is an uninitialized value. The computed value will
  also be garbage
        ent.port &amp;= ~BIT(port);
        ~~~~~~~~ ^

ent is set by a successful call to b53_arl_read().  Unsuccessful
calls are caught by an switch statement handling specific returns.
b32_arl_read() calls b53_arl_op_wait() which fails with the
unhandled -ETIMEDOUT.

So add -ETIMEDOUT to the switch statement.  Because
b53_arl_op_wait() already prints out a message, do not add another
one.

Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations")
Signed-off-by: Tom Rix &lt;trix@redhat.com&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.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>hv_netvsc: Fix the queue_mapping in netvsc_vf_xmit()</title>
<updated>2020-08-26T09:42:23Z</updated>
<author>
<name>Haiyang Zhang</name>
<email>haiyangz@microsoft.com</email>
</author>
<published>2020-08-20T21:53:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3650750e9942703f37613cf0932ba578d8da4a2e'/>
<id>urn:sha1:3650750e9942703f37613cf0932ba578d8da4a2e</id>
<content type='text'>
[ Upstream commit c3d897e01aef8ddc43149e4d661b86f823e3aae7 ]

netvsc_vf_xmit() / dev_queue_xmit() will call VF NIC’s ndo_select_queue
or netdev_pick_tx() again. They will use skb_get_rx_queue() to get the
queue number, so the “skb-&gt;queue_mapping - 1” will be used. This may
cause the last queue of VF not been used.

Use skb_record_rx_queue() here, so that the skb_get_rx_queue() called
later will get the correct queue number, and VF will be able to use
all queues.

Fixes: b3bf5666a510 ("hv_netvsc: defer queue selection to VF")
Signed-off-by: Haiyang Zhang &lt;haiyangz@microsoft.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>net: gemini: Fix missing free_netdev() in error path of gemini_ethernet_port_probe()</title>
<updated>2020-08-26T09:42:22Z</updated>
<author>
<name>Wang Hai</name>
<email>wanghai38@huawei.com</email>
</author>
<published>2020-08-19T02:33:09Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bb34f5efa78881a65cb72ddf83f893e04cf42ff1'/>
<id>urn:sha1:bb34f5efa78881a65cb72ddf83f893e04cf42ff1</id>
<content type='text'>
[ Upstream commit cf96d977381d4a23957bade2ddf1c420b74a26b6 ]

Replace alloc_etherdev_mq with devm_alloc_etherdev_mqs. In this way,
when probe fails, netdev can be freed automatically.

Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Wang Hai &lt;wanghai38@huawei.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>
</feed>
