aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2021-01-15net: mscc: ocelot: auto-detect packet buffer size and number of frame referencesVladimir Oltean6-6/+21
Instead of reading these values from the reference manual and writing them down into the driver, it appears that the hardware gives us the option of detecting them dynamically. The number of frame references corresponds to what the reference manual notes, however it seems that the frame buffers are reported as slightly less than the books would indicate. On VSC9959 (Felix), the books say it should have 128KB of packet buffer, but the registers indicate only 129840 bytes (126.79 KB). Also, the unit of measurement for FREECNT from the documentation of all these devices is incorrect (taken from an older generation). This was confirmed by Younes Leroul from Microchip support. Not having anything better to do with these values at the moment* (this will change soon), let's just print them. *The frame buffer size is, in fact, used to calculate the tail dropping watermarks. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-15Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextJakub Kicinski28-205/+151
Daniel Borkmann says: ==================== pull-request: bpf-next 2021-01-16 1) Extend atomic operations to the BPF instruction set along with x86-64 JIT support, that is, atomic{,64}_{xchg,cmpxchg,fetch_{add,and,or,xor}}, from Brendan Jackman. 2) Add support for using kernel module global variables (__ksym externs in BPF programs) retrieved via module's BTF, from Andrii Nakryiko. 3) Generalize BPF stackmap's buildid retrieval and add support to have buildid stored in mmap2 event for perf, from Jiri Olsa. 4) Various fixes for cross-building BPF sefltests out-of-tree which then will unblock wider automated testing on ARM hardware, from Jean-Philippe Brucker. 5) Allow to retrieve SOL_SOCKET opts from sock_addr progs, from Daniel Borkmann. 6) Clean up driver's XDP buffer init and split into two helpers to init per- descriptor and non-changing fields during processing, from Lorenzo Bianconi. 7) Minor misc improvements to libbpf & bpftool, from Ian Rogers. * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (41 commits) perf: Add build id data in mmap2 event bpf: Add size arg to build_id_parse function bpf: Move stack_map_get_build_id into lib bpf: Document new atomic instructions bpf: Add tests for new BPF atomic operations bpf: Add bitwise atomic instructions bpf: Pull out a macro for interpreting atomic ALU operations bpf: Add instructions for atomic_[cmp]xchg bpf: Add BPF_FETCH field / create atomic_fetch_add instruction bpf: Move BPF_STX reserved field check into BPF_STX verifier code bpf: Rename BPF_XADD and prepare to encode other atomics in .imm bpf: x86: Factor out a lookup table for some ALU opcodes bpf: x86: Factor out emission of REX byte bpf: x86: Factor out emission of ModR/M for *(reg + off) tools/bpftool: Add -Wall when building BPF programs bpf, libbpf: Avoid unused function warning on bpf_tail_call_static selftests/bpf: Install btf_dump test cases selftests/bpf: Fix installation of urandom_read selftests/bpf: Move generated test files to $(TEST_GEN_FILES) selftests/bpf: Fix out-of-tree build ... ==================== Link: https://lore.kernel.org/r/20210116012922.17823-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-15net: ks8851: remove definition of DEBUGTom Rix3-6/+0
Defining DEBUG should only be done in development. So remove DEBUG. Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20210115153128.131026-1-trix@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-15gianfar: remove definition of DEBUGTom Rix1-1/+0
Defining DEBUG should only be done in development. So remove DEBUG. Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20210113215603.1721958-1-trix@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-15net: dsa: set configure_vlan_while_not_filtering to true by defaultVladimir Oltean13-15/+12
As explained in commit 54a0ed0df496 ("net: dsa: provide an option for drivers to always receive bridge VLANs"), DSA has historically been skipping VLAN switchdev operations when the bridge wasn't in vlan_filtering mode, but the reason why it was doing that has never been clear. So the configure_vlan_while_not_filtering option is there merely to preserve functionality for existing drivers. It isn't some behavior that drivers should opt into. Ideally, when all drivers leave this flag set, we can delete the dsa_port_skip_vlan_configuration() function. New drivers always seem to omit setting this flag, for some reason. So let's reverse the logic: the DSA core sets it by default to true before the .setup() callback, and legacy drivers can turn it off. This way, new drivers get the new behavior by default, unless they explicitly set the flag to false, which is more obvious during review. Remove the assignment from drivers which were setting it to true, and add the assignment to false for the drivers that didn't previously have it. This way, it should be easier to see how many we have left. The following drivers: lan9303, mv88e6060 were skipped from setting this flag to false, because they didn't have any VLAN offload ops in the first place. The Broadcom Starfighter 2 driver calls the common b53_switch_alloc and therefore also inherits the configure_vlan_while_not_filtering=true behavior. Also, print a message through netlink extack every time a VLAN has been skipped. This is mildly annoying on purpose, so that (a) it is at least clear that VLANs are being skipped - the legacy behavior in itself is confusing, and the extack should be much more difficult to miss, unlike kernel logs - and (b) people have one more incentive to convert to the new behavior. No behavior change except for the added prints is intended at this time. $ ip link add br0 type bridge vlan_filtering 0 $ ip link set sw0p2 master br0 [ 60.315148] br0: port 1(sw0p2) entered blocking state [ 60.320350] br0: port 1(sw0p2) entered disabled state [ 60.327839] device sw0p2 entered promiscuous mode [ 60.334905] br0: port 1(sw0p2) entered blocking state [ 60.340142] br0: port 1(sw0p2) entered forwarding state Warning: dsa_core: skipping configuration of VLAN. # This was the pvid $ bridge vlan add dev sw0p2 vid 100 Warning: dsa_core: skipping configuration of VLAN. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210115231919.43834-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-15netxen_nic: switch from 'pci_' to 'dma_' APIChristophe JAILLET3-77/+77
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 'netxen_get_minidump_template()' GFP_KERNEL can be used because its only caller, ' netxen_setup_minidump(()' already uses it and no lock is acquired in the between. When memory is allocated in other function in 'netxen_nic_ctx.c' GFP_KERNEL can be used because the call chain already uses GFP_KERNEL and no lock is taken in the between. The call chain is: netxen_nic_attach() --> netxen_alloc_sw_resources() : already uses GFP_KERNEL --> netxen_alloc_hw_resources() --> nx_fw_cmd_create_rx_ctx() --> nx_fw_cmd_create_tx_ctx() When memory is allocated in 'netxen_init_dummy_dma()' GFP_KERNEL can be used because its only call chain already uses it and no lock is acquired in the between. The call chain is: --> netxen_start_firmware --> netxen_request_firmware() --> request_firmware() --> _request_firmware(() --> fw_get_filesystem_firmware() --> __getname() : already uses GFP_KERNEL --> netxen_init_dummy_dma() @@ @@ - 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> Link: https://lore.kernel.org/r/20210113202519.487672-1-christophe.jaillet@wanadoo.fr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-15net: dsa: mv88e6xxx: Only allow LAG offload on supported hardwareTobias Waldekranz2-1/+10
There are chips that do have Global 2 registers, and therefore trunk mapping/mask tables are not available. Refuse the offload as early as possible on those devices. Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support") Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-15net: dsa: mv88e6xxx: Provide dummy implementations for trunk settersTobias Waldekranz1-0/+12
Support for Global 2 registers is build-time optional. In the case where it was not enabled the build would fail as no "dummy" implementation of these functions was available. Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support") Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Tested-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-15net: dsa: add Arrow SpeedChips XRS700x driverGeorge McCollister9-0/+1213
Add a driver with initial support for the Arrow SpeedChips XRS7000 series of gigabit Ethernet switch chips which are typically used in critical networking applications. The switches have up to three RGMII ports and one RMII port. Management to the switches can be performed over i2c or mdio. Support for advanced features such as PTP and HSR/PRP (IEC 62439-3 Clause 5 & 4) is not included in this patch and may be added at a later date. Signed-off-by: George McCollister <george.mccollister@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-15net: phy: at803x: add support for configuring SmartEEERussell King1-1/+64
SmartEEE for the atheros phy was deemed buggy by Freescale and commits were added to disable it for their boards. In initial testing, SolidRun found that the default settings were causing disconnects but by increasing the Tw buffer time we could allow enough time for all parts of the link to come out of a low power state and function properly without causing a disconnect. This allows us to have functional power savings of between 300 and 400mW, rather than disabling the feature altogether. This commit adds support for disabling SmartEEE and configuring the Tw parameters for 1G and 100M speeds. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-15octeontx2-af: Fix missing check bugs in rvu_cgx.cYingjie Wang1-0/+6
In rvu_mbox_handler_cgx_mac_addr_get() and rvu_mbox_handler_cgx_mac_addr_set(), the msg is expected only from PFs that are mapped to CGX LMACs. It should be checked before mapping, so we add the is_cgx_config_permitted() in the functions. Fixes: 96be2e0da85e ("octeontx2-af: Support for MAC address filters in CGX") Signed-off-by: Yingjie Wang <wangyingjie55@126.com> Reviewed-by: Geetha sowjanya<gakula@marvell.com> Link: https://lore.kernel.org/r/1610719804-35230-1-git-send-email-wangyingjie55@126.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski22-79/+156
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14bpf: Rename BPF_XADD and prepare to encode other atomics in .immBrendan Jackman3-11/+22
A subsequent patch will add additional atomic operations. These new operations will use the same opcode field as the existing XADD, with the immediate discriminating different operations. In preparation, rename the instruction mode BPF_ATOMIC and start calling the zero immediate BPF_ADD. This is possible (doesn't break existing valid BPF progs) because the immediate field is currently reserved MBZ and BPF_ADD is zero. All uses are removed from the tree but the BPF_XADD definition is kept around to avoid breaking builds for people including kernel headers. Signed-off-by: Brendan Jackman <jackmanb@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Björn Töpel <bjorn.topel@gmail.com> Link: https://lore.kernel.org/bpf/20210114181751.768687-5-jackmanb@google.com
2021-01-14ch_ipsec: Remove initialization of rxq related dataAyush Sawal1-3/+0
Removing initialization of nrxq and rxq_size in uld_info. As ipsec uses nic queues only, there is no need to create uld rx queues for ipsec. Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com> Link: https://lore.kernel.org/r/20210113044302.25522-1-ayush.sawal@chelsio.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14net: ipa: retry TX channel stop commandsAlex Elder1-5/+2
For RX channels we issue a stop command more than once if necessary to allow it to stop. It turns out that TX channels could also require retries. Retry channel stop commands if necessary regardless of the channel direction. Rename the symbol defining the retry count so it's not RX-specific. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14net: ipa: change stop channel retry delayAlex Elder1-1/+1
If a GSI stop channel command leaves the channel in STOP_IN_PROC state, we retry the stop command after a 1-2 millisecond delay. I have been told that a 3-5 millisecond delay is a better choice. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14net: ipa: change GSI command timeoutAlex Elder1-2/+4
The GSI command timeout is currently 5 seconds, which is much higher than it should be. Express the timeout in milliseconds rather than seconds, and reduce it to 50 milliseconds. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14net: ipa: use usleep_range()Alex Elder2-4/+5
65;6003;1c The use of msleep() for small periods (less than 20 milliseconds) is not recommended because the actual delay can be much different than expected. We use msleep(1) in several places in the IPA driver to insert short delays. Replace them with usleep_range calls, which should reliably delay a period in the range requested. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14net: ipa: introduce some interrupt helpersAlex Elder1-36/+58
Create a new function gsi_irq_ev_ctrl_enable() that encapsulates enabling the event ring control GSI interrupt type, and enables a single event ring to signal that interrupt. When an event ring changes state as a result of an event ring command, it triggers this interrupt. Create an inverse function gsi_irq_ev_ctrl_disable() as well. Because only one event ring at a time is enabled for this interrupt, we can simply disable the interrupt for *all* channels. Create a pair of helpers that serve the same purpose for channel commands. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14net: ipa: a few simple renamesAlex Elder1-14/+14
The return value of gsi_command() is true if successful or false if we time out waiting for a completion interrupt. Rename the variables in the three callers of gsi_command() to be "timeout", to make it more obvious that's the only reason for failure. In addition, add a "gsi_" prefix to evt_ring_command() so its name is consistent with the convention used for GSI channel and generic commands. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14Merge tag 'linux-can-next-for-5.12-20210114' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-nextJakub Kicinski41-1411/+1509
Marc Kleine-Budde says: ==================== pull-request: can-next 2021-01-14 The first two patches update the MAINTAINERS file, Lukas Bulwahn's patch fixes the files entry for the tcan4x5x driver, which was broken by me in net-next. A patch by me adds the a missing header file to the CAN Networking Layer. The next 5 patches are by me and split the the CAN driver related infrastructure code into more files in a separate subdir. The next two patches by me clean up the CAN length related code. This is followed by 6 patches by Vincent Mailhol and me, they add helper code for for CAN frame length calculation neede for BQL support. A patch by Vincent Mailhol adds software TX timestamp support. The last patch is by me, targets the tcan4x5x driver, and removes the unneeded __packed attribute from the struct tcan4x5x_map_buf. * tag 'linux-can-next-for-5.12-20210114' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: tcan4x5x: remove __packed attribute from struct tcan4x5x_map_buf can: dev: can_put_echo_skb(): add software tx timestamps can: dev: can_rx_offload_get_echo_skb(): extend to return can frame length can: dev: can_get_echo_skb(): extend to return can frame length can: dev: can_put_echo_skb(): extend to handle frame_len can: dev: extend struct can_skb_priv to hold CAN frame length can: length: can_skb_get_frame_len(): introduce function to get data length of frame in data link layer can: length: canfd_sanitize_len(): add function to sanitize CAN-FD data length can: length: can_fd_len2dlc(): simplify length calculcation can: length: convert to kernel coding style can: dev: move netlink related code into seperate file can: dev: move skb related into seperate file can: dev: move length related code into seperate file can: dev: move bittiming related code into seperate file can: dev: move driver related infrastructure into separate subdir MAINTAINERS: CAN network layer: add missing header file can-ml.h MAINTAINERS: adjust entry to tcan4x5x file split ==================== Link: https://lore.kernel.org/r/20210114075617.1402597-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14net: dsa: mv88e6xxx: Link aggregation supportTobias Waldekranz5-5/+330
Support offloading of LAGs to hardware. LAGs may be attached to a bridge in which case VLANs, multicast groups, etc. are also offloaded as usual. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14net: bonding: Notify ports about their initial stateTobias Waldekranz1-0/+2
When creating a static bond (e.g. balance-xor), all ports will always be enabled. This is set, and the corresponding notification is sent out, before the port is linked to the bond upper. In the offloaded case, this ordering is hard to deal with. The lower will first see a notification that it can not associate with any bond. Then the bond is joined. After that point no more notifications are sent, so all ports remain disabled. This change simply sends an extra notification once the port has been linked to the upper to synchronize the initial state. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com> Tested-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14mlxsw: pci: switch from 'pci_' to 'dma_' APIChristophe JAILLET1-31/+25
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 'mlxsw_pci_queue_init()' and 'mlxsw_pci_fw_area_init()' GFP_KERNEL can be used because both functions are already using this flag and no lock is acquired. When memory is allocated in 'mlxsw_pci_mbox_alloc()' GFP_KERNEL can be used because it is only called from the probe function and no lock is acquired in the between. The call chain is: --> mlxsw_pci_probe() --> mlxsw_pci_cmd_init() --> mlxsw_pci_mbox_alloc() While at it, also replace the 'dma_set_mask/dma_set_coherent_mask' sequence by a less verbose 'dma_set_mask_and_coherent() call. @@ @@ - 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> Tested-by: Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20210114084757.490540-1-christophe.jaillet@wanadoo.fr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14net: marvell: prestera: fix uninitialized vid in prestera_port_vlans_addVladimir Oltean1-2/+1
prestera_bridge_port_vlan_add should have been called with vlan->vid, however this was masked by the presence of the local vid variable and I did not notice the build warning. Reported-by: kernel test robot <lkp@intel.com> Fixes: b7a9e0da2d1c ("net: switchdev: remove vid_begin -> vid_end range from VLAN objects") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Taras Chornyi <tchornyi@marvell.com> Link: https://lore.kernel.org/r/20210114083556.2274440-1-olteanv@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14sfp: add support for 100 base-x SFPsBjarni Jonasson1-0/+9
Add support for 100Base-FX, 100Base-LX, 100Base-PX and 100Base-BX10 modules This is needed for Sparx-5 switch. Signed-off-by: Bjarni Jonasson <bjarni.jonasson@microchip.com> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14net: phy: ar803x: disable extended next page bitRussell King1-1/+7
This bit is enabled by default and advertises support for extended next page support. XNP is only needed for 10GBase-T and MultiGig support which is not supported. Additionally, Cisco MultiGig switches will read this bit and attempt 10Gb negotiation even though Next Page support is disabled. This will cause timeouts when the interface is forced to 100Mbps and auto-negotiation will fail. The interfaces are only 1000Base-T and supporting auto-negotiation for this only requires the Next Page bit to be set. Taken from: https://github.com/SolidRun/linux-stable/commit/7406c5244b7ea6bc17a2afe8568277a8c4b126a9 and adapted to mainline kernels by rmk. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1kzSdb-000417-FJ@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14nt: usb: USB_RTL8153_ECM should not default to yGeert Uytterhoeven1-1/+0
In general, device drivers should not be enabled by default. Fixes: 657bc1d10bfc23ac ("r8153_ecm: avoid to be prior to r8152 driver") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20210113144309.1384615-1-geert+renesas@glider.be Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14net: stmmac: fix taprio configuration when base_time is in the pastYannick Vignon1-2/+18
The Synopsys TSN MAC supports Qbv base times in the past, but only up to a certain limit. As a result, a taprio qdisc configuration with a small base time (for example when treating the base time as a simple phase offset) is not applied by the hardware and silently ignored. This was observed on an NXP i.MX8MPlus device, but likely affects all TSN-variants of the MAC. Fix the issue by making sure the base time is in the future, pushing it by an integer amount of cycle times if needed. (a similar check is already done in several other taprio implementations, see for example drivers/net/ethernet/intel/igc/igc_tsn.c#L116 or drivers/net/dsa/sja1105/sja1105_ptp.h#L39). Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API") Signed-off-by: Yannick Vignon <yannick.vignon@nxp.com> Link: https://lore.kernel.org/r/20210113131557.24651-2-yannick.vignon@oss.nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14net: stmmac: fix taprio schedule configurationYannick Vignon1-48/+4
When configuring a 802.1Qbv schedule through the tc taprio qdisc on an NXP i.MX8MPlus device, the effective cycle time differed from the requested one by N*96ns, with N number of entries in the Qbv Gate Control List. This is because the driver was adding a 96ns margin to each interval of the GCL, apparently to account for the IPG. The problem was observed on NXP i.MX8MPlus devices but likely affected all devices relying on the same configuration callback (dwmac 4.00, 4.10, 5.10 variants). Fix the issue by removing the margins, and simply setup the MAC with the provided cycle time value. This is the behavior expected by the user-space API, as altering the Qbv schedule timings would break standards conformance. This is also the behavior of several other Ethernet MAC implementations supporting taprio, including the dwxgmac variant of stmmac. Fixes: 504723af0d85 ("net: stmmac: Add basic EST support for GMAC5+") Signed-off-by: Yannick Vignon <yannick.vignon@nxp.com> Link: https://lore.kernel.org/r/20210113131557.24651-1-yannick.vignon@oss.nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-14wlcore: Downgrade exceeded max RX BA sessions to debugTony Lindgren1-1/+1
We can get the following in the logs every few minutes or so: wlcore: ERROR exceeded max RX BA sessions Let's downgrade the message to a debug message as suggested by the TI support folks at: https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/352435/1244754 "The WL127x firmware supports max of 3 BA sessions. It cannot be increased. I think the problem here is the peer trying to initiate a 4th BA session (ADDBA request)." Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210101065955.63386-1-tony@atomide.com
2021-01-14wilc1000: use flexible-array member instead of zero-length arrayTian Tao1-4/+4
Use flexible-array member introduced in C99 instead of zero-length array. Most of zero-length array was already taken care in previous patch [1]. [1]. https://patchwork.kernel.org/patch/11394197/ Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1608881703-37060-1-git-send-email-tiantao6@hisilicon.com
2021-01-14brcmfmac: clear EAP/association status bits on linkdown eventsLuca Pesce1-2/+5
This ensure that previous association attempts do not leave stale statuses on subsequent attempts. This fixes the WARN_ON(!cr->bss)) from __cfg80211_connect_result() when connecting to an AP after a previous connection failure (e.g. where EAP fails due to incorrect psk but association succeeded). In some scenarios, indeed, brcmf_is_linkup() was reporting a link up event too early due to stale BRCMF_VIF_STATUS_ASSOC_SUCCESS bit, thus reporting to cfg80211 a connection result with a zeroed bssid (vif->profile.bssid is still empty), causing the WARN_ON due to the call to cfg80211_get_bss() with the empty bssid. Signed-off-by: Luca Pesce <luca.pesce@vimar.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1608807119-21785-1-git-send-email-luca.pesce@vimar.com
2021-01-14brcmfmac: Delete useless kfree codeZheng Yongjun1-6/+4
A null pointer will be passed to a kfree() call after a kzalloc() call failed. This code is useless. Thus delete the extra function call. A goto statement is also no longer needed. Thus adjust an if branch. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201222135113.20680-1-zhengyongjun3@huawei.com
2021-01-14qtnfmac_pcie: Use module_pci_driverAmey Narkhede1-12/+1
Use module_pci_driver for drivers whose init and exit functions only register and unregister, respectively. Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201221075735.197255-1-ameynarkhede03@gmail.com
2021-01-14mt7601u: check the status of device in calibrationZhi Han1-0/+3
When the usb device being plugged out, before ieee80211 gets to know the hw being removed, it gets to know that the association status changed, and thus ask for the device to do the calibration. This causes error as the hw is absent. This can be avoid by checking the status of the device before sending the calibration request to the device. Signed-off-by: Zhi Han <z.han@gmx.net> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201217161657.GB12562@E480
2021-01-14mt7601u: process URBs in status EPROTO properlyZhi Han1-0/+1
When the usb device being plugged out, before the usb_driver:disconnect called by e.g workqueue, it is possible that some URBs are still in processing, and being marked as EPROTO in host controller. Those URBs should not be scheduled in complete_rx callback function to get further processing. Signed-off-by: Zhi Han <z.han@gmx.net> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201217161302.GA12562@E480
2021-01-14brcmfmac: support BCM4365E with 43666 ChipCommon chip IDRafał Miłecki3-0/+3
This adds support for the BCM43666/4 which seems to be using the same firmware as BCM4366 (4366c0). I found it in the Netgear R8000P router. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214101553.32097-1-zajec5@gmail.com
2021-01-14wilc1000: fix spelling mistake in Kconfig "devision" -> "division"Colin Ian King1-1/+1
There is a spelling mistake in the Kconfig help text. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201216115808.12987-1-colin.king@canonical.com
2021-01-14mwifiex: pcie: Drop bogus __refdata annotationGeert Uytterhoeven1-1/+1
As the Marvell PCIE WiFi-Ex driver does not have any code or data located in initmem, there is no need to annotate the mwifiex_pcie structure with __refdata. Drop the annotation, to avoid suppressing future section warnings. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201211133835.2970384-1-geert+renesas@glider.be
2021-01-14rtw88: Simplify bool comparisonYANG LI1-1/+1
Fix the following coccicheck warning: ./drivers/net/wireless/realtek/rtw88/debug.c:800:17-23: WARNING: Comparison of 0/1 to bool variable Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: YANG LI <abaci-bugfix@linux.alibaba.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1610445040-23599-1-git-send-email-abaci-bugfix@linux.alibaba.com
2021-01-14rtw88: coex: set 4 slot TDMA for BT link and WL busyChing-Te Ku1-1/+3
To protect both of WL/BT performance while BT is under re-link state. 4-slot mode TDMA can make the re-link more sensitive and mitigate the WL throughput drop. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210112021135.3823-1-pkshih@realtek.com
2021-01-14rtw88: 8821c: apply CCK PD level which calculates from dynamic mechanismVincent Fann1-7/+0
Hal function must follow the value that calculates from dynamic mechanism. Force to set new_lvl to 4 damages receiving ability. System will not able to reconnect to the AP if wifi unexpected disconnecting at this moment. Signed-off-by: Vincent Fann <vincent_fann@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201228082516.16488-1-pkshih@realtek.com
2021-01-14rtw88: reduce the log level for failure of tx reportChin-Yen Lee1-1/+1
Sometimes driver does not get tx report from firmware because wifi environment is too noisy to get ack from AP about a TX frame, or firmware is too busy to report driver in a estimated time. But the condition will not affect wifi function or throughput. So we reduce the log level to rtw_debug instead of scary backtrace. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201228082433.16431-1-pkshih@realtek.com
2021-01-14rtw88: Delete useless kfree codeZheng Yongjun1-1/+0
The parameter of kfree function is NULL, so kfree code is useless, delete it. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201216130442.13869-1-zhengyongjun3@huawei.com
2021-01-14iwlwifi: dbg: Don't touch the tlv dataTakashi Iwai1-7/+0
The commit ba8f6f4ae254 ("iwlwifi: dbg: add dumping special device memory") added a termination of name string just to be sure, and this seems causing a regression, a GPF triggered at firmware loading. Basically we shouldn't modify the firmware data that may be provided as read-only. This patch drops the code that caused the regression and keep the tlv data as is. Fixes: ba8f6f4ae254 ("iwlwifi: dbg: add dumping special device memory") BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1180344 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210733 Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210112132449.22243-2-tiwai@suse.de
2021-01-14mt76: Fix queue ID variable types after mcu queue splitNathan Chancellor2-6/+6
Clang warns in both mt7615 and mt7915: drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:271:9: warning: implicit conversion from enumeration type 'enum mt76_mcuq_id' to different enumeration type 'enum mt76_txq_id' [-Wenum-conversion] txq = MT_MCUQ_FWDL; ~ ^~~~~~~~~~~~ drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:278:9: warning: implicit conversion from enumeration type 'enum mt76_mcuq_id' to different enumeration type 'enum mt76_txq_id' [-Wenum-conversion] txq = MT_MCUQ_WA; ~ ^~~~~~~~~~ drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:282:9: warning: implicit conversion from enumeration type 'enum mt76_mcuq_id' to different enumeration type 'enum mt76_txq_id' [-Wenum-conversion] txq = MT_MCUQ_WM; ~ ^~~~~~~~~~ 3 warnings generated. drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:238:9: warning: implicit conversion from enumeration type 'enum mt76_mcuq_id' to different enumeration type 'enum mt76_txq_id' [-Wenum-conversion] qid = MT_MCUQ_WM; ~ ^~~~~~~~~~ drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:240:9: warning: implicit conversion from enumeration type 'enum mt76_mcuq_id' to different enumeration type 'enum mt76_txq_id' [-Wenum-conversion] qid = MT_MCUQ_FWDL; ~ ^~~~~~~~~~~~ 2 warnings generated. Use the proper type for the queue ID variables to fix these warnings. Additionally, rename the txq variable in mt7915_mcu_send_message to be more neutral like mt7615_mcu_send_message. Fixes: e637763b606b ("mt76: move mcu queues to mt76_dev q_mcu array") Link: https://github.com/ClangBuiltLinux/linux/issues/1229 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201229211548.1348077-1-natechancellor@gmail.com
2021-01-14can: tcan4x5x: remove __packed attribute from struct tcan4x5x_map_bufMarc Kleine-Budde1-1/+1
The first member of struct tcan4x5x_map_buf is the struct tcan4x5x_buf_cmd, which has a size of 4 bytes. It's followed by an array of u8. The compiler places the array directly after the struct tcan4x5x_buf_cmd. This patch removes the not needed attribute __packed from the struct tcan4x5x_map_buf. Suggested-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20210113203955.912916-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-01-14can: dev: can_put_echo_skb(): add software tx timestampsVincent Mailhol1-0/+2
Call skb_tx_timestamp() within can_put_echo_skb() so that a software tx timestamp gets attached to the skb. There two main reasons to include this call in can_put_echo_skb(): * It easily allow to enable the tx timestamp on all devices with just one small change. * According to Documentation/networking/timestamping.rst, the tx timestamps should be generated in the device driver as close as possible, but always prior to passing the packet to the network interface. During the call to can_put_echo_skb(), the skb gets cloned meaning that the driver should not dereference the skb variable anymore after can_put_echo_skb() returns. This makes can_put_echo_skb() the very last place we can use the skb without having to access the echo_skb[] array. Remark: by default, skb_tx_timestamp() does nothing. It needs to be activated by passing the SOF_TIMESTAMPING_TX_SOFTWARE flag either through socket options or control messages. References: * Support for the error queue in CAN RAW sockets (which is needed for tx timestamps) was introduced in: https://git.kernel.org//torvalds/c/eb88531bdbfaafb827192d1fc6c5a3fcc4fadd96 * Put the call to skb_tx_timestamp() just before adding it to the array: https://lore.kernel.org/r/043c3ea1-6bdd-59c0-0269-27b2b5b36cec@victronenergy.com * About Tx hardware timestamps https://lore.kernel.org/r/20210111171152.GB11715@hoboy.vegasvil.org Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20210112095437.6488-2-mailhol.vincent@wanadoo.fr Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-01-14can: dev: can_rx_offload_get_echo_skb(): extend to return can frame lengthMarc Kleine-Budde4-6/+8
In order to implement byte queue limits (bql) in CAN drivers, the length of the CAN frame needs to be passed into the networking stack after queueing and after transmission completion. To avoid to calculate this length twice, extend can_rx_offload_get_echo_skb() to return that value. Convert all users of this function, too. Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20210111141930.693847-15-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>