- 17 Feb, 2021 3 commits
-
-
Jakub Kicinski authored
Signed-off-by:Jakub Kicinski <kuba@kernel.org>
-
-
Linus Walleij authored
Support also transmitting frames using the custom "8899 A" 4 byte tag. Qingfang came up with the solution: we need to pad the ethernet frame to 60 bytes using eth_skb_pad(), then the switch will happily accept frames with custom tags. Cc: Mauri Sandberg <sandberg@mailfence.com> Reported-by:
DENG Qingfang <dqfext@gmail.com> Fixes: efd7fe68 ("net: dsa: tag_rtl4_a: Implement Realtek 4 byte A tag") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 16 Feb, 2021 37 commits
-
-
David S. Miller authored
Robert Hancock says: ==================== Broadcom PHY driver updates Updates to the Broadcom PHY driver related to use with copper SFP modules. Changed since v3: -fixed kerneldoc error Changed since v2: -Create flag for PHY on SFP module and use that rather than accessing attached_dev directly in PHY driver Changed since v1: -Reversed conditional to reduce indentation -Added missing setting of MII_BCM54XX_AUXCTL_MISC_WREN in MII_BCM54XX_AUXCTL_SHDWSEL_MISC register ==================== Signed-off-by: -
Robert Hancock authored
bcm54xx_config_init was modifying the PHY LED configuration to enable link and activity indications. However, some SFP modules (such as Bel-Fuse SFP-1GBT-06) have no LEDs but use the LED outputs to control the SFP LOS signal, and modifying the LED settings will cause the LOS output to malfunction. Skip this configuration for PHYs which are bound to an SFP bus. Signed-off-by:
Robert Hancock <robert.hancock@calian.com> Signed-off-by:
-
Robert Hancock authored
Add a flag and helper function to indicate that a PHY device is part of an SFP module, which is set on attach. This can be used by PHY drivers to handle SFP-specific quirks or behavior. Signed-off-by:
-
Robert Hancock authored
The default configuration for the BCM54616S PHY may not match the desired mode when using 1000BaseX or SGMII interface modes, such as when it is on an SFP module. Add code to explicitly set the correct mode using programming sequences provided by Bel-Fuse: https://www.belfuse.com/resources/datasheets/powersolutions/ds-bps-sfp-1gbt-05-series.pdf https://www.belfuse.com/resources/datasheets/powersolutions/ds-bps-sfp-1gbt-06-series.pdfSigned-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Sven Van Asbroeck authored
On cpu architectures w/o dma cache snooping, dma_unmap() is a is a very expensive operation, because its resulting sync needs to invalidate cpu caches. Increase efficiency/performance by syncing only those sections of the lan743x's rx ring buffers that are actually in use. Signed-off-by:
Sven Van Asbroeck <thesven73@gmail.com> Reviewed-by:
Bryan Whitehead <Bryan.Whitehead@microchip.com> Signed-off-by:
-
Sven Van Asbroeck authored
The buffers in the lan743x driver's receive ring are always 9K, even when the largest packet that can be received (the mtu) is much smaller. This performs particularly badly on cpu archs without dma cache snooping (such as ARM): each received packet results in a 9K dma_{map|unmap} operation, which is very expensive because cpu caches need to be invalidated. Careful measurement of the driver rx path on armv7 reveals that the cpu spends the majority of its time waiting for cache invalidation. Optimize by keeping the rx ring buffer size as close as possible to the mtu. This limits the amount of cache that requires invalidation. This optimization would normally force us to re-allocate all ring buffers when the mtu is changed - a disruptive event, because it can only happen when the network interface is down. Remove the need to re-allocate all ring buffers by adding support for multi-buffer frames. Now any combination of mtu and ring buffer size will work. When the mtu changes from mtu1 to mtu2, consumed buffers of size mtu1 are lazily replaced by newly allocated buffers of size mtu2. These optimizations double the rx performance on armv7. Third parties report 3x rx speedup on armv8. Tested with iperf3 on a freescale imx6qp + lan7430, both sides set to mtu 1500 bytes, measure rx performance: Before: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-20.00 sec 550 MBytes 231 Mbits/sec 0 After: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-20.00 sec 1.33 GBytes 570 Mbits/sec 0 Signed-off-by: -
Vladimir Oltean authored
The following call path suggests that calling unregister_netdev on an interface that is up will first bring it down. enetc_pf_remove -> unregister_netdev -> unregister_netdevice_queue -> unregister_netdevice_many -> dev_close_many -> __dev_close_many -> enetc_close -> enetc_stop -> phylink_stop However, enetc first destroys the phylink instance, then calls unregister_netdev. This is already dissimilar to the setup (and error path teardown path) from enetc_pf_probe, but more than that, it is buggy because it is invalid to call phylink_stop after phylink_destroy. So let's first unregister the netdev (and let the .ndo_stop events consume themselves), then destroy the phylink instance, then free the netdev. Fixes: 71b77a7a ("enetc: Migrate to PHYLINK and PCS_LYNX") Signed-off-by:Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
David S. Miller authored
Maxime Chevallier says: ==================== net: mvneta: implement basic MQPrio support This is V2 for the MQPrio support in mvneta. This small series adds basic support for mqprio offloading, by having the rx queueing mirroring the TCs based on VLAN prio fields. This was tested on Armada 3700, and proves useful to make sure high-priority traffic has a better chance not getting dropped when there's lots of packets incoming. The first patch of the series deals with the per-cpu interrupts on the armada 3700. Since they don't work, there were already some patches applied to keep all queue mappings to CPU0, but there still were some remaining mappings left to be dealt with. The second patch implements the MQPrio offloading for the receive path. Changes in V2 : - Add a Fixes tag for the first patch - Fix some warnings and the xmas tree in the second patch ==================== Signed-off-by: -
Maxime Chevallier authored
Implement a basic MQPrio support, inserting rules in RX that translate the TC to prio mapping into vlan prio to queues. The TX logic stays the same as when we don't offload the qdisc. Signed-off-by:
Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by:
-
Maxime Chevallier authored
According to Errata #23 "The per-CPU GbE interrupt is limited to Core 0", we can't use the per-cpu interrupt mechanism on the Armada 3700 familly. This is correctly checked for RSS configuration, but the initial queue mapping is still done by having the queues spread across all the CPUs in the system, both in the init path and in the cpu_hotplug path. Fixes: 2636ac3c ("net: mvneta: Add network support for Armada 3700 SoC") Signed-off-by:
-
Vlad Buslov authored
When police action is created by cls API tcf_exts_validate() first conditional that calls tcf_action_init_1() directly, the action idr is not updated according to latest changes in action API that require caller to commit newly created action to idr with tcf_idr_insert_many(). This results such action not being accessible through act API and causes crash reported by syzbot: ================================================================== BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:71 [inline] BUG: KASAN: null-ptr-deref in atomic_read include/asm-generic/atomic-instrumented.h:27 [inline] BUG: KASAN: null-ptr-deref in __tcf_idr_release net/sched/act_api.c:178 [inline] BUG: KASAN: null-ptr-deref in tcf_idrinfo_destroy+0x129/0x1d0 net/sched/act_api.c:598 Read of size 4 at addr 0000000000000010 by task kworker/u4:5/204 CPU: 0 PID: 204 Comm: kworker/u4:5 Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 __kasan_report mm/kasan/report.c:400 [inline] kasan_report.cold+0x5f/0xd5 mm/kasan/report.c:413 check_memory_region_inline mm/kasan/generic.c:179 [inline] check_memory_region+0x13d/0x180 mm/kasan/generic.c:185 instrument_atomic_read include/linux/instrumented.h:71 [inline] atomic_read include/asm-generic/atomic-instrumented.h:27 [inline] __tcf_idr_release net/sched/act_api.c:178 [inline] tcf_idrinfo_destroy+0x129/0x1d0 net/sched/act_api.c:598 tc_action_net_exit include/net/act_api.h:151 [inline] police_exit_net+0x168/0x360 net/sched/act_police.c:390 ops_exit_list+0x10d/0x160 net/core/net_namespace.c:190 cleanup_net+0x4ea/0xb10 net/core/net_namespace.c:604 process_one_work+0x98d/0x15f0 kernel/workqueue.c:2275 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 kthread+0x3b1/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 ================================================================== Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 204 Comm: kworker/u4:5 Tainted: G B 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 panic+0x306/0x73d kernel/panic.c:231 end_report+0x58/0x5e mm/kasan/report.c:100 __kasan_report mm/kasan/report.c:403 [inline] kasan_report.cold+0x67/0xd5 mm/kasan/report.c:413 check_memory_region_inline mm/kasan/generic.c:179 [inline] check_memory_region+0x13d/0x180 mm/kasan/generic.c:185 instrument_atomic_read include/linux/instrumented.h:71 [inline] atomic_read include/asm-generic/atomic-instrumented.h:27 [inline] __tcf_idr_release net/sched/act_api.c:178 [inline] tcf_idrinfo_destroy+0x129/0x1d0 net/sched/act_api.c:598 tc_action_net_exit include/net/act_api.h:151 [inline] police_exit_net+0x168/0x360 net/sched/act_police.c:390 ops_exit_list+0x10d/0x160 net/core/net_namespace.c:190 cleanup_net+0x4ea/0xb10 net/core/net_namespace.c:604 process_one_work+0x98d/0x15f0 kernel/workqueue.c:2275 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 kthread+0x3b1/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Kernel Offset: disabled Fix the issue by calling tcf_idr_insert_many() after successful action initialization. Fixes: 0fedc63f ("net_sched: commit action insertions together") Reported-by: syzbot+151e3e714d34ae4ce7e8@syzkaller.appspotmail.com Signed-off-by:
Vlad Buslov <vladbu@nvidia.com> Reviewed-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== pull-request: mlx5-next 2021-02-16 The patches in this pr are already submitted and reviewed through the netdev and rdma mailing lists. The series includes mlx5 HW bits and definitions for mlx5 real time clock translation and handling in the mlx5 driver clock module to enable and support such mode [1] [1] https://patchwork.kernel.org/project/netdevbpf/patch/20210212223042.449816-7-saeed@kernel.org/ ==================== Signed-off-by:
-
Gary Guo authored
The changes made in eccd5403 is enough for xilinx_emaclite to run without problem on 64-bit systems. I have tested it on a Xilinx FPGA with RV64 softcore. The architecture limitation in Kconfig seems no longer necessary. A small change is included to print address with %lx instead of casting to int and print with %x. Signed-off-by:
Gary Guo <gary@garyguo.net> Signed-off-by:
-
David S. Miller authored
Horatiu Vulturv says: ==================== bridge: mrp: Extend br_mrp_switchdev_* This patch series extends MRP switchdev to allow the SW to have a better understanding if the HW can implement the MRP functionality or it needs to help the HW to run it. There are 3 cases: - when HW can't implement at all the functionality. - when HW can implement a part of the functionality but needs the SW implement the rest. For example if it can't detect when it stops receiving MRP Test frames but it can copy the MRP frames to CPU to allow the SW to determine this. Another example is generating the MRP Test frames. If HW can't do that then the SW is used as backup. - when HW can implement completely the functionality. So, initially the SW tries to offload the entire functionality in HW, if that fails it tries offload parts of the functionality in HW and use the SW as helper and if also this fails then MRP can't run on this HW. Based on these new calls, implement the switchdev for Ocelot driver. This is an example where the HW can't run completely the functionality but it can help the SW to run it, by trapping all MRP frames to CPU. Also this patch series adds MRP support to DSA and implements the Felix driver which just reuse the Ocelot functions. This part was just compiled tested because I don't have any HW on which to do the actual tests. v4: - remove ifdef MRP from include/net/switchdev.h - move MRP implementation for Ocelot in a different file such that Felix driver can use it. - extend DSA with MRP support - implement MRP support for Felix. v3: - implement the switchdev calls needed by Ocelot driver. v2: - fix typos in comments and in commit messages - remove some of the comments - move repeated code in helper function - fix issue when deleting a node when sw_backup was true ==================== Signed-off-by: -
Horatiu Vultur authored
Implement functions 'port_mrp_add', 'port_mrp_del', 'port_mrp_add_ring_role' and 'port_mrp_del_ring_role' to call the mrp functions from ocelot. Also all MRP frames that arrive to CPU on queue number OCELOT_MRP_CPUQ will be forward by the SW. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Horatiu Vultur authored
Add support for offloading MRP in HW. Currently implement the switchdev calls 'SWITCHDEV_OBJ_ID_MRP', 'SWITCHDEV_OBJ_ID_RING_ROLE_MRP', to allow to create MRP instances and to set the role of these instances. Add DSA_NOTIFIER_MRP_ADD/DEL and DSA_NOTIFIER_MRP_ADD/DEL_RING_ROLE which calls to .port_mrp_add/del and .port_mrp_add/del_ring_role in the DSA driver for the switch. Signed-off-by:
-
Horatiu Vultur authored
Add basic support for MRP. The HW will just trap all MRP frames on the ring ports to CPU and allow the SW to process them. In this way it is possible to for this node to behave both as MRM and MRC. Current limitations are: - it doesn't support Interconnect roles. - it supports only a single ring. - the HW should be able to do forwarding of MRP Test frames so the SW will not need to do this. So it would be able to have the role MRC without SW support. Signed-off-by:
-
Horatiu Vultur authored
Check the return values of the br_mrp_switchdev function. In case of: - BR_MRP_NONE, return the error to userspace, - BR_MRP_SW, continue with SW implementation, - BR_MRP_HW, continue without SW implementation, Signed-off-by:
-
Horatiu Vultur authored
This patch extends the br_mrp_switchdev functions to be able to have a better understanding what cause the issue and if the SW needs to be used as a backup. There are the following cases: - when the code is compiled without CONFIG_NET_SWITCHDEV. In this case return success so the SW can continue with the protocol. Depending on the function, it returns 0 or BR_MRP_SW. - when code is compiled with CONFIG_NET_SWITCHDEV and the driver doesn't implement any MRP callbacks. In this case the HW can't run MRP so it just returns -EOPNOTSUPP. So the SW will stop further to configure the node. - when code is compiled with CONFIG_NET_SWITCHDEV and the driver fully supports any MRP functionality. In this case the SW doesn't need to do anything. The functions will return 0 or BR_MRP_HW. - when code is compiled with CONFIG_NET_SWITCHDEV and the HW can't run completely the protocol but it can help the SW to run it. For example, the HW can't support completely MRM role(can't detect when it stops receiving MRP Test frames) but it can redirect these frames to CPU. In this case it is possible to have a SW fallback. The SW will try initially to call the driver with sw_backup set to false, meaning that the HW should implement completely the role. If the driver returns -EOPNOTSUPP, the SW will try again with sw_backup set to false, meaning that the SW will detect when it stops receiving the frames but it needs HW support to redirect the frames to CPU. In case the driver returns 0 then the SW will continue to configure the node accordingly. Signed-off-by:
-
Horatiu Vultur authored
Add the enum br_mrp_hw_support that is used by the br_mrp_switchdev functions to allow the SW to detect the cases where HW can't implement the functionality or when SW is used as a backup. Signed-off-by:
-
Horatiu Vultur authored
Add the member sw_backup to the structures switchdev_obj_ring_role_mrp and switchdev_obj_in_role_mrp. In this way the SW can call the driver in 2 ways, once when sw_backup is set to false, meaning that the driver should implement this completely in HW. And if that is not supported the SW will call again but with sw_backup set to true, meaning that the HW should help or allow the SW to run the protocol. For example when role is MRM, if the HW can't detect when it stops receiving MRP Test frames but it can trap these frames to CPU, then it needs to return -EOPNOTSUPP when sw_backup is false and return 0 when sw_backup is true. Signed-off-by:
-
Horatiu Vultur authored
Remove #IS_ENABLED(CONFIG_BRIDGE_MRP) from switchdev.h. This will simplify the code implements MRP callbacks and will be similar with the vlan filtering. Signed-off-by:
-
Robert Hancock authored
When 88E1111 is operating in SGMII mode, auto-negotiation should be enabled on the SGMII side so that the link will come up properly with PCSes which normally have auto-negotiation enabled. This is normally the case when the PHY defaults to SGMII mode at power-up, however if we switched it from some other mode like 1000Base-X, as may happen in some SFP module situations, it may not be, particularly for modules which have 1000Base-X auto-negotiation defaulting to disabled. Call genphy_check_and_restart_aneg on the fiber page to ensure that auto- negotiation is properly enabled on the SGMII interface. Signed-off-by:
-
David S. Miller authored
Marek Behún says: ====================- Add 5gbase-r PHY interface mode there is still some testing needed for Amethyst patches, so I have split the part adding support for 5gbase-r interface mode and am sending it alone. The first two patches are already reviewed. Changes since last patches (Amethyst v16): - added phylink 5gbase-r handler - added SFP support for 5gbase-r mode ==================== Signed-off-by: -
Marek Behún authored
The sfp_parse_support() function is setting 5000baseT_Full in some cases. Now that we have PHY_INTERFACE_MODE_5GBASER interface mode available, change sfp_select_interface() to return PHY_INTERFACE_MODE_5GBASER if 5000baseT_Full is set in the link mode mask. Signed-off-by:
Marek Behún <kabel@kernel.org> Signed-off-by:
-
Marek Behún authored
Add 5GBASER interface type and speed to phylink. Signed-off-by:
-
Pavana Sharma authored
Add 5GBASE-R phy interface mode Signed-off-by:
Pavana Sharma <pavana.sharma@digi.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
-
Pavana Sharma authored
Add 5gbase-r PHY interface mode. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Florian Fainelli authored
The tg3 driver tried to communicate towards the PHY driver whether it wanted RGMII in-band signaling enabled or disabled however there is nothing that looks at those flags in drivers/net/phy/broadcom.c so this does do not anything. Suggested-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
David S. Miller authored
Shyam Sundar S K says: ==================== Bug fixes to amd-xgbe driver General fixes on amd-xgbe driver are addressed in this series, mostly on the mailbox communication failures and improving the link stability of the amd-xgbe device. ==================== Signed-off-by: -
Shyam Sundar S K authored
Frequent link up/down events can happen when a Bel Fuse SFP part is connected to the amd-xgbe device. Try to avoid the frequent link issues by resetting the PHY as documented in Bel Fuse SFP datasheets. Fixes: e722ec82 ("amd-xgbe: Update the BelFuse quirk to support SGMII") Co-developed-by:
Sudheesh Mavila <sudheesh.mavila@amd.com> Signed-off-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Acked-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Shyam Sundar S K authored
Normally, auto negotiation and reconnect should be automatically done by the hardware. But there seems to be an issue where auto negotiation has to be restarted manually. This happens because of link training and so even though still connected to the partner the link never "comes back". This needs an auto-negotiation restart. Also, a change in xgbe-mdio is needed to get ethtool to recognize the link down and get the link change message. This change is only required in a backplane connection mode. Fixes: abf0a1c2 ("amd-xgbe: Add support for SFP+ modules") Co-developed-by:
-
Shyam Sundar S K authored
The current driver calls netif_carrier_off() late in the link tear down which can result in a netdev watchdog timeout. Calling netif_carrier_off() immediately after netif_tx_stop_all_queues() avoids the warning. ------------[ cut here ]------------ NETDEV WATCHDOG: enp3s0f2 (amd-xgbe): transmit queue 0 timed out WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x20d/0x220 Modules linked in: amd_xgbe(E) amd-xgbe 0000:03:00.2 enp3s0f2: Link is Down CPU: 3 PID: 0 Comm: swapper/3 Tainted: G E Hardware name: AMD Bilby-RV2/Bilby-RV2, BIOS RBB1202A 10/18/2019 RIP: 0010:dev_watchdog+0x20d/0x220 Code: 00 49 63 4e e0 eb 92 4c 89 e7 c6 05 c6 e2 c1 00 01 e8 e7 ce fc ff 89 d9 48 RSP: 0018:ffff90cfc28c3e88 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff90cfc28d63c0 RBP: ffff90cfb977845c R08: 0000000000000050 R09: 0000000000196018 R10: ffff90cfc28c3ef8 R11: 0000000000000000 R12: ffff90cfb9778000 R13: 0000000000000003 R14: ffff90cfb9778480 R15: 0000000000000010 FS: 0000000000000000(0000) GS:ffff90cfc28c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f240ff2d9d0 CR3: 00000001e3e0a000 CR4: 00000000003406e0 Call Trace: <IRQ> ? pfifo_fast_reset+0x100/0x100 call_timer_fn+0x2b/0x130 run_timer_softirq+0x3e8/0x440 ? enqueue_hrtimer+0x39/0x90 Fixes: e722ec82 ("amd-xgbe: Update the BelFuse quirk to support SGMII") Co-developed-by:
-
Shyam Sundar S K authored
Sometimes mailbox commands timeout when the RX data path becomes unresponsive. This prevents the submission of new mailbox commands to DXIO. This patch identifies the timeout and resets the RX data path so that the next message can be submitted properly. Fixes: 549b32af ("amd-xgbe: Simplify mailbox interface rate change code") Co-developed-by:
-
David S. Miller authored
Bjarni Jonasson says: ==================== Fixes applied to VCS8514 3 different fixes applied to VSC8514: LCPLL reset, serdes calibration and coma mode disabled. Especially the serdes calibration is large and is now placed in a new file 'mscc_serdes.c' which can act as a placeholder for future serdes configuration. v1 -> v2: Preserved reversed christmas tree Removed forward definitions Fixed build issues Changed net to net-next v2 -> v3: Added cover letter. Removed ena_clk_bypass from function call Created mscc_serdes.c and .h for serdes configuration Modified coma register config. ==================== Signed-off-by: -
Bjarni Jonasson authored
The 'coma mode' (configurable through sw or hw) provides an optional feature that may be used to control when the PHYs become active. The typical usage is to synchronize the link-up time across all PHY instances. This patch releases coma mode if not done by hardware, otherwise the phys will not link-up. Fixes: e4f9ba64 ("net: phy: mscc: add support for VSC8514 PHY.") Signed-off-by:
Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by:
Bjarni Jonasson <bjarni.jonasson@microchip.com> Signed-off-by:
-
Bjarni Jonasson authored
The current IB serdes calibration algorithm (performed by the onboard 8051) has proven to be unstable for the VSC8514 QSGMII phy. A new algorithm has been developed based on 'Frequency-offset Jittered-Injection' or 'FoJi' method which solves all known issues. This patch disables the 8051 algorithm and replaces it with the new FoJi algorithm. The calibration is now performed in a new file (mscc_serdes.c), which can act as an placeholder for future serdes configurations. Fixes: e4f9ba64 ("net: phy: mscc: add support for VSC8514 PHY.") Signed-off-by:
-
