- 18 Jan, 2023 28 commits
-
-
David S. Miller authored
Siddharth Vadapalli says: ==================== Add PPS support to am65-cpts driver The CPTS hardware doesn't support PPS signal generation. Using the GenFx (periodic signal generator) function, it is possible to model a PPS signal followed by routing it via the time sync router to the CPTS_HWy_TS_PUSH (hardware time stamp) input, in order to generate timestamps at 1 second intervals. This series adds driver support for enabling PPS signal generation. Additionally, the documentation for the am65-cpts driver is updated with the bindings for the "ti,pps" property, which is used to inform the pair [CPTS_HWy_TS_PUSH, GenFx] to the cpts driver. Changes from v1: 1. Drop device-tree patches. 2. Address Roger's comments on the: "net: ethernet: ti: am65-cpts: add pps support" patch. 3. Collect Reviewed-by tag from Rob Herring. v1: https://lore.kernel.org/r/20230111114429.1297557-1-s-vadapalli@ti.com/ ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Grygorii Strashko authored
When CPTS clock is sync/adjusted by running linuxptp (ptp4l) it will cause PPS jitter as Genf running PPS is not adjusted. The same PPM adjustment has to be applied to GenF as to PHC clock to correct PPS length and keep them in sync. Testing: Master: ptp4l -P -2 -H -i eth0 -l 6 -m -q -p /dev/ptp1 -f ptp.cfg & testptp -d /dev/ptp1 -P 1 ppstest /dev/pps0 Slave: linuxptp/ptp4l -P -2 -H -i eth0 -l 6 -m -q -p /dev/ptp1 -f ptp1.cfg -s & <port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED;> testptp -d /dev/ptp1 -P 1 ppstest /dev/pps0 Master log: source 0 - assert 620.000000689, sequence: 530 source 0 - assert 621.000000689, sequence: 531 source 0 - assert 622.000000689, sequence: 532 source 0 - assert 623.000000689, sequence: 533 source 0 - assert 624.000000689, sequence: 534 source 0 - assert 625.000000689, sequence: 535 source 0 - assert 626.000000689, sequence: 536 source 0 - assert 627.000000689, sequence: 537 source 0 - assert 628.000000689, sequence: 538 source 0 - assert 629.000000689, sequence: 539 source 0 - assert 630.000000689, sequence: 540 source 0 - assert 631.000000689, sequence: 541 source 0 - assert 632.000000689, sequence: 542 source 0 - assert 633.000000689, sequence: 543 source 0 - assert 634.000000689, sequence: 544 source 0 - assert 635.000000689, sequence: 545 Slave log: source 0 - assert 620.000000706, sequence: 252 source 0 - assert 621.000000709, sequence: 253 source 0 - assert 622.000000707, sequence: 254 source 0 - assert 623.000000707, sequence: 255 source 0 - assert 624.000000706, sequence: 256 source 0 - assert 625.000000705, sequence: 257 source 0 - assert 626.000000709, sequence: 258 source 0 - assert 627.000000709, sequence: 259 source 0 - assert 628.000000707, sequence: 260 source 0 - assert 629.000000706, sequence: 261 source 0 - assert 630.000000710, sequence: 262 source 0 - assert 631.000000708, sequence: 263 source 0 - assert 632.000000705, sequence: 264 source 0 - assert 633.000000710, sequence: 265 source 0 - assert 634.000000708, sequence: 266 source 0 - assert 635.000000707, sequence: 267 Signed-off-by:Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by:
Roger Quadros <rogerq@kernel.org> Signed-off-by:
-
Grygorii Strashko authored
CPTS doesn't have HW support for PPS ("pulse per second”) signal generation, but it can be modeled by using Time Sync Router and routing GenFx (periodic signal generator) output to CPTS_HWy_TS_PUSH (hardware time stamp) input, and configuring GenFx to generate 1sec pulses. +------------------------+ | CPTS | | | +--->CPTS_HW4_PUSH GENFx+---+ | | | | | +------------------------+ | | | +--------------------------------+ Add corresponding support to am65-cpts driver. The DT property "ti,pps" has to be used to enable PPS support and configure pair [CPTS_HWy_TS_PUSH, GenFx]. Once enabled, PPS can be tested using ppstest tool: # ./ppstest /dev/pps0 Signed-off-by: -
Grygorii Strashko authored
Add the ti,pps property used to indicate the pair of HWx_TS_PUSH input and the TS_GENFy output. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
David S. Miller authored
Clark Wang says: ==================== stmmac: Add eqos and fec support for imx93 This patchset add imx93 support for dwmac-imx glue driver. There are some changes of GPR implement. And add fec and eqos nodes for imx93 dts. ==================== Signed-off-by: -
Clark Wang authored
Enable FEC function for imx93-11x11-evk board. Signed-off-by:
Clark Wang <xiaoning.wang@nxp.com> Reviewed-by:
Peng Fan <peng.fan@nxp.com> Signed-off-by:
-
Clark Wang authored
Enable EQoS function for imx93-11x11-evk board. Signed-off-by:
-
Clark Wang authored
Add FEC node for imx93 platform. Signed-off-by:
-
Clark Wang authored
Add EQoS node for imx93 platform. Signed-off-by:
-
Clark Wang authored
Add mx93 compatible string for fec driver. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Clark Wang authored
Add mx93 compatible string for eqos driver. Signed-off-by:
-
Clark Wang authored
Add imx93 platform support for dwmac-imx driver. Signed-off-by:
-
Jakub Kicinski authored
Michael Walle says: ==================== net: mdio: Continue separating C22 and C45 I've picked this older series from Andrew up and rebased it onto the latest net-next. This is the third (and hopefully last) patch set in the series which separates the C22 and C45 MDIO bus transactions at the API level to the MDIO bus drivers. The first patch is a newer version of the former "net: dsa: Separate C22 and C45 MDIO bus transaction methods", which only contains the mt7530 changes. Although posted as v1, because this is a new series, there is a changelog included in the patch comment section. The last patch is a new one, which isn't from Andrew's tree. ==================== Link: https://lore.kernel.org/r/20230116-net-next-c45-seperation-part-3-v1-0-0c53afa56aad@walle.ccSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Michael Walle authored
The rswitch MDIO bus driver only supports C45 transfers. Update the function names to make this clear, pass the mmd as a parameter, and register the accessors to the _c45 ops of the bus driver structure. Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
-
Andrew Lunn authored
The T1 MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Andrew Lunn authored
The sja1105 MDIO bus driver only supports C45 transfers. Update the function names to make this clear, pass the mmd as a parameter, and register the accessors to the _c45 ops of the bus driver structure. Signed-off-by:
-
Andrew Lunn authored
The xgbe driver reuses MII_ADDR_C45 for its own purpose. The values derived with it are never passed to phylib or a linux MDIO bus driver. In order that MII_ADDR_C45 can be removed, add an XGBE specific Signed-off-by:
-
Andrew Lunn authored
The xgbe MDIO bus driver can perform both C22 and C45 transfers, when using its MDIO bus hardware. The SFP I2C mdio bus driver only supports C22. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
-
Andrew Lunn authored
The hns MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
-
Andrew Lunn authored
When performing a C45 bus transaction, make use of the c45 variants of the bus read/write helpers. The ability to pass a special register value is being removed to clean up the mdio bus driver API. Signed-off-by:
-
Andrew Lunn authored
The ixgbe MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
-
Andrew Lunn authored
The macb MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
-
Andrew Lunn authored
The nixge MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
-
Andrew Lunn authored
The sxgdb MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
-
Andrew Lunn authored
mt7530 does support C45, but its uses a mix of registering its MDIO bus and providing its private MDIO bus to the DSA core, too. This makes the change a bit more complex. Signed-off-by:
-
Mengyuan Lou authored
Convert various mult-bit fields to be defined using GENMASK/FIELD_PREP. Simplify the code with the ternary operator. Signed-off-by:
Mengyuan Lou <mengyuanlou@net-swift.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230116103839.84087-1-mengyuanlou@net-swift.comSigned-off-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxJakub Kicinski authored
Wolfram Sang says: ==================== Immutable branch adding fwnode API to the I2C core I2C changes requested by Russell King. This allows him to rework SFP code further. * tag 'i2c-fwnode-api-2023017' of https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: add fwnode APIs ==================== Link: https://lore.kernel.org/r/Y8ZhI4g0wsvpjokd@ninjato/Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'regmap-mdio-c45-rework' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Mark Brown says: ==================== regmap: Rework regmap_mdio_c45_{read|write} for new C45 API. This reworks the regmap MDIO handling of C45 addresses in preparation for some forthcoming updates to the networking code. * tag 'regmap-mdio-c45-rework' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: Rework regmap_mdio_c45_{read|write} for new C45 API. ==================== Link: https://lore.kernel.org/r/Y8VjkgcWHjR9TzNw@sirena.org.ukSigned-off-by:
-
- 17 Jan, 2023 12 commits
-
-
Andrew Lunn authored
The recent refactoring to split C22 and C45 introduced two unneeded semiconons which the kernel test bot reported. Remove them. Reported-by:
kernel test robot <lkp@intel.com> Fixes: 93641ecb ("net: mdio: cavium: Separate C22 and C45 transactions") Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Pietro Borrello authored
__inet_hash_connect() has a fast path taken if sk_head(&tb->owners) is equal to the sk parameter. sk_head() returns the hlist_entry() with respect to the sk_node field. However entries in the tb->owners list are inserted with respect to the sk_bind_node field with sk_add_bind_node(). Thus the check would never pass and the fast path never execute. This fast path has never been executed or tested as this bug seems to be present since commit 1da177e4 ("Linux-2.6.12-rc2"), thus remove it to reduce code complexity. Signed-off-by:
Pietro Borrello <borrello@diag.uniroma1.it> Reviewed-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20230112-inet_hash_connect_bind_head-v3-1-b591fd212b93@diag.uniroma1.itSigned-off-by:
-
Paolo Abeni authored
Lorenzo Bianconi says: ==================== net: ethernet: mtk_wed: introduce reset support Introduce proper reset integration between ethernet and wlan drivers in order to schedule wlan driver reset when ethernet/wed driver is resetting. Introduce mtk_hw_reset_monitor work in order to detect possible DMA hangs. ==================== Link: https://lore.kernel.org/r/cover.1673715298.git.lorenzo@kernel.orgSigned-off-by:
-
Lorenzo Bianconi authored
Introduce reset and reset_complete wlan callback to schedule WLAN driver reset when ethernet/wed driver is resetting. Tested-by:
Daniel Golle <daniel@makrotopia.org> Co-developed-by:
Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
Lorenzo Bianconi authored
Introduce mtk_hw_check_dma_hang routine to monitor possible dma hangs. Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Tested-by:
-
Lorenzo Bianconi authored
Avoid to power-down the ethernet chip during hw reset and align reset procedure to vendor sdk. Reviewed-by:
-
Lorenzo Bianconi authored
Introduce mtk_hw_warm_reset utility routine. This is a preliminary patch to align reset procedure to vendor sdk and avoid to power down the chip during hw reset. Reviewed-by:
-
Lorenzo Bianconi authored
This is a preliminary patch to add Wireless Ethernet Dispatcher reset support. Reviewed-by:
-
Paolo Abeni authored
Jesper Dangaard Brouer says: ==================== net: use kmem_cache_free_bulk in kfree_skb_list The kfree_skb_list function walks SKB (via skb->next) and frees them individually to the SLUB/SLAB allocator (kmem_cache). It is more efficient to bulk free them via the kmem_cache_free_bulk API. Netstack NAPI fastpath already uses kmem_cache bulk alloc and free APIs for SKBs. The kfree_skb_list call got an interesting optimization in commit 520ac30f ("net_sched: drop packets after root qdisc lock is released") that can create a list of SKBs "to_free" e.g. when qdisc enqueue fails or deliberately chooses to drop . It isn't a normal data fastpath, but the situation will likely occur when system/qdisc are under heavy workloads, thus it makes sense to use a faster API for freeing the SKBs. E.g. the (often distro default) qdisc fq_codel will drop batches of packets from fattest elephant flow, default capped at 64 packets (but adjustable via tc argument drop_batch). Performance measurements done in [1]: [1] https://github.com/xdp-project/xdp-project/blob/master/areas/mem/kfree_skb_list01.org ==================== Link: https://lore.kernel.org/r/167361788585.531803.686364041841425360.stgit@firesoulSigned-off-by:
-
Jesper Dangaard Brouer authored
The kfree_skb_list function walks SKB (via skb->next) and frees them individually to the SLUB/SLAB allocator (kmem_cache). It is more efficient to bulk free them via the kmem_cache_free_bulk API. This patches create a stack local array with SKBs to bulk free while walking the list. Bulk array size is limited to 16 SKBs to trade off stack usage and efficiency. The SLUB kmem_cache "skbuff_head_cache" uses objsize 256 bytes usually in an order-1 page 8192 bytes that is 32 objects per slab (can vary on archs and due to SLUB sharing). Thus, for SLUB the optimal bulk free case is 32 objects belonging to same slab, but runtime this isn't likely to occur. The expected gain from using kmem_cache bulk alloc and free API have been assessed via a microbencmark kernel module[1]. The module 'slab_bulk_test01' results at bulk 16 element: kmem-in-loop Per elem: 109 cycles(tsc) 30.532 ns (step:16) kmem-bulk Per elem: 64 cycles(tsc) 17.905 ns (step:16) More detailed description of benchmarks avail in [2]. [1] https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/mm [2] https://github.com/xdp-project/xdp-project/blob/master/areas/mem/kfree_skb_list01.org V2: rename function to kfree_skb_add_bulk. Reviewed-by:
Saeed Mahameed <saeed@kernel.org> Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
Jesper Dangaard Brouer authored
The SKB drop reason uses __builtin_return_address(0) to give the call "location" to trace_kfree_skb() tracepoint skb:kfree_skb. To keep this stable for compilers kfree_skb_reason() is annotated with __fix_address (noinline __noclone) as fixed in commit c205cc75 ("net: skb: prevent the split of kfree_skb_reason() by gcc"). The function kfree_skb_list_reason() invoke kfree_skb_reason(), which cause the __builtin_return_address(0) "location" to report the unexpected address of kfree_skb_list_reason. Example output from 'perf script': kpktgend_0 1337 [000] 81.002597: skb:kfree_skb: skbaddr=0xffff888144824700 protocol=2048 location=kfree_skb_list_reason+0x1e reason: QDISC_DROP Patch creates an __always_inline __kfree_skb_reason() helper call that is called from both kfree_skb_list() and kfree_skb_list_reason(). Suggestions for solutions that shares code better are welcome. As preparation for next patch move __kfree_skb() invocation out of this helper function. Reviewed-by:
-
Dan Carpenter authored
This code checks if (attrs[DEVLINK_ATTR_TRAP_POLICER_ID]) twice. Once at the start of the function and then a couple lines later. Delete the second check since that one must be true. Because the second condition is always true, it means the: policer_item = group_item->policer_item; assignment is immediately over-written. Delete that as well. Signed-off-by:
Dan Carpenter <error27@gmail.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Acked-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/Y8EJz8oxpMhfiPUb@kiliSigned-off-by:
-
