<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/ethernet/broadcom, branch v4.19.77</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.77</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.77'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-08-25T08:48:03+00:00</updated>
<entry>
<title>bnx2x: Fix VF's VLAN reconfiguration in reload.</title>
<updated>2019-08-25T08:48:03+00:00</updated>
<author>
<name>Manish Chopra</name>
<email>manishc@marvell.com</email>
</author>
<published>2019-08-18T14:25:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=40933af400c5e0e37fe475111d7d9fcc815f27de'/>
<id>urn:sha1:40933af400c5e0e37fe475111d7d9fcc815f27de</id>
<content type='text'>
[ Upstream commit 4a4d2d372fb9b9229327e2ed01d5d9572eddf4de ]

Commit 04f05230c5c13 ("bnx2x: Remove configured vlans as
part of unload sequence."), introduced a regression in driver
that as a part of VF's reload flow, VLANs created on the VF
doesn't get re-configured in hardware as vlan metadata/info
was not getting cleared for the VFs which causes vlan PING to stop.

This patch clears the vlan metadata/info so that VLANs gets
re-configured back in the hardware in VF's reload flow and
PING/traffic continues for VLANs created over the VFs.

Fixes: 04f05230c5c13 ("bnx2x: Remove configured vlans as part of unload sequence.")
Signed-off-by: Manish Chopra &lt;manishc@marvell.com&gt;
Signed-off-by: Sudarsana Kalluru &lt;skalluru@marvell.com&gt;
Signed-off-by: Shahed Shaikh &lt;shshaikh@marvell.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>bnx2x: Disable multi-cos feature.</title>
<updated>2019-08-09T15:52:29+00:00</updated>
<author>
<name>Sudarsana Reddy Kalluru</name>
<email>skalluru@marvell.com</email>
</author>
<published>2019-07-24T02:32:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=774358df88f7259dafebb5876de4196826ca75a7'/>
<id>urn:sha1:774358df88f7259dafebb5876de4196826ca75a7</id>
<content type='text'>
[ Upstream commit d1f0b5dce8fda09a7f5f04c1878f181d548e42f5 ]

Commit 3968d38917eb ("bnx2x: Fix Multi-Cos.") which enabled multi-cos
feature after prolonged time in driver added some regression causing
numerous issues (sudden reboots, tx timeout etc.) reported by customers.
We plan to backout this commit and submit proper fix once we have root
cause of issues reported with this feature enabled.

Fixes: 3968d38917eb ("bnx2x: Fix Multi-Cos.")
Signed-off-by: Sudarsana Reddy Kalluru &lt;skalluru@marvell.com&gt;
Signed-off-by: Manish Chopra &lt;manishc@marvell.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: use promisc for unsupported filters</title>
<updated>2019-07-28T06:29:24+00:00</updated>
<author>
<name>Justin Chen</name>
<email>justinpopo6@gmail.com</email>
</author>
<published>2019-07-17T21:58:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5832ef4afd90ef5dda9960b56fa3b8092530e0fb'/>
<id>urn:sha1:5832ef4afd90ef5dda9960b56fa3b8092530e0fb</id>
<content type='text'>
[ Upstream commit 35cbef9863640f06107144687bd13151bc2e8ce3 ]

Currently we silently ignore filters if we cannot meet the filter
requirements. This will lead to the MAC dropping packets that are
expected to pass. A better solution would be to set the NIC to promisc
mode when the required filters cannot be met.

Also correct the number of MDF filters supported. It should be 17,
not 16.

Signed-off-by: Justin Chen &lt;justinpopo6@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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bnx2x: Prevent load reordering in tx completion processing</title>
<updated>2019-07-28T06:29:23+00:00</updated>
<author>
<name>Brian King</name>
<email>brking@linux.vnet.ibm.com</email>
</author>
<published>2019-07-15T21:41:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8fb37be120469a4bd729be833d32010d4bba4e41'/>
<id>urn:sha1:8fb37be120469a4bd729be833d32010d4bba4e41</id>
<content type='text'>
[ Upstream commit ea811b795df24644a8eb760b493c43fba4450677 ]

This patch fixes an issue seen on Power systems with bnx2x which results
in the skb is NULL WARN_ON in bnx2x_free_tx_pkt firing due to the skb
pointer getting loaded in bnx2x_free_tx_pkt prior to the hw_cons
load in bnx2x_tx_int. Adding a read memory barrier resolves the 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>bnx2x: Prevent ptp_task to be rescheduled indefinitely</title>
<updated>2019-07-26T07:14:15+00:00</updated>
<author>
<name>Guilherme G. Piccoli</name>
<email>gpiccoli@canonical.com</email>
</author>
<published>2019-06-27T16:31:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=51216937c3196b61ede2ec86098af50c65ab321d'/>
<id>urn:sha1:51216937c3196b61ede2ec86098af50c65ab321d</id>
<content type='text'>
[ Upstream commit 3c91f25c2f72ba6001775a5932857c1d2131c531 ]

Currently bnx2x ptp worker tries to read a register with timestamp
information in case of TX packet timestamping and in case it fails,
the routine reschedules itself indefinitely. This was reported as a
kworker always at 100% of CPU usage, which was narrowed down to be
bnx2x ptp_task.

By following the ioctl handler, we could narrow down the problem to
an NTP tool (chrony) requesting HW timestamping from bnx2x NIC with
RX filter zeroed; this isn't reproducible for example with ptp4l
(from linuxptp) since this tool requests a supported RX filter.
It seems NIC FW timestamp mechanism cannot work well with
RX_FILTER_NONE - driver's PTP filter init routine skips a register
write to the adapter if there's not a supported filter request.

This patch addresses the problem of bnx2x ptp thread's everlasting
reschedule by retrying the register read 10 times; between the read
attempts the thread sleeps for an increasing amount of time starting
in 1ms to give FW some time to perform the timestamping. If it still
fails after all retries, we bail out in order to prevent an unbound
resource consumption from bnx2x.

The patch also adds an ethtool statistic for accounting the skipped
TX timestamp packets and it reduces the priority of timestamping
error messages to prevent log flooding. The code was tested using
both linuxptp and chrony.

Reported-and-tested-by: Przemyslaw Hausman &lt;przemyslaw.hausman@canonical.com&gt;
Suggested-by: Sudarsana Reddy Kalluru &lt;skalluru@marvell.com&gt;
Signed-off-by: Guilherme G. Piccoli &lt;gpiccoli@canonical.com&gt;
Acked-by: Sudarsana Reddy Kalluru &lt;skalluru@marvell.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>bnx2x: Check if transceiver implements DDM before access</title>
<updated>2019-07-14T06:11:14+00:00</updated>
<author>
<name>Mauro S. M. Rodrigues</name>
<email>maurosr@linux.vnet.ibm.com</email>
</author>
<published>2019-06-13T19:25:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4c938a635fc37906761c72d70ebd00c54e497499'/>
<id>urn:sha1:4c938a635fc37906761c72d70ebd00c54e497499</id>
<content type='text'>
[ Upstream commit cf18cecca911c0db96b868072665347efe6df46f ]

Some transceivers may comply with SFF-8472 even though they do not
implement the Digital Diagnostic Monitoring (DDM) interface described in
the spec. The existence of such area is specified by the 6th bit of byte
92, set to 1 if implemented.

Currently, without checking this bit, bnx2x fails trying to read sfp
module's EEPROM with the follow message:

ethtool -m enP5p1s0f1
Cannot get Module EEPROM data: Input/output error

Because it fails to read the additional 256 bytes in which it is assumed
to exist the DDM data.

This issue was noticed using a Mellanox Passive DAC PN 01FT738. The EEPROM
data was confirmed by Mellanox as correct and similar to other Passive
DACs from other manufacturers.

Signed-off-by: Mauro S. M. Rodrigues &lt;maurosr@linux.vnet.ibm.com&gt;
Acked-by: Sudarsana Reddy Kalluru &lt;skalluru@marvell.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>bnxt_en: Fix aggregation buffer leak under OOM condition.</title>
<updated>2019-06-04T06:02:33+00:00</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2019-05-22T23:12:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=27d8ad1d8ea9b9c80ae13556c34927ad83a4355d'/>
<id>urn:sha1:27d8ad1d8ea9b9c80ae13556c34927ad83a4355d</id>
<content type='text'>
[ Upstream commit 296d5b54163964b7ae536b8b57dfbd21d4e868e1 ]

For every RX packet, the driver replenishes all buffers used for that
packet and puts them back into the RX ring and RX aggregation ring.
In one code path where the RX packet has one RX buffer and one or more
aggregation buffers, we missed recycling the aggregation buffer(s) if
we are unable to allocate a new SKB buffer.  This leads to the
aggregation ring slowly running out of buffers over time.  Fix it
by properly recycling the aggregation buffers.

Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Reported-by: Rakesh Hemnani &lt;rhemnani@fb.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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Fix uninitialized variable usage in bnxt_rx_pkt().</title>
<updated>2019-05-05T12:42:40+00:00</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2019-04-26T02:31:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f1fd68e934091734c21e3ea21748d272f08b3fee'/>
<id>urn:sha1:f1fd68e934091734c21e3ea21748d272f08b3fee</id>
<content type='text'>
[ Upstream commit 0b397b17a4120cb80f7bf89eb30587b3dd9b0d1d ]

In bnxt_rx_pkt(), if the driver encounters BD errors, it will recycle
the buffers and jump to the end where the uninitailized variable "len"
is referenced.  Fix it by adding a new jump label that will skip
the length update.  This is the most correct fix since the length
may not be valid when we get this type of error.

Fixes: 6a8788f25625 ("bnxt_en: add support for software dynamic interrupt moderation")
Reported-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Cc: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Reviewed-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Tested-by: Nathan Chancellor &lt;natechancellor@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>bnxt_en: Free short FW command HWRM memory in error path in bnxt_init_one()</title>
<updated>2019-05-05T12:42:39+00:00</updated>
<author>
<name>Vasundhara Volam</name>
<email>vasundhara-v.volam@broadcom.com</email>
</author>
<published>2019-04-26T02:31:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=396350737326d0e54c848ae14e4eb7160592633d'/>
<id>urn:sha1:396350737326d0e54c848ae14e4eb7160592633d</id>
<content type='text'>
[ Upstream commit f9099d611449836a51a65f40ea7dc9cb5f2f665e ]

In the bnxt_init_one() error path, short FW command request memory
is not freed. This patch fixes it.

Fixes: e605db801bde ("bnxt_en: Support for Short Firmware Message")
Signed-off-by: Vasundhara Volam &lt;vasundhara-v.volam@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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Improve multicast address setup logic.</title>
<updated>2019-05-05T12:42:39+00:00</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2019-04-26T02:31:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=09a9213613533a7e34245df1f258764cf71a5206'/>
<id>urn:sha1:09a9213613533a7e34245df1f258764cf71a5206</id>
<content type='text'>
[ Upstream commit b4e30e8e7ea1d1e35ffd64ca46f7d9a7f227b4bf ]

The driver builds a list of multicast addresses and sends it to the
firmware when the driver's ndo_set_rx_mode() is called.  In rare
cases, the firmware can fail this call if internal resources to
add multicast addresses are exhausted.  In that case, we should
try the call again by setting the ALL_MCAST flag which is more
guaranteed to succeed.

Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
