<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/net/ethernet/broadcom, 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-08-25T14:10:38+00:00</updated>
<entry>
<title>bnxt_en: Fix to include flow direction in L2 key</title>
<updated>2019-08-25T14:10:38+00:00</updated>
<author>
<name>Somnath Kotur</name>
<email>somnath.kotur@broadcom.com</email>
</author>
<published>2019-08-17T21:04:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=13ac261e86b5f6cdd6b7aaf2cb57ed48a2b8793d'/>
<id>urn:sha1:13ac261e86b5f6cdd6b7aaf2cb57ed48a2b8793d</id>
<content type='text'>
[ Upstream commit 9bf46566e80fd94845527d01ebd888eb49313551 ]

FW expects the driver to provide unique flow reference handles
for Tx or Rx flows. When a Tx flow and an Rx flow end up sharing
a reference handle, flow offload does not seem to work.
This could happen in the case of 2 flows having their L2 fields
wildcarded but in different direction.
Fix to incorporate the flow direction as part of the L2 key

v2: Move the dir field to the end of the bnxt_tc_l2_key struct to
fix the warning reported by kbuild test robot &lt;lkp@intel.com&gt;.
There is existing code that initializes the structure using
nested initializer and will warn with the new u8 field added to
the beginning.  The structure also packs nicer when this new u8 is
added to the end of the structure [MChan].

Fixes: abd43a13525d ("bnxt_en: Support for 64-bit flow handle.")
Signed-off-by: Somnath Kotur &lt;somnath.kotur@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: Use correct src_fid to determine direction of the flow</title>
<updated>2019-08-25T14:10:37+00:00</updated>
<author>
<name>Venkat Duvvuru</name>
<email>venkatkumar.duvvuru@broadcom.com</email>
</author>
<published>2019-08-17T21:04:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=58516d32c2871e277ceaaa0ab1dec5c56f29034d'/>
<id>urn:sha1:58516d32c2871e277ceaaa0ab1dec5c56f29034d</id>
<content type='text'>
[ Upstream commit 685ec6a81bb0d47faf1dba49437d5bdaede2733d ]

Direction of the flow is determined using src_fid. For an RX flow,
src_fid is PF's fid and for TX flow, src_fid is VF's fid. Direction
of the flow must be specified, when getting statistics for that flow.
Currently, for DECAP flow, direction is determined incorrectly, i.e.,
direction is initialized as TX for DECAP flow, instead of RX. Because
of which, stats are not reported for this DECAP flow, though it is
offloaded and there is traffic for that flow, resulting in flow age out.

This patch fixes the problem by determining the DECAP flow's direction
using correct fid.  Set the flow direction in all cases for consistency
even if 64-bit flow handle is not used.

Fixes: abd43a13525d ("bnxt_en: Support for 64-bit flow handle.")
Signed-off-by: Venkat Duvvuru &lt;venkatkumar.duvvuru@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: Suppress HWRM errors for HWRM_NVM_GET_VARIABLE command</title>
<updated>2019-08-25T14:10:37+00:00</updated>
<author>
<name>Vasundhara Volam</name>
<email>vasundhara-v.volam@broadcom.com</email>
</author>
<published>2019-08-17T21:04:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=45ad3556e9edcc9ee505ca8544dad7480736a713'/>
<id>urn:sha1:45ad3556e9edcc9ee505ca8544dad7480736a713</id>
<content type='text'>
[ Upstream commit b703ba751dbb4bcd086509ed4b28102bc1670b35 ]

For newly added NVM parameters, older firmware may not have the support.
Suppress the error message to avoid the unncessary error message which is
triggered when devlink calls the driver during initialization.

Fixes: 782a624d00fa ("bnxt_en: Add bnxt_en initial params table and register it.")
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: Fix handling FRAG_ERR when NVM_INSTALL_UPDATE cmd fails</title>
<updated>2019-08-25T14:10:37+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/BMC/Intel-BMC/linux.git/commit/?id=d54cfa9da8fec22421fb3c1f2f5c0ad1c225dcab'/>
<id>urn:sha1:d54cfa9da8fec22421fb3c1f2f5c0ad1c225dcab</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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Improve RX doorbell sequence.</title>
<updated>2019-08-25T14:10:37+00:00</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2019-08-17T21:04:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=889e8658d99a2fbab7a0fd7925720e341e1e15d9'/>
<id>urn:sha1:889e8658d99a2fbab7a0fd7925720e341e1e15d9</id>
<content type='text'>
[ Upstream commit e8f267b063208372f7a329c6d5288d58944d873c ]

When both RX buffers and RX aggregation buffers have to be
replenished at the end of NAPI, post the RX aggregation buffers first
before RX buffers.  Otherwise, we may run into a situation where
there are only RX buffers without RX aggregation buffers for a split
second.  This will cause the hardware to abort the RX packet and
report buffer errors, which will cause unnecessary cleanup by the
driver.

Ringing the Aggregation ring doorbell first before the RX ring doorbell
will prevent some of these buffer errors.  Use the same sequence during
ring initialization as well.

Fixes: 697197e5a173 ("bnxt_en: Re-structure doorbells.")
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 VNIC clearing logic for 57500 chips.</title>
<updated>2019-08-25T14:10:37+00:00</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2019-08-17T21:04:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=6fdedaf3ad0c6f76ddc3436705b48714930f8bf0'/>
<id>urn:sha1:6fdedaf3ad0c6f76ddc3436705b48714930f8bf0</id>
<content type='text'>
[ Upstream commit a46ecb116fb7f722fa8cb2da01959c36e4e10c41 ]

During device shutdown, the VNIC clearing sequence needs to be modified
to free the VNIC first before freeing the RSS contexts.  The current
code is doing the reverse and we can get mis-directed RX completions
to CP ring ID 0 when the RSS contexts are freed and zeroed.  The clearing
of RSS contexts is not required with the new sequence.

Refactor the VNIC clearing logic into a new function bnxt_clear_vnic()
and do the chip specific VNIC clearing sequence.

Fixes: 7b3af4f75b81 ("bnxt_en: Add RSS support for 57500 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>bnx2x: Fix VF's VLAN reconfiguration in reload.</title>
<updated>2019-08-25T14:10:36+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/BMC/Intel-BMC/linux.git/commit/?id=5d6f83b9ed50d271bc6e95f901efc44c49d7cb7a'/>
<id>urn:sha1:5d6f83b9ed50d271bc6e95f901efc44c49d7cb7a</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:51:42+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/BMC/Intel-BMC/linux.git/commit/?id=1bd9197d30118523dba164a59d6337fc7c0c068a'/>
<id>urn:sha1:1bd9197d30118523dba164a59d6337fc7c0c068a</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>bnxt_en: Fix VNIC accounting when enabling aRFS on 57500 chips.</title>
<updated>2019-07-28T06:27:20+00:00</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2019-07-17T07:07:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a48f25afe922c0723dbbe902938c6dbf22f14d36'/>
<id>urn:sha1:a48f25afe922c0723dbbe902938c6dbf22f14d36</id>
<content type='text'>
[ Upstream commit 9b3d15e6b05e0b916be5fbd915f90300a403098b ]

Unlike legacy chips, 57500 chips don't need additional VNIC resources
for aRFS/ntuple.  Fix the code accordingly so that we don't reserve
and allocate additional VNICs on 57500 chips.  Without this patch,
the driver is failing to initialize when it tries to allocate extra
VNICs.

Fixes: ac33906c67e2 ("bnxt_en: Add support for aRFS on 57500 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>net: bcmgenet: use promisc for unsupported filters</title>
<updated>2019-07-28T06:27:13+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/BMC/Intel-BMC/linux.git/commit/?id=24a5602b4c3f3e3b0791b569df33cca96d63a15d'/>
<id>urn:sha1:24a5602b4c3f3e3b0791b569df33cca96d63a15d</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>
</feed>
