<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/net/ethernet/stmicro, branch dev-5.2</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.2</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2019-09-10T09:35:06+00:00</updated>
<entry>
<title>net: stmmac: dwmac-rk: Don't fail if phy regulator is absent</title>
<updated>2019-09-10T09:35:06+00:00</updated>
<author>
<name>Chen-Yu Tsai</name>
<email>wens@csie.org</email>
</author>
<published>2019-08-29T03:17:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=939cc35d5f8179ec7de7ef765a41ae161349f247'/>
<id>urn:sha1:939cc35d5f8179ec7de7ef765a41ae161349f247</id>
<content type='text'>
[ Upstream commit 3b25528e1e355c803e73aa326ce657b5606cda73 ]

The devicetree binding lists the phy phy as optional. As such, the
driver should not bail out if it can't find a regulator. Instead it
should just skip the remaining regulator related code and continue
on normally.

Skip the remainder of phy_power_on() if a regulator supply isn't
available. This also gets rid of the bogus return code.

Fixes: 2e12f536635f ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator")
Signed-off-by: Chen-Yu Tsai &lt;wens@csie.org&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: tc: Do not return a fragment entry</title>
<updated>2019-08-29T06:30:16+00:00</updated>
<author>
<name>Jose Abreu</name>
<email>Jose.Abreu@synopsys.com</email>
</author>
<published>2019-08-06T13:16:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=84de7cd06750319006a20404f0493bb4119560c1'/>
<id>urn:sha1:84de7cd06750319006a20404f0493bb4119560c1</id>
<content type='text'>
[ Upstream commit 4a6a1385a4db5f42258a40fcd497cbfd22075968 ]

Do not try to return a fragment entry from TC list. Otherwise we may not
clean properly allocated entries.

Signed-off-by: Jose Abreu &lt;joabreu@synopsys.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: stmmac: Fix issues when number of Queues &gt;= 4</title>
<updated>2019-08-29T06:30:16+00:00</updated>
<author>
<name>Jose Abreu</name>
<email>Jose.Abreu@synopsys.com</email>
</author>
<published>2019-08-06T13:16:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f0d73daeef24d50c596444e881d596ebc2cb1d6b'/>
<id>urn:sha1:f0d73daeef24d50c596444e881d596ebc2cb1d6b</id>
<content type='text'>
[ Upstream commit e8df7e8c233a18d2704e37ecff47583b494789d3 ]

When queues &gt;= 4 we use different registers but we were not subtracting
the offset of 4. Fix this.

Found out by Coverity.

Signed-off-by: Jose Abreu &lt;joabreu@synopsys.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: stmmac: manage errors returned by of_get_mac_address()</title>
<updated>2019-08-29T06:30:08+00:00</updated>
<author>
<name>Martin Blumenstingl</name>
<email>martin.blumenstingl@googlemail.com</email>
</author>
<published>2019-07-27T19:21:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=edd7585d6751c993327a9eff6f56136c3baa4b21'/>
<id>urn:sha1:edd7585d6751c993327a9eff6f56136c3baa4b21</id>
<content type='text'>
[ Upstream commit 195b2919ccd7ffcaf6b6bbcb39444a53ab8308c7 ]

Commit d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
added support for reading the MAC address from an nvmem-cell. This
required changing the logic to return an error pointer upon failure.

If stmmac is loaded before the nvmem provider driver then
of_get_mac_address() return an error pointer with -EPROBE_DEFER.

Propagate this error so the stmmac driver will be probed again after the
nvmem provider driver is loaded.
Default to a random generated MAC address in case of any other error,
instead of using the error pointer as MAC address.

Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
Signed-off-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Reviewed-by: Neil Armstrong &lt;narmstrong@baylibre.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: stmmac: Use netif_tx_napi_add() for TX polling function</title>
<updated>2019-08-09T15:51:45+00:00</updated>
<author>
<name>Frode Isaksen</name>
<email>fisaksen@baylibre.com</email>
</author>
<published>2019-07-30T11:38:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b28c977b32b1a363d3dece84734f08c945626ac4'/>
<id>urn:sha1:b28c977b32b1a363d3dece84734f08c945626ac4</id>
<content type='text'>
[ Upstream commit 4d97972b45f080db4c6d27cc0b54321d9cd7be17 ]

This variant of netif_napi_add() should be used from drivers
using NAPI to exclusively poll a TX queue.

Signed-off-by: Frode Isaksen &lt;fisaksen@baylibre.com&gt;
Tested-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
Signed-off-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.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: Re-work the queue selection for TSO packets</title>
<updated>2019-07-28T06:27:14+00:00</updated>
<author>
<name>Jose Abreu</name>
<email>Jose.Abreu@synopsys.com</email>
</author>
<published>2019-07-08T12:26:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=bdd871af95e542fe50559027baba72cecb8f20c9'/>
<id>urn:sha1:bdd871af95e542fe50559027baba72cecb8f20c9</id>
<content type='text'>
[ Upstream commit 4993e5b37e8bcb55ac90f76eb6d2432647273747 ]

Ben Hutchings says:
	"This is the wrong place to change the queue mapping.
	stmmac_xmit() is called with a specific TX queue locked,
	and accessing a different TX queue results in a data race
	for all of that queue's state.

	I think this commit should be reverted upstream and in all
	stable branches.  Instead, the driver should implement the
	ndo_select_queue operation and override the queue mapping there."

Fixes: c5acdbee22a1 ("net: stmmac: Send TSO packets always from Queue 0")
Suggested-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Jose Abreu &lt;joabreu@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: stmmac: sun8i: force select external PHY when no internal one</title>
<updated>2019-07-26T07:10:34+00:00</updated>
<author>
<name>Icenowy Zheng</name>
<email>icenowy@aosc.io</email>
</author>
<published>2019-06-20T13:47:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=95b09c87f75588a4a4024aedbefcc13a9cda499a'/>
<id>urn:sha1:95b09c87f75588a4a4024aedbefcc13a9cda499a</id>
<content type='text'>
[ Upstream commit 0fec7e72ae1391bb2d7527efb54fe6ae88acabce ]

The PHY selection bit also exists on SoCs without an internal PHY; if it's
set to 1 (internal PHY, default value) then the MAC will not make use of
any PHY on such SoCs.

This problem appears when adapting for H6, which has no real internal PHY
(the "internal PHY" on H6 is not on-die, but on a co-packaged AC200 chip,
connected via RMII interface at GPIO bank A).

Force the PHY selection bit to 0 when the SOC doesn't have an internal PHY,
to address the problem of a wrong default value.

Signed-off-by: Icenowy Zheng &lt;icenowy@aosc.io&gt;
Signed-off-by: Ondrej Jirman &lt;megous@megous.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: stmmac: modify default value of tx-frames</title>
<updated>2019-07-26T07:10:22+00:00</updated>
<author>
<name>Biao Huang</name>
<email>biao.huang@mediatek.com</email>
</author>
<published>2019-06-03T01:58:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=faac7e78c489cd3debb9881a1bd40d4c5e2bb156'/>
<id>urn:sha1:faac7e78c489cd3debb9881a1bd40d4c5e2bb156</id>
<content type='text'>
[ Upstream commit d2facb4b3983425f6776c24dd678a82dbe673773 ]

the default value of tx-frames is 25, it's too late when
passing tstamp to stack, then the ptp4l will fail:

ptp4l -i eth0 -f gPTP.cfg -m
ptp4l: selected /dev/ptp0 as PTP clock
ptp4l: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l: port 1: link up
ptp4l: timed out while polling for tx timestamp
ptp4l: increasing tx_timestamp_timeout may correct this issue,
       but it is likely caused by a driver bug
ptp4l: port 1: send peer delay response failed
ptp4l: port 1: LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)

ptp4l tests pass when changing the tx-frames from 25 to 1 with
ethtool -C option.
It should be fine to set tx-frames default value to 1, so ptp4l will pass
by default.

Signed-off-by: Biao Huang &lt;biao.huang@mediatek.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: stmmac: dwmac4: fix flow control issue</title>
<updated>2019-07-26T07:10:22+00:00</updated>
<author>
<name>Biao Huang</name>
<email>biao.huang@mediatek.com</email>
</author>
<published>2019-06-03T01:58:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=037f641e406d026dcb36031142a2bc834da5084d'/>
<id>urn:sha1:037f641e406d026dcb36031142a2bc834da5084d</id>
<content type='text'>
[ Upstream commit ee326fd01e79dfa42014d55931260b68b9fa3273 ]

Current dwmac4_flow_ctrl will not clear
GMAC_RX_FLOW_CTRL_RFE/GMAC_RX_FLOW_CTRL_RFE bits,
so MAC hw will keep flow control on although expecting
flow control off by ethtool. Add codes to fix it.

Fixes: 477286b53f55 ("stmmac: add GMAC4 core support")
Signed-off-by: Biao Huang &lt;biao.huang@mediatek.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: stmmac: Prevent missing interrupts when running NAPI</title>
<updated>2019-07-26T07:10:15+00:00</updated>
<author>
<name>Jose Abreu</name>
<email>Jose.Abreu@synopsys.com</email>
</author>
<published>2019-05-24T08:20:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=55635ebe4f6aec64d7359ddf2901f8d138a8993d'/>
<id>urn:sha1:55635ebe4f6aec64d7359ddf2901f8d138a8993d</id>
<content type='text'>
[ Upstream commit a976ca79e23f13bff79c14e7266cea4a0ea51e67 ]

When we trigger NAPI we are disabling interrupts but in case we receive
or send a packet in the meantime, as interrupts are disabled, we will
miss this event.

Trigger both NAPI instances (RX and TX) when at least one event happens
so that we don't miss any interrupts.

Signed-off-by: Jose Abreu &lt;joabreu@synopsys.com&gt;
Cc: Joao Pinto &lt;jpinto@synopsys.com&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Giuseppe Cavallaro &lt;peppe.cavallaro@st.com&gt;
Cc: Alexandre Torgue &lt;alexandre.torgue@st.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>
