- 21 Jun, 2023 29 commits
-
-
Petr Machata authored
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge, the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The selftest itself however checks whether skbedit changes packet priority as appropriate. The bridge thus does not need to participate in routing traffic and the IP address or the RIF are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridge in this selftest, thus exempting it from mlxsw router attention. Since the bridge is only used for L2 forwarding, this change should not hinder usefulness of this selftest for testing SW datapath or HW datapaths in other devices. Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Danielle Ratson <danieller@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Petr Machata authored
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge, the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The selftest itself however checks operation of pedit on IPv4 and IPv6 dsfield and its parts. The bridge thus does not need to participate in routing traffic and the IP address or the RIF are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridge in this selftest, thus exempting it from mlxsw router attention. Since the bridge is only used for L2 forwarding, this change should not hinder usefulness of this selftest for testing SW datapath or HW datapaths in other devices. Signed-off-by:
-
Petr Machata authored
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. This will cause this selftest to fail spuriously. The swp enslavement to the 802.1ad bridge is not allowed, because RIFs are not allowed to be created for 802.1ad bridges, but the address indicates one needs to be created. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridge in this selftest, thus exempting it from mlxsw router attention. Signed-off-by:
Amit Cohen <amcohen@nvidia.com> Signed-off-by:
-
Petr Machata authored
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. This will cause this selftest to fail spuriously. The swp enslavement to the 802.1ad bridge is not allowed, because RIFs are not allowed to be created for 802.1ad bridges, but the address indicates one needs to be created. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridge in this selftest, thus exempting it from mlxsw router attention. Signed-off-by:
-
Horatiu Vultur authored
Currently for each timestamp frame, the SW needs to go and read the received timestamp over the MDIO bus. But the HW has the capability to store the received nanoseconds part and the least significant two bits of the seconds in the reserved field of the PTP header. In this way we could save few MDIO transactions (actually a little more transactions because the access to the PTP registers are indirect) for each received frame. Instead of reading the rest of seconds part of the timestamp of the frame using MDIO transactions schedule PTP worker thread to read the seconds part every 500ms and then for each of the received frames use this information. Because if for example running with 512 frames per second, there is no point to read 512 times the second part. Doing all these changes will give a great CPU usage performance. Running ptp4l with logSyncInterval of -9 will give a ~60% CPU improvement. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Bartosz Golaszewski says: ==================== net: stmmac: dwmac-qcom-ethqos: add support for EMAC4 Extend the dwmac-qcom-ethqos driver to support EMAC4. While at it: rework the code somewhat. The bindings have been reviewed by DT maintainers. This is a sub-series of [1] with only the patches targetting the net subsystem as they can go in independently. [1] https://lore.kernel.org/lkml/20230617001644.4e093326@kernel.org/T/ ==================== Link: https://lore.kernel.org/r/20230619092402.195578-1-brgl@bgdev.plSigned-off-by:
-
Bartosz Golaszewski authored
sa8775p uses EMAC version 4, add the relevant defines, rename the has_emac3 switch to has_emac_ge_3 (has emac greater-or-equal than 3) and add the new compatible. Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by:
-
Bartosz Golaszewski authored
Add the compatible for the MAC controller on sa8775p platforms. This MAC works with a single interrupt so add minItems to the interrupts property. The fourth clock's name is different here so change it. Enable relevant PHY properties. Add the relevant compatibles to the binding document for snps,dwmac as well. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Bartosz Golaszewski authored
On some platforms, the PCS can be integrated in the MAC so the driver will not see any PCS link activity. Add a switch that allows the platform drivers to let the core code know. Signed-off-by:
Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by:
-
Bartosz Golaszewski authored
On sa8775p the MAC is connected to the external PHY over SGMII so add support for it to the driver. Signed-off-by:
-
Bartosz Golaszewski authored
In preparation for supporting SGMII, let's make the code a bit more generic. Add a new callback for MAC configuration so that we can assign a different variant of it in the future. Signed-off-by:
Andrew Halaney <ahalaney@redhat.com> Signed-off-by:
-
Bartosz Golaszewski authored
On sa8775p, the EMAC revision is 4 and we use SGMII instead of RGMII. There's no "rgmii" clock but there's a fourth clock under a different name: "phyaux". Add a new field to the chip data struct that specifies the link clock name. Default to "rgmii" for backward compatibility. Signed-off-by:
-
Bartosz Golaszewski authored
On sa8775p platforms, there's a SGMII SerDes PHY between the MAC and external PHY that we need to enable and configure. Signed-off-by:
-
Bartosz Golaszewski authored
There's an unnecessary space in the rgmii_updatel() function, remove it. Signed-off-by:
-
Bartosz Golaszewski authored
Typically we use a newline between global and local headers so add it here as well. Signed-off-by:
-
Bartosz Golaszewski authored
device_get_phy_mode() is declared in linux/property.h but this header is not included. Signed-off-by:
-
Bartosz Golaszewski authored
Shrink code and avoid line breaks by using a helper variable for &pdev->dev. Signed-off-by:
-
Bartosz Golaszewski authored
Make sure we follow the reverse-xmas tree convention. Signed-off-by:
-
Bartosz Golaszewski authored
The err_mem label's name is unclear. It actually should be reached on any error after stmmac_probe_config_dt() succeeds. Name it after the cleanup action that needs to be called before exiting. Signed-off-by:
-
Bartosz Golaszewski authored
We can use a devm action to completely drop the remove callback and use stmmac_pltfr_remove() directly for remove. We can also drop one of the goto labels. Signed-off-by:
-
Arnd Bergmann authored
The new efx_bind_neigh() function contains a broken code path when IPV6 is disabled: drivers/net/ethernet/sfc/tc_encap_actions.c:144:7: error: variable 'n' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] if (encap->type & EFX_ENCAP_FLAG_IPV6) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/sfc/tc_encap_actions.c:184:8: note: uninitialized use occurs here if (!n) { ^ drivers/net/ethernet/sfc/tc_encap_actions.c:144:3: note: remove the 'if' if its condition is always false if (encap->type & EFX_ENCAP_FLAG_IPV6) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/sfc/tc_encap_actions.c:141:22: note: initialize the variable 'n' to silence this warning struct neighbour *n; ^ = NULL Change it to use the existing error handling path here. Fixes: 7e5e7d80 ("sfc: neighbour lookup for TC encap action offload") Suggested-by:Edward Cree <ecree.xilinx@gmail.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Arnd Bergmann authored
The driver now fails to link when CONFIG_INET is disabled, so add an explicit Kconfig dependency: ld.lld: error: undefined symbol: ip_route_output_flow >>> referenced by tc_encap_actions.c >>> drivers/net/ethernet/sfc/tc_encap_actions.o:(efx_tc_flower_create_encap_md) in archive vmlinux.a ld.lld: error: undefined symbol: ip_send_check >>> referenced by tc_encap_actions.c >>> drivers/net/ethernet/sfc/tc_encap_actions.o:(efx_gen_encap_header) in archive vmlinux.a >>> referenced by tc_encap_actions.c >>> drivers/net/ethernet/sfc/tc_encap_actions.o:(efx_gen_encap_header) in archive vmlinux.a ld.lld: error: undefined symbol: arp_tbl >>> referenced by tc_encap_actions.c >>> drivers/net/ethernet/sfc/tc_encap_actions.o:(efx_tc_netevent_event) in archive vmlinux.a >>> referenced by tc_encap_actions.c >>> drivers/net/ethernet/sfc/tc_encap_actions.o:(efx_tc_netevent_event) in archive vmlinux.a Fixes: a1e82162 ("sfc: generate encap headers for TC offload") Reviewed-by:
Simon Horman <simon.horman@corigine.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306151656.yttECVTP-lkp@intel.com/Signed-off-by:
-
Andrew Lunn authored
The text has been cut/paste from genphy_c45_ethtool_get_eee but not changed to reflect it performs set. Additionally, extend the comment. This function implements the logic that eee_enabled has global control over EEE. When eee_enabled is false, no link modes will be advertised, and as a result, the MAC should not transmit LPI. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230619220332.4038924-1-andrew@lunn.chSigned-off-by:
-
Eric Dumazet authored
Blamed commit added these helpers for sake of detecting RAW sockets specific ioctl. syzbot complained about it [1]. Issue here is that RAW sockets could pretend there was no need to call ipmr_sk_ioctl() Regardless of inet_sk(sk)->inet_num, we must be prepared for ipmr_ioctl() being called later. This must happen from ipmr_sk_ioctl() context only. We could add a safety check in ipmr_ioctl() at the risk of breaking applications. Instead, remove sk_is_ipmr() and sk_is_icmpv6() because their name would be misleading, once we change their implementation. [1] BUG: KASAN: stack-out-of-bounds in ipmr_ioctl+0xb12/0xbd0 net/ipv4/ipmr.c:1654 Read of size 4 at addr ffffc90003aefae4 by task syz-executor105/5004 CPU: 0 PID: 5004 Comm: syz-executor105 Not tainted 6.4.0-rc6-syzkaller-01304-gc08afcdc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 ipmr_ioctl+0xb12/0xbd0 net/ipv4/ipmr.c:1654 raw_ioctl+0x4e/0x1e0 net/ipv4/raw.c:881 sock_ioctl_out net/core/sock.c:4186 [inline] sk_ioctl+0x151/0x440 net/core/sock.c:4214 inet_ioctl+0x18c/0x380 net/ipv4/af_inet.c:1001 sock_do_ioctl+0xcc/0x230 net/socket.c:1189 sock_ioctl+0x1f8/0x680 net/socket.c:1306 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f2944bf6ad9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd8897a028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2944bf6ad9 RDX: 0000000000000000 RSI: 00000000000089e1 RDI: 0000000000000003 RBP: 00007f2944bbac80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2944bbad10 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> The buggy address belongs to stack of task syz-executor105/5004 and is located at offset 36 in frame: sk_ioctl+0x0/0x440 net/core/sock.c:4172 This frame has 2 objects: [32, 36) 'karg' [48, 88) 'buffer' Fixes: e1d001fa ("net: ioctl: Use kernel memory on protocol ioctl callbacks") Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Breno Leitao <leitao@debian.org> Cc: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Reviewed-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20230619124336.651528-1-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
SIOCGETSGCNT_IN6 uses a "struct sioc_sg_req6 buffer". Unfortunately the blamed commit made hard to ensure type safety. syzbot reported: BUG: KASAN: stack-out-of-bounds in ip6mr_ioctl+0xba3/0xcb0 net/ipv6/ip6mr.c:1917 Read of size 16 at addr ffffc900039afb68 by task syz-executor937/5008 CPU: 1 PID: 5008 Comm: syz-executor937 Not tainted 6.4.0-rc6-syzkaller-01304-gc08afcdc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 ip6mr_ioctl+0xba3/0xcb0 net/ipv6/ip6mr.c:1917 rawv6_ioctl+0x4e/0x1e0 net/ipv6/raw.c:1143 sock_ioctl_out net/core/sock.c:4186 [inline] sk_ioctl+0x151/0x440 net/core/sock.c:4214 inet6_ioctl+0x1b8/0x290 net/ipv6/af_inet6.c:582 sock_do_ioctl+0xcc/0x230 net/socket.c:1189 sock_ioctl+0x1f8/0x680 net/socket.c:1306 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f255849bad9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd06792778 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f255849bad9 RDX: 0000000000000000 RSI: 00000000000089e1 RDI: 0000000000000003 RBP: 00007f255845fc80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f255845fd10 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> The buggy address belongs to stack of task syz-executor937/5008 and is located at offset 40 in frame: sk_ioctl+0x0/0x440 net/core/sock.c:4172 This frame has 2 objects: [32, 36) 'karg' [48, 88) 'buffer' Fixes: e1d001fa ("net: ioctl: Use kernel memory on protocol ioctl callbacks") Reported-by:
Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/20230619072740.464528-1-edumazet@google.comSigned-off-by:
-
Ratheesh Kannoth authored
TC rule support to offload rx queue mapping rules. Eg: tc filter add dev eth2 ingress protocol ip flower \ dst_ip 192.168.8.100 \ action skbedit queue_mapping 4 skip_sw action mirred ingress redirect dev eth5 Packets destined to 192.168.8.100 will be forwarded to rx queue 4 of eth5 interface. tc filter add dev eth2 ingress protocol ip flower \ dst_ip 192.168.8.100 \ action skbedit queue_mapping 9 skip_sw Packets destined to 192.168.8.100 will be forwarded to rx queue 4 of eth2 interface. Signed-off-by:Ratheesh Kannoth <rkannoth@marvell.com> Link: https://lore.kernel.org/r/20230619060638.1032304-1-rkannoth@marvell.comSigned-off-by:
-
Christophe JAILLET authored
Group some variables based on their sizes to reduce hole and avoid padding. On x86_64, this shrinks the size of 'struct netlbl_domaddr6_map' from 72 to 64 bytes. It saves a few bytes of memory and is more cache-line friendly. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Paul Moore <paul@paul-moore.com> Link: https://lore.kernel.org/r/aa109847260e51e174c823b6d1441f75be370f01.1687083361.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Christophe JAILLET authored
Group some variables based on their sizes to reduce hole and avoid padding. On x86_64, this shrinks the size of 'struct mptcp_pm_add_entry' from 136 to 128 bytes. It saves a few bytes of memory and is more cache-line friendly. Signed-off-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Reviewed-by:
-
Christophe JAILLET authored
Group some variables based on their sizes to reduce hole and avoid padding. On x86_64, this shrinks the size of 'struct mctp_route' from 72 to 64 bytes. It saves a few bytes of memory and is more cache-line friendly. Signed-off-by:
Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by:
-
- 20 Jun, 2023 11 commits
-
-
Lucas Stach authored
Commit 6970ef27 ("net: fec: add xdp and page pool statistics") selected CONFIG_PAGE_POOL_STATS from the FEC driver symbol, making it impossible to build without the page pool statistics when this driver is enabled. The help text of those statistics mentions increased overhead. Allow the user to choose between usefulness of the statistics and the added overhead. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
-
David Howells authored
If an AF_ALG socket bound to a hashing algorithm is sent a zero-length message with MSG_MORE set and then recvmsg() is called without first sending another message without MSG_MORE set to end the operation, an oops will occur because the crypto context and result doesn't now get set up in advance because hash_sendmsg() now defers that as long as possible in the hope that it can use crypto_ahash_digest() - and then because the message is zero-length, it the data wrangling loop is skipped. Fix this by handling zero-length sends at the top of the hash_sendmsg() function. If we're not continuing the previous sendmsg(), then just ignore the send (hash_recvmsg() will invent something when called); if we are continuing, then we finalise the request at this point if MSG_MORE is not set to get any error here, otherwise the send is of no effect and can be ignored. Whilst we're at it, remove the code to create a kvmalloc'd scatterlist if we get more than ALG_MAX_PAGES - this shouldn't happen. Fixes: c662b043 ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES") Reported-by: syzbot+13a08c0bf4d212766c3c@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/000000000000b928f705fdeb873a@google.com/ Reported-by: syzbot+14234ccf6d0ef629ec1a@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/000000000000c047db05fdeb8790@google.com/ Reported-by: syzbot+4e2e47f32607d0f72d43@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/000000000000bcca3205fdeb87fb@google.com/ Reported-by: syzbot+472626bb5e7c59fb768f@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/000000000000b55d8805fdeb8385@google.com/Signed-off-by:
David Howells <dhowells@redhat.com> Reported-and-tested-by: syzbot+6efc50cc1f8d718d6cb7@syzkaller.appspotmail.com cc: Jens Axboe <axboe@kernel.dk> cc: Matthew Wilcox <willy@infradead.org> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Link: https://lore.kernel.org/r/427646.1686913832@warthog.procyon.org.ukSigned-off-by:
-
Arnd Bergmann authored
The new phy driver attempts to select a driver from another subsystem, but that fails when the NVMEM subsystem is disabled: WARNING: unmet direct dependencies detected for NVMEM_MTK_EFUSE Depends on [n]: NVMEM [=n] && (ARCH_MEDIATEK [=n] || COMPILE_TEST [=y]) && HAS_IOMEM [=y] Selected by [y]: - MEDIATEK_GE_SOC_PHY [=y] && NETDEVICES [=y] && PHYLIB [=y] && (ARM64 && ARCH_MEDIATEK [=n] || COMPILE_TEST [=y]) I could not see an actual compile time dependency, so presumably this is only needed for for working correctly but not technically a dependency on that particular nvmem driver implementation, so it would likely be safe to remove the select for compile testing. To keep the spirit of the original 'select', just replace this with a 'depends on' that ensures that the driver will work but does not get in the way of build testing. Fixes: 98c485ea ("net: phy: add driver for MediaTek SoC built-in GE PHYs") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Reviewed-by:
Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/20230616093009.3511692-1-arnd@kernel.orgSigned-off-by:
-
David S. Miller authored
Rahul Rameshbabu says: ==================== ptp .adjphase cleanups The goal of this patch series is to improve documentation of .adjphase, add a new callback .getmaxphase to enable advertising the max phase offset a device PHC can support, and support invoking .adjphase from the testptp kselftest. Changes: v2->v1: * Removes arbitrary rule that the PHC servo must restore the frequency to the value used in the last .adjfine call if any other PHC operation is used after a .adjphase operation. * Removes a macro introduced in v1 for adding PTP sysfs device attribute nodes using a callback for populating the data. Link: https://lore.kernel.org/netdev/20230120160609.19160723@kernel.org/ Link: https://lore.kernel.org/netdev/20230510205306.136766-1-rrameshbabu@nvidia.com/ ==================== Signed-off-by: -
Rahul Rameshbabu authored
Add a function that advertises a maximum offset of zero supported by ptp_clock_info .adjphase in the OCP null ptp implementation. Cc: Richard Cochran <richardcochran@gmail.com> Cc: Jonathan Lemon <jonathan.lemon@gmail.com> Cc: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by:
Rahul Rameshbabu <rrameshbabu@nvidia.com> Acked-by:
Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by:
-
Rahul Rameshbabu authored
Advertise the maximum offset the .adjphase callback is capable of supporting in nanoseconds for IDT devices. Refactor the negation of the offset stored in the register to be after the boundary check of the offset value rather than before. Boundary check based on the intended value rather than its device-specific representation. Depend on ptp_clock_adjtime for handling out-of-range offsets. ptp_clock_adjtime returns -ERANGE instead of clamping out-of-range offsets. Cc: Richard Cochran <richardcochran@gmail.com> Cc: Min Li <min.li.xe@renesas.com> Signed-off-by:
-
Rahul Rameshbabu authored
Advertise the maximum offset the .adjphase callback is capable of supporting in nanoseconds for IDT ClockMatrix devices. Depend on ptp_clock_adjtime for handling out-of-range offsets. ptp_clock_adjtime returns -ERANGE instead of clamping out-of-range offsets. Cc: Richard Cochran <richardcochran@gmail.com> Cc: Vincent Cheng <vincent.cheng.xh@renesas.com> Signed-off-by:
-
Rahul Rameshbabu authored
Implement .getmaxphase callback of ptp_clock_info in mlx5 driver. No longer do a range check in .adjphase callback implementation. Handled by the ptp stack. Cc: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
-
Rahul Rameshbabu authored
Enables advertisement of the maximum offset supported by the phase control functionality of PHCs. The callback is used to return an error if an offset not supported by the PHC is used in ADJ_OFFSET. The ioctls PTP_CLOCK_GETCAPS and PTP_CLOCK_GETCAPS2 now advertise the maximum offset a PHC's phase control functionality is capable of supporting. Introduce new sysfs node, max_phase_adjustment. Cc: Jakub Kicinski <kuba@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Maciek Machnikowski <maciek@machnikowski.net> Signed-off-by:
-
Rahul Rameshbabu authored
Invoke clock_adjtime syscall with tx.modes set with ADJ_OFFSET when testptp is invoked with a phase adjustment offset value. Support seconds and nanoseconds for the offset value. Cc: Jakub Kicinski <kuba@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Maciek Machnikowski <maciek@machnikowski.net> Signed-off-by:
-
Rahul Rameshbabu authored
Use existing NSEC_PER_SEC declaration in place of hardcoded magic numbers. Cc: Jakub Kicinski <kuba@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Maciek Machnikowski <maciek@machnikowski.net> Signed-off-by:
-
