<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/ethernet/broadcom, branch v3.18.100</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.18.100</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.18.100'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-03-03T09:17:09+00:00</updated>
<entry>
<title>bnx2x: Improve reliability in case of nested PCI errors</title>
<updated>2018-03-03T09:17:09+00:00</updated>
<author>
<name>Guilherme G. Piccoli</name>
<email>gpiccoli@linux.vnet.ibm.com</email>
</author>
<published>2017-12-22T15:01:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c85a6e7bdea9a9532c1e68c1c472082bf88bc210'/>
<id>urn:sha1:c85a6e7bdea9a9532c1e68c1c472082bf88bc210</id>
<content type='text'>
[ Upstream commit f7084059a9cb9e56a186e1677b1dcffd76c2cd24 ]

While in recovery process of PCI error (called EEH on PowerPC arch),
another PCI transaction could be corrupted causing a situation of
nested PCI errors. Also, this scenario could be reproduced with
error injection mechanisms (for debug purposes).

We observe that in case of nested PCI errors, bnx2x might attempt to
initialize its shmem and cause a kernel crash due to bad addresses
read from MCP. Multiple different stack traces were observed depending
on the point the second PCI error happens.

This patch avoids the crashes by:

 * failing PCI recovery in case of nested errors (since multiple
 PCI errors in a row are not expected to lead to a functional
 adapter anyway), and by,

 * preventing access to adapter FW when MCP is failed (we mark it as
 failed when shmem cannot get initialized properly).

Reported-by: Abdul Haleem &lt;abdhalee@linux.vnet.ibm.com&gt;
Signed-off-by: Guilherme G. Piccoli &lt;gpiccoli@linux.vnet.ibm.com&gt;
Acked-by: Shahed Shaikh &lt;Shahed.Shaikh@cavium.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tg3: Enable PHY reset in MTU change path for 5720</title>
<updated>2018-03-03T09:17:09+00:00</updated>
<author>
<name>Siva Reddy Kallam</name>
<email>siva.kallam@broadcom.com</email>
</author>
<published>2017-12-22T10:35:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e93041fc495ba9b76b842b4edff57655e54e4fd0'/>
<id>urn:sha1:e93041fc495ba9b76b842b4edff57655e54e4fd0</id>
<content type='text'>
[ Upstream commit e60ee41aaf898584205a6af5c996860d0fe6a836 ]

A customer noticed RX path hang when MTU is changed on the fly while
running heavy traffic with NCSI enabled for 5717 and 5719. Since 5720
belongs to same ASIC family, we observed same issue and same fix
could solve this problem for 5720.

Signed-off-by: Siva Reddy Kallam &lt;siva.kallam@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tg3: Add workaround to restrict 5762 MRRS to 2048</title>
<updated>2018-03-03T09:17:08+00:00</updated>
<author>
<name>Siva Reddy Kallam</name>
<email>siva.kallam@broadcom.com</email>
</author>
<published>2017-12-22T10:35:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7862b4d6f8acde0386d17ee162e0ddb26faea751'/>
<id>urn:sha1:7862b4d6f8acde0386d17ee162e0ddb26faea751</id>
<content type='text'>
[ Upstream commit 4419bb1cedcda0272e1dc410345c5a1d1da0e367 ]

One of AMD based server with 5762 hangs with jumbo frame traffic.
This AMD platform has southbridge limitation which is restricting MRRS
to 4000. As a work around, driver to restricts the MRRS to 2048 for
this particular 5762 NX1 card.

Signed-off-by: Siva Reddy Kallam &lt;siva.kallam@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tg3: Fix rx hang on MTU change with 5717/5719</title>
<updated>2018-01-02T19:04:58+00:00</updated>
<author>
<name>Brian King</name>
<email>brking@linux.vnet.ibm.com</email>
</author>
<published>2017-12-15T21:21:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=13550e44cf624e75e57f073fe753b0c45bd2cbf1'/>
<id>urn:sha1:13550e44cf624e75e57f073fe753b0c45bd2cbf1</id>
<content type='text'>
[ Upstream commit 748a240c589824e9121befb1cba5341c319885bc ]

This fixes a hang issue seen when changing the MTU size from 1500 MTU
to 9000 MTU on both 5717 and 5719 chips. In discussion with Broadcom,
they've indicated that these chipsets have the same phy as the 57766
chipset, so the same workarounds apply. This has been tested by IBM
on both Power 8 and Power 9 systems as well as by Broadcom on x86
hardware and has been confirmed to resolve the hang issue.

Signed-off-by: Brian King &lt;brking@linux.vnet.ibm.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: bcmgenet: Power up the internal PHY before probing the MII</title>
<updated>2017-12-20T09:01:29+00:00</updated>
<author>
<name>Doug Berger</name>
<email>opendmb@gmail.com</email>
</author>
<published>2017-03-10T00:58:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f73422f3a6e833ec44f0f37211781eab50223f71'/>
<id>urn:sha1:f73422f3a6e833ec44f0f37211781eab50223f71</id>
<content type='text'>
[ Upstream commit 6be371b053dc86f11465cc1abce2e99bda0a0574 ]

When using the internal PHY it must be powered up when the MII is probed
or the PHY will not be detected.  Since the PHY is powered up at reset
this has not been a problem.  However, when the kernel is restarted with
kexec the PHY will likely be powered down when the kernel starts so it
will not be detected and the Ethernet link will not be established.

This commit explicitly powers up the internal PHY when the GENET driver
is probed to correct this behavior.

Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger &lt;opendmb@gmail.com&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: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: bcmgenet: correct MIB access of UniMAC RUNT counters</title>
<updated>2017-12-20T09:01:29+00:00</updated>
<author>
<name>Doug Berger</name>
<email>opendmb@gmail.com</email>
</author>
<published>2017-03-10T00:58:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1a34a1137f7693d9dbd3ad108dd9a13fa44cdc57'/>
<id>urn:sha1:1a34a1137f7693d9dbd3ad108dd9a13fa44cdc57</id>
<content type='text'>
[ Upstream commit 1ad3d225e5a40ca6c586989b4baaca710544c15a ]

The gap between the Tx status counters and the Rx RUNT counters is now
being added to allow correct reporting of the registers.

Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger &lt;opendmb@gmail.com&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: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values</title>
<updated>2017-12-20T09:01:29+00:00</updated>
<author>
<name>Doug Berger</name>
<email>opendmb@gmail.com</email>
</author>
<published>2017-03-10T00:58:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bbfc83efb91c5f1f3b393367356105d3a6f5f17a'/>
<id>urn:sha1:bbfc83efb91c5f1f3b393367356105d3a6f5f17a</id>
<content type='text'>
[ Upstream commit ffff71328a3c321f7c14cc1edd33577717037744 ]

The location of the RBUF overflow and error counters has moved between
different version of the GENET MAC.  This commit corrects the driver to
read from the correct locations depending on the version of the GENET
MAC.

Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger &lt;opendmb@gmail.com&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: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bnx2x: fix possible overrun of VFPF multicast addresses array</title>
<updated>2017-12-16T09:32:29+00:00</updated>
<author>
<name>Michal Schmidt</name>
<email>mschmidt@redhat.com</email>
</author>
<published>2017-03-03T16:08:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fc4281753409d6afd4851e864c35a3a74a62dd37'/>
<id>urn:sha1:fc4281753409d6afd4851e864c35a3a74a62dd37</id>
<content type='text'>
[ Upstream commit 22118d861cec5da6ed525aaf12a3de9bfeffc58f ]

It is too late to check for the limit of the number of VF multicast
addresses after they have already been copied to the req-&gt;multicast[]
array, possibly overflowing it.

Do the check before copying.

Also fix the error path to not skip unlocking vf2pf_mutex.

Signed-off-by: Michal Schmidt &lt;mschmidt@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tg3: Fix race condition in tg3_get_stats64().</title>
<updated>2017-08-11T16:30:15+00:00</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2017-01-06T21:18:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=80334372c59660b41e7526070fef5261fad4c28c'/>
<id>urn:sha1:80334372c59660b41e7526070fef5261fad4c28c</id>
<content type='text'>
[ Upstream commit f5992b72ebe0dde488fa8f706b887194020c66fc ]

The driver's ndo_get_stats64() method is not always called under RTNL.
So it can race with driver close or ethtool reconfigurations.  Fix the
race condition by taking tp-&gt;lock spinlock in tg3_free_consistent()
when freeing the tp-&gt;hw_stats memory block.  tg3_get_stats64() is
already taking tp-&gt;lock.

Reported-by: Wang Yufen &lt;wangyufen@huawei.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bgmac: reset &amp; enable Ethernet core before using it</title>
<updated>2017-07-15T08:14:38+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>zajec5@gmail.com</email>
</author>
<published>2016-04-12T11:30:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c3a247e00b4024812ce4574c30c95fcdf5d28973'/>
<id>urn:sha1:c3a247e00b4024812ce4574c30c95fcdf5d28973</id>
<content type='text'>
commit b4dfd8e92956b396d3438212bc9a0be6267b8b34 upstream.

This fixes Ethernet on D-Link DIR-885L with BCM47094 SoC. Felix reported
similar fix was needed for his BCM4709 device (Buffalo WXR-1900DHP?).
I tested this for regressions on BCM4706, BCM4708A0 and BCM47081A0.

Cc: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Amit Pundir &lt;amit.pundir@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
