- 18 Jan, 2018 1 commit
-
-
Jörg Krause authored
This patch adds the device ID for the bluetooth chip used in the AMPAK AP6212 WiFi+Bluetooth module. The AP6212 is used on several BananaPi boards, e.g. M2-Ultra. The AP6212 is a combo module, where the WiFi chip is identified as BCM43430A0 whereas the Bluetooth chip identifies itself as 4343A0. Note, the missing '0' before the 'A0'. The AP6212 needs a firmware blob. Loading the provided firmware file from the BananaPi vendor, the adapter name is printed as 'BCM4343A0 26MHz AP6212_CL1-0061': ''' hci0: Type: Primary Bus: UART BD Address: 43:43:A0:12:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:3076 acl:0 sco:0 events:278 errors:0 TX bytes:39726 acl:0 sco:0 commands:279 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'BCM4343A0 26MHz AP6212_CL1-0061' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 4.1 (0x7) Revision: 0xf2 LMP Version: 4.1 (0x7) Subversion: 0x2122 Manufacturer: Broadcom Corporation (15) ''' Signed-off-by:
Jörg Krause <joerg.krause@embedded.rocks> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- 17 Jan, 2018 39 commits
-
-
David S. Miller authored
Merge tag 'linux-can-next-for-4.16-20180116' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2018-01-16 this is a pull request for net-next/master consisting of 9 patches. This is a series of patches, some of them initially by Franklin S Cooper Jr, which was picked up by Faiz Abbas. Faiz Abbas added some patches while working on this series, I contributed one as well. The first two patches add support to CAN device infrastructure to limit the bitrate of a CAN adapter if the used CAN-transceiver has a certain maximum bitrate. The remaining patches improve the m_can driver. They add support for bitrate limiting to the driver, clean up the driver and add support for runtime PM. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Luis de Bethencourt authored
The trailing semicolon is an empty statement that does no operation. It is completely stripped out by the compiler. Removing it since it doesn't do anything. Fixes: 5f35227e ("net: Generalize ndo_gso_check to ndo_features_check") Signed-off-by:
Luis de Bethencourt <luisbg@kernel.org> Acked-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
Ganesh Goudar authored
restructure the code which adds support for configuring PCIe VF via mgmt netdevice. which was added by commit 7829451c ("cxgb4: Add control net_device for configuring PCIe VF") Original work by: Casey Leedom <leedom@chelsio.com> Signed-off-by:
Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by:
-
Kirill Tkhai authored
idr_find() is safe under rcu_read_lock() and maybe_get_net() guarantees that net is alive. Signed-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by:
-
Kirill Tkhai authored
peernet2id_alloc() is racy without rtnl_lock() as refcount_read(&peer->count) under net->nsid_lock does not guarantee, peer is alive: rcu_read_lock() peernet2id_alloc() .. spin_lock_bh(&net->nsid_lock) .. refcount_read(&peer->count) (!= 0) .. .. put_net() .. cleanup_net() .. for_each_net(tmp) .. spin_lock_bh(&tmp->nsid_lock) .. __peernet2id(tmp, net) == -1 .. .. .. .. __peernet2id_alloc(alloc == true) .. .. .. rcu_read_unlock() .. .. synchronize_rcu() .. kmem_cache_free(net) After the above situation, net::netns_id contains id pointing to freed memory, and any other dereferencing by the id will operate with this freed memory. Currently, peernet2id_alloc() is used under rtnl_lock() everywhere except ovs_vport_cmd_fill_info(), and this race can't occur. But peernet2id_alloc() is generic interface, and better we fix it before someone really starts use it in wrong context. v2: Don't place refcount_read(&net->count) under net->nsid_lock as suggested by Eric W. Biederman <ebiederm@xmission.com> v3: Rebase on top of net-next Signed-off-by: -
David S. Miller authored
Jason Wang says: ==================== tun: allow to attach eBPF filter This series tries to implement eBPF socket filter for tun. This could be used for implementing efficient virtio-net receive filter for vhost-net. Changes from V2: - fix typo - remove unnecessary double check ==================== Signed-off-by: -
Jason Wang authored
This patch allows userspace to attach eBPF filter to tun. This will allow to implement VM dataplane filtering in a more efficient way compared to cBPF filter by allowing either qemu or libvirt to attach eBPF filter to tun. Signed-off-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Jason Wang authored
To be reused by other eBPF program other than queue selection. Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== net: sched: allow qdiscs to share filter block instances Currently the filters added to qdiscs are independent. So for example if you have 2 netdevices and you create ingress qdisc on both and you want to add identical filter rules both, you need to add them twice. This patchset makes this easier and mainly saves resources allowing to share all filters within a qdisc - I call it a "filter block". Also this helps to save resources when we do offload to hw for example to expensive TCAM. So back to the example. First, we create 2 qdiscs. Both will share block number 22. "22" is just an identification: $ tc qdisc add dev ens7 ingress_block 22 ingress ^^^^^^^^^^^^^^^^ $ tc qdisc add dev ens8 ingress_block 22 ingress ^^^^^^^^^^^^^^^^ If we don't specify "block" command line option, no shared block would be created: $ tc qdisc add dev ens9 ingress Now if we list the qdiscs, we will see the block index in the output: $ tc qdisc qdisc ingress ffff: dev ens7 parent ffff:fff1 ingress_block 22 qdisc ingress ffff: dev ens8 parent ffff:fff1 ingress_block 22 qdisc ingress ffff: dev ens9 parent ffff:fff1 To make is more visual, the situation looks like this: ens7 ingress qdisc ens7 ingress qdisc | | | | +----------> block 22 <----------+ Unlimited number of qdiscs may share the same block. Note that this patchset introduces block sharing support also for clsact qdisc: $ tc qdisc add dev ens10 ingress_block 23 egress_block 24 clsact $ tc qdisc show dev ens10 qdisc clsact ffff: dev ens10 parent ffff:fff1 ingress_block 23 egress_block 24 We can add filter using the block index: $ tc filter add block 22 protocol ip pref 25 flower dst_ip 192.168.0.0/16 action drop Note we cannot use the qdisc for filter manipulations of shared blocks: $ tc filter add dev ens8 ingress protocol ip pref 1 flower dst_ip 192.168.100.2 action drop Error: This filter block is shared. Please use the block index to manipulate the filters. We will see the same output if we list filters for ingress qdisc of ens7 and ens8, also for the block 22: $ tc filter show block 22 filter block 22 protocol ip pref 25 flower chain 0 filter block 22 protocol ip pref 25 flower chain 0 handle 0x1 ... $ tc filter show dev ens7 ingress filter block 22 protocol ip pref 25 flower chain 0 filter block 22 protocol ip pref 25 flower chain 0 handle 0x1 ... $ tc filter show dev ens8 ingress filter block 22 protocol ip pref 25 flower chain 0 filter block 22 protocol ip pref 25 flower chain 0 handle 0x1 ... --- v10->v11: - patch 2: - fixed error path when register_pernet_subsys fails pointed out by Cong - patch 9: - rebased on top of the current net-next v9->v10: - patch 7: - fixed ifindex magic in the patch description - userspace patches: - added manpages and patch descriptions v8->v9: - patch "net: sched: add rt netlink message type for block get" was removed, userspace check filter existence using qdisc dump v7->v8: - patch 7: - added comment to ifindex block magic - patch 9: - new patch - patch 10: - base this on the patch that introduces qdisc-generic block index attributes parsing/dumping - patch 13: - rebased on top of current net-next v6->v7: - patch 1: - unsquashed shared block patch that was previously squashed by mistake - fixed error path in block create - freeing chain 0 - patch 2: - new patch - splitted from the previous one as it got accidentaly squashed in the rebasing process in the past - converted to idr extended - removed auto-generating of block indexes. Callers have to explicily tell that the block is shared by passing non-zero block index - fixed error path in block get ext - freeing chain 0 - patch 7: - changed extack message for block index handle as suggested by DaveA - added extack message when block index does not exist - the block ifindex magic is in define and change to 0xffffffff as suggested by Jamal - patch 8: - new patch implementing RTM_GETBLOCK in order to query if the block with some index exists - patch 9: - adjust to the core changes and check block index attributes for being 0 v5->v6: - added patch 6 that introduces block handle v4->v5: - patch 5: - add tracking of binding of devs that are unable to offload and check that before block cbs call. v3->v4: - patch 1: - rebased on top of the current net-next - added some extack strings - patch 3: - rebased on top of the current net-next - patch 5: - propagate netdev_ops->ndo_setup_tc error up to tcf_block_offload_bind caller - patch 7: - rebased on top of the current net-next v2->v3: - removed original patch 1, removing tp->q cls_bpf dependency. Fixed by Jakub in the meantime. - patch 1: - rebased on top of the current net-next - patch 5: - new patch - patch 8: - removed "p_" prefix from block index function args - patch 10: - add tc offload feature handling ==================== Acked-by:David Ahern <dsahern@gmail.com> Signed-off-by:
-
Jiri Pirko authored
No need to convert from mlxsw_sp_port to net_device and back again. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Acked-by:
-
Jiri Pirko authored
Benefit from the prepared TC and in-driver ACL infrastructure and introduce block sharing offload. For that, a new struct "block" is introduced in spectrum_acl in order to hold a list of specific block-port bindings. Signed-off-by:
-
Jiri Pirko authored
Instead, pass netdev and ingress flag to ruleset unbind op. Signed-off-by:
-
Jiri Pirko authored
In order to prepare for follow-up changes, make the bind/unbind helpers very simple. That required move of ht insertion/removal and bind/unbind calls into mlxsw_sp_acl_ruleset_create/destroy. Signed-off-by:
-
Jiri Pirko authored
Benefit from the previously introduced shared filter blocks infrastructure and allow ingress and clsact qdisc instances to share filter blocks. The block index is coming from userspace as qdisc option. Signed-off-by:
Jamal Hadi Salim <jhs@mojatatu.com> Acked-by:
-
Jiri Pirko authored
Introduce two new attributes to be used for qdisc creation and dumping. One for ingress block, one for egress block. Introduce a set of ops that qdisc which supports block sharing would implement. Passing block indexes in qdisc change is not supported yet and it is checked and forbidded. In future, these attributes are to be reused for specifying block indexes for classes as well. As of this moment however, it is not supported so a check is in place to forbid it. Suggested-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by:
-
Jiri Pirko authored
As the tcm_ifindex with value TCM_IFINDEX_MAGIC_BLOCK is invalid ifindex, use it to indicate that we work with block, instead of qdisc. So if tcm_ifindex is set to TCM_IFINDEX_MAGIC_BLOCK, tcm_parent is used to carry block_index. If the block is set to be shared between at least 2 qdiscs, it is forbidden to use the qdisc handle to add/delete filters. In that case, userspace has to pass block_index. Also, for dump of the filters, in case the block is shared in between at least 2 qdiscs, the each filter is dumped with tcm_ifindex value TCM_IFINDEX_MAGIC_BLOCK and tcm_parent set to block_index. That gives the user clear indication, that the filter belongs to a shared block and not only to one qdisc under which it is dumped. Suggested-by:
-
Jiri Pirko authored
During block bind, we need to check tc offload feature. If it is disabled yet still the block contains offloaded filters, forbid the bind. Also forbid to register callback for a block that already contains offloaded filters, as the play back is not supported now. For keeping track of offloaded filters there is a new counter introduced, alongside with couple of helpers called from cls_* code. These helpers set and clear TCA_CLS_FLAGS_IN_HW flag. Signed-off-by:
-
Jiri Pirko authored
Both are no longer used, so remove them. Signed-off-by:
-
Jiri Pirko authored
Couple of classifiers call netif_keep_dst directly on q->dev. That is not possible to do directly for shared blocke where multiple qdiscs are owning the block. So introduce a infrastructure to keep track of the block owners in list and use this list to implement block variant of netif_keep_dst. Signed-off-by:
-
Jiri Pirko authored
Use block index in the messages instead. Signed-off-by:
-
Jiri Pirko authored
Allow qdiscs to share filter blocks among them. Each qdisc type has to use block get/put extended modifications that enable sharing. Shared blocks are tracked within each net namespace and identified by u32 index. This index is passed from user during the qdisc creation. If user passes index that is not used by any other qdisc, new block is created. If user passes index that is already used, the existing block will be re-used. Signed-off-by:
-
Jiri Pirko authored
So far, there was possible only to register a single filter chain pointer to block->chain[0]. However, when the blocks will get shareable, we need to allow multiple filter chain pointers registration. Signed-off-by:
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: Updates for net-next. First, we upgrade the firmware interface spec. Due to a change in the toolchains, the auto-generated bnxt_hsi.h does not match the old bnxt_hsi.h and the patch is really big. This should be just one-time. Going forward, changes should be incremental. The next 10 patches implement a new scheme for the PF and VF drivers to allocate and reserve resources. The new scheme is more flexible and allows dynamic and asymmetric distribution of resources, whereas the old scheme is static and even distribution. The last few patches add cacheline size setting, a couple of PCI IDs, better management of VF MAC address, and a better parent switchdev ID for dual-port devices. ==================== Signed-off-by: -
Sathya Perla authored
Currently the driver exports different switchdev PARENT_IDs for representors belonging to different SR-IOV PF-pools of an adapter. This is not correct as the adapter can switch across all vports of an adapter. This patch fixes this by exporting a common switchdev PARENT_ID for all reps of an adapter. The PCIE DSN is used as the id. Signed-off-by:
Sathya Perla <sathya.perla@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Michael Chan authored
The chip supports 64-byte and 128-byte cache line size for more optimal DMA performance when matched to the CPU cache line size. The default is 64. If the system is using 128-byte cache line size, set it to 128. Signed-off-by:
-
Vasundhara Volam authored
Forward hwrm_func_vf_cfg command from VF to PF driver, to store VF MAC address in PF's context. This will allow "ip link show" to display all VF MAC addresses. Maintain 2 locations of MAC address in VF info structure, one for a PF assigned MAC and one for VF assigned MAC. Display VF assigned MAC in "ip link show", only if PF assigned MAC is not valid. Signed-off-by:
Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by:
-
Vasundhara Volam authored
Signed-off-by:
-
Michael Chan authored
bnxt_check_rings() is called by ethtool, XDP setup, and ndo_setup_tc() to see if there are enough resources to support the new configuration. Expand the call to test all resources if the firmware supports the new API. With the more flexible resource allocation scheme, this call must be made to check that all resources are available before committing to allocate the resources. Signed-off-by:
-
Michael Chan authored
Instead of the old method of evenly dividing the resources to the VFs, use the new firmware API to specify min and max resources for each VF. This way, there is more flexibility for each VF to allocate more or less resources. The min is the absolute minimum for each VF to function. The max is the global resources minus the resources used by the PF. Each VF is guaranteed the min. Up to max resources may be available for some VFs. The PF driver can use one of 2 strategies specified in NVRAM to assign the resources. The old legacy strategy of evenly dividing the resources or the new flexible strategy. Signed-off-by:
-
Michael Chan authored
In bnxt_rfs_capable(), add call to reserve vnic resources to support NTUPLE. Return true if we can successfully reserve enough vnics. Otherwise, reserve the minimum 1 VNIC for normal operations not supporting NTUPLE and return false. Also, suppress warning message about not enough resources for NTUPLE when only 1 RX ring is in use. NTUPLE filters by definition require multiple RX rings. Signed-off-by:
-
Michael Chan authored
The new method will call firmware to reserve the desired tx, rx, cmpl rings, ring groups, stats context, and vnic resources. A second query call will check the actual resources that firmware is able to reserve. The driver will then trim and adjust based on the actual resources provided by firmware. The driver will then reserve the final resources in use. This method is a more flexible way of using hardware resources. The resources are not fixed and can by adjusted by firmware. The driver adapts to the available resources that the firmware can reserve for the driver. Signed-off-by:
-
Michael Chan authored
In combined mode, the driver is currently not setting RX and TX ring numbers the same when firmware can allocate more RX than TX or vice versa. This will confuse the user as the ethtool convention assumes they are the same in combined mode. Fix it by adding bnxt_trim_dflt_sh_rings() to trim RX and TX ring numbers to be the same as the completion ring number in combined mode. Note that if TCs are enabled and/or XDP is enabled, the number of TX rings will not be the same as RX rings in combined mode. Signed-off-by:
-
Michael Chan authored
The new API HWRM_FUNC_RESOURCE_QCAPS provides min and max hardware resources. Use the new API when it is supported by firmware. Signed-off-by:
-
Michael Chan authored
In preparation for new firmware APIs to allocate hardware resources, add a new struct bnxt_hw_resc to hold various min, max and reserved resources. This new structure is common for PFs and VFs. Signed-off-by:
-
Michael Chan authored
After SRIOV has been enabled and disabled, the MSIX vectors assigned to the VFs have to be re-initialized. Otherwise they cannot be re-used by the PF. For example, increasing the number of PF rings after disabling SRIOV may fail if the PF uses MSIX vectors previously assigned to the VFs. To fix this, we add logic in bnxt_restore_pf_fw_resources() to close the NIC, clear and re-init MSIX, and re-open the NIC. Signed-off-by:
-
Michael Chan authored
Add a new __bnxt_close_nic() function to do all the work previously done in bnxt_close_nic() except waiting for SRIOV configuration. The new function will be used in the next patch as part of SRIOV cleanup. Signed-off-by:
-
Michael Chan authored
The version has new firmware APIs to allocate PF/VF resources more flexibly. New toolchains were used to generate this file, resulting in a one-time large diffstat. Signed-off-by:
-
David S. Miller authored
Martin Blumenstingl says: ==================== dwmac-meson8b: clock fixes for Meson8b this series is now successfully tested, thus we think it's ready to be applied to your net-next tree. Emiliano reported [0] that he couldn't get dwmac-meson8b to work on his Odroid-C1. This is the (hopefully) final version of this series, which was successfully tested. Due to the fact that the public S805/S905/S912 datasheets all seem to be outdated regarding the description of the PRG_ETH0 (also called PRG_ETHERNET_ADDR0) register Linus Lüssing offered to help testing with an oscilloscope and an Odroid-C1. I would like to say HUGE thanks to him at this point as he spent hours figuring out the effects of the bits that are (though to be) relevant to get Ethernet working on the Odroid-C1. We tested three scenarios, all based on version 3 of this series: 1) MPLL2 at ~500MHz, m250_div set to 1, bit 10 enabled this resulted in a clock rate twice as high as expected at the RGMII TX clock pin (250MHz instead of 125MHz for Gbit connections and 50MHz instead of 25MHz for 100Mbit/s connections). it did not change the rate at the XTAL_IN pin of PHY (which stayed consistenly at 25MHz) 2) MPLL2 at ~250MHz, m250_div set to 1, bit 10 disabled the oscilloscope shows "no clock" for the RGMII TX clock pin at it's highest resolution (and random rates at lower resolutions). XTAL_IN is still at 25MHz 3) MPLL2 at ~250MHz, m250_div set to 1, bit 10 enabled this resulted in a 125MHz signal at the RGMII TX clock pin for Gbit speeds and 25MHz for 100Mbit/s - both values are as expected. The rate on the XTAL_IN pin was at 25MHz -> boot-logs (with the PRG_ETH0 register value) and screenshots from the readings of the oscilloscope can be found at: https://metameute.de/~tux/linux/amlogic/odroidc1/ethernet/ Version 4 of this series is based on the results from Linus Lüssing's help with the oscilloscope and Odroid-C1. Unfortunately I don't have any Meson8b boards with RGMII PHY so I could only partially test this. @Emiliano: Could you please give this version a try and let me know about the results (preferably with a "Tested-by" if it works)? You obviously still need your two "ARM: dts: meson8b" patches which - add the amlogic,meson8b-dwmac" compatible to meson8b.dtsi - enable Ethernet on the Odroid-C1 (according to your last thest a TX delay of 4ns is required to make it work properly) When testing on Meson8b this also needs a fix for the MPLL clock driver: "clk: meson: mpll: use 64-bit maths in params_from_rate", see: https://patchwork.kernel.org/patch/10131677/ I have tested this myself on a Khadas VIM (GXL SoC, internal RMII PHY) and a Khadas VIM2 (GXM SoC, external RGMII PHY). Both are still working fine (so let's hope that this also fixes your Meson8b issue :)). changes since v4 at [4]: - dropped "RFT" status since Jerome tested this series successfully! - dropped PATCH #2 ("simplify generating the clock names"). I will improve the whole clock registration in a separate series. since that patch didn't really improve anything I dropped it for now - added Jerome's Acked-/Reviewed-/Tested-by's - many thanks! changes since v3 at [3]: - renamed the function PATCH #1 from meson8b_init_rgmii_clk to meson8b_init_rgmii_tx_clk since we now know what the register bits mean - rewrote PATCH #3 because bit 10 is a gate clock and it seems that there is an internal fixed divide-by-2 clock. see the patch description for a detailed explanation - updated the description of PATCH #4 and #5 as the clock we're trying to fix is the "RGMII TX" clock (old version stated that this is the "RGMII clock" or "PHY reference clock"). also updated the numbers in the description now that we have the clock hierarchy right (at least we hope so) changes since v2 at [2]: - added PATCH #2 to make the following patch easier - Emiliano reported that there's currently another bug in the dwmac-meson8b driver which prevents it from working with RGMII PHYs on Meson8b: bit 10 of the PRG_ETH0 register is configures a clock gate (instead of a divide by 5 or divide by 10 clock divider). This has not been visible on GXBB and later due to the input clock which always led to a selection of "divide by 10" (which is done internally in the IP block, but the bit actually means "enable RGMII clock output"). PATCH #3 was added to address this issue. - the commit message of PATCH #4 and #5 (formerly PATCH #2 and #3) were updated and the patch itself rebased because the m25_div clock was removed with the new PATCH #3 (so some of the statements were not valid anymore) changes since v1 at [1]: - changed the subject of the cover-letter to indicate that this is all about the RGMII clock - added PATCH #1 which ensures that we don't unnecessarily change the parent clocks in RMII mode (and also makes the code easier to understand) - changed subject of PATCH #2 (formerly PATCH #1) to state that this is about the RGMII clock - added Jerome's Reviewed-by to PATCH #2 (formerly PATCH #1) - replaced PATCH #3 (formerly PATCH #2) with one that sets CLK_SET_RATE_PARENT on the mux and thus re-configures the MPLL2 clock on Meson8b correctly [0] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005596.html [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005848.html [2] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005861.html [3] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005899.html [4] http://lists.infradead.org/pipermail/linux-amlogic/2018-January/006125.html ==================== Tested-by:
Emiliano Ingrassia <ingrassia@epigenesys.com> Signed-off-by:
-
Martin Blumenstingl authored
On Meson8b the only valid input clock is MPLL2. The bootloader configures that to run at 500002394Hz which cannot be divided evenly down to 125MHz using the m250_div clock. Currently the common clock framework chooses a m250_div of 2 - with the internal fixed "divide by 10" this results in a RGMII TX clock of 125001197Hz (120Hz above the requested 125MHz). Letting the common clock framework propagate the rate changes up to the parent of m250_mux allows us to get the best possible clock rate. With this patch the common clock framework calculates a rate of very-close-to-250MHz (249999701Hz to be exact) for the MPLL2 clock (which is the mux input). Dividing that by 2 (which is an internal, fixed divider for the RGMII TX clock) gives us an RGMII TX clock of 124999850Hz (which is only 150Hz off the requested 125MHz, compared to 1197Hz based on the MPLL2 rate set by u-boot and the Amlogic GPL kernel sources). SoCs from the Meson GX series are not affected by this change because the input clock is FCLK_DIV2 whose rate cannot be changed (which is fine since it's running at 1GHz, so it's already a multiple of 250MHz and 125MHz). Fixes: 566e8251 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC") Suggested-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by:
-
