<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/ethernet/stmicro, branch v5.19</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.19</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.19'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-07-28T17:43:04+00:00</updated>
<entry>
<title>stmmac: dwmac-mediatek: fix resource leak in probe</title>
<updated>2022-07-28T17:43:04+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2022-07-28T11:52:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4d3d3a1b244fd54629a6b7047f39a7bbc8d11910'/>
<id>urn:sha1:4d3d3a1b244fd54629a6b7047f39a7bbc8d11910</id>
<content type='text'>
If mediatek_dwmac_clks_config() fails, then call stmmac_remove_config_dt()
before returning.  Otherwise it is a resource leak.

Fixes: fa4b3ca60e80 ("stmmac: dwmac-mediatek: fix clock issue")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Link: https://lore.kernel.org/r/YuJ4aZyMUlG6yGGa@kili
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: stmmac: remove redunctant disable xPCS EEE call</title>
<updated>2022-07-19T03:15:45+00:00</updated>
<author>
<name>Wong Vee Khee</name>
<email>vee.khee.wong@linux.intel.com</email>
</author>
<published>2022-07-15T12:24:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=da791bac104a3169b05b54270afe75daacba4641'/>
<id>urn:sha1:da791bac104a3169b05b54270afe75daacba4641</id>
<content type='text'>
Disable is done in stmmac_init_eee() on the event of MAC link down.
Since setting enable/disable EEE via ethtool will eventually trigger
a MAC down, removing this redunctant call in stmmac_ethtool.c to avoid
calling xpcs_config_eee() twice.

Fixes: d4aeaed80b0e ("net: stmmac: trigger PCS EEE to turn off on link down")
Signed-off-by: Wong Vee Khee &lt;vee.khee.wong@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20220715122402.1017470-1-vee.khee.wong@linux.intel.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: stmmac: fix dma queue left shift overflow issue</title>
<updated>2022-07-18T10:30:26+00:00</updated>
<author>
<name>Junxiao Chang</name>
<email>junxiao.chang@intel.com</email>
</author>
<published>2022-07-15T07:47:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=613b065ca32e90209024ec4a6bb5ca887ee70980'/>
<id>urn:sha1:613b065ca32e90209024ec4a6bb5ca887ee70980</id>
<content type='text'>
When queue number is &gt; 4, left shift overflows due to 32 bits
integer variable. Mask calculation is wrong for MTL_RXQ_DMA_MAP1.

If CONFIG_UBSAN is enabled, kernel dumps below warning:
[   10.363842] ==================================================================
[   10.363882] UBSAN: shift-out-of-bounds in /build/linux-intel-iotg-5.15-8e6Tf4/
linux-intel-iotg-5.15-5.15.0/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c:224:12
[   10.363929] shift exponent 40 is too large for 32-bit type 'unsigned int'
[   10.363953] CPU: 1 PID: 599 Comm: NetworkManager Not tainted 5.15.0-1003-intel-iotg
[   10.363956] Hardware name: ADLINK Technology Inc. LEC-EL/LEC-EL, BIOS 0.15.11 12/22/2021
[   10.363958] Call Trace:
[   10.363960]  &lt;TASK&gt;
[   10.363963]  dump_stack_lvl+0x4a/0x5f
[   10.363971]  dump_stack+0x10/0x12
[   10.363974]  ubsan_epilogue+0x9/0x45
[   10.363976]  __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e
[   10.363979]  ? wake_up_klogd+0x4a/0x50
[   10.363983]  ? vprintk_emit+0x8f/0x240
[   10.363986]  dwmac4_map_mtl_dma.cold+0x42/0x91 [stmmac]
[   10.364001]  stmmac_mtl_configuration+0x1ce/0x7a0 [stmmac]
[   10.364009]  ? dwmac410_dma_init_channel+0x70/0x70 [stmmac]
[   10.364020]  stmmac_hw_setup.cold+0xf/0xb14 [stmmac]
[   10.364030]  ? page_pool_alloc_pages+0x4d/0x70
[   10.364034]  ? stmmac_clear_tx_descriptors+0x6e/0xe0 [stmmac]
[   10.364042]  stmmac_open+0x39e/0x920 [stmmac]
[   10.364050]  __dev_open+0xf0/0x1a0
[   10.364054]  __dev_change_flags+0x188/0x1f0
[   10.364057]  dev_change_flags+0x26/0x60
[   10.364059]  do_setlink+0x908/0xc40
[   10.364062]  ? do_setlink+0xb10/0xc40
[   10.364064]  ? __nla_validate_parse+0x4c/0x1a0
[   10.364068]  __rtnl_newlink+0x597/0xa10
[   10.364072]  ? __nla_reserve+0x41/0x50
[   10.364074]  ? __kmalloc_node_track_caller+0x1d0/0x4d0
[   10.364079]  ? pskb_expand_head+0x75/0x310
[   10.364082]  ? nla_reserve_64bit+0x21/0x40
[   10.364086]  ? skb_free_head+0x65/0x80
[   10.364089]  ? security_sock_rcv_skb+0x2c/0x50
[   10.364094]  ? __cond_resched+0x19/0x30
[   10.364097]  ? kmem_cache_alloc_trace+0x15a/0x420
[   10.364100]  rtnl_newlink+0x49/0x70

This change fixes MTL_RXQ_DMA_MAP1 mask issue and channel/queue
mapping warning.

Fixes: d43042f4da3e ("net: stmmac: mapping mtl rx to dma channel")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216195
Reported-by: Cedric Wassenaar &lt;cedric@bytespeed.nl&gt;
Signed-off-by: Junxiao Chang &lt;junxiao.chang@intel.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&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: fix unbalanced ptp clock issue in suspend/resume flow</title>
<updated>2022-07-15T11:06:56+00:00</updated>
<author>
<name>Biao Huang</name>
<email>biao.huang@mediatek.com</email>
</author>
<published>2022-07-14T06:00:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f4c7d8948e866918d61493264dbbd67e45ef2bda'/>
<id>urn:sha1:f4c7d8948e866918d61493264dbbd67e45ef2bda</id>
<content type='text'>
Current stmmac driver will prepare/enable ptp_ref clock in
stmmac_init_tstamp_counter().

The stmmac_pltfr_noirq_suspend will disable it once in suspend flow.

But in resume flow,
	stmmac_pltfr_noirq_resume --&gt; stmmac_init_tstamp_counter
	stmmac_resume --&gt; stmmac_hw_setup --&gt; stmmac_init_ptp --&gt; stmmac_init_tstamp_counter
ptp_ref clock reference counter increases twice, which leads to unbalance
ptp clock when resume back.

Move ptp_ref clock prepare/enable out of stmmac_init_tstamp_counter to fix it.

Fixes: 0735e639f129d ("net: stmmac: skip only stmmac_ptp_register when resume from suspend")
Signed-off-by: Biao Huang &lt;biao.huang@mediatek.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: stmmac: fix pm runtime issue in stmmac_dvr_remove()</title>
<updated>2022-07-15T11:06:56+00:00</updated>
<author>
<name>Biao Huang</name>
<email>biao.huang@mediatek.com</email>
</author>
<published>2022-07-14T06:00:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0d9a15913b871e03fdd3b3d90a2e665fb22f9bcf'/>
<id>urn:sha1:0d9a15913b871e03fdd3b3d90a2e665fb22f9bcf</id>
<content type='text'>
If netif is running when stmmac_dvr_remove is invoked,
the unregister_netdev will call ndo_stop(stmmac_release) and
vlan_kill_rx_filter(stmmac_vlan_rx_kill_vid).

Currently, stmmac_dvr_remove() will disable pm runtime before
unregister_netdev. When stmmac_vlan_rx_kill_vid is invoked,
pm_runtime_resume_and_get in it returns EACCESS error number,
and reports:

	dwmac-mediatek 11021000.ethernet eth0: stmmac_dvr_remove: removing driver
	dwmac-mediatek 11021000.ethernet eth0: FPE workqueue stop
	dwmac-mediatek 11021000.ethernet eth0: failed to kill vid 0081/0

Move the pm_runtime_disable to the end of stmmac_dvr_remove
to fix this issue.

Fixes: 6449520391dfc ("net: stmmac: properly handle with runtime pm in stmmac_dvr_remove()")
Signed-off-by: Biao Huang &lt;biao.huang@mediatek.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>stmmac: dwmac-mediatek: fix clock issue</title>
<updated>2022-07-15T11:06:55+00:00</updated>
<author>
<name>Biao Huang</name>
<email>biao.huang@mediatek.com</email>
</author>
<published>2022-07-14T06:00:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fa4b3ca60e8011d3046765b3de8d3f1ffc53af28'/>
<id>urn:sha1:fa4b3ca60e8011d3046765b3de8d3f1ffc53af28</id>
<content type='text'>
The pm_runtime takes care of the clock handling in current
stmmac drivers, and dwmac-mediatek implement the
mediatek_dwmac_clks_config() as the callback for pm_runtime.

Then, stripping duplicated clocks handling in old init()/exit()
to fix clock issue in suspend/resume test.

As to clocks in probe/remove, vendor need symmetric handling to
ensure clocks balance.

Test pass, including suspend/resume and ko insertion/remove.

Fixes: 3186bdad97d5 ("stmmac: dwmac-mediatek: add platform level clocks management")
Signed-off-by: Biao Huang &lt;biao.huang@mediatek.com&gt;
Reviewed-by: Matthias Brugger &lt;matthias.bgg@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: stmmac: fix leaks in probe</title>
<updated>2022-07-13T13:21:42+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2022-07-12T14:42:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=23aa6d5088e3bd65de77c5c307237b9937f8b48a'/>
<id>urn:sha1:23aa6d5088e3bd65de77c5c307237b9937f8b48a</id>
<content type='text'>
These two error paths should clean up before returning.

Fixes: 2bb4b98b60d7 ("net: stmmac: Add Ingenic SoCs MAC support.")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: stmmac: dwc-qos: Disable split header for Tegra194</title>
<updated>2022-07-08T00:05:01+00:00</updated>
<author>
<name>Jon Hunter</name>
<email>jonathanh@nvidia.com</email>
</author>
<published>2022-07-06T08:39:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=029c1c2059e9c4b38f97a06204cdecd10cfbeb8a'/>
<id>urn:sha1:029c1c2059e9c4b38f97a06204cdecd10cfbeb8a</id>
<content type='text'>
There is a long-standing issue with the Synopsys DWC Ethernet driver
for Tegra194 where random system crashes have been observed [0]. The
problem occurs when the split header feature is enabled in the stmmac
driver. In the bad case, a larger than expected buffer length is
received and causes the calculation of the total buffer length to
overflow. This results in a very large buffer length that causes the
kernel to crash. Why this larger buffer length is received is not clear,
however, the feedback from the NVIDIA design team is that the split
header feature is not supported for Tegra194. Therefore, disable split
header support for Tegra194 to prevent these random crashes from
occurring.

[0] https://lore.kernel.org/linux-tegra/b0b17697-f23e-8fa5-3757-604a86f3a095@nvidia.com/

Fixes: 67afd6d1cfdf ("net: stmmac: Add Split Header support and enable it in XGMAC cores")
Signed-off-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://lore.kernel.org/r/20220706083913.13750-1-jonathanh@nvidia.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>stmmac: intel: Fix an error handling path in intel_eth_pci_probe()</title>
<updated>2022-06-07T09:56:29+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2022-06-05T20:50:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5e74a4b3ec1816e3bbfd715d46ae29d2508079cb'/>
<id>urn:sha1:5e74a4b3ec1816e3bbfd715d46ae29d2508079cb</id>
<content type='text'>
When the managed API is used, there is no need to explicitly call
pci_free_irq_vectors().

This looks to be a left-over from the commit in the Fixes tag. Only the
.remove() function had been updated.

So remove this unused function call and update goto label accordingly.

Fixes: 8accc467758e ("stmmac: intel: use managed PCI function on probe and resume")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Reviewed-by: Wong Vee Khee &lt;vee.khee.wong@linux.intel.com&gt;
Link: https://lore.kernel.org/r/1ac9b6787b0db83b0095711882c55c77c8ea8da0.1654462241.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
</feed>
