<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/net, branch v5.3.15</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v5.3.15</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v5.3.15'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2019-12-04T21:34:31+00:00</updated>
<entry>
<title>net: fec: fix clock count mis-match</title>
<updated>2019-12-04T21:34:31+00:00</updated>
<author>
<name>Chuhong Yuan</name>
<email>hslester96@gmail.com</email>
</author>
<published>2019-11-20T01:25:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=d9c7531fb4708eb3f22cccdb0b7371834d37555a'/>
<id>urn:sha1:d9c7531fb4708eb3f22cccdb0b7371834d37555a</id>
<content type='text'>
commit a31eda65ba210741b598044d045480494d0ed52a upstream.

pm_runtime_put_autosuspend in probe will call runtime suspend to
disable clks automatically if CONFIG_PM is defined. (If CONFIG_PM
is not defined, its implementation will be empty, then runtime
suspend will not be called.)

Therefore, we can call pm_runtime_get_sync to runtime resume it
first to enable clks, which matches the runtime suspend. (Only when
CONFIG_PM is defined, otherwise pm_runtime_get_sync will also be
empty, then runtime resume will not be called.)

Then it is fine to disable clks without causing clock count mis-match.

Fixes: c43eab3eddb4 ("net: fec: add missed clk_disable_unprepare in remove")
Signed-off-by: Chuhong Yuan &lt;hslester96@gmail.com&gt;
Acked-by: Fugang Duan &lt;fugang.duan@nxp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Nobuhiro Iwamatsu &lt;nobuhiro1.iwamatsu@toshiba.co.jp&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>slip: Fix use-after-free Read in slip_open</title>
<updated>2019-12-04T21:34:19+00:00</updated>
<author>
<name>Jouni Hogander</name>
<email>jouni.hogander@unikie.com</email>
</author>
<published>2019-11-25T12:23:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=31359cfe886f429c0ca6df6a70370ecd29fcf96e'/>
<id>urn:sha1:31359cfe886f429c0ca6df6a70370ecd29fcf96e</id>
<content type='text'>
[ Upstream commit e58c1912418980f57ba2060017583067f5f71e52 ]

Slip_open doesn't clean-up device which registration failed from the
slip_devs device list. On next open after failure this list is iterated
and freed device is accessed. Fix this by calling sl_free_netdev in error
path.

Here is the trace from the Syzbot:

__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x197/0x210 lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
__kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
kasan_report+0x12/0x20 mm/kasan/common.c:634
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
sl_sync drivers/net/slip/slip.c:725 [inline]
slip_open+0xecd/0x11b7 drivers/net/slip/slip.c:801
tty_ldisc_open.isra.0+0xa3/0x110 drivers/tty/tty_ldisc.c:469
tty_set_ldisc+0x30e/0x6b0 drivers/tty/tty_ldisc.c:596
tiocsetd drivers/tty/tty_io.c:2334 [inline]
tty_ioctl+0xe8d/0x14f0 drivers/tty/tty_io.c:2594
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696
ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Fixes: 3b5a39979daf ("slip: Fix memory leak in slip_open error path")
Reported-by: syzbot+4d5170758f3762109542@syzkaller.appspotmail.com
Cc: David Miller &lt;davem@davemloft.net&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Lukas Bulwahn &lt;lukas.bulwahn@gmail.com&gt;
Signed-off-by: Jouni Hogander &lt;jouni.hogander@unikie.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>net: macb: add missed tasklet_kill</title>
<updated>2019-12-04T21:34:16+00:00</updated>
<author>
<name>Chuhong Yuan</name>
<email>hslester96@gmail.com</email>
</author>
<published>2019-11-28T02:00:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=8824ad6d657b500f5debd6bb1d85a981bf3248bb'/>
<id>urn:sha1:8824ad6d657b500f5debd6bb1d85a981bf3248bb</id>
<content type='text'>
[ Upstream commit 61183b056b49e2937ff92a1424291ba36a6f6d05 ]

This driver forgets to kill tasklet in remove.
Add the call to fix it.

Fixes: 032dc41ba6e2 ("net: macb: Handle HRESP error")
Signed-off-by: Chuhong Yuan &lt;hslester96@gmail.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>net: dsa: sja1105: fix sja1105_parse_rgmii_delays()</title>
<updated>2019-12-04T21:34:16+00:00</updated>
<author>
<name>Oleksij Rempel</name>
<email>o.rempel@pengutronix.de</email>
</author>
<published>2019-11-25T11:43:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=195af1df87e6bef1ded21921638a31ef8dc7d632'/>
<id>urn:sha1:195af1df87e6bef1ded21921638a31ef8dc7d632</id>
<content type='text'>
[ Upstream commit 9bca3a0a923fc3f0fb9e41391be1d0f291e86858 ]

This function was using configuration of port 0 in devicetree for all ports.
In case CPU port was not 0, the delay settings was ignored. This resulted not
working communication between CPU and the switch.

Fixes: f5b8631c293b ("net: dsa: sja1105: Error out if RGMII delays are requested in DT")
Signed-off-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Reviewed-by: Vladimir Oltean &lt;olteanv@gmail.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>mdio_bus: don't use managed reset-controller</title>
<updated>2019-12-04T21:34:15+00:00</updated>
<author>
<name>David Bauer</name>
<email>mail@david-bauer.net</email>
</author>
<published>2019-11-22T21:44:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a6fb1f4ff4cf5ed955f21330e64da5a53b1cee6d'/>
<id>urn:sha1:a6fb1f4ff4cf5ed955f21330e64da5a53b1cee6d</id>
<content type='text'>
[ Upstream commit 32085f25d7b68404055f3525c780142fc72e543f ]

Geert Uytterhoeven reported that using devm_reset_controller_get leads
to a WARNING when probing a reset-controlled PHY. This is because the
device devm_reset_controller_get gets supplied is not actually the
one being probed.

Acquire an unmanaged reset-control as well as free the reset_control on
unregister to fix this.

Reported-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
CC: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David Bauer &lt;mail@david-bauer.net&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&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>macvlan: schedule bc_work even if error</title>
<updated>2019-12-04T21:34:14+00:00</updated>
<author>
<name>Menglong Dong</name>
<email>dong.menglong@zte.com.cn</email>
</author>
<published>2019-11-25T08:58:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5a5d2003f4d87f1d1f07315105d51db9c106be89'/>
<id>urn:sha1:5a5d2003f4d87f1d1f07315105d51db9c106be89</id>
<content type='text'>
[ Upstream commit 1d7ea55668878bb350979c377fc72509dd6f5b21 ]

While enqueueing a broadcast skb to port-&gt;bc_queue, schedule_work()
is called to add port-&gt;bc_work, which processes the skbs in
bc_queue, to "events" work queue. If port-&gt;bc_queue is full, the
skb will be discarded and schedule_work(&amp;port-&gt;bc_work) won't be
called. However, if port-&gt;bc_queue is full and port-&gt;bc_work is not
running or pending, port-&gt;bc_queue will keep full and schedule_work()
won't be called any more, and all broadcast skbs to macvlan will be
discarded. This case can happen:

macvlan_process_broadcast() is the pending function of port-&gt;bc_work,
it moves all the skbs in port-&gt;bc_queue to the queue "list", and
processes the skbs in "list". During this, new skbs will keep being
added to port-&gt;bc_queue in macvlan_broadcast_enqueue(), and
port-&gt;bc_queue may already full when macvlan_process_broadcast()
return. This may happen, especially when there are a lot of real-time
threads and the process is preempted.

Fix this by calling schedule_work(&amp;port-&gt;bc_work) even if
port-&gt;bc_work is full in macvlan_broadcast_enqueue().

Fixes: 412ca1550cbe ("macvlan: Move broadcasts into a work queue")
Signed-off-by: Menglong Dong &lt;dong.menglong@zte.com.cn&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>gve: Fix the queue page list allocated pages count</title>
<updated>2019-12-04T21:34:14+00:00</updated>
<author>
<name>Jeroen de Borst</name>
<email>jeroendb@google.com</email>
</author>
<published>2019-11-26T23:36:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=071598ee0440c32f97101d8ea5e46a9de396c535'/>
<id>urn:sha1:071598ee0440c32f97101d8ea5e46a9de396c535</id>
<content type='text'>
[ Upstream commit a95069ecb7092d03b2ea1c39ee04514fe9627540 ]

In gve_alloc_queue_page_list(), when a page allocation fails,
qpl-&gt;num_entries will be wrong.  In this case priv-&gt;num_registered_pages
can underflow in gve_free_queue_page_list(), causing subsequent calls
to gve_alloc_queue_page_list() to fail.

Fixes: f5cedc84a30d ("gve: Add transmit and receive support")
Signed-off-by: Jeroen de Borst &lt;jeroendb@google.com&gt;
Reviewed-by: Catherine Sullivan &lt;csully@google.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>i40e: Fix for ethtool -m issue on X722 NIC</title>
<updated>2019-12-04T21:34:04+00:00</updated>
<author>
<name>Arkadiusz Kubalewski</name>
<email>arkadiusz.kubalewski@intel.com</email>
</author>
<published>2019-11-06T14:24:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=dc2ccb9b36511d213ba15ad31d641fbb439a10e1'/>
<id>urn:sha1:dc2ccb9b36511d213ba15ad31d641fbb439a10e1</id>
<content type='text'>
[ Upstream commit 4c9da6f2b8a029052c75bd4a61ae229135831177 ]

This patch contains fix for a problem with command:
'ethtool -m &lt;dev&gt;'
which breaks functionality of:
'ethtool &lt;dev&gt;'
when called on X722 NIC

Disallowed update of link phy_types on X722 NIC
Currently correct value cannot be obtained from FW
Previously wrong value returned by FW was used and was
a root cause for incorrect output of 'ethtool &lt;dev&gt;' command

Signed-off-by: Arkadiusz Kubalewski &lt;arkadiusz.kubalewski@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iavf: initialize ITRN registers with correct values</title>
<updated>2019-12-04T21:34:03+00:00</updated>
<author>
<name>Nicholas Nunley</name>
<email>nicholas.d.nunley@intel.com</email>
</author>
<published>2019-11-05T12:22:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=e3625adbba38042a56957721488ac53bdbcdddff'/>
<id>urn:sha1:e3625adbba38042a56957721488ac53bdbcdddff</id>
<content type='text'>
[ Upstream commit 4eda4e0096842764d725bcfd77471a419832b074 ]

Since commit 92418fb14750 ("i40e/i40evf: Use usec value instead of reg
value for ITR defines") the driver tracks the interrupt throttling
intervals in single usec units, although the actual ITRN registers are
programmed in 2 usec units. Most register programming flows in the driver
correctly handle the conversion, although it is currently not applied when
the registers are initialized to their default values. Most of the time
this doesn't present a problem since the default values are usually
immediately overwritten through the standard adaptive throttling mechanism,
or updated manually by the user, but if adaptive throttling is disabled and
the interval values are left alone then the incorrect value will persist.

Since the intended default interval of 50 usecs (vs. 100 usecs as
programmed) performs better for most traffic workloads, this can lead to
performance regressions.

This patch adds the correct conversion when writing the initial values to
the ITRN registers.

Signed-off-by: Nicholas Nunley &lt;nicholas.d.nunley@intel.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ice: fix potential infinite loop because loop counter being too small</title>
<updated>2019-12-04T21:34:02+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2019-11-01T14:00:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=d0f58d784d4cd6ce7446451dddcd6dde98f73c84'/>
<id>urn:sha1:d0f58d784d4cd6ce7446451dddcd6dde98f73c84</id>
<content type='text'>
[ Upstream commit 615457a226f042bffc3a1532afb244cab37460d4 ]

Currently the for-loop counter i is a u8 however it is being checked
against a maximum value hw-&gt;num_tx_sched_layers which is a u16. Hence
there is a potential wrap-around of counter i back to zero if
hw-&gt;num_tx_sched_layers is greater than 255.  Fix this by making i
a u16.

Addresses-Coverity: ("Infinite loop")
Fixes: b36c598c999c ("ice: Updates to Tx scheduler code")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
