- 09 Sep, 2020 40 commits
-
-
Russell King authored
Add support for timestamping transmit packets. We allocate SYNC messages to queue 1, every other message to queue 0. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Russell King authored
Add support for receive timestamping. When enabled, the hardware adds a timestamp into the receive queue descriptor for all received packets with no filtering. Hence, we can only support NONE or ALL receive filter modes. The timestamp in the receive queue contains two bit sof seconds and the full nanosecond timestamp. This has to be merged with the remainder of the seconds from the TAI clock to arrive at a full timestamp before we can convert it to a ktime for the skb hardware timestamp field. Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Russell King authored
Add support for the TAI block in the mvpp2.2 hardware. Acked-by:
-
Russell King authored
Check the first level interrupt status registers to determine how to further process the port interrupt. We will need this to know whether to invoke the link status processing and/or the PTP processing for both XLG and GMAC. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Russell King authored
The link interrupt is used for way more than just the link status; it comes from a collection of units to do with the port. The Marvell documentation describes the interrupt as "GOP port X interrupt". Since we are adding PTP support, and the PTP interrupt uses this, rename it to be more inline with the documentation. This interrupt is also mis-named in the DT binding, but we leave that alone. Reviewed-by:
-
Russell King authored
The "link status" interrupt is used for more than just link status. Restructure mvpp2_link_status_isr() so we can add additional handling. Reviewed-by:
-
David S. Miller authored
Parav Pandit says: ==================== devlink show controller number Currently a devlink instance that supports an eswitch handles eswitch ports of two type of controllers. (1) controller discovered on same system where eswitch resides. This is the case where PCI PF/VF of a controller and devlink eswitch instance both are located on a single system. (2) controller located on external system. This is the case where a controller is plugged in one system and its devlink eswitch ports are located in a different system. In this case devlink instance of the eswitch only have access to ports of the controller. However, there is no way to describe that a eswitch devlink port belongs to which controller (mainly which external host controller). This problem is more prevalent when port attribute such as PF and VF numbers are overlapping between multiple controllers of same eswitch. Due to this, for a specific switch_id, unique phys_port_name cannot be constructed for such devlink ports. This short series overcomes this limitation by defining two new attributes. (a) external: Indicates if port belongs to external controller (b) controller number: Indicates a controller number of the port Based on this a unique phys_port_name is prepared using controller number. phys_port_name construction using unique controller number is only applicable to external controller ports. This ensures that for non smartnic usecases where there is no external controller, phys_port_name stays same as before. Patch summary: Patch-1 Added mlx5 driver to read controller number Patch-2 Adds the missing comment for the port attributes Patch-3 Move structure comments away from structure fields Patch-4 external attribute added for PCI port flavours Patch-5 Add controller number Patch-6 Use controller number to build phys_port_name --- Changelog: v2->v3: - Updated diagram to get rid of controller 'A' and 'B' - Kept ports of single controller together in diagram - Updated diagram for pf1's VF and SF and its ports v1->v2: - Added text diagram of multiple controllers - Updated example for a VF - Addressed comments from Jiri and Jakub - Moved controller number attribute to PCI port flavours This enables to better, hirerchical view with controller and its PF, VF numbers - Split 'external' and 'controller number' attributes as two different attributes - Merged mlx5_core driver to avoid compiliation break ==================== Acked-by:Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Parav Pandit authored
Now that controller number attribute is available, use it when building phsy_port_name for external controller ports. An example devlink port and representor netdev name consist of controller annotation for external controller with controller number = 1, for a VF 1 of PF 0: $ devlink port show pci/0000:06:00.0/2 pci/0000:06:00.0/2: type eth netdev ens2f0c1pf0vf1 flavour pcivf controller 1 pfnum 0 vfnum 1 external true splittable false function: hw_addr 00:00:00:00:00:00 $ devlink port show pci/0000:06:00.0/2 -jp { "port": { "pci/0000:06:00.0/2": { "type": "eth", "netdev": "ens2f0c1pf0vf1", "flavour": "pcivf", "controller": 1, "pfnum": 0, "vfnum": 1, "external": true, "splittable": false, "function": { "hw_addr": "00:00:00:00:00:00" } } } } Controller number annotation is skipped for non external controllers to maintain backward compatibility. Signed-off-by:Parav Pandit <parav@nvidia.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Parav Pandit authored
A devlink port may be for a controller consist of PCI device. A devlink instance holds ports of two types of controllers. (1) controller discovered on same system where eswitch resides This is the case where PCI PF/VF of a controller and devlink eswitch instance both are located on a single system. (2) controller located on external host system. This is the case where a controller is located in one system and its devlink eswitch ports are located in a different system. When a devlink eswitch instance serves the devlink ports of both controllers together, PCI PF/VF numbers may overlap. Due to this a unique phys_port_name cannot be constructed. For example in below such system controller-0 and controller-1, each has PCI PF pf0 whose eswitch ports can be present in controller-0. These results in phys_port_name as "pf0" for both. Similar problem exists for VFs and upcoming Sub functions. An example view of two controller systems: --------------------------------------------------------- | | | --------- --------- ------- ------- | ----------- | | vf(s) | | sf(s) | |vf(s)| |sf(s)| | | server | | ------- ----/---- ---/----- ------- ---/--- ---/--- | | pci rc |=== | pf0 |______/________/ | pf1 |___/_______/ | | connect | | ------- ------- | ----------- | | controller_num=1 (no eswitch) | ------|-------------------------------------------------- (internal wire) | --------------------------------------------------------- | devlink eswitch ports and reps | | ----------------------------------------------------- | | |ctrl-0 | ctrl-0 | ctrl-0 | ctrl-0 | ctrl-0 |ctrl-0 | | | |pf0 | pf0vfN | pf0sfN | pf1 | pf1vfN |pf1sfN | | | ----------------------------------------------------- | | |ctrl-1 | ctrl-1 | ctrl-1 | ctrl-1 | ctrl-1 |ctrl-1 | | | |pf1 | pf1vfN | pf1sfN | pf1 | pf1vfN |pf0sfN | | | ----------------------------------------------------- | | | | | | --------- --------- ------- ------- | | | vf(s) | | sf(s) | |vf(s)| |sf(s)| | | ------- ----/---- ---/----- ------- ---/--- ---/--- | | | pf0 |______/________/ | pf1 |___/_______/ | | ------- ------- | | | | local controller_num=0 (eswitch) | --------------------------------------------------------- An example devlink port for external controller with controller number = 1 for a VF 1 of PF 0: $ devlink port show pci/0000:06:00.0/2 pci/0000:06:00.0/2: type eth netdev ens2f0pf0vf1 flavour pcivf controller 1 pfnum 0 vfnum 1 external true splittable false function: hw_addr 00:00:00:00:00:00 $ devlink port show pci/0000:06:00.0/2 -jp { "port": { "pci/0000:06:00.0/2": { "type": "eth", "netdev": "ens2f0pf0vf1", "flavour": "pcivf", "controller": 1, "pfnum": 0, "vfnum": 1, "external": true, "splittable": false, "function": { "hw_addr": "00:00:00:00:00:00" } } } } Signed-off-by: -
Parav Pandit authored
A devlink eswitch port may represent PCI PF/VF ports of a controller. A controller either located on same system or it can be an external controller located in host where such NIC is plugged in. Add the ability for driver to specify if a port is for external controller. Use such flag in the mlx5_core driver. An example of an external controller having VF1 of PF0 belong to controller 1. $ devlink port show pci/0000:06:00.0/2 pci/0000:06:00.0/2: type eth netdev ens2f0pf0vf1 flavour pcivf pfnum 0 vfnum 1 external true splittable false function: hw_addr 00:00:00:00:00:00 $ devlink port show pci/0000:06:00.0/2 -jp { "port": { "pci/0000:06:00.0/2": { "type": "eth", "netdev": "ens2f0pf0vf1", "flavour": "pcivf", "pfnum": 0, "vfnum": 1, "external": true, "splittable": false, "function": { "hw_addr": "00:00:00:00:00:00" } } } } Signed-off-by: -
Parav Pandit authored
To add more fields to the PCI PF and VF port attributes, follow standard structure comment format. Signed-off-by:
-
Parav Pandit authored
Add comment block for physical, PF and VF port attributes. Signed-off-by:
Roi Dayan <roid@nvidia.com> Signed-off-by:
-
Parav Pandit authored
ECPF supports one external host controller. Read controller number from the device. Signed-off-by:
-
Zhang Changzhong authored
Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by:
-
Zhang Changzhong authored
Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Reported-by:
-
David S. Miller authored
Marco Felsch says: ==================== SMSC: Cleanups and clock setup this small series cleans the smsc-phy code a bit and adds the support to specify the phy clock source. Adding the phy clock source support is also the main purpose of this series. Each file has its own changelog. Thanks a lot to Florian and Andrew for reviewing it. ==================== Signed-off-by: -
Marco Felsch authored
Don't reset the phy without respect to the PHY library state machine because this breaks the phy IRQ mode. The same behaviour can be archived now by specifying the refclk. Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Marco Felsch authored
Add support to specify the clock provider for the PHY refclk and don't rely on 'magic' host clock setup. [1] tried to address this by introducing a flag and fixing the corresponding host. But this commit breaks the IRQ support since the irq setup during .config_intr() is thrown away because the reset comes from the side without respecting the current PHY state within the PHY library state machine. Furthermore the commit fixed the problem only for FEC based hosts other hosts acting like the FEC are not covered. This commit goes the other way around to address the bug fixed by [1]. Instead of resetting the device from the side every time the refclk gets (re-)enabled it requests and enables the clock till the device gets removed. Now the PHY library is the only place where the PHY gets reset to respect the PHY library state machine. [1] commit 7f64e5b1 ("net: phy: smsc: LAN8710/20: add PHY_RST_AFTER_CLK_EN flag") Signed-off-by:
-
Marco Felsch authored
Add support to specify the reference clock for the phy. Signed-off-by:
-
Marco Felsch authored
Exit the driver specific config_init hook early if energy detection is disabled. We can do this because we don't need to clear the interrupt status here. Clearing the status should be removed anyway since this is handled by the phy_enable_interrupts(). Signed-off-by:
-
Marco Felsch authored
Don't enable the interrupt if the platform disable the energy detection by "smsc,disable-energy-detect". Signed-off-by:
-
Wang Hai authored
Rename ptp to ptp_info. Fix W=1 compile warnings (invalid kerneldoc): drivers/net/ethernet/cavium/common/cavium_ptp.c:94: warning: Excess function parameter 'ptp' description in 'cavium_ptp_adjfine' drivers/net/ethernet/cavium/common/cavium_ptp.c:141: warning: Excess function parameter 'ptp' description in 'cavium_ptp_adjtime' drivers/net/ethernet/cavium/common/cavium_ptp.c:163: warning: Excess function parameter 'ptp' description in 'cavium_ptp_gettime' drivers/net/ethernet/cavium/common/cavium_ptp.c:185: warning: Excess function parameter 'ptp' description in 'cavium_ptp_settime' drivers/net/ethernet/cavium/common/cavium_ptp.c:208: warning: Excess function parameter 'ptp' description in 'cavium_ptp_enable' Reported-by:
Wang Hai <wanghai38@huawei.com> Signed-off-by:
-
Ayush Sawal authored
As ch_ipsec was removed without clearing xfrmdev_ops and netdev feature(esp-hw-offload). When a recalculation of netdev feature is triggered by changing tls feature(tls-hw-tx-offload) from user request, it causes a page fault due to absence of valid xfrmdev_ops. Fixes: 6dad4e8a ("chcr: Add support for Inline IPSec") Signed-off-by:
Ayush Sawal <ayush.sawal@chelsio.com> Acked-by:
-
David S. Miller authored
Paul Barker says: ==================== ksz9477 dsa switch driver improvements These changes were made while debugging the ksz9477 driver for use on a custom board which uses the ksz9893 switch supported by this driver. The patches have been runtime tested on top of Linux 5.8.4, I couldn't runtime test them on top of 5.9-rc3 due to unrelated issues. They have been build tested on top of net-next. These changes can also be pulled from: https://gitlab.com/pbarker.dev/staging/linux.git tag: for-net-next/ksz-v3_2020-09-09 Changes from v2: * Fixed incorrect type in assignment error. Reported-by:
kernel test robot <lkp@intel.com> Changes from v1: * Rebased onto net-next. * Dropped unnecessary `#include <linux/printk.h>`. * Instead of printing the phy mode in `ksz9477_port_setup()`, modify the existing print in `ksz9477_config_cpu_port()` to always produce output and to be more clear. ==================== Signed-off-by:
-
Paul Barker authored
The datasheet for the ksz9893 and ksz9477 switches recommend waiting at least 100us after the de-assertion of reset before trying to program the device through any interface. Also switch the existing msleep() call to usleep_range() as recommended in Documentation/timers/timers-howto.rst. The 2ms range used here is somewhat arbitrary, as long as the reset is asserted for at least 10ms we should be ok. Signed-off-by:
Paul Barker <pbarker@konsulko.com> Reviewed-by:
-
Paul Barker authored
We can't assume that the link partner supports the in-band status reporting which is enabled by default on the KSZ9893 when using RGMII for the upstream port. Signed-off-by:
-
Paul Barker authored
Always print the selected phy mode for the CPU port when using the ksz9477 driver. If the phy mode was changed, also print the previous mode to aid in debugging. To make the message more clear, prefix it with the port number which it applies to and improve the language a little. Signed-off-by:
-
Paul Barker authored
To make switch detection more informative print the result of the ksz9477/ksz9893 compatibility check. With debug output enabled also print the contents of the Chip ID registers as a 40-bit hex string. As this detection is the first communication with the switch performed by the driver, making it easy to see any errors here will help identify issues with SPI data corruption or reset sequencing. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-nextDavid S. Miller authored
Pablo Neira Ayuso says: ==================== Netfilter updates for net-next The following patchset contains Netfilter updates for net-next: 1) Rewrite inner header IPv6 in ICMPv6 messages in ip6t_NPT, from Michael Zhou. 2) do_ip_vs_set_ctl() dereferences uninitialized value, from Peilin Ye. 3) Support for userdata in tables, from Jose M. Guisado. 4) Do not increment ct error and invalid stats at the same time, from Florian Westphal. 5) Remove ct ignore stats, also from Florian. 6) Add ct stats for clash resolution, from Florian Westphal. 7) Bump reference counter bump on ct clash resolution only, this is safe because bucket lock is held, again from Florian. 8) Use ip_is_fragment() in xt_HMARK, from YueHaibing. 9) Add wildcard support for nft_socket, from Balazs Scheidler. 10) Remove superfluous IPVS dependency on iptables, from Yaroslav Bolyukin. 11) Remove unused definition in ebt_stp, from Wang Hai. 12) Replace CONFIG_NFT_CHAIN_NAT_{IPV4,IPV6} by CONFIG_NFT_NAT in selftests/net, from Fabian Frederick. 13) Add userdata support for nft_object, from Jose M. Guisado. ==================== Signed-off-by: -
Randy Dunlap authored
Fix typo/spello of "functionality". Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Jon Mason <jdmason@kudzu.us> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Cc: Jiri Kosina <trivial@kernel.org> Signed-off-by:
-
Randy Dunlap authored
Fix typo/spello of "functions". Signed-off-by:
-
Wei Wang authored
Currently, ipv6 stack does not do any TOS reflection. To make the behavior consistent with v4 stack, this commit adds TOS reflection in tcp_v6_reqsk_send_ack() and tcp_v6_send_reset(). We clear the lower 2-bit ECN value of the received TOS in compliance with RFC 3168 6.1.5 robustness principles. Signed-off-by:
Wei Wang <weiwan@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fsDavid S. Miller authored
David Howells says: ==================== rxrpc: Allow more calls to same peer Here are some development patches for AF_RXRPC that allow more simultaneous calls to be made to the same peer with the same security parameters. The current code allows a maximum of 4 simultaneous calls, which limits the afs filesystem to that many simultaneous threads. This increases the limit to 16. To make this work, the way client connections are limited has to be changed (incoming call/connection limits are unaffected) as the current code depends on queuing calls on a connection and then pushing the connection through a queue. The limit is on the number of available connections. This is changed such that there's a limit[*] on the total number of calls systemwide across all namespaces, but the limit on the number of client connections is removed. Once a call is allowed to proceed, it finds a bundle of connections and tries to grab a call slot. If there's a spare call slot, fine, otherwise it will wait. If there's already a waiter, it will try to create another connection in the bundle, unless the limit of 4 is reached (4 calls per connection, giving 16). A number of things throttle someone trying to set up endless connections: - Calls that fail immediately have their conns deleted immediately, - Calls that don't fail immediately have to wait for a timeout, - Connections normally get automatically reaped if they haven't been used for 2m, but this is sped up to 2s if the number of connections rises over 900. This number is tunable by sysctl. [*] Technically two limits - kernel sockets and userspace rxrpc sockets are accounted separately. ==================== Signed-off-by: -
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'tc35815_init_queues()' GFP_ATOMIC must be used because it can be called from 'tc35815_restart()' where some spinlock are taken. The call chain is: tc35815_restart --> tc35815_clear_queues --> tc35815_init_queues @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by:Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'rr_init_one()' GFP_KERNEL can be used because it is a probe function and no spinlock is taken in the between. When memory is allocated in 'rr_open()' GFP_KERNEL can be used because it is a '.ndo_open' function (see struct net_device_ops) and no spinlock is taken in the between. '.ndo_open' functions are synchronized using the rtnl_lock() semaphore. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by:
-
Edward Cree authored
The code recently moved into this file contained a number of coding style issues, about which checkpatch and xmastree complained. Fix them. Signed-off-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
Nikolay Aleksandrov authored
Stephen reported the following warning: net/bridge/br_multicast.c: In function 'br_multicast_find_port': net/bridge/br_multicast.c:1818:21: warning: unused variable 'br' [-Wunused-variable] 1818 | struct net_bridge *br = mp->br; | ^~ It happens due to bridge's mlock_dereference() when lockdep isn't defined. Silence the warning by annotating the variable as __maybe_unused. Fixes: 0436862e ("net: bridge: mcast: support for IGMPv3/MLDv2 ALLOW_NEW_SOURCES report") Reported-by:Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): net/netlabel/netlabel_calipso.c:438: warning: Excess function parameter 'audit_secid' description in 'calipso_doi_remove' net/netlabel/netlabel_calipso.c:605: warning: Excess function parameter 'reg' description in 'calipso_req_delattr' Reported-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): drivers/net/wimax/i2400m/control.c:709: warning: Excess function parameter 'msg_skb' description in 'i2400m_msg_to_dev' This parameter is not in use. Remove it. Reported-by:
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:4238: warning: Excess function parameter 'netdev' description in 'bnx2x_setup_tc' drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:4238: warning: Excess function parameter 'tc' description in 'bnx2x_setup_tc' Reported-by:
-
