#
9cb54af2 |
|
12-Apr-2024 |
Serge Semin <fancer.lancer@gmail.com> |
net: stmmac: Fix IP-cores specific MAC capabilities Here is the list of the MAC capabilities specific to the particular DW MAC IP-cores currently supported by the driver: DW MAC100: MAC_ASYM_PAUSE | MAC_SYM_PAUSE | MAC_10 | MAC_100 DW GMAC: MAC_ASYM_PAUSE | MAC_SYM_PAUSE | MAC_10 | MAC_100 | MAC_1000 Allwinner sun8i MAC: MAC_ASYM_PAUSE | MAC_SYM_PAUSE | MAC_10 | MAC_100 | MAC_1000 DW QoS Eth: MAC_ASYM_PAUSE | MAC_SYM_PAUSE | MAC_10 | MAC_100 | MAC_1000 | MAC_2500FD if there is more than 1 active Tx/Rx queues: MAC_ASYM_PAUSE | MAC_SYM_PAUSE | MAC_10FD | MAC_100FD | MAC_1000FD | MAC_2500FD DW XGMAC: MAC_ASYM_PAUSE | MAC_SYM_PAUSE | MAC_1000FD | MAC_2500FD | MAC_5000FD | MAC_10000FD DW XLGMAC: MAC_ASYM_PAUSE | MAC_SYM_PAUSE | MAC_1000FD | MAC_2500FD | MAC_5000FD | MAC_10000FD | MAC_25000FD | MAC_40000FD | MAC_50000FD | MAC_100000FD As you can see there are only two common capabilities: MAC_ASYM_PAUSE | MAC_SYM_PAUSE. Meanwhile what is currently implemented defines 10/100/1000 link speeds for all IP-cores, which is definitely incorrect for DW MAC100, DW XGMAC and DW XLGMAC devices. Seeing the flow-control is implemented as a callback for each MAC IP-core (see dwmac100_flow_ctrl(), dwmac1000_flow_ctrl(), sun8i_dwmac_flow_ctrl(), etc) and since the MAC-specific setup() method is supposed to be called for each available DW MAC-based device, the capabilities initialization can be freely moved to these setup() functions, thus correctly setting up the MAC-capabilities for each IP-core (including the Allwinner Sun8i). A new stmmac_link::caps field was specifically introduced for that so to have all link-specific info preserved in a single structure. Note the suggested change fixes three earlier commits at a time. The commit 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports") permitted the 10-100 link speeds and 1G half-duplex mode for DW XGMAC IP-core even though it doesn't support them. The commit df7699c70c1b ("net: stmmac: Do not cut down 1G modes") incorrectly added the MAC1000 capability to the DW MAC100 IP-core. Similarly to the DW XGMAC the commit 8a880936e902 ("net: stmmac: Add XLGMII support") incorrectly permitted the 10-100 link speeds and 1G half-duplex mode for DW XLGMAC IP-core. Fixes: 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports") Fixes: df7699c70c1b ("net: stmmac: Do not cut down 1G modes") Fixes: 8a880936e902 ("net: stmmac: Add XLGMII support") Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk> Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Reviewed-by: Romain Gantois <romain.gantois@bootlin.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
#
38cc3c6d |
|
03-Feb-2024 |
Petr Tesarik <petr@tesarici.cz> |
net: stmmac: protect updates of 64-bit statistics counters As explained by a comment in <linux/u64_stats_sync.h>, write side of struct u64_stats_sync must ensure mutual exclusion, or one seqcount update could be lost on 32-bit platforms, thus blocking readers forever. Such lockups have been observed in real world after stmmac_xmit() on one CPU raced with stmmac_napi_poll_tx() on another CPU. To fix the issue without introducing a new lock, split the statics into three parts: 1. fields updated only under the tx queue lock, 2. fields updated only during NAPI poll, 3. fields updated only from interrupt context, Updates to fields in the first two groups are already serialized through other locks. It is sufficient to split the existing struct u64_stats_sync so that each group has its own. Note that tx_set_ic_bit is updated from both contexts. Split this counter so that each context gets its own, and calculate their sum to get the total value in stmmac_get_ethtool_stats(). For the third group, multiple interrupts may be processed by different CPUs at the same time, but interrupts on the same CPU will not nest. Move fields from this group to a newly created per-cpu struct stmmac_pcpu_stats. Fixes: 133466c3bbe1 ("net: stmmac: use per-queue 64 bit statistics where necessary") Link: https://lore.kernel.org/netdev/Za173PhviYg-1qIn@torres.zugschlus.de/t/ Cc: stable@vger.kernel.org Signed-off-by: Petr Tesarik <petr@tesarici.cz> Reviewed-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
2c9fc838 |
|
16-Sep-2023 |
Jisheng Zhang <jszhang@kernel.org> |
net: stmmac: rename stmmac_pltfr_remove_no_dt to stmmac_pltfr_remove Now, all users of the old stmmac_pltfr_remove() are converted to the devres helper, it's time to rename stmmac_pltfr_remove_no_dt() back to stmmac_pltfr_remove() and remove the old stmmac_pltfr_remove(). Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9bdf6909 |
|
16-Sep-2023 |
Jisheng Zhang <jszhang@kernel.org> |
net: stmmac: dwmac-sun8i: use devm_stmmac_probe_config_dt() Simplify the driver's probe() function by using the devres variant of stmmac_probe_config_dt(). The calling of stmmac_pltfr_remove() now needs to be switched to stmmac_pltfr_remove_no_dt(). Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
8070274b |
|
17-Sep-2023 |
Jisheng Zhang <jszhang@kernel.org> |
net: stmmac: fix incorrect rxq|txq_stats reference commit 133466c3bbe1 ("net: stmmac: use per-queue 64 bit statistics where necessary") caused one regression as found by Uwe, the backtrace looks like: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc1-00449-g133466c3bbe1-dirty #21 Hardware name: STM32 (Device Tree Support) unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x60/0x90 dump_stack_lvl from register_lock_class+0x98c/0x99c register_lock_class from __lock_acquire+0x74/0x293c __lock_acquire from lock_acquire+0x134/0x398 lock_acquire from stmmac_get_stats64+0x2ac/0x2fc stmmac_get_stats64 from dev_get_stats+0x44/0x130 dev_get_stats from rtnl_fill_stats+0x38/0x120 rtnl_fill_stats from rtnl_fill_ifinfo+0x834/0x17f4 rtnl_fill_ifinfo from rtmsg_ifinfo_build_skb+0xc0/0x144 rtmsg_ifinfo_build_skb from rtmsg_ifinfo+0x50/0x88 rtmsg_ifinfo from __dev_notify_flags+0xc0/0xec __dev_notify_flags from dev_change_flags+0x50/0x5c dev_change_flags from ip_auto_config+0x2f4/0x1260 ip_auto_config from do_one_initcall+0x70/0x35c do_one_initcall from kernel_init_freeable+0x2ac/0x308 kernel_init_freeable from kernel_init+0x1c/0x138 kernel_init from ret_from_fork+0x14/0x2c The reason is the rxq|txq_stats structures are not what expected because stmmac_open() -> __stmmac_open() the structure is overwritten by "memcpy(&priv->dma_conf, dma_conf, sizeof(*dma_conf));" This causes the well initialized syncp member of rxq|txq_stats is overwritten unexpectedly as pointed out by Johannes and Uwe. Fix this issue by moving rxq|txq_stats back to stmmac_extra_stats. For SMP cache friendly, we also mark stmmac_txq_stats and stmmac_rxq_stats as ____cacheline_aligned_in_smp. Fixes: 133466c3bbe1 ("net: stmmac: use per-queue 64 bit statistics where necessary") Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230917165328.3403-1-jszhang@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
#
a014c355 |
|
26-Aug-2023 |
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> |
net: stmmac: clarify difference between "interface" and "phy_interface" Clarify the difference between "interface" and "phy_interface" in struct plat_stmmacenet_data, both by adding a comment, and also renaming "interface" to be "mac_interface". The difference between these are: MAC ----- optional PCS ----- SerDes ----- optional PHY ----- Media ^ ^ mac_interface phy_interface Note that phylink currently only deals with phy_interface. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qZq83-005tts-6K@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
3d40aed8 |
|
26-Jul-2023 |
Rob Herring <robh@kernel.org> |
net: Explicitly include correct DT includes The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Acked-by: Alex Elder <elder@linaro.org> Reviewed-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Reviewed-by: Wei Fang <wei.fang@nxp.com> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230727014944.3972546-1-robh@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
133466c3 |
|
17-Jul-2023 |
Jisheng Zhang <jszhang@kernel.org> |
net: stmmac: use per-queue 64 bit statistics where necessary Currently, there are two major issues with stmmac driver statistics First of all, statistics in stmmac_extra_stats, stmmac_rxq_stats and stmmac_txq_stats are 32 bit variables on 32 bit platforms. This can cause some stats to overflow after several minutes of high traffic, for example rx_pkt_n, tx_pkt_n and so on. Secondly, if HW supports multiqueues, there are frequent cacheline ping pongs on some driver statistic vars, for example, normal_irq_n, tx_pkt_n and so on. What's more, frequent cacheline ping pongs on normal_irq_n happens in ISR, this makes the situation worse. To improve the driver, we convert those statistics to 64 bit, implement ndo_get_stats64 and update .get_ethtool_stats implementation accordingly. We also use per-queue statistics where necessary to remove the cacheline ping pongs as much as possible to make multiqueue operations faster. Those statistics which are not possible to overflow and not frequently updated are kept as is. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://lore.kernel.org/r/20230717160630.1892-3-jszhang@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
d8daff28 |
|
10-Jul-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
net: stmmac: replace the has_sun8i field with a flag Drop the boolean field of the plat_stmmacenet_data structure in favor of a simple bitfield flag. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Link: https://lore.kernel.org/r/20230710090001.303225-5-brgl@bgdev.pl Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
cc708d4e |
|
08-May-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
net: stmmac: dwmac-sun8i: Convert to platform remove callback returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
1d84b487 |
|
11-Apr-2023 |
Andrew Halaney <ahalaney@redhat.com> |
net: stmmac: Pass stmmac_priv in some callbacks Passing stmmac_priv to some of the callbacks allows hwif implementations to grab some data that platforms can customize. Adjust the callbacks accordingly in preparation of such a platform customization. Signed-off-by: Andrew Halaney <ahalaney@redhat.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
#
1a15267b |
|
28-Apr-2022 |
Yang Yingliang <yangyingliang@huawei.com> |
net: stmmac: dwmac-sun8i: add missing of_node_put() in sun8i_dwmac_register_mdio_mux() The node pointer returned by of_get_child_by_name() with refcount incremented, so add of_node_put() after using it. Fixes: 634db83b8265 ("net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220428095716.540452-1-yangyingliang@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
b76bbb34 |
|
28-Jan-2022 |
Jisheng Zhang <jszhang@kernel.org> |
net: stmmac: dwmac-sun8i: make clk really gated during rpm suspended Currently, the dwmac-sun8i's stmmaceth clk isn't disabled even if the the device has been runtime suspended. The reason is the driver gets the "stmmaceth" clk as tx_clk and enabling it during probe. But there's no other usage of tx_clk except preparing and enabling, so we can remove tx_clk and its usage then rely on the common routine stmmac_probe_config_dt() to prepare and enable the stmmaceth clk during driver initialization, and benefit from the runtime pm feature after probed. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9e0db41e |
|
26-Jan-2022 |
Jisheng Zhang <jszhang@kernel.org> |
net: stmmac: dwmac-sun8i: use return val of readl_poll_timeout() When readl_poll_timeout() timeout, we'd better directly use its return value. Before this patch: [ 2.145528] dwmac-sun8i: probe of 4500000.ethernet failed with error -14 After this patch: [ 2.138520] dwmac-sun8i: probe of 4500000.ethernet failed with error -110 Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
76660757 |
|
14-Oct-2021 |
Jakub Kicinski <kuba@kernel.org> |
ethernet: constify references to netdev->dev_addr in drivers This big patch sprinkles const on local variables and function arguments which may refer to netdev->dev_addr. Commit 406f42fa0d3c ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it got through appropriate helpers. Some of the changes here are not strictly required - const is sometimes cast off but pointer is not used for writing. It seems like it's still better to add the const in case the code changes later or relevant -W flags get enabled for the build. No functional changes. Link: https://lore.kernel.org/r/20211014142432.449314-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
83216e39 |
|
12-Apr-2021 |
Michael Walle <michael@walle.cc> |
of: net: pass the dst buffer to of_get_mac_address() of_get_mac_address() returns a "const void*" pointer to a MAC address. Lately, support to fetch the MAC address by an NVMEM provider was added. But this will only work with platform devices. It will not work with PCI devices (e.g. of an integrated root complex) and esp. not with DSA ports. There is an of_* variant of the nvmem binding which works without devices. The returned data of a nvmem_cell_read() has to be freed after use. On the other hand the return of_get_mac_address() points to some static data without a lifetime. The trick for now, was to allocate a device resource managed buffer which is then returned. This will only work if we have an actual device. Change it, so that the caller of of_get_mac_address() has to supply a buffer where the MAC address is written to. Unfortunately, this will touch all drivers which use the of_get_mac_address(). Usually the code looks like: const char *addr; addr = of_get_mac_address(np); if (!IS_ERR(addr)) ether_addr_copy(ndev->dev_addr, addr); This can then be simply rewritten as: of_get_mac_address(np, ndev->dev_addr); Sometimes is_valid_ether_addr() is used to test the MAC address. of_get_mac_address() already makes sure, it just returns a valid MAC address. Thus we can just test its return code. But we have to be careful if there are still other sources for the MAC address before the of_get_mac_address(). In this case we have to keep the is_valid_ether_addr() call. The following coccinelle patch was used to convert common cases to the new style. Afterwards, I've manually gone over the drivers and fixed the return code variable: either used a new one or if one was already available use that. Mansour Moufid, thanks for that coccinelle patch! <spml> @a@ identifier x; expression y, z; @@ - x = of_get_mac_address(y); + x = of_get_mac_address(y, z); <... - ether_addr_copy(z, x); ...> @@ identifier a.x; @@ - if (<+... x ...+>) {} @@ identifier a.x; @@ if (<+... x ...+>) { ... } - else {} @@ identifier a.x; expression e; @@ - if (<+... x ...+>@e) - {} - else + if (!(e)) {...} @@ expression x, y, z; @@ - x = of_get_mac_address(y, z); + of_get_mac_address(y, z); ... when != x </spml> All drivers, except drivers/net/ethernet/aeroflex/greth.c, were compile-time tested. Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
7e1c520c |
|
25-Mar-2021 |
Ong Boon Leong <boon.leong.ong@intel.com> |
net: stmmac: introduce DMA interrupt status masking per traffic direction In preparation to make stmmac support multi-vector MSI, we introduce the interrupt status masking according to RX, TX or RXTX. Default to use RXTX inside stmmac_dma_interrupt(), so there is no run-time logic difference now. Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by: Voon Weifeng <weifeng.voon@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
014dfa26 |
|
19-Mar-2021 |
Corentin Labbe <clabbe@baylibre.com> |
net: stmmac: dwmac-sun8i: Provide TX and RX fifo sizes MTU cannot be changed on dwmac-sun8i. (ip link set eth0 mtu xxx returning EINVAL) This is due to tx_fifo_size being 0, since this value is used to compute valid MTU range. Like dwmac-sunxi (with commit 806fd188ce2a ("net: stmmac: dwmac-sunxi: Provide TX and RX fifo sizes")) dwmac-sun8i need to have tx and rx fifo sizes set. I have used values from datasheets. After this patch, setting a non-default MTU (like 1000) value works and network is still useable. Tested-on: sun8i-h3-orangepi-pc Tested-on: sun8i-r40-bananapi-m2-ultra Tested-on: sun50i-a64-bananapi-m64 Tested-on: sun50i-h5-nanopi-neo-plus2 Tested-on: sun50i-h6-pine-h64 Fixes: 9f93ac8d408 ("net-next: stmmac: Add dwmac-sun8i") Reported-by: Belisko Marek <marek.belisko@gmail.com> Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
96be41d7 |
|
16-Feb-2021 |
Samuel Holland <samuel@sholland.org> |
net: stmmac: dwmac-sun8i: Add a shutdown callback The Ethernet MAC and PHY are usually major consumers of power on boards which may not be able to fully power off (those with no PMIC). Powering down the MAC and internal PHY saves power while these boards are "off". Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
2743aa24 |
|
16-Feb-2021 |
Samuel Holland <samuel@sholland.org> |
net: stmmac: dwmac-sun8i: Minor probe function cleanup Adjust the spacing and use an explicit "return 0" in the success path to make the function easier to parse. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1c22f546 |
|
16-Feb-2021 |
Samuel Holland <samuel@sholland.org> |
net: stmmac: dwmac-sun8i: Use reset_control_reset Use the appropriate function instead of reimplementing it, and update the error message to match the code. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
afac1d34 |
|
16-Feb-2021 |
Samuel Holland <samuel@sholland.org> |
net: stmmac: dwmac-sun8i: Remove unnecessary PHY power check sun8i_dwmac_unpower_internal_phy already checks if the PHY is powered, so there is no need to do it again here. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
557ef2df |
|
16-Feb-2021 |
Samuel Holland <samuel@sholland.org> |
net: stmmac: dwmac-sun8i: Return void from PHY unpower This is a deinitialization function that always returned zero, and that return value was always ignored. Have it return void instead. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9b1e39cf |
|
03-Jan-2021 |
Samuel Holland <samuel@sholland.org> |
net: stmmac: dwmac-sun8i: Balance syscon (de)initialization Previously, sun8i_dwmac_set_syscon was called from a chain of functions in several different files: sun8i_dwmac_probe stmmac_dvr_probe stmmac_hw_init stmmac_hwif_init sun8i_dwmac_setup sun8i_dwmac_set_syscon which made the lifetime of the syscon values hard to reason about. Part of the problem is that there is no similar platform driver callback from stmmac_dvr_remove. As a result, the driver unset the syscon value in sun8i_dwmac_exit, but this leaves it uninitialized after a suspend/ resume cycle. It was also unset a second time (outside sun8i_dwmac_exit) in the probe error path. Move the init to the earliest available place in sun8i_dwmac_probe (after stmmac_probe_config_dt, which initializes plat_dat), and the deinit to the corresponding position in the cleanup order. Since priv is not filled in until stmmac_dvr_probe, this requires changing the sun8i_dwmac_set_syscon parameters to priv's two relevant members. Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i") Fixes: 634db83b8265 ("net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs") Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b8239638 |
|
03-Jan-2021 |
Samuel Holland <samuel@sholland.org> |
net: stmmac: dwmac-sun8i: Balance internal PHY power sun8i_dwmac_exit calls sun8i_dwmac_unpower_internal_phy, but sun8i_dwmac_init did not call sun8i_dwmac_power_internal_phy. This caused PHY power to remain off after a suspend/resume cycle. Fix this by recording if PHY power should be restored, and if so, restoring it. Fixes: 634db83b8265 ("net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs") Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
52925421 |
|
03-Jan-2021 |
Samuel Holland <samuel@sholland.org> |
net: stmmac: dwmac-sun8i: Balance internal PHY resource references While stmmac_pltfr_remove calls sun8i_dwmac_exit, the sun8i_dwmac_init and sun8i_dwmac_exit functions are also called by the stmmac_platform suspend/resume callbacks. They may be called many times during the device's lifetime and should not release resources used by the driver. Furthermore, there was no error handling in case registering the MDIO mux failed during probe, and the EPHY clock was never released at all. Fix all of these issues by moving the deinitialization code to a driver removal callback. Also ensure the EPHY is powered down before removal. Fixes: 634db83b8265 ("net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs") Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
7eeecc4b |
|
03-Jan-2021 |
Samuel Holland <samuel@sholland.org> |
net: stmmac: dwmac-sun8i: Fix probe error handling stmmac_pltfr_remove does three things in one function, making it inapproprate for unwinding the steps in the probe function. Currently, a failure before the call to stmmac_dvr_probe would leak OF node references due to missing a call to stmmac_remove_config_dt. And an error in stmmac_dvr_probe would cause the driver to attempt to remove a netdevice that was never added. Fix these by reordering the init and splitting out the error handling steps. Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i") Fixes: 40a1dcee2d18 ("net: ethernet: dwmac-sun8i: Use the correct function in exit path") Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
f1239d8a |
|
05-Jan-2020 |
Chen-Yu Tsai <wens@csie.org> |
net: stmmac: dwmac-sun8i: Allow all RGMII modes Allow all the RGMII modes to be used. This would allow us to represent the hardware better in the device tree with RGMII_ID where in most cases the PHY's internal delay for both RX and TX are used. Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
021bd5e3 |
|
18-Dec-2019 |
Jose Abreu <Jose.Abreu@synopsys.com> |
net: stmmac: Let TX and RX interrupts be independently enabled/disabled By using this mechanism we can get rid of the not so nice method of scheduling TX NAPI when the RX was scheduled. No bandwidth reduction was seen with this change. Changes from v1: - Remove useless comment (Jakub) - Do not bind the TX clean to NAPI budget (Jakub) Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
40a1dcee |
|
10-Nov-2019 |
Corentin Labbe <clabbe@baylibre.com> |
net: ethernet: dwmac-sun8i: Use the correct function in exit path When PHY is not powered, the probe function fail and some resource are still unallocated. Furthermore some BUG happens: dwmac-sun8i 5020000.ethernet: EMAC reset timeout ------------[ cut here ]------------ kernel BUG at /linux-next/net/core/dev.c:9844! So let's use the right function (stmmac_pltfr_remove) in the error path. Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i") Cc: <stable@vger.kernel.org> # v4.15+ Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0c65b2b9 |
|
03-Nov-2019 |
Andrew Lunn <andrew@lunn.ch> |
net: of_get_phy_mode: Change API to solve int/unit warnings Before this change of_get_phy_mode() returned an enum, phy_interface_t. On error, -ENODEV etc, is returned. If the result of the function is stored in a variable of type phy_interface_t, and the compiler has decided to represent this as an unsigned int, comparision with -ENODEV etc, is a signed vs unsigned comparision. Fix this problem by changing the API. Make the function return an error, or 0 on success, and pass a pointer, of type phy_interface_t, where the phy mode should be stored. v2: Return with *interface set to PHY_INTERFACE_MODE_NA on error. Add error checks to all users of of_get_phy_mode() Fixup a few reverse christmas tree errors Fixup a few slightly malformed reverse christmas trees v3: Fix 0-day reported errors. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
05908d72 |
|
18-Oct-2019 |
Mans Rullgard <mans@mansr.com> |
net: ethernet: dwmac-sun8i: show message only when switching to promisc Printing the info message every time more than the max number of mac addresses are requested generates unnecessary log spam. Showing it only when the hw is not already in promiscous mode is equally informative without being annoying. Signed-off-by: Mans Rullgard <mans@mansr.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
e33b4325 |
|
30-Aug-2019 |
Yizhuo <yzhai003@ucr.edu> |
net: stmmac: dwmac-sun8i: Variable "val" in function sun8i_dwmac_set_syscon() could be uninitialized In function sun8i_dwmac_set_syscon(), local variable "val" could be uninitialized if function regmap_field_read() returns -EINVAL. However, it will be used directly in the if statement, which is potentially unsafe. Signed-off-by: Yizhuo <yzhai003@ucr.edu> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
aa4c0c90 |
|
09-Jul-2019 |
Joe Perches <joe@perches.com> |
net: stmmac: Fix misuses of GENMASK macro Arguments are supposed to be ordered high then low. Fixes: 293e4365a1ad ("stmmac: change descriptor layout") Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i") Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
06a80a7d |
|
09-Jul-2019 |
Jose Abreu <Jose.Abreu@synopsys.com> |
net: stmmac: Fix descriptors address being in > 32 bits address space Commit a993db88d17d ("net: stmmac: Enable support for > 32 Bits addressing in XGMAC"), introduced support for > 32 bits addressing in XGMAC but the conversion of descriptors to dma_addr_t was left out. As some devices assing coherent memory in regions > 32 bits we need to set lower and upper value of descriptors address when initializing DMA channels. Luckly, this was working for me because I was assigning CMA to < 4GB address space for performance reasons. Fixes: a993db88d17d ("net: stmmac: Enable support for > 32 Bits addressing in XGMAC") Signed-off-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0fec7e72 |
|
20-Jun-2019 |
Icenowy Zheng <icenowy@aosc.io> |
net: stmmac: sun8i: force select external PHY when no internal one The PHY selection bit also exists on SoCs without an internal PHY; if it's set to 1 (internal PHY, default value) then the MAC will not make use of any PHY on such SoCs. This problem appears when adapting for H6, which has no real internal PHY (the "internal PHY" on H6 is not on-die, but on a co-packaged AC200 chip, connected via RMII interface at GPIO bank A). Force the PHY selection bit to 0 when the SOC doesn't have an internal PHY, to address the problem of a wrong default value. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
adadd38c |
|
20-Jun-2019 |
Icenowy Zheng <icenowy@aosc.io> |
net: stmmac: sun8i: add support for Allwinner H6 EMAC The EMAC on Allwinner H6 is just like the one on A64. The "internal PHY" on H6 is on a co-packaged AC200 chip, and it's not really internal (it's connected via RMII at PA GPIO bank). Add support for the Allwinner H6 EMAC in the dwmac-sun8i driver. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c942fddf |
|
27-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157 Based on 3 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [graeme] [gregory] [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema] [hk] [hemahk]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1105 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
8edb1271 |
|
24-May-2019 |
Corentin Labbe <clabbe@baylibre.com> |
net: ethernet: stmmac: dwmac-sun8i: Enable control of loopback This patch enable use of set_mac_loopback in dwmac-sun8i Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Jose Abreu <joabreu@synopsys.com> Cc: Joao Pinto <jpinto@synopsys.com> Cc: David S. Miller <davem@davemloft.net> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
d4c26eb6 |
|
13-May-2019 |
Corentin Labbe <clabbe@baylibre.com> |
net: ethernet: stmmac: dwmac-sun8i: enable support of unicast filtering When adding more MAC addresses to a dwmac-sun8i interface, the device goes directly in promiscuous mode. This is due to IFF_UNICAST_FLT missing flag. So since the hardware support unicast filtering, let's add IFF_UNICAST_FLT. Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i") Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4ec850e5 |
|
12-Mar-2019 |
Kangjie Lu <kjlu@umn.edu> |
net: dwmac-sun8i: fix a missing check of of_get_phy_mode of_get_phy_mode may fail and return a negative error code; the fix checks the return value of of_get_phy_mode and returns -EINVAL of it fails. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ac63043d |
|
27-Aug-2018 |
Johan Hovold <johan@kernel.org> |
net: stmmac: dwmac-sun8i: fix OF child-node lookup Use the new of_get_compatible_child() helper to lookup the mdio-internal child node instead of using of_find_compatible_node(), which searches the entire tree from a given start node and thus can return an unrelated (i.e. non-child) node. This also addresses a potential use-after-free (e.g. after probe deferral) as the tree-wide helper drops a reference to its first argument (i.e. the mdio-mux node). Fortunately, this was inadvertently balanced by a failure to drop the mdio-mux reference after lookup. While at it, also fix the related mdio-internal- and phy-node reference leaks. Fixes: 634db83b8265 ("net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs") Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Jose Abreu <joabreu@synopsys.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
56c266dc |
|
13-Jul-2018 |
Corentin Labbe <clabbe@baylibre.com> |
net: stmmac: dwmac-sun8i: fix typo descrive => describe This patch fix a typo in the word Describe Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
24aaed0c |
|
18-May-2018 |
Jose Abreu <Jose.Abreu@synopsys.com> |
net: stmmac: Uniformize the use of dma_init_* callbacks Instead of relying on the GMAC version for choosing if we need to use dma_init or dma_init_{rx/tx}_chan callback, lets uniformize this and always use the dma_init_{rx/tx}_chan callbacks. While at it, fix the use of dma_init_chan callback, which shall be called for as many channels as the max of rx/tx channels. Signed-off-by: Jose Abreu <joabreu@synopsys.com> Cc: David S. Miller <davem@davemloft.net> Cc: Joao Pinto <jpinto@synopsys.com> Cc: Vitor Soares <soares@synopsys.com> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ab0204e3 |
|
18-May-2018 |
Jose Abreu <Jose.Abreu@synopsys.com> |
net: stmmac: Uniformize the use of dma_{rx/tx}_mode callbacks Instead of relying on the GMAC version for choosing if we need to use dma_{rx/tx}_mode or just dma_mode callback lets uniformize this and always use the dma_{rx/tx}_mode callbacks. Signed-off-by: Jose Abreu <joabreu@synopsys.com> Cc: David S. Miller <davem@davemloft.net> Cc: Joao Pinto <jpinto@synopsys.com> Cc: Vitor Soares <soares@synopsys.com> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9bf5085a |
|
13-May-2018 |
Chen-Yu Tsai <wens@csie.org> |
net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC The Allwinner R40 SoC has the EMAC controller supported by dwmac-sun8i. It is named "GMAC", while EMAC refers to the 10/100 Mbps Ethernet controller supported by sun4i-emac. The controller is the same, but the R40 has the glue layer controls in the clock control unit (CCU), with a reduced RX delay chain, and no TX delay chain. This patch adds support for it using the framework laid out by previous patches to map the differences. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
7b270b72 |
|
13-May-2018 |
Chen-Yu Tsai <wens@csie.org> |
net: stmmac: dwmac-sun8i: Support different ranges for TX/RX delay chains On the R40 SoC, the RX delay chain only has a range of 0~7 (hundred picoseconds), instead of 0~31. Also the TX delay chain is completely absent. This patch adds support for different ranges by adding per-compatible maximum values in the variant data. A maximum of 0 indicates that the delay chain is not supported or absent. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
49a06cae |
|
13-May-2018 |
Chen-Yu Tsai <wens@csie.org> |
net: stmmac: dwmac-sun8i: Allow getting syscon regmap from external device On the Allwinner R40 SoC, the "GMAC clock" register is in the CCU address space. Using a standard syscon to access it provides no coordination with the CCU driver for register access. Neither does it prevent this and other drivers from accessing other, maybe critical, clock control registers. On other SoCs, the register is in the "system control" address space, which might also contain controls for mapping SRAM to devices or the CPU. This hardware has the same issues. Instead, for these types of setups, we let the device containing the control register create a regmap tied to it. We can then get the device from the existing syscon phandle, and retrieve the regmap with dev_get_regmap(). Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
25ae15fb |
|
13-May-2018 |
Chen-Yu Tsai <wens@csie.org> |
net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access On the Allwinner R40, the "GMAC clock" register is located in the CCU block, at a different register address than the other SoCs that have it in the "system control" block. This patch converts the use of regmap to regmap_field for mapping and accessing the syscon register, so we can have the register address in the variants data, and not in the actual register manipulation code. This patch only converts regmap_read() and regmap_write() calls to regmap_field_read() and regmap_field_write() calls. There are some places where it might make sense to switch to regmap_field_update_bits(), but this is not done here to keep the patch simple. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
8cad443e |
|
18-Jan-2018 |
Florian Fainelli <f.fainelli@gmail.com> |
net: stmmac: Fix reception of Broadcom switches tags Broadcom tags inserted by Broadcom switches put a 4 byte header after the MAC SA and before the EtherType, which may look like some sort of 0 length LLC/SNAP packet (tcpdump and wireshark do think that way). With ACS enabled in stmmac the packets were truncated to 8 bytes on reception, whereas clearing this bit allowed normal reception to occur. In order to make that possible, we need to pass a net_device argument to the different core_init() functions and we are dependent on the Broadcom tagger padding packets correctly (which it now does). To be as little invasive as possible, this is only done for gmac1000 when the network device is DSA-enabled (netdev_uses_dsa() returns true). Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1c08ac0c |
|
28-Nov-2017 |
Corentin Labbe <clabbe.montjoie@gmail.com> |
net: stmmac: dwmac-sun8i: fix allwinner,leds-active-low handling The driver expect "allwinner,leds-active-low" to be in PHY node, but the binding doc expect it to be in MAC node. Since all board DT use it also in MAC node, the driver need to search allwinner,leds-active-low in MAC node. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
a8ff8ccb |
|
24-Oct-2017 |
Corentin Labbe <clabbe.montjoie@gmail.com> |
net: stmmac: sun8i: Restore the compatibles The original dwmac-sun8i DT bindings have some issue on how to handle integrated PHY and was reverted in last RC of 4.13. But now we have a solution so we need to get back that was reverted. This patch restore compatibles about dwmac-sun8i This reverts commit ad4540cc5aa3 ("net: stmmac: sun8i: Remove the compatibles") Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
634db83b |
|
24-Oct-2017 |
Corentin Labbe <clabbe.montjoie@gmail.com> |
net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs The Allwinner H3 SoC have two distinct MDIO bus, only one could be active at the same time. The selection of the active MDIO bus are done via some bits in the EMAC register of the system controller. This patch implement this MDIO switch via a custom MDIO-mux. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ad4540cc |
|
25-Aug-2017 |
Maxime Ripard <mripard@kernel.org> |
net: stmmac: sun8i: Remove the compatibles Since the bindings have been controversial, and we follow the DT stable ABI rule, we shouldn't let a driver with a DT binding that might change slip through in a stable release. Remove the compatibles to make sure the driver will not probe and no-one will start using the binding currently implemented. This commit will obviously need to be reverted in due time. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
d93b07f8 |
|
12-Jul-2017 |
LABBE Corentin <clabbe.montjoie@gmail.com> |
net: stmmac: revert "support future possible different internal phy mode" Since internal phy-mode is reserved for non-xMII protocol we cannot use it with dwmac-sun8i. Furthermore, all DT patchs which comes with this patch were cleaned, so the current state is broken. This reverts commit 1c2fa5f84683 ("net: stmmac: support future possible different internal phy mode") Fixes: 1c2fa5f84683 ("net: stmmac: support future possible different internal phy mode") Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1c2fa5f8 |
|
27-Jun-2017 |
LABBE Corentin <clabbe.montjoie@gmail.com> |
net: stmmac: support future possible different internal phy mode The current way to find if the phy is internal is to compare DT phy-mode and emac_variant/internal_phy. But it will negate a possible future SoC where an external PHY use the same phy mode than the internal one. By using phy-mode = "internal" we permit to have an external PHY with the same mode than the internal one. Reported-by: André Przywara <andre.przywara@arm.com> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
57fde47d |
|
17-Jun-2017 |
Icenowy Zheng <icenowy@aosc.io> |
net-next: stmmac: dwmac-sun8i: add support for V3s EMAC Allwinner V3s SoC has an Ethernet MAC and an internal PHY like the ones in H3 SoC, however the MAC has no external *MII interfaces available at GPIOs, thus only MII connection to internal PHY is supported. Add this variant of EMAC to dwmac-sun8i driver. The default value of the syscon EMAC-related register seems to have changed from H3, but it seems to be a harmless change. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1450ba8a |
|
17-Jun-2017 |
Icenowy Zheng <icenowy@aosc.io> |
net-next: stmmac: dwmac-sun8i: force EPHY clock freq to 24MHz The EPHY control part of the EMAC syscon register has a bit called CLK_SEL. On the datasheet it says that if it's 0 the EPHY clock is 25MHz and if it's 1 the clock is 24MHz. However, according to the datasheets, no Allwinner SoC with EPHY has any extra xtal input pins for the EPHY, and the system xtal is 24MHz. That means the EPHY is not possible to get a 25MHz xtal input, and thus the frequency can only be 24MHz. It doesn't matter on H3 as the default value of H3 is 24MHz, however on V3s the default value is wrongly set to 25MHz, which prevented the EPHY from working properly. Force the EPHY clock frequency to 24MHz. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
2f878491 |
|
04-Jun-2017 |
Icenowy Zheng <icenowy@aosc.io> |
net-next: stmmac: dwmac-sun8i: ensure the EPHY is properly reseted The EPHY may be already enabled by bootloaders which have Ethernet capability (e.g. current U-Boot). Thus it should be reseted properly before doing the enabling sequence in the dwmac-sun8i driver, otherwise the EMAC reset process may fail if no cable is plugged, and then fail the dwmac-sun8i probing. Tested on Orange Pi PC, One and Zero. All the boards fail to have dwmac-sun8i probed with "EMAC reset timeout" without cable plugged before, and with this fix they're now all able to successfully probe the EMAC without cable plugged and then use the connection after a cable is hot-plugged in. Fixes: 9f93ac8d408 ("net-next: stmmac: Add dwmac-sun8i") Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com> Acked-by: Corentin Labbe <clabbe.montjoie@gmail.com> Reviewed-by: Corentin Labbe <clabbe.montjoie@gmail.com> Acked-by: is not as formal as Signed-off-by:. It is a record that the acker Reviewed-by: is similar. Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9f93ac8d |
|
31-May-2017 |
LABBE Corentin <clabbe.montjoie@gmail.com> |
net-next: stmmac: Add dwmac-sun8i The dwmac-sun8i is a heavy hacked version of stmmac hardware by allwinner. In fact the only common part is the descriptor management and the first register function. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|