<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/ethernet/broadcom, branch v4.19.112</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.112</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.112'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-03-18T06:14:13+00:00</updated>
<entry>
<title>bnxt_en: reinitialize IRQs when MTU is modified</title>
<updated>2020-03-18T06:14:13+00:00</updated>
<author>
<name>Vasundhara Volam</name>
<email>vasundhara-v.volam@broadcom.com</email>
</author>
<published>2020-03-02T03:07:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aadf2a728fd714d683c3b2910784d9083e501405'/>
<id>urn:sha1:aadf2a728fd714d683c3b2910784d9083e501405</id>
<content type='text'>
[ Upstream commit a9b952d267e59a3b405e644930f46d252cea7122 ]

MTU changes may affect the number of IRQs so we must call
bnxt_close_nic()/bnxt_open_nic() with the irq_re_init parameter
set to true.  The reason is that a larger MTU may require
aggregation rings not needed with smaller MTU.  We may not be
able to allocate the required number of aggregation rings and
so we reduce the number of channels which will change the number
of IRQs.  Without this patch, it may crash eventually in
pci_disable_msix() when the IRQs are not properly unwound.

Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
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>net: systemport: fix index check to avoid an array out of bounds access</title>
<updated>2020-03-18T06:14:13+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2020-03-12T15:04:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c8149165ac27482b575620c55fc91afe8832d8ad'/>
<id>urn:sha1:c8149165ac27482b575620c55fc91afe8832d8ad</id>
<content type='text'>
[ Upstream commit c0368595c1639947839c0db8294ee96aca0b3b86 ]

Currently the bounds check on index is off by one and can lead to
an out of bounds access on array priv-&gt;filters_loc when index is
RXCHK_BRCM_TAG_MAX.

Fixes: bb9051a2b230 ("net: systemport: Add support for WAKE_FILTER")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.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: systemport: Avoid RBUF stuck in Wake-on-LAN mode</title>
<updated>2020-02-11T12:34:15+00:00</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2020-02-05T20:32:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b81a002bc03395c012624f8238dfb81a34915187'/>
<id>urn:sha1:b81a002bc03395c012624f8238dfb81a34915187</id>
<content type='text'>
[ Upstream commit 263a425a482fc495d6d3f9a29b9103a664c38b69 ]

After a number of suspend and resume cycles, it is possible for the RBUF
to be stuck in Wake-on-LAN mode, despite the MPD enable bit being
cleared which instructed the RBUF to exit that mode.

Avoid creating that problematic condition by clearing the RX_EN and
TX_EN bits in the UniMAC prior to disable the Magic Packet Detector
logic which is guaranteed to make the RBUF exit Wake-on-LAN mode.

Fixes: 83e82f4c706b ("net: systemport: add Wake-on-LAN support")
Signed-off-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>bnxt_en: Fix TC queue mapping.</title>
<updated>2020-02-11T12:33:53+00:00</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2020-02-02T07:41:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e7ec10b4ea8f6dbc19e8377b1064f4be3f630f3e'/>
<id>urn:sha1:e7ec10b4ea8f6dbc19e8377b1064f4be3f630f3e</id>
<content type='text'>
[ Upstream commit 18e4960c18f484ac288f41b43d0e6c4c88e6ea78 ]

The driver currently only calls netdev_set_tc_queue when the number of
TCs is greater than 1.  Instead, the comparison should be greater than
or equal to 1.  Even with 1 TC, we need to set the queue mapping.

This bug can cause warnings when the number of TCs is changed back to 1.

Fixes: 7809592d3e2e ("bnxt_en: Enable MSIX early in bnxt_init_one().")
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Fix ipv6 RFS filter matching logic.</title>
<updated>2020-02-05T14:43:47+00:00</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2020-01-17T05:32:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=23b8f9d7aa90574daf83ccbb541370c17c538372'/>
<id>urn:sha1:23b8f9d7aa90574daf83ccbb541370c17c538372</id>
<content type='text'>
[ Upstream commit 6fc7caa84e713f7627e171ab1e7c4b5be0dc9b3d ]

Fix bnxt_fltr_match() to match ipv6 source and destination addresses.
The function currently only checks ipv4 addresses and will not work
corrently on ipv6 filters.

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: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drivers/net/b44: Change to non-atomic bit operations on pwol_mask</title>
<updated>2020-02-01T09:37:08+00:00</updated>
<author>
<name>Fenghua Yu</name>
<email>fenghua.yu@intel.com</email>
</author>
<published>2020-01-02T21:27:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6079715f2cc204bb381fbbcd7ae0d9b9ef6b32de'/>
<id>urn:sha1:6079715f2cc204bb381fbbcd7ae0d9b9ef6b32de</id>
<content type='text'>
[ Upstream commit f11421ba4af706cb4f5703de34fa77fba8472776 ]

Atomic operations that span cache lines are super-expensive on x86
(not just to the current processor, but also to other processes as all
memory operations are blocked until the operation completes). Upcoming
x86 processors have a switch to cause such operations to generate a #AC
trap. It is expected that some real time systems will enable this mode
in BIOS.

In preparation for this, it is necessary to fix code that may execute
atomic instructions with operands that cross cachelines because the #AC
trap will crash the kernel.

Since "pwol_mask" is local and never exposed to concurrency, there is
no need to set bits in pwol_mask using atomic operations.

Directly operate on the byte which contains the bit instead of using
__set_bit() to avoid any big endian concern due to type cast to
unsigned long in __set_bit().

Suggested-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Signed-off-by: Fenghua Yu &lt;fenghua.yu@intel.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.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: bcmgenet: Use netif_tx_napi_add() for TX NAPI</title>
<updated>2020-01-29T15:43:15+00:00</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2020-01-23T17:49:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0705c8d7aae518e4cb22c68749eaac917e9902b8'/>
<id>urn:sha1:0705c8d7aae518e4cb22c68749eaac917e9902b8</id>
<content type='text'>
[ Upstream commit 148965df1a990af98b2c84092c2a2274c7489284 ]

Before commit 7587935cfa11 ("net: bcmgenet: move NAPI initialization to
ring initialization") moved the code, this used to be
netif_tx_napi_add(), but we lost that small semantic change in the
process, restore that.

Fixes: 7587935cfa11 ("net: bcmgenet: move NAPI initialization to ring initialization")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Acked-by: Doug Berger &lt;opendmb@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: broadcom/bcmsysport: Fix signedness in bcm_sysport_probe()</title>
<updated>2020-01-27T13:51:15+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2019-09-25T10:56:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=49ebb26880bc4f0d3b748d3ec48110a459b1f6ad'/>
<id>urn:sha1:49ebb26880bc4f0d3b748d3ec48110a459b1f6ad</id>
<content type='text'>
[ Upstream commit 25a584955f020d6ec499c513923fb220f3112d2b ]

The "priv-&gt;phy_interface" variable is an enum and in this context GCC
will treat it as unsigned so the error handling will never be
triggered.

Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Acked-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;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Increase timeout for HWRM_DBG_COREDUMP_XX commands</title>
<updated>2020-01-27T13:51:13+00:00</updated>
<author>
<name>Vasundhara Volam</name>
<email>vasundhara-v.volam@broadcom.com</email>
</author>
<published>2019-09-14T04:01:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3f225f58d89591eccde789e09589e61fdf2193e3'/>
<id>urn:sha1:3f225f58d89591eccde789e09589e61fdf2193e3</id>
<content type='text'>
[ Upstream commit 57a8730b1f7a0be7bf8a0a0bb665329074ba764f ]

Firmware coredump messages take much longer than standard messages,
so increase the timeout accordingly.

Fixes: 6c5657d085ae ("bnxt_en: Add support for ethtool get dump.")
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: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Fix handling FRAG_ERR when NVM_INSTALL_UPDATE cmd fails</title>
<updated>2020-01-27T13:51:05+00:00</updated>
<author>
<name>Vasundhara Volam</name>
<email>vasundhara-v.volam@broadcom.com</email>
</author>
<published>2019-08-17T21:04:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9b259f1ed0489e23d33868437666140d48f561c4'/>
<id>urn:sha1:9b259f1ed0489e23d33868437666140d48f561c4</id>
<content type='text'>
[ Upstream commit dd2ebf3404c7c295014bc025dea23960960ceb1a ]

If FW returns FRAG_ERR in response error code, driver is resending the
command only when HWRM command returns success. Fix the code to resend
NVM_INSTALL_UPDATE command with DEFRAG install flags, if FW returns
FRAG_ERR in its response error code.

Fixes: cb4d1d626145 ("bnxt_en: Retry failed NVM_INSTALL_UPDATE with defragmentation flag enabled.")
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: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
