<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/ethernet/broadcom, branch linux-5.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2019-07-28T06:28:26Z</updated>
<entry>
<title>net: bcmgenet: use promisc for unsupported filters</title>
<updated>2019-07-28T06:28:26Z</updated>
<author>
<name>Justin Chen</name>
<email>justinpopo6@gmail.com</email>
</author>
<published>2019-07-17T21:58:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=17f782cc4039d48436587b897658937158c2ef33'/>
<id>urn:sha1:17f782cc4039d48436587b897658937158c2ef33</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:28:23Z</updated>
<author>
<name>Brian King</name>
<email>brking@linux.vnet.ibm.com</email>
</author>
<published>2019-07-15T21:41:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c73a6485a8aa9fe08ca8d31af3c9925ff59cf9c7'/>
<id>urn:sha1:c73a6485a8aa9fe08ca8d31af3c9925ff59cf9c7</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:12:48Z</updated>
<author>
<name>Guilherme G. Piccoli</name>
<email>gpiccoli@canonical.com</email>
</author>
<published>2019-06-27T16:31:33Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=74d03f7e9017e6c0301817094f0437e6ff710ae5'/>
<id>urn:sha1:74d03f7e9017e6c0301817094f0437e6ff710ae5</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>bnxt_en: Fix statistics context reservation logic for RDMA driver.</title>
<updated>2019-07-26T07:12:47Z</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2019-06-29T15:16:46Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=dcbc804c94d678cb8acd6c06dc8410a67cbc52d4'/>
<id>urn:sha1:dcbc804c94d678cb8acd6c06dc8410a67cbc52d4</id>
<content type='text'>
[ Upstream commit d77b1ad8e87dc5a6cd0d9158b097a4817946ca3b ]

The current logic assumes that the RDMA driver uses one statistics
context adjacent to the ones used by the network driver.  This
assumption is not true and the statistics context used by the
RDMA driver is tied to its MSIX base vector.  This wrong assumption
can cause RDMA driver failure after changing ethtool rings on the
network side.  Fix the statistics reservation logic accordingly.

Fixes: 780baad44f0f ("bnxt_en: Reserve 1 stat_ctx for RDMA 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: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Disable bus master during PCI shutdown and driver unload.</title>
<updated>2019-07-26T07:12:47Z</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2019-06-29T15:16:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=51a21893890373b6daad0a139a55ea642959db3d'/>
<id>urn:sha1:51a21893890373b6daad0a139a55ea642959db3d</id>
<content type='text'>
[ Upstream commit c20dc142dd7b2884b8570eeab323bcd4a84294fa ]

Some chips with older firmware can continue to perform DMA read from
context memory even after the memory has been freed.  In the PCI shutdown
method, we need to call pci_disable_device() to shutdown DMA to prevent
this DMA before we put the device into D3hot.  DMA memory request in
D3hot state will generate PCI fatal error.  Similarly, in the driver
remove method, the context memory should only be freed after DMA has
been shutdown for correctness.

Fixes: 98f04cf0f1fc ("bnxt_en: Check context memory requirements from firmware.")
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;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnx2x: Check if transceiver implements DDM before access</title>
<updated>2019-07-14T06:09:45Z</updated>
<author>
<name>Mauro S. M. Rodrigues</name>
<email>maurosr@linux.vnet.ibm.com</email>
</author>
<published>2019-06-13T19:25:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d929834822c78b3a88105ec52a796f08f3a8976e'/>
<id>urn:sha1:d929834822c78b3a88105ec52a796f08f3a8976e</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: Reduce memory usage when running in kdump kernel.</title>
<updated>2019-06-04T05:59:44Z</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2019-05-22T23:12:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7b16eb9190b2eb4d2a063260f9951c859bc850ad'/>
<id>urn:sha1:7b16eb9190b2eb4d2a063260f9951c859bc850ad</id>
<content type='text'>
[ Upstream commit d629522e1d66561f38e5c8d4f52bb6d254ec0707 ]

Skip RDMA context memory allocations, reduce to 1 ring, and disable
TPA when running in the kdump kernel.  Without this patch, the driver
fails to initialize with memory allocation errors when running in a
typical kdump kernel.

Fixes: cf6daed098d1 ("bnxt_en: Increase context memory allocations on 57500 chips for RDMA.")
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 possible BUG() condition when calling pci_disable_msix().</title>
<updated>2019-06-04T05:59:44Z</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2019-05-22T23:12:55Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=45e8cd220d74c5628941ce525f0a3481385edec8'/>
<id>urn:sha1:45e8cd220d74c5628941ce525f0a3481385edec8</id>
<content type='text'>
[ Upstream commit 1b3f0b75c39f534278a895c117282014e9d0ae1f ]

When making configuration changes, the driver calls bnxt_close_nic()
and then bnxt_open_nic() for the changes to take effect.  A parameter
irq_re_init is passed to the call sequence to indicate if IRQ
should be re-initialized.  This irq_re_init parameter needs to
be included in the bnxt_reserve_rings() call.  bnxt_reserve_rings()
can only call pci_disable_msix() if the irq_re_init parameter is
true, otherwise it may hit BUG() because some IRQs may not have been
freed yet.

Fixes: 41e8d7983752 ("bnxt_en: Modify the ring reservation functions for 57500 series chips.")
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 aggregation buffer leak under OOM condition.</title>
<updated>2019-06-04T05:59:43Z</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2019-05-22T23:12:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=024512262906267f810817d58ec345b8050647cb'/>
<id>urn:sha1:024512262906267f810817d58ec345b8050647cb</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-04-27T21:00:19Z</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2019-04-26T02:31:55Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0b397b17a4120cb80f7bf89eb30587b3dd9b0d1d'/>
<id>urn:sha1:0b397b17a4120cb80f7bf89eb30587b3dd9b0d1d</id>
<content type='text'>
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;
</content>
</entry>
</feed>
