<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/linux/stmmac.h, branch v6.1.168</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-03-25T10:03:19+00:00</updated>
<entry>
<title>net: stmmac: remove support for lpi_intr_o</title>
<updated>2026-03-25T10:03:19+00:00</updated>
<author>
<name>Russell King (Oracle)</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2026-03-06T15:07:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=800424523dac51630f7336706050790d4fbc024d'/>
<id>urn:sha1:800424523dac51630f7336706050790d4fbc024d</id>
<content type='text'>
commit 14eb64db8ff07b58a35b98375f446d9e20765674 upstream.

The dwmac databook for v3.74a states that lpi_intr_o is a sideband
signal which should be used to ungate the application clock, and this
signal is synchronous to the receive clock. The receive clock can run
at 2.5, 25 or 125MHz depending on the media speed, and can stop under
the control of the link partner. This means that the time it takes to
clear is dependent on the negotiated media speed, and thus can be 8,
40, or 400ns after reading the LPI control and status register.

It has been observed with some aggressive link partners, this clock
can stop while lpi_intr_o is still asserted, meaning that the signal
remains asserted for an indefinite period that the local system has
no direct control over.

The LPI interrupts will still be signalled through the main interrupt
path in any case, and this path is not dependent on the receive clock.

This, since we do not gate the application clock, and the chances of
adding clock gating in the future are slim due to the clocks being
ill-defined, lpi_intr_o serves no useful purpose. Remove the code which
requests the interrupt, and all associated code.

Reported-by: Ovidiu Panait &lt;ovidiu.panait.rb@renesas.com&gt;
Tested-by: Ovidiu Panait &lt;ovidiu.panait.rb@renesas.com&gt; # Renesas RZ/V2H board
Signed-off-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Link: https://patch.msgid.link/E1vnJbt-00000007YYN-28nm@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Ovidiu Panait &lt;ovidiu.panait.rb@renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: stmmac: dwmac4: Allow platforms to specify some DMA/MTL offsets</title>
<updated>2026-01-11T14:19:02+00:00</updated>
<author>
<name>Andrew Halaney</name>
<email>ahalaney@redhat.com</email>
</author>
<published>2023-04-11T20:04:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f4b91e169513d0b625820181b596c90ac2fdc0f4'/>
<id>urn:sha1:f4b91e169513d0b625820181b596c90ac2fdc0f4</id>
<content type='text'>
[ Upstream commit 33719b57f52e5b761234373f98f55f4e036d61c9 ]

Some platforms have dwmac4 implementations that have a different
address space layout than the default, resulting in the need to define
their own DMA/MTL offsets.

Extend the functions to allow a platform driver to indicate what its
addresses are, overriding the defaults.

Signed-off-by: Andrew Halaney &lt;ahalaney@redhat.com&gt;
Reviewed-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Tested-by: Brian Masney &lt;bmasney@redhat.com&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Stable-dep-of: a48e23221000 ("net: stmmac: fix the crash issue for zero copy XDP_TX action")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: stmmac: Power up SERDES after the PHY link</title>
<updated>2026-01-11T14:19:02+00:00</updated>
<author>
<name>Revanth Kumar Uppala</name>
<email>ruppala@nvidia.com</email>
</author>
<published>2022-12-01T15:58:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fcf5d921f5ad2768c9ec69fcbef619a19d4821a0'/>
<id>urn:sha1:fcf5d921f5ad2768c9ec69fcbef619a19d4821a0</id>
<content type='text'>
[ Upstream commit a46e9010124256f5bf5fc2c241a45cf1944b768e ]

The Tegra MGBE ethernet controller requires that the SERDES link is
powered-up after the PHY link is up, otherwise the link fails to
become ready following a resume from suspend. Add a variable to indicate
that the SERDES link must be powered-up after the PHY link.

Signed-off-by: Revanth Kumar Uppala &lt;ruppala@nvidia.com&gt;
Signed-off-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Stable-dep-of: a48e23221000 ("net: stmmac: fix the crash issue for zero copy XDP_TX action")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: stmmac: fix FPE events losing</title>
<updated>2023-12-13T17:39:08+00:00</updated>
<author>
<name>Jianheng Zhang</name>
<email>Jianheng.Zhang@synopsys.com</email>
</author>
<published>2023-12-01T03:22:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ed7e211b67863546afea3a2ed5164e41d00e8160'/>
<id>urn:sha1:ed7e211b67863546afea3a2ed5164e41d00e8160</id>
<content type='text'>
[ Upstream commit 37e4b8df27bc68340f3fc80dbb27e3549c7f881c ]

The status bits of register MAC_FPE_CTRL_STS are clear on read. Using
32-bit read for MAC_FPE_CTRL_STS in dwmac5_fpe_configure() and
dwmac5_fpe_send_mpacket() clear the status bits. Then the stmmac interrupt
handler missing FPE event status and leads to FPE handshaking failure and
retries.
To avoid clear status bits of MAC_FPE_CTRL_STS in dwmac5_fpe_configure()
and dwmac5_fpe_send_mpacket(), add fpe_csr to stmmac_fpe_cfg structure to
cache the control bits of MAC_FPE_CTRL_STS and to avoid reading
MAC_FPE_CTRL_STS in those methods.

Fixes: 5a5586112b92 ("net: stmmac: support FPE link partner hand-shaking procedure")
Reviewed-by: Serge Semin &lt;fancer.lancer@gmail.com&gt;
Signed-off-by: Jianheng Zhang &lt;Jianheng.Zhang@synopsys.com&gt;
Link: https://lore.kernel.org/r/CY5PR12MB637225A7CF529D5BE0FBE59CBF81A@CY5PR12MB6372.namprd12.prod.outlook.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: stmmac: Fix for mismatched host/device DMA address width</title>
<updated>2023-03-30T10:49:05+00:00</updated>
<author>
<name>Jochen Henneberg</name>
<email>jh@henneberg-systemdesign.com</email>
</author>
<published>2023-03-17T08:08:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0e60f30e65d350497d640f29028715724b2d9554'/>
<id>urn:sha1:0e60f30e65d350497d640f29028715724b2d9554</id>
<content type='text'>
[ Upstream commit 070246e4674b125860d311c18ce2623e73e2bd51 ]

Currently DMA address width is either read from a RO device register
or force set from the platform data. This breaks DMA when the host DMA
address width is &lt;=32it but the device is &gt;32bit.

Right now the driver may decide to use a 2nd DMA descriptor for
another buffer (happens in case of TSO xmit) assuming that 32bit
addressing is used due to platform configuration but the device will
still use both descriptor addresses as one address.

This can be observed with the Intel EHL platform driver that sets
32bit for addr64 but the MAC reports 40bit. The TX queue gets stuck in
case of TCP with iptables NAT configuration on TSO packets.

The logic should be like this: Whatever we do on the host side (memory
allocation GFP flags) should happen with the host DMA width, whenever
we decide how to set addresses on the device registers we must use the
device DMA address width.

This patch renames the platform address width field from addr64 (term
used in device datasheet) to host_addr and uses this value exclusively
for host side operations while all chip operations consider the device
DMA width as read from the device register.

Fixes: 7cfc4486e7ea ("stmmac: intel: Configure EHL PSE0 GbE and PSE1 GbE to 32 bits DMA addressing")
Signed-off-by: Jochen Henneberg &lt;jh@henneberg-systemdesign.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: stmmac: do not stop RX_CLK in Rx LPI state for qcs404 SoC</title>
<updated>2023-02-22T11:59:43+00:00</updated>
<author>
<name>Andrey Konovalov</name>
<email>andrey.konovalov@linaro.org</email>
</author>
<published>2023-01-26T21:35:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=07c53834ec278d49ff67fe623ded572578e6968e'/>
<id>urn:sha1:07c53834ec278d49ff67fe623ded572578e6968e</id>
<content type='text'>
[ Upstream commit 54aa39a513dbf2164ca462a19f04519b2407a224 ]

Currently in phy_init_eee() the driver unconditionally configures the PHY
to stop RX_CLK after entering Rx LPI state. This causes an LPI interrupt
storm on my qcs404-base board.

Change the PHY initialization so that for "qcom,qcs404-ethqos" compatible
device RX_CLK continues to run even in Rx LPI state.

Signed-off-by: Andrey Konovalov &lt;andrey.konovalov@linaro.org&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>stmmac: intel: remove unused 'has_crossts' flag</title>
<updated>2022-08-18T03:40:52+00:00</updated>
<author>
<name>Wong Vee Khee</name>
<email>veekhee@apple.com</email>
</author>
<published>2022-08-17T06:43:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e34cfee65ec891a319ce79797dda18083af33a76'/>
<id>urn:sha1:e34cfee65ec891a319ce79797dda18083af33a76</id>
<content type='text'>
The 'has_crossts' flag was not used anywhere in the stmmac driver,
removing it from both header file and dwmac-intel driver.

Signed-off-by: Wong Vee Khee &lt;veekhee@apple.com&gt;
Reviewed-by: Kurt Kanzenbach &lt;kurt@linutronix.de&gt;
Link: https://lore.kernel.org/r/20220817064324.10025-1-veekhee@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: stmmac: switch to use interrupt for hw crosstimestamping</title>
<updated>2022-07-18T10:14:35+00:00</updated>
<author>
<name>Wong Vee Khee</name>
<email>vee.khee.wong@linux.intel.com</email>
</author>
<published>2022-07-14T07:54:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=76c16d3e19446deea98b7883f261758b96b8781a'/>
<id>urn:sha1:76c16d3e19446deea98b7883f261758b96b8781a</id>
<content type='text'>
Using current implementation of polling mode, there is high chances we
will hit into timeout error when running phc2sys. Hence, update the
implementation of hardware crosstimestamping to use the MAC interrupt
service routine instead of polling for TSIS bit in the MAC Timestamp
Interrupt Status register to be set.

Cc: Richard Cochran &lt;richardcochran@gmail.com&gt;
Signed-off-by: Wong Vee Khee &lt;vee.khee.wong@linux.intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: stmmac: disable Split Header (SPH) for Intel platforms</title>
<updated>2022-05-01T12:20:03+00:00</updated>
<author>
<name>Tan Tee Min</name>
<email>tee.min.tan@linux.intel.com</email>
</author>
<published>2022-04-29T11:58:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=47f753c1108e287edb3e27fad8a7511a9d55578e'/>
<id>urn:sha1:47f753c1108e287edb3e27fad8a7511a9d55578e</id>
<content type='text'>
Based on DesignWare Ethernet QoS datasheet, we are seeing the limitation
of Split Header (SPH) feature is not supported for Ipv4 fragmented packet.
This SPH limitation will cause ping failure when the packets size exceed
the MTU size. For example, the issue happens once the basic ping packet
size is larger than the configured MTU size and the data is lost inside
the fragmented packet, replaced by zeros/corrupted values, and leads to
ping fail.

So, disable the Split Header for Intel platforms.

v2: Add fixes tag in commit message.

Fixes: 67afd6d1cfdf("net: stmmac: Add Split Header support and enable it in XGMAC cores")
Cc: &lt;stable@vger.kernel.org&gt; # 5.10.x
Suggested-by: Ong, Boon Leong &lt;boon.leong.ong@intel.com&gt;
Signed-off-by: Mohammad Athari Bin Ismail &lt;mohammad.athari.ismail@intel.com&gt;
Signed-off-by: Wong Vee Khee &lt;vee.khee.wong@linux.intel.com&gt;
Signed-off-by: Tan Tee Min &lt;tee.min.tan@linux.intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: stmmac: Add platform level debug register dump feature</title>
<updated>2021-11-30T11:57:58+00:00</updated>
<author>
<name>Bhupesh Sharma</name>
<email>bhupesh.sharma@linaro.org</email>
</author>
<published>2021-11-28T19:58:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4047b9db1aa7512a10ba3560a3f63821c8c40235'/>
<id>urn:sha1:4047b9db1aa7512a10ba3560a3f63821c8c40235</id>
<content type='text'>
dwmac-qcom-ethqos currently exposes a mechanism to dump rgmii registers
after the 'stmmac_dvr_probe()' returns. However with commit
5ec55823438e ("net: stmmac: add clocks management for gmac driver"),
we now let 'pm_runtime_put()' disable the clocks before returning from
'stmmac_dvr_probe()'.

This causes a crash when 'rgmii_dump()' register dumps are enabled,
as the clocks are already off.

Since other dwmac drivers (possible future users as well) might
require a similar register dump feature, introduce a platform level
callback to allow the same.

This fixes the crash noticed while enabling rgmii_dump() dumps in
dwmac-qcom-ethqos driver as well. It also allows future changes
to keep a invoking the register dump callback from the correct
place inside 'stmmac_dvr_probe()'.

Fixes: 5ec55823438e ("net: stmmac: add clocks management for gmac driver")
Cc: Joakim Zhang &lt;qiangqing.zhang@nxp.com&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Bhupesh Sharma &lt;bhupesh.sharma@linaro.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
