<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/ethernet/broadcom, branch linux-5.3.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.3.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.3.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-12-04T21:33:51Z</updated>
<entry>
<title>net: bcmgenet: reapply manual settings to the PHY</title>
<updated>2019-12-04T21:33:51Z</updated>
<author>
<name>Doug Berger</name>
</author>
<published>2019-11-05T19:07:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d100120fbc8122e6d418ff6ec64887b1e0209593'/>
<id>urn:sha1:d100120fbc8122e6d418ff6ec64887b1e0209593</id>
<content type='text'>
[ Upstream commit 0686bd9d5e6863f60e4bb1e78e6fe7bb217a0890 ]

The phy_init_hw() function may reset the PHY to a configuration
that does not match manual network settings stored in the phydev
structure. If the phy state machine is polled rather than event
driven this can create a timing hazard where the phy state machine
might alter the settings stored in the phydev structure from the
value read from the BMCR.

This commit follows invocations of phy_init_hw() by the bcmgenet
driver with invocations of the genphy_config_aneg() function to
ensure that the BMCR is written to match the settings held in the
phydev structure. This prevents the risk of manual settings being
accidentally altered.

Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger &lt;opendmb@gmail.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>net: bcmgenet: use RGMII loopback for MAC reset</title>
<updated>2019-12-04T21:33:50Z</updated>
<author>
<name>Doug Berger</name>
</author>
<published>2019-11-05T19:07:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f0a08ebb6668c5e9c7d538d5f86a4ba6c4114ed1'/>
<id>urn:sha1:f0a08ebb6668c5e9c7d538d5f86a4ba6c4114ed1</id>
<content type='text'>
[ Upstream commit 3a55402c93877d291b0a612d25edb03d1b4b93ac ]

As noted in commit 28c2d1a7a0bf ("net: bcmgenet: enable loopback
during UniMAC sw_reset") the UniMAC must be clocked while sw_reset
is asserted for its state machines to reset cleanly.

The transmit and receive clocks used by the UniMAC are derived from
the signals used on its PHY interface. The bcmgenet MAC can be
configured to work with different PHY interfaces including MII,
GMII, RGMII, and Reverse MII on internal and external interfaces.
Unfortunately for the UniMAC, when configured for MII the Tx clock
is always driven from the PHY which places it outside of the direct
control of the MAC.

The earlier commit enabled a local loopback mode within the UniMAC
so that the receive clock would be derived from the transmit clock
which addressed the observed issue with an external GPHY disabling
it's Rx clock. However, when a Tx clock is not available this
loopback is insufficient.

This commit implements a workaround that leverages the fact that
the MAC can reliably generate all of its necessary clocking by
enterring the external GPHY RGMII interface mode with the UniMAC in
local loopback during the sw_reset interval. Unfortunately, this
has the undesirable side efect of the RGMII GTXCLK signal being
driven during the same window.

In most configurations this is a benign side effect as the signal
is either not routed to a pin or is already expected to drive the
pin. The one exception is when an external MII PHY is expected to
drive the same pin with its TX_CLK output creating output driver
contention.

This commit exploits the IEEE 802.3 clause 22 standard defined
isolate mode to force an external MII PHY to present a high
impedance on its TX_CLK output during the window to prevent any
contention at the pin.

The MII interface is used internally with the 40nm internal EPHY
which agressively disables its clocks for power savings leading to
incomplete resets of the UniMAC and many instabilities observed
over the years. The workaround of this commit is expected to put
an end to those problems.

Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger &lt;opendmb@gmail.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>net: bcmgenet: reset 40nm EPHY on energy detect</title>
<updated>2019-11-10T10:34:55Z</updated>
<author>
<name>Doug Berger</name>
</author>
<published>2019-10-16T23:06:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cf65d6a7511cef6075f7cba344b23a6b6dc9c160'/>
<id>urn:sha1:cf65d6a7511cef6075f7cba344b23a6b6dc9c160</id>
<content type='text'>
[ Upstream commit 25382b991d252aed961cd434176240f9de6bb15f ]

The EPHY integrated into the 40nm Set-Top Box devices can falsely
detect energy when connected to a disabled peer interface. When the
peer interface is enabled the EPHY will detect and report the link
as active, but on occasion may get into a state where it is not
able to exchange data with the connected GENET MAC. This issue has
not been observed when the link parameters are auto-negotiated;
however, it has been observed with a manually configured link.

It has been empirically determined that issuing a soft reset to the
EPHY when energy is detected prevents it from getting into this bad
state.

Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger &lt;opendmb@gmail.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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: bcmgenet: don't set phydev-&gt;link from MAC</title>
<updated>2019-11-10T10:34:51Z</updated>
<author>
<name>Doug Berger</name>
</author>
<published>2019-10-16T23:06:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=834b3cdd0785bb008b458f53e367ffbee617f937'/>
<id>urn:sha1:834b3cdd0785bb008b458f53e367ffbee617f937</id>
<content type='text'>
[ Upstream commit 7de48402faa32298c3551ea32c76ccb4f9d3025d ]

When commit 28b2e0d2cd13 ("net: phy: remove parameter new_link from
phy_mac_interrupt()") removed the new_link parameter it set the
phydev-&gt;link state from the MAC before invoking phy_mac_interrupt().

However, once commit 88d6272acaaa ("net: phy: avoid unneeded MDIO
reads in genphy_read_status") was added this initialization prevents
the proper determination of the connection parameters by the function
genphy_read_status().

This commit removes that initialization to restore the proper
functionality.

Fixes: 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in genphy_read_status")
Signed-off-by: Doug Berger &lt;opendmb@gmail.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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: ethernet: broadcom: have drivers select DIMLIB as needed</title>
<updated>2019-10-29T08:22:01Z</updated>
<author>
<name>Randy Dunlap</name>
</author>
<published>2019-10-12T04:03:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=50efedbf77433a9dc9cbc9a1c5f941499874c11d'/>
<id>urn:sha1:50efedbf77433a9dc9cbc9a1c5f941499874c11d</id>
<content type='text'>
[ Upstream commit ddc790e92b3afa4e366ffb41818cfcd19015031e ]

NET_VENDOR_BROADCOM is intended to control a kconfig menu only.
It should not have anything to do with code generation.
As such, it should not select DIMLIB for all drivers under
NET_VENDOR_BROADCOM.  Instead each driver that needs DIMLIB should
select it (being the symbols SYSTEMPORT, BNXT, and BCMGENET).

Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1907021810220.13058@ramsan.of.borg/

Fixes: 4f75da3666c0 ("linux/dim: Move implementation to .c files")
Reported-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Uwe Kleine-König &lt;uwe@kleine-koenig.org&gt;
Cc: Tal Gilboa &lt;talgi@mellanox.com&gt;
Cc: Saeed Mahameed &lt;saeedm@mellanox.com&gt;
Cc: netdev@vger.kernel.org
Cc: linux-rdma@vger.kernel.org
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: Jakub Kicinski &lt;jakub.kicinski@netronome.com&gt;
Cc: Doug Ledford &lt;dledford@redhat.com&gt;
Cc: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Cc: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Cc: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Cc: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Reviewed-by: Leon Romanovsky &lt;leonro@mellanox.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: Set phydev-&gt;dev_flags only for internal PHYs</title>
<updated>2019-10-29T08:21:52Z</updated>
<author>
<name>Florian Fainelli</name>
</author>
<published>2019-10-11T19:53:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e230bab860f3afb961a20e84f4b89cd45161cd7d'/>
<id>urn:sha1:e230bab860f3afb961a20e84f4b89cd45161cd7d</id>
<content type='text'>
[ Upstream commit 92696286f3bb37ba50e4bd8d1beb24afb759a799 ]

phydev-&gt;dev_flags is entirely dependent on the PHY device driver which
is going to be used, setting the internal GENET PHY revision in those
bits only makes sense when drivers/net/phy/bcm7xxx.c is the PHY driver
being used.

Fixes: 487320c54143 ("net: bcmgenet: communicate integrated PHY revision to PHY driver")
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: bcmgenet: Fix RGMII_MODE_EN value for GENET v1/2/3</title>
<updated>2019-10-29T08:21:52Z</updated>
<author>
<name>Florian Fainelli</name>
</author>
<published>2019-10-15T17:45:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=16bc04ac20e0e4dc9faff2d9e5f2b47a1d347163'/>
<id>urn:sha1:16bc04ac20e0e4dc9faff2d9e5f2b47a1d347163</id>
<content type='text'>
[ Upstream commit efb86fede98cdc70b674692ff617b1162f642c49 ]

The RGMII_MODE_EN bit value was 0 for GENET versions 1 through 3, and
became 6 for GENET v4 and above, account for that difference.

Fixes: aa09677cba42 ("net: bcmgenet: add MDIO routines")
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: bcmgenet: use ethtool_op_get_ts_info()</title>
<updated>2019-09-01T06:51:19Z</updated>
<author>
<name>Ryan M. Collins</name>
</author>
<published>2019-08-30T18:49:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=dd1bf47a84fe64edf50f6a83fdc164d0da6fa021'/>
<id>urn:sha1:dd1bf47a84fe64edf50f6a83fdc164d0da6fa021</id>
<content type='text'>
This change enables the use of SW timestamping on the Raspberry Pi 4.

bcmgenet's transmit function bcmgenet_xmit() implements software
timestamping. However the SOF_TIMESTAMPING_TX_SOFTWARE capability was
missing and only SOF_TIMESTAMPING_RX_SOFTWARE was announced. By using
ethtool_ops bcmgenet_ethtool_ops() as get_ts_info(), the
SOF_TIMESTAMPING_TX_SOFTWARE capability is announced.

Similar to commit a8f5cb9e7991 ("smsc95xx: use ethtool_op_get_ts_info()")

Signed-off-by: Ryan M. Collins &lt;rmc032@bucknell.edu&gt;
Acked-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;
</content>
</entry>
<entry>
<title>bnxt_en: Fix to include flow direction in L2 key</title>
<updated>2019-08-18T20:05:01Z</updated>
<author>
<name>Somnath Kotur</name>
</author>
<published>2019-08-17T21:04:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9bf46566e80fd94845527d01ebd888eb49313551'/>
<id>urn:sha1:9bf46566e80fd94845527d01ebd888eb49313551</id>
<content type='text'>
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;
</content>
</entry>
<entry>
<title>bnxt_en: Use correct src_fid to determine direction of the flow</title>
<updated>2019-08-18T20:05:01Z</updated>
<author>
<name>Venkat Duvvuru</name>
</author>
<published>2019-08-17T21:04:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=685ec6a81bb0d47faf1dba49437d5bdaede2733d'/>
<id>urn:sha1:685ec6a81bb0d47faf1dba49437d5bdaede2733d</id>
<content type='text'>
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;
</content>
</entry>
</feed>
