- 26 May, 2023 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/lee/ledsJakub Kicinski authored
Lee Jones says: ==================== Immutable branch between LEDs and netdev due for the v6.5 merge window Andrew Lunn says: Christian Marangi and I will be continuing the work of offloading LED blinking to Ethernet MAC and PHY LED controllers. The next set of patches is again cross subsystem, LEDs and netdev. It also requires some patches you have in for-leds-next: a286befc24e8 leds: trigger: netdev: Use mutex instead of spinlocks 509412749002 leds: trigger: netdev: Convert device attr to macro 0fd93ac85826 leds: trigger: netdev: Rename add namespace to netdev trigger enum modes eb31ca4531a0 leds: trigger: netdev: Drop NETDEV_LED_MODE_LINKUP from mode 3fc498cf54b4 leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev rename I'm assuming the new series will get nerged via netdev, with your Acked-by. Could you create a stable branch with these patches which can be pulled into netdev? * tag 'ib-leds-netdev-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: leds: trigger: netdev: Use mutex instead of spinlocks leds: trigger: netdev: Convert device attr to macro leds: trigger: netdev: Rename add namespace to netdev trigger enum modes leds: trigger: netdev: Drop NETDEV_LED_MODE_LINKUP from mode leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev rename ==================== Link: https://lore.kernel.org/r/20230525111521.GA411262@google.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
Cross-merge networking fixes after downstream PR. Conflicts: net/ipv4/raw.c 3632679d ("ipv{4,6}/raw: fix output xfrm lookup wrt protocol") c85be08f ("raw: Stop using RTO_ONLINK.") https://lore.kernel.org/all/20230525110037.2b532b83@canb.auug.org.au/ Adjacent changes: drivers/net/ethernet/freescale/fec_main.c 9025944f ("net: fec: add dma_wmb to ensure correct descriptor values") 144470c8 ("net: fec: using the standard return codes when xdp xmit errors") Signed-off-by:
-
- 25 May, 2023 26 commits
-
-
Niklas Schnelle authored
A future change will convert the DMA API implementation from the architecture specific arch/s390/pci/pci_dma.c to using the common code drivers/iommu/dma-iommu.c which the utilizes the same IOMMU hardware through the s390-iommu driver. Unlike the s390 specific DMA API this requires devices to correctly set the coherent mask to be allowed to use IOVAs >2^32 in dma_alloc_coherent(). This was however not done for ISM devices. ISM requires such addresses since currently the DMA aperture for PCI devices starts at 2^32 and all calls to dma_alloc_coherent() would thus fail. Link: https://lore.kernel.org/all/20230310-dma_iommu-v9-1-65bb8edd2beb@linux.ibm.com/Reviewed-by:
Alexandra Winter <wintera@linux.ibm.com> Reviewed-by:
Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by:
Pierre Morel <pmorel@linux.ibm.com> Signed-off-by:
Niklas Schnelle <schnelle@linux.ibm.com> Link: https://lore.kernel.org/r/20230524075411.3734141-1-schnelle@linux.ibm.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Christophe JAILLET authored
Use bitmap_weight_and() instead of hand writing it. This saves a few LoC and is slightly faster, should it mater. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/a29c2348a062408bec45cee2601b2417310e5ea7.1684865809.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Paolo Abeni authored
Antoine Tenart says: ==================== net: tcp: make txhash use consistent for IPv4 Series is divided in two parts. First two commits make the txhash (used for the skb hash in TCP) to be consistent for all IPv4/TCP packets (IPv6 doesn't have the same issue). Last commit improve a hash-related doc. One example is when using OvS with dp_hash, which uses skb->hash, to select a path. We'd like packets from the same flow to be consistent, as well as the hash being stable over time when using net.core.txrehash=0. Same applies for kernel ECMP which also can use skb->hash. ==================== Link: https://lore.kernel.org/r/20230523161453.196094-1-atenart@kernel.orgSigned-off-by:
-
Antoine Tenart authored
The net.core.txrehash documentation mentions this knob is for listening sockets only, while sk_rethink_txhash can be called on SYN and RTO retransmits on all TCP sockets. Remove the listening socket part. Signed-off-by:
Antoine Tenart <atenart@kernel.org> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Antoine Tenart authored
When using IPv4/TCP, skb->hash comes from sk->sk_txhash except in TIME_WAIT and SYN_RECV where it's not set in the reply skb from ip_send_unicast_reply. Those packets will have a mismatched hash with others from the same flow as their hashes will be 0. IPv6 does not have the same issue as the hash is set from the socket txhash in those cases. This commits sets the hash in the reply skb from ip_send_unicast_reply, which makes the IPv4 code behaving like IPv6. Signed-off-by:
-
Antoine Tenart authored
Commit c67b8555 ("ipv6: tcp: send consistent autoflowlabel in TIME_WAIT state") made the socket txhash also available in TIME_WAIT sockets but for IPv6 only. Make it available for IPv4 too as we'll use it in later commits. Signed-off-by:
-
Christian Marangi authored
Some LEDs may require to sleep while doing some operation like setting brightness and other cleanup. For this reason, using a spinlock will cause a sleep under spinlock warning. It should be safe to convert this to a sleepable lock since: - sysfs read/write can sleep - netdev_trig_work is a work queue and can sleep - netdev _trig_notify can sleep The spinlock was used when brightness didn't support sleeping, but this changed and now it supported with brightness_set_blocking(). Convert to mutex lock to permit sleeping using brightness_set_blocking(). Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-6-ansuelsmth@gmail.com
-
Christian Marangi authored
Convert link tx and rx device attr to a common macro to reduce common code and in preparation for additional attr. Signed-off-by:
-
Christian Marangi authored
Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by:
-
Christian Marangi authored
Putting NETDEV_LED_MODE_LINKUP in the same list of the netdev trigger modes is wrong as it's used to set the link state of the device and not to set a blink mode as it's done by NETDEV_LED_LINK, NETDEV_LED_TX and NETDEV_LED_RX. It's also wrong to put this state in the same bitmap of the netdev trigger mode and should be external to it. Drop NETDEV_LED_MODE_LINKUP from mode list and convert to a simple bool that will be true or false based on the carrier link. No functional change intended. Signed-off-by:
-
Christian Marangi authored
Dev can be renamed also while up for supported device. We currently wrongly clear the NETDEV_LED_MODE_LINKUP flag on NETDEV_CHANGENAME event. Fix this by rechecking if the carrier is ok on NETDEV_CHANGENAME and correctly set the NETDEV_LED_MODE_LINKUP bit. Fixes: 5f820ed5 ("leds: trigger: netdev: fix handling on interface rename") Cc: stable@vger.kernel.org # v5.5+ Signed-off-by:
-
Kuniyuki Iwashima authored
syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while using IPPROTO_UDPLITE (0x88): 14:25:52 executing program 1: r0 = socket$inet6(0xa, 0x80002, 0x88) We had a similar report [1] for probably sk_memory_allocated_add() in __sk_mem_raise_allocated(), and commit c915fe13 ("udplite: fix NULL pointer dereference") fixed it by setting .memory_allocated for udplite_prot and udplitev6_prot. To fix the variant, we need to set either .sysctl_wmem_offset or .sysctl_rmem. Now UDP and UDPLITE share the same value for .memory_allocated, so we use the same .sysctl_wmem_offset for UDP and UDPLITE. [0]: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023 RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline] RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006 Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8b RSP: 0018:ffffc90005d7f450 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000 RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8 RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000 R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0 Call Trace: <TASK> __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077 udp_rmem_schedule net/ipv4/udp.c:1539 [inline] __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581 __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline] udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775 udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793 __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline] __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013 ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437 ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482 NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491 ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585 dst_input include/net/dst.h:468 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491 __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605 netif_receive_skb_internal net/core/dev.c:5691 [inline] netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750 tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553 tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989 tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035 call_write_iter include/linux/fs.h:1868 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x945/0xd50 fs/read_write.c:584 ksys_write+0x12b/0x250 fs/read_write.c:637 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 RIP: 0023:0xf7f21579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f7f1c590 EFLAGS: 00000282 ORIG_RAX: 0000000000000004 RAX: ffffffffffffffda RBX: 00000000000000c8 RCX: 0000000020000040 RDX: 0000000000000083 RSI: 00000000f734e000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Modules linked in: Link: https://lore.kernel.org/netdev/CANaxB-yCk8hhP68L4Q2nFOJht8sqgXGGQO2AftpHs0u1xyGG5A@mail.gmail.com/ [1] Fixes: 850cbadd ("udp: use it's own memory accounting schema") Reported-by: syzbot+444ca0907e96f7c5e48b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=444ca0907e96f7c5e48bSigned-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://lore.kernel.org/r/20230523163305.66466-1-kuniyu@amazon.comSigned-off-by:
-
Russell King (Oracle) authored
Add two helper functions for calling PCS methods. phylink_pcs_config() allows us to handle PCS configuration specifics in one location, rather than the two call sites. phylink_pcs_link_up() gives us consistency. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1q1TzK-007Exd-Rs@rmk-PC.armlinux.org.ukSigned-off-by:
-
Jakub Kicinski authored
David Epping says: ==================== net: phy: mscc: support VSC8501 this updated series of patches adds support for the VSC8501 Ethernet PHY and fixes support for the VSC8502 PHY in cases where no other software (like U-Boot) has initialized the PHY after power up. The first patch simply adds the VSC8502 to the MODULE_DEVICE_TABLE, where I guess it was unintentionally missing. I have no hardware to test my change. The second patch adds the VSC8501 PHY with exactly the same driver implementation as the existing VSC8502. The (new) third patch removes phydev locking from vsc85xx_rgmii_set_skews(), as discussed for v2 of the patch set. The (now) fourth patch fixes the initialization for VSC8501 and VSC8502. I have tested this patch with VSC8501 on hardware in RGMII mode only. https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/VSC8501-03_Datasheet_60001741A.PDF https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/VSC8502-03_Datasheet_60001742B.pdf Table 4-42 "RGMII CONTROL, ADDRESS 20E2 (0X14)" Bit 11 for each of them. By default the RX_CLK is disabled for these PHYs. In cases where no other software, like U-Boot, enabled the clock, this results in no received packets being handed to the MAC. The patch enables this clock output. According to Microchip support (case number 01268776) this applies to all modes (RGMII, GMII, and MII). Other PHYs sharing the same register map and code, like VSC8530/31/40/41 have the clock enabled and the relevant bit 11 is reserved and read-only for them. As per previous discussion the patch still clears the bit on these PHYs, too, possibly more easily supporting other future PHYs implementing this functionality. For the VSC8572 family of PHYs, having a different register map, no such changes are applied. ==================== Link: https://lore.kernel.org/r/20230523153108.18548-1-david.epping@missinglinkelectronics.comSigned-off-by:
-
David Epping authored
By default the VSC8501 and VSC8502 RGMII/GMII/MII RX_CLK output is disabled. To allow packet forwarding towards the MAC it needs to be enabled. For other PHYs supported by this driver the clock output is enabled by default. Fixes: d3169863 ("net: phy: mscc: add support for VSC8502") Signed-off-by:
David Epping <david.epping@missinglinkelectronics.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
David Epping authored
Holding the struct phy_device (phydev) lock is unnecessary when accessing phydev->interface in the PHY driver .config_init method, which is the only place that vsc85xx_rgmii_set_skews() is called from. The phy_modify_paged() function implements required MDIO bus level locking, which can not be achieved by a phydev lock. Signed-off-by:
-
David Epping authored
The VSC8501 PHY can use the same driver implementation as the VSC8502. Adding the PHY ID and copying the handler functions of VSC8502 is sufficient to operate it. Signed-off-by:
-
David Epping authored
The mscc driver implements support for VSC8502, so its ID should be in the MODULE_DEVICE_TABLE for automatic loading. Signed-off-by:
-
Jakub Kicinski authored
Chuck Lever says: ==================== Bug fixes for net/handshake Paolo observed that there is a possible leak of sock->file. I haven't looked into that yet, but it seems to be separate from the fixes in this series, so no need to hold these up. ==================== The submissions mentions net-next but it means netdev (perhaps merge window left over when trees are converged). In any case, it should have gone into net, but was instead applied to net-next as commit deb2e484 ("Merge branch 'net-handshake-fixes'"). These are fixes tho, and Chuck needs them to make progress with the client so double-merging them into net... it is what it is :( Link: https://lore.kernel.org/r/168381978252.84244.1933636428135211300.stgit@91.116.238.104.host.secureserver.netSigned-off-by:
-
Chuck Lever authored
Enable the upper layer protocol to specify the SNI peername. This avoids the need for tlshd to use a DNS lookup, which can return a hostname that doesn't match the incoming certificate's SubjectName. Fixes: 2fd55320 ("net/handshake: Add a kernel API for requesting a TLSv1.3 handshake") Reviewed-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
Chuck Lever authored
If user space never calls DONE, sock->file's reference count remains elevated. Enable sock->file to be freed eventually in this case. Reported-by:
-
Chuck Lever authored
Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Fixes: 3b3009ea ("net/handshake: Create a NETLINK service for handling handshake requests") Reviewed-by:
-
Chuck Lever authored
trace_handshake_cmd_done_err() simply records the pointer in @req, so initializing it to NULL is sufficient and safe. Reported-by:
-
Chuck Lever authored
If get_unused_fd_flags() fails, we ended up calling fput(sock->file) twice. Reported-by:
-
Chuck Lever authored
handshake_req_submit() now verifies that the socket has a file. Fixes: 3b3009ea ("net/handshake: Create a NETLINK service for handling handshake requests") Reviewed-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfJakub Kicinski authored
Daniel Borkmann says: ==================== pull-request: bpf 2023-05-24 We've added 19 non-merge commits during the last 10 day(s) which contain a total of 20 files changed, 738 insertions(+), 448 deletions(-). The main changes are: 1) Batch of BPF sockmap fixes found when running against NGINX TCP tests, from John Fastabend. 2) Fix a memleak in the LRU{,_PERCPU} hash map when bucket locking fails, from Anton Protopopov. 3) Init the BPF offload table earlier than just late_initcall, from Jakub Kicinski. 4) Fix ctx access mask generation for 32-bit narrow loads of 64-bit fields, from Will Deacon. 5) Remove a now unsupported __fallthrough in BPF samples, from Andrii Nakryiko. 6) Fix a typo in pkg-config call for building sign-file, from Jeremy Sowden. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf, sockmap: Test progs verifier error with latest clang bpf, sockmap: Test FIONREAD returns correct bytes in rx buffer with drops bpf, sockmap: Test FIONREAD returns correct bytes in rx buffer bpf, sockmap: Test shutdown() correctly exits epoll and recv()=0 bpf, sockmap: Build helper to create connected socket pair bpf, sockmap: Pull socket helpers out of listen test for general use bpf, sockmap: Incorrectly handling copied_seq bpf, sockmap: Wake up polling after data copy bpf, sockmap: TCP data stall on recv before accept bpf, sockmap: Handle fin correctly bpf, sockmap: Improved check for empty queue bpf, sockmap: Reschedule is now done through backlog bpf, sockmap: Convert schedule_work into delayed_work bpf, sockmap: Pass skb ownership through read_skb bpf: fix a memory leak in the LRU and LRU_PERCPU hash maps bpf: Fix mask generation for 32-bit narrow loads of 64-bit fields samples/bpf: Drop unnecessary fallthrough bpf: netdev: init the offload table earlier selftests/bpf: Fix pkg-config call building sign-file ==================== Link: https://lore.kernel.org/r/20230524170839.13905-1-daniel@iogearbox.netSigned-off-by:
-
- 24 May, 2023 12 commits
-
-
Jakub Kicinski authored
Russell King says: ==================== net: pcs: xpcs: cleanups for clause 73 support This series cleans up xpcs code, moving much of the clause 73 code out of the driver into places where others can make use of it. Specifically, we add a helper to convert a clause 73 advertisement to ethtool link modes to mdio.h, and a helper to resolve the clause 73 negotiation state to phylink, which includes the pause modes. In doing this cleanup, several issues were identified with the original xpcs implementation: 1) it masks the link partner advertisement with its own advertisement so userspace can't see what the full link partner advertisement was. 2) it was always setting pause modes irrespective of the advertisements on either end of the link. 3) it was reading the STAT1 registers multiple times. Reading STAT1 has the side effect of unlatching the link-down status, so multiple reads should be avoided. This patch series addresses the first two first by addressing the issues, and then by moving over to the new helpers. The third issue is solved by restructuring the xpcs code. ==================== Link: https://lore.kernel.org/r/ZGyR/jDyYTYzRklg@shell.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
Avoid reading the STAT1 registers more than once while getting the PCS state, as this register contains latching-low bits that are lost after the first read. Signed-off-by:
-
Russell King (Oracle) authored
Use phylink_resolve_c73() to resolve the clause 73 autonegotiation result. Signed-off-by:
-
Russell King (Oracle) authored
xpcs was indicating symmetric pause should be enabled regardless of the advertisements by either party. Fix this to use linkmode_resolve_pause() now that we're no longer obliterating the link partner's advertisement by logically anding it with our own. This is transitional, the function will be entirely replaced with phylink_resolve_c73() in the following patch. Reviewed-by:
-
Russell King (Oracle) authored
lp_advertising is supposed to reflect the link partner's advertisement unmodified by the local advertisement, but xpcs bitwise ands it with the local advertisement prior to calculating the resolution of the negotiation. Fix this by moving the bitwise and to xpcs_resolve_lpa_c73() so it can place the results in a temporary bitmap before passing that to ixpcs_get_max_usxgmii_speed(). Reviewed-by:
-
Russell King (Oracle) authored
Convert xpcs clause 73 reading to use the newly introduced mii_c73_to_linkmode() helper to translate the link partner advertisement to an ethtool bitmap. Reviewed-by:
-
Russell King (Oracle) authored
Read the clause 73 link partner advertisement in a loop and then translate to the ethtool modes. Reviewed-by:
-
Russell King (Oracle) authored
Add a function to resolve clause 73 negotiation according to the priority resolution function described in clause 73.3.6. Signed-off-by:
-
Russell King (Oracle) authored
Phylink had two chunks of code virtually the same for resolving the negotiated pause modes. Factor this down to one function. Reviewed-by:
-
Russell King (Oracle) authored
Add a helper to convert a clause 73 advertisement to an ethtool bitmap. Reviewed-by:
-
David S. Miller authored
Jiri Pirko says: ==================== devlink: small port_new/del() cleanup This patchset cleans up couple of leftovers after recent devlink locking changes. Previously, both port_new/dev() commands were called without holding instance lock. Currently all devlink commands are called with instance lock held. The first patch just removes redundant port notification. The second one removes couple of outdated comments. The last patch changes port_dev() to have devlink_port pointer as an arg instead of port_index, which makes it similar to the rest of port related ops. ==================== Reviewed-by:
David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
Historically there was a reason why port_dev() along with for example port_split() did get port_index instead of the devlink_port pointer. With the locking changes that were done which ensured devlink instance mutex is hold for every command, the port ops could get devlink_port pointer directly. Change the forgotten port_dev() op to be as others and pass devlink_port pointer instead of port_index. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
-
