- 08 Oct, 2020 2 commits
-
-
Lee Jones authored
None of these headers attempt to document any function parameters. Fixes the following W=1 kernel build warning(s): drivers/net/wireless/intel/iwlwifi/dvm/rs.c:165: warning: cannot understand function prototype: 'const u16 expected_tpt_legacy[IWL_RATE_COUNT] = ' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:329: warning: Function parameter or member 'priv' not described in 'rs_program_fix_rate' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:329: warning: Function parameter or member 'lq_sta' not described in 'rs_program_fix_rate' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:452: warning: Function parameter or member 'tbl' not described in 'rs_collect_tx_data' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:452: warning: Function parameter or member 'scale_index' not described in 'rs_collect_tx_data' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:452: warning: Function parameter or member 'attempts' not described in 'rs_collect_tx_data' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:452: warning: Function parameter or member 'successes' not described in 'rs_collect_tx_data' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:681: warning: Function parameter or member 'sta' not described in 'rs_use_green' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:702: warning: Function parameter or member 'lq_sta' not described in 'rs_get_supported_rates' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:702: warning: Function parameter or member 'hdr' not described in 'rs_get_supported_rates' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:702: warning: Function parameter or member 'rate_type' not described in 'rs_get_supported_rates' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:2628: warning: duplicate section name 'NOTE' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:2632: warning: Function parameter or member 'priv' not described in 'rs_initialize_lq' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:2632: warning: Function parameter or member 'sta' not described in 'rs_initialize_lq' drivers/net/wireless/intel/iwlwifi/dvm/rs.c:2632: warning: Function parameter or member 'lq_sta' not described in 'rs_initialize_lq' Cc: Johannes Berg <johannes.berg@intel.com> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Intel Linux Wireless <linuxwifi@intel.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200910065431.657636-3-lee.jones@linaro.org
-
Lee Jones authored
None of these headers attempt to document any function parameters. Fixes the following W=1 kernel build warning(s): drivers/net/wireless/intel/iwlwifi/dvm/main.c:388: warning: Function parameter or member 't' not described in 'iwl_bg_statistics_periodic' drivers/net/wireless/intel/iwlwifi/dvm/main.c:545: warning: Function parameter or member 't' not described in 'iwl_bg_ucode_trace' drivers/net/wireless/intel/iwlwifi/dvm/main.c:771: warning: Function parameter or member 'priv' not described in 'iwl_alive_start' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function parameter or member 'priv' not described in 'iwl_print_event_log' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function parameter or member 'start_idx' not described in 'iwl_print_event_log' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function parameter or member 'num_events' not described in 'iwl_print_event_log' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function parameter or member 'mode' not described in 'iwl_print_event_log' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function parameter or member 'pos' not described in 'iwl_print_event_log' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function parameter or member 'buf' not described in 'iwl_print_event_log' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function parameter or member 'bufsz' not described in 'iwl_print_event_log' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function parameter or member 'priv' not described in 'iwl_print_last_event_logs' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function parameter or member 'capacity' not described in 'iwl_print_last_event_logs' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function parameter or member 'num_wraps' not described in 'iwl_print_last_event_logs' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function parameter or member 'next_entry' not described in 'iwl_print_last_event_logs' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function parameter or member 'size' not described in 'iwl_print_last_event_logs' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function parameter or member 'mode' not described in 'iwl_print_last_event_logs' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function parameter or member 'pos' not described in 'iwl_print_last_event_logs' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function parameter or member 'buf' not described in 'iwl_print_last_event_logs' drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function parameter or member 'bufsz' not described in 'iwl_print_last_event_logs' Cc: Johannes Berg <johannes.berg@intel.com> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Intel Linux Wireless <linuxwifi@intel.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by:
-
- 05 Oct, 2020 3 commits
-
-
David S. Miller authored
Rikard Falkeborn says: ==================== net: Constify struct genl_small_ops Make a couple of static struct genl_small_ops const to allow the compiler to put them in read-only memory. Patches are independent. v2: Rebase on net-next, genl_ops -> genl_small_ops ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Rikard Falkeborn authored
The only usage of these is to assign their address to the small_ops field in the genl_family struct, which is a const pointer, and applying ARRAY_SIZE() on them. Make them const to allow the compiler to put them in read-only memory. Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by:
-
Rikard Falkeborn authored
The only usages of mptcp_pm_ops is to assign its address to the small_ops field of the genl_family struct, which is a const pointer, and applying ARRAY_SIZE() on it. Make it const to allow the compiler to put it in read-only memory. Signed-off-by:
-
- 04 Oct, 2020 35 commits
-
-
Xie He authored
1. Keep the code for the normal (non-error) flow at the lowest indentation level. And use "goto drop" for all error handling. 2. Replace code that pads short Ethernet frames with a "__skb_pad" call. 3. Change "dev_kfree_skb" to "kfree_skb" in error handling code. "kfree_skb" is the correct function to call when dropping an skb due to an error. "dev_kfree_skb", which is an alias of "consume_skb", is for dropping skbs normally (not due to an error). Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
Xie He <xie.he.0141@gmail.com> Signed-off-by:
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: net-next updates. This series starts off with the usual update of the firmware interface spec. A new firmware status bit in the interface will be used in patch add the infrastructure to read the firmware status very early during driver probe and this will allow patch #4 to do the recovery if needed. The rest of the patches add improvements to the current RX reset logic by localizing the reset to the affected RX ring only and to reset only if firmware has determined that the RX ring is in permanent error state. ==================== Signed-off-by: -
Michael Chan authored
Currently, the driver will schedule RX ring reset when we get a buffer error in the RX completion record. These RX buffer errors can be due to normal out-of-buffer conditions or a permanent error in the RX ring. Because the driver cannot distinguish between these 2 conditions, we assume all these buffer errors require reset. This is very disruptive when it is just a normal out-of-buffer condition. Newer firmware will now monitor the rings for the permanent failure and will send a notification to the driver when it happens. This allows the driver to reset only when such a notification is received. In environments where we have predominently out-of-buffer conditions, we now can avoid these unnecessary resets. Reviewed-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Michael Chan authored
There is logic in the RX path to detect unexpected handles in the RX completion. We'll print a warning and schedule a reset. The next expected handle is then set to 0xffff which is guaranteed to not match any valid handle. This will force all remaining packets in the ring to be discarded before the reset. There can be hundreds of these packets remaining in the ring and there is no need to print the warnings for these forced errors. Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by:
-
Michael Chan authored
Add a per ring rx_resets counter to count these RX resets. Signed-off-by:
-
Michael Chan authored
On some older chips, it is necessary to do a reset when we get buffer errors associated with an RX ring. These buffer errors may become frequent if the RX ring underruns under heavy traffic. The current code does a global reset of all reasources when this happens. This works but creates a big disruption of all rings when one RX ring is having problem. This patch implements a localized RX ring reset of just the RX ring having the issue. All other rings including all TX rings will not be affected by this single RX ring reset. Only the older chips prior to the P5 class supports this reset. Because it is not a global reset, packets may still be arriving while we are calling firmware to reset that ring. We need to be sure that we don't post any buffers during this time while the ring is undergoing reset. After firmware completes successfully, the ring will be in the reset state with no buffers and we can start filling it with new buffers and posting them. Reviewed-by:
-
Michael Chan authored
bnxt_init_one_rx_ring() includes logic to initialize the BDs for one RX ring and to allocate the buffers. Separate the allocation logic into a new bnxt_alloc_one_rx_ring() function. The allocation function will be used later to allocate new buffers for one specified RX ring when we reset that RX ring. Reviewed-by:
-
Michael Chan authored
bnxt_free_rx_skbs() frees all the allocated buffers and SKBs for every RX ring. Refactor this function by calling a new function bnxt_free_one_rx_ring_skbs() to free these buffers on one specified RX ring at a time. This is preparation work for resetting one RX ring during run-time. Reviewed-by:
-
Michael Chan authored
If firmware does not come out of reset, log FW health status info to provide more information on firmware status. Signed-off-by:
-
Edwin Peer authored
The NS3 SoC platforms require assistance from the OP-TEE to recover firmware if a crash occurs while no driver is bound. The CRASHED_NO_MASTER condition is recorded in the firmware status register during the crash to indicate when driver intervension is needed to coordinate a firmware reload. This condition is detected during early driver initialization in order to effect a firmware fastboot on supported platforms when necessary. Reviewed-by:
Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by:
-
Edwin Peer authored
Firmware now supports device independent discovery of the status register location. This status register can provide more detailed information about firmware errors, especially if problems occur before the HWRM interface is functioning. Attempt to map this register if it is present and report the firmware status on firmware init failures. Signed-off-by:
-
Edwin Peer authored
The allocator for the firmware health structure conflates allocation and capability checks, limiting the reusability of the code. This patch separates out the capability check and disablement and improves the warning message to better describe the consequences of an allocation failure. Signed-off-by:
-
Vasundhara Volam authored
Main changes is to extend hwrm_nvm_get_dev_info_output() for stored firmware versions and a new flag is added to fw_status_reg. Reviewed-by:
-
David S. Miller authored
Andrew Lunn says: ==================== mv88e6xxx: Add per port devlink regions This patchset extends devlink regions to support per port regions, and them makes use of them to support the ports of the mv88e6xxx switches. root@rap:~# devlink region show mdio_bus/gpio-0:00/global1: size 64 snapshot [] mdio_bus/gpio-0:00/global2: size 64 snapshot [] mdio_bus/gpio-0:00/atu: size 49152 snapshot [] mdio_bus/gpio-0:00/0/port: size 64 snapshot [] mdio_bus/gpio-0:00/1/port: size 64 snapshot [] mdio_bus/gpio-0:00/2/port: size 64 snapshot [] mdio_bus/gpio-0:00/3/port: size 64 snapshot [] mdio_bus/gpio-0:00/4/port: size 64 snapshot [] mdio_bus/gpio-0:00/5/port: size 64 snapshot [] mdio_bus/gpio-0:00/6/port: size 64 snapshot [] mdio_bus/gpio-0:00/7/port: size 64 snapshot [] mdio_bus/gpio-0:00/8/port: size 64 snapshot [] mdio_bus/gpio-0:00/9/port: size 64 snapshot [] mdio_bus/gpio-0:00/10/port: size 64 snapshot [] root@rap:~# devlink region new mdio_bus/gpio-0:00/1/port snapshot 42 root@rap:~# devlink region dump mdio_bus/gpio-0:00/1/port snapshot 42 0000000000000000 4f 1e 3e 20 00 01 01 39 3f 05 00 00 fd 07 00 00 0000000000000010 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 91 0000000000000020 00 00 00 00 00 00 00 00 00 00 00 00 22 00 00 00 0000000000000030 07 3e 00 00 00 00 00 80 00 00 00 00 00 00 5b 00 In order to support all ports of the switch, a new devlink flavour has been added for unused ports: mdio_bus/gpio-0:00/0: type notset flavour unused splittable false mdio_bus/gpio-0:00/1: type notset flavour cpu port 1 splittable false mdio_bus/gpio-0:00/2: type eth netdev red flavour physical port 2 splittable fae mdio_bus/gpio-0:00/3: type eth netdev blue flavour physical port 3 splittable fe mdio_bus/gpio-0:00/4: type eth netdev green flavour physical port 4 splittable e mdio_bus/gpio-0:00/5: type notset flavour unused splittable false mdio_bus/gpio-0:00/6: type notset flavour unused splittable false mdio_bus/gpio-0:00/7: type notset flavour unused splittable false mdio_bus/gpio-0:00/8: type eth netdev waic0 flavour physical port 8 splittable e mdio_bus/gpio-0:00/9: type notset flavour unused splittable false mdio_bus/gpio-0:00/10: type notset flavour unused splittable false The DSA core now creates the devlink port instances earlier, so that the driver setup function can make use of them. v3: Whitespace cleanup Added justification for devlink unused flavour Added Tested-by, Reviewed-by: ==================== Signed-off-by: -
Andrew Lunn authored
Add a devlink region to return the per port registers. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Andrew Lunn authored
Hide away from DSA drivers how devlink works. Signed-off-by:
-
Andrew Lunn authored
Allow DSA drivers to make use of devlink port regions, via simple wrappers. Reviewed-by:
-
Andrew Lunn authored
Allow regions to be registered to a devlink port. The same netlink API is used, but the port index is provided to indicate when a region is a port region as opposed to a device region. Reviewed-by:
-
Andrew Lunn authored
DSA drivers want to create regions on devlink ports as well as the devlink device instance, in order to export registers and other tables per port. To keep all this code together in the drivers, have the devlink ports registered early, so the setup() method can setup both device and port devlink regions. v3: Remove dp->setup Move common code out of switch statement. Fix wrong goto Signed-off-by:
-
Andrew Lunn authored
If a port is unused, still create a devlink port for it, but set the flavour to unused. This allows us to attach devlink regions to the port, etc. Reviewed-by:
-
Andrew Lunn authored
Not all ports of a switch need to be used, particularly in embedded systems. Add a port flavour for ports which physically exist in the switch, but are not connected to the front panel etc, and so are unused. By having unused ports present in devlink, it gives a more accurate representation of the hardware. It also allows regions to be associated to such ports, so allowing, for example, to determine unused ports are correctly powered off, or to compare probable reset defaults of unused ports to used ports experiences issues. Actually registering unused ports and setting the flavour to unused is optional. The DSA core will register all such switch ports, but such ports are expected to be limited in number. Bigger ASICs may decide not to list unused ports. v2: Expand the description about why it is useful Reviewed-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) Rename 'searched' column to 'clashres' in conntrack /proc/ stats to amend a recent patch, from Florian Westphal. 2) Remove unused nft_data_debug(), from YueHaibing. 3) Remove unused definitions in IPVS, also from YueHaibing. 4) Fix user data memleak in tables and objects, this is also amending a recent patch, from Jose M. Guisado. 5) Use nla_memdup() to allocate user data in table and objects, also from Jose M. Guisado 6) User data support for chains, from Jose M. Guisado 7) Remove unused definition in nf_tables_offload, from YueHaibing. 8) Use kvzalloc() in ip_set_alloc(), from Vasily Averin. 9) Fix false positive reported by lockdep in nfnetlink mutexes, from Florian Westphal. 10) Extend fast variant of cmp for neq operation, from Phil Sutter. 11) Implement fast bitwise variant, also from Phil Sutter. ==================== Signed-off-by: -
Phil Sutter authored
A typical use of bitwise expression is to mask out parts of an IP address when matching on the network part only. Optimize for this common use with a fast variant for NFT_BITWISE_BOOL-type expressions operating on 32bit-sized values. Signed-off-by:
Phil Sutter <phil@nwl.cc> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
Phil Sutter authored
Add a boolean indicating NFT_CMP_NEQ. To include it into the match decision, it is sufficient to XOR it with the data comparison's result. While being at it, store the mask that is calculated during expression init and free the eval routine from having to recalculate it each time. Signed-off-by:
-
Florian Westphal authored
From time to time there are lockdep reports similar to this one: WARNING: possible circular locking dependency detected ------------------------------------------------------ 000000004f61aa56 (&table[i].mutex){+.+.}, at: nfnl_lock [nfnetlink] but task is already holding lock: [..] (&net->nft.commit_mutex){+.+.}, at: nf_tables_valid_genid [nf_tables] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&net->nft.commit_mutex){+.+.}: [..] nf_tables_valid_genid+0x18/0x60 [nf_tables] nfnetlink_rcv_batch+0x24c/0x620 [nfnetlink] nfnetlink_rcv+0x110/0x140 [nfnetlink] netlink_unicast+0x12c/0x1e0 [..] sys_sendmsg+0x18/0x40 linux_sparc_syscall+0x34/0x44 -> #0 (&table[i].mutex){+.+.}: [..] nfnl_lock+0x24/0x40 [nfnetlink] ip_set_nfnl_get_byindex+0x19c/0x280 [ip_set] set_match_v1_checkentry+0x14/0xc0 [xt_set] xt_check_match+0x238/0x260 [x_tables] __nft_match_init+0x160/0x180 [nft_compat] [..] sys_sendmsg+0x18/0x40 linux_sparc_syscall+0x34/0x44 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&net->nft.commit_mutex); lock(&table[i].mutex); lock(&net->nft.commit_mutex); lock(&table[i].mutex); Lockdep considers this an ABBA deadlock because the different nfnl subsys mutexes reside in the same lockdep class, but this is a false positive. CPU1 table[i] refers to the nftables subsys mutex, whereas CPU1 locks the ipset subsys mutex. Yi Che reported a similar lockdep splat, this time between ipset and ctnetlink subsys mutexes. Time to place them in distinct classes to avoid these warnings. Signed-off-by:Florian Westphal <fw@strlen.de> Signed-off-by:
-
Vasily Averin authored
Currently netadmin inside non-trusted container can quickly allocate whole node's memory via request of huge ipset hashtable. Other ipset-related memory allocations should be restricted too. v2: fixed typo ALLOC -> ACCOUNT Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Signed-off-by:
-
YueHaibing authored
commit 9a32669f ("netfilter: nf_tables_offload: support indr block call") left behind this. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Matthieu Baerts authored
The MPTCP ADD_ADDR suboption with echo-flag=1 has no HMAC, the size is smaller than the one initially sent without echo-flag=1. We then need to use the correct size everywhere when we need this echo bit. Before this patch, the wrong size was reserved but the correct amount of bytes were written (and read): the remaining bytes contained garbage. Fixes: 6a6c05a8 ("mptcp: send out ADD_ADDR with echo flag") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/95Reported-and-tested-by:
Davide Caratti <dcaratti@redhat.com> Acked-by:
Geliang Tang <geliangtang@gmail.com> Signed-off-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
-
Kurt Kanzenbach authored
There is no such property as duplex-full. It's called full-duplex. Leading to reduced speed when using the example as base for a real device tree. Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
-
Kurt Kanzenbach authored
The unit address should be 1e, because the unit address is supposed to be in hexadecimal. Suggested-by:
-
Vladimir Oltean authored
This is a strictly cosmetic change that renames some macros in sja1105_dynamic_config.c. They were copy-pasted in haste and this has resulted in them having the driver prefix twice. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Replace /* no break */ comments with the new pseudo-keyword macro fallthrough[1]. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-throughSigned-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Gustavo A. R. Silva authored
Replace /* Fallthrough... */ comment with the new pseudo-keyword macro fallthrough[1]. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-throughSigned-off-by:
-
Gustavo A. R. Silva authored
Replace /* !!! fall through !!! */ comments with the new pseudo-keyword macro fallthrough[1]. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-throughSigned-off-by:
-
Gustavo A. R. Silva authored
Replace // FALLTHROUGH comment with the new pseudo-keyword macro fallthrough[1]. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-throughSigned-off-by:
-
