<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v4.14.60</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.60</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.60'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-08-03T05:50:44+00:00</updated>
<entry>
<title>xen-netfront: wait xenbus state change when load module manually</title>
<updated>2018-08-03T05:50:44+00:00</updated>
<author>
<name>Xiao Liang</name>
<email>xiliang@redhat.com</email>
</author>
<published>2018-07-27T09:56:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=da970765b24cad557bde1b0372166e46c1276230'/>
<id>urn:sha1:da970765b24cad557bde1b0372166e46c1276230</id>
<content type='text'>
[ Upstream commit 822fb18a82abaf4ee7058793d95d340f5dab7bfc ]

When loading module manually, after call xenbus_switch_state to initializes
the state of the netfront device, the driver state did not change so fast
that may lead no dev created in latest kernel. This patch adds wait to make
sure xenbus knows the driver is not in closed/unknown state.

Current state:
[vm]# ethtool eth0
Settings for eth0:
	Link detected: yes
[vm]# modprobe -r xen_netfront
[vm]# modprobe  xen_netfront
[vm]# ethtool eth0
Settings for eth0:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available

With the patch installed.
[vm]# ethtool eth0
Settings for eth0:
	Link detected: yes
[vm]# modprobe -r xen_netfront
[vm]# modprobe xen_netfront
[vm]# ethtool eth0
Settings for eth0:
	Link detected: yes

Signed-off-by: Xiao Liang &lt;xiliang@redhat.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: stmmac: align DMA stuff to largest cache line length</title>
<updated>2018-08-03T05:50:44+00:00</updated>
<author>
<name>Eugeniy Paltsev</name>
<email>Eugeniy.Paltsev@synopsys.com</email>
</author>
<published>2018-07-26T12:05:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7f36a065963aebecc94d2be1e37f30162e5fe229'/>
<id>urn:sha1:7f36a065963aebecc94d2be1e37f30162e5fe229</id>
<content type='text'>
[ Upstream commit 9939a46d90c6c76f4533d534dbadfa7b39dc6acc ]

As for today STMMAC_ALIGN macro (which is used to align DMA stuff)
relies on L1 line length (L1_CACHE_BYTES).
This isn't correct in case of system with several cache levels
which might have L1 cache line length smaller than L2 line. This
can lead to sharing one cache line between DMA buffer and other
data, so we can lose this data while invalidate DMA buffer before
DMA transaction.

Fix that by using SMP_CACHE_BYTES instead of L1_CACHE_BYTES for
aligning.

Signed-off-by: Eugeniy Paltsev &lt;Eugeniy.Paltsev@synopsys.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: mdio-mux: bcm-iproc: fix wrong getter and setter pair</title>
<updated>2018-08-03T05:50:44+00:00</updated>
<author>
<name>Anton Vasilyev</name>
<email>vasilyev@ispras.ru</email>
</author>
<published>2018-07-27T15:57:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e071e2fdf45e1505436ad61e42b0d44904db1997'/>
<id>urn:sha1:e071e2fdf45e1505436ad61e42b0d44904db1997</id>
<content type='text'>
[ Upstream commit b0753408aadf32c7ece9e6b765017881e54af833 ]

mdio_mux_iproc_probe() uses platform_set_drvdata() to store md pointer
in device, whereas mdio_mux_iproc_remove() restores md pointer by
dev_get_platdata(&amp;pdev-&gt;dev). This leads to wrong resources release.

The patch replaces getter to platform_get_drvdata.

Fixes: 98bc865a1ec8 ("net: mdio-mux: Add MDIO mux driver for iProc SoCs")
Signed-off-by: Anton Vasilyev &lt;vasilyev@ispras.ru&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>net: lan78xx: fix rx handling before first packet is send</title>
<updated>2018-08-03T05:50:44+00:00</updated>
<author>
<name>Stefan Wahren</name>
<email>stefan.wahren@i2se.com</email>
</author>
<published>2018-07-28T07:52:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ccdbe7e2374a0be4ab81d70b53d23dd12b043648'/>
<id>urn:sha1:ccdbe7e2374a0be4ab81d70b53d23dd12b043648</id>
<content type='text'>
[ Upstream commit 136f55f660192ce04af091642efc75d85e017364 ]

As long the bh tasklet isn't scheduled once, no packet from the rx path
will be handled. Since the tx path also schedule the same tasklet
this situation only persits until the first packet transmission.
So fix this issue by scheduling the tasklet after link reset.

Link: https://github.com/raspberrypi/linux/issues/2617
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet")
Suggested-by: Floris Bos &lt;bos@je-eigen-domein.nl&gt;
Signed-off-by: Stefan Wahren &lt;stefan.wahren@i2se.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: fix amd-xgbe flow-control issue</title>
<updated>2018-08-03T05:50:44+00:00</updated>
<author>
<name>tangpengpeng</name>
<email>tangpengpeng@higon.com</email>
</author>
<published>2018-07-26T06:45:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=112e80ac82851912fd8dae1e4c0bf1a0fb3bffeb'/>
<id>urn:sha1:112e80ac82851912fd8dae1e4c0bf1a0fb3bffeb</id>
<content type='text'>
[ Upstream commit 7f3fc7ddf719cd6faaf787722c511f6918ac6aab ]

If we enable or disable xgbe flow-control by ethtool ,
it does't work.Because the parameter is not properly
assigned,so we need to adjust the assignment order
of the parameters.

Fixes: c1ce2f77366b ("amd-xgbe: Fix flow control setting logic")
Signed-off-by: tangpengpeng &lt;tangpengpeng@higon.com&gt;
Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.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: ena: Fix use of uninitialized DMA address bits field</title>
<updated>2018-08-03T05:50:44+00:00</updated>
<author>
<name>Gal Pressman</name>
<email>pressmangal@gmail.com</email>
</author>
<published>2018-07-26T20:40:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=11b694387ab493fbc10e203109ed2faed5d592b1'/>
<id>urn:sha1:11b694387ab493fbc10e203109ed2faed5d592b1</id>
<content type='text'>
[ Upstream commit 101f0cd4f2216d32f1b8a75a2154cf3997484ee2 ]

UBSAN triggers the following undefined behaviour warnings:
[...]
[   13.236124] UBSAN: Undefined behaviour in drivers/net/ethernet/amazon/ena/ena_eth_com.c:468:22
[   13.240043] shift exponent 64 is too large for 64-bit type 'long long unsigned int'
[...]
[   13.744769] UBSAN: Undefined behaviour in drivers/net/ethernet/amazon/ena/ena_eth_com.c:373:4
[   13.748694] shift exponent 64 is too large for 64-bit type 'long long unsigned int'
[...]

When splitting the address to high and low, GENMASK_ULL is used to generate
a bitmask with dma_addr_bits field from io_sq (in ena_com_prepare_tx and
ena_com_add_single_rx_desc).
The problem is that dma_addr_bits is not initialized with a proper value
(besides being cleared in ena_com_create_io_queue).
Assign dma_addr_bits the correct value that is stored in ena_dev when
initializing the SQ.

Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
Signed-off-by: Gal Pressman &lt;pressmangal@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: qca8k: Allow overwriting CPU port setting</title>
<updated>2018-08-03T05:50:44+00:00</updated>
<author>
<name>Michal Vokáč</name>
<email>vokac.m@gmail.com</email>
</author>
<published>2018-05-23T06:20:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=20556dc7f239f8ad724f8ff5fec289961439cd6b'/>
<id>urn:sha1:20556dc7f239f8ad724f8ff5fec289961439cd6b</id>
<content type='text'>
commit 9bb2289f90e671bdb78e306974187424ac19ff8e upstream.

Implement adjust_link function that allows to overwrite default CPU port
setting using fixed-link device tree subnode.

Signed-off-by: Michal Vokáč &lt;michal.vokac@ysoft.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@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: qca8k: Enable RXMAC when bringing up a port</title>
<updated>2018-08-03T05:50:43+00:00</updated>
<author>
<name>Michal Vokáč</name>
<email>vokac.m@gmail.com</email>
</author>
<published>2018-05-23T06:20:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1fbc97b32b7e3756e2b84f652108281791e9d377'/>
<id>urn:sha1:1fbc97b32b7e3756e2b84f652108281791e9d377</id>
<content type='text'>
commit eee1fe64765c562d8bcaf95e5631a8ea2f760f34 upstream.

When a port is brought up/down do not enable/disable only the TXMAC
but the RXMAC as well. This is essential for the CPU port to work.

Fixes: 6b93fb46480a ("net-next: dsa: add new driver for qca8xxx family")
Signed-off-by: Michal Vokáč &lt;michal.vokac@ysoft.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@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: qca8k: Force CPU port to its highest bandwidth</title>
<updated>2018-08-03T05:50:43+00:00</updated>
<author>
<name>Michal Vokáč</name>
<email>vokac.m@gmail.com</email>
</author>
<published>2018-05-23T06:20:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=62310e69f1ae5923646adedfd916fa2b090bada7'/>
<id>urn:sha1:62310e69f1ae5923646adedfd916fa2b090bada7</id>
<content type='text'>
commit 79a4ed4f0f93fc65e48a0fc5247ffa5645f7b0cc upstream.

By default autonegotiation is enabled to configure MAC on all ports.
For the CPU port autonegotiation can not be used so we need to set
some sensible defaults manually.

This patch forces the default setting of the CPU port to 1000Mbps/full
duplex which is the chip maximum capability.

Also correct size of the bit field used to configure link speed.

Fixes: 6b93fb46480a ("net-next: dsa: add new driver for qca8xxx family")
Signed-off-by: Michal Vokáč &lt;michal.vokac@ysoft.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@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>RDMA/uverbs: Protect from attempts to create flows on unsupported QP</title>
<updated>2018-08-03T05:50:43+00:00</updated>
<author>
<name>Leon Romanovsky</name>
<email>leonro@mellanox.com</email>
</author>
<published>2018-06-24T08:23:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a61b3378b8473694ebd87e59c8a5dd35839c50fc'/>
<id>urn:sha1:a61b3378b8473694ebd87e59c8a5dd35839c50fc</id>
<content type='text'>
commit 940efcc8889f0d15567eb07fc9fd69b06e366aa5 upstream.

Flows can be created on UD and RAW_PACKET QP types. Attempts to provide
other QP types as an input causes to various unpredictable failures.

The reason is that in order to support all various types (e.g. XRC), we
are supposed to use real_qp handle and not qp handle and expect to
driver/FW to fail such (XRC) flows. The simpler and safer variant is to
ban all QP types except UD and RAW_PACKET, instead of relying on
driver/FW.

Cc: &lt;stable@vger.kernel.org&gt; # 3.11
Fixes: 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow through uverbs")
Cc: syzkaller &lt;syzkaller@googlegroups.com&gt;
Reported-by: Noa Osherovich &lt;noaos@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
