- 13 Nov, 2020 12 commits
-
-
Edward Cree authored
Our TSO descriptors got even more fussy. Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Martin Habets <mhabets@solarflare.com> Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: GSI register consolidation This series rearranges and consolidates some GSI register definitions. Its general aim is to make things more consistent, by: - Using enumerated types to define the values held in GSI register fields - Defining field values in "gsi_reg.h", together with the definition of the register (and field) that holds them - Format enumerated type members consistently, with hexidecimal numeric values, and assignments aligned on the same column There is one checkpatch "CHECK" warning requesting a blank line; I ignored that because my intention was to group certain definitions. ==================== Link: https://lore.kernel.org/r/20201110215922.23514-1-elder@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
Replace constants defined with an "_FVAL" suffix with values defined in enumerated types, to be consistent with other usage in the driver. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
The gsi_ch_cmd_opcode, gsi_evt_cmd_opcode, and gsi_generic_cmd_opcode enumerated types are values that fields in the GSI command registers can take on. Move their definitions out of "gsi.c" and into "gsi_reg.h", alongside the definition of registers they are associated with. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
The gsi_err_code and gsi_err_type enumerated types are values that fields in the GSI ERROR_LOG register can take on. Move their definitions out of "gsi.c" and into "gsi_reg.h", alongside the definition of the ERROR_LOG register offset and field symbols. Drop the "_ERR" suffix in the names of the gsi_err_code members. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
The gsi_channel_type enumerated type define values used for the channel type/protocol for event rings and channels. Move its definition out of "gsi.c" and into "gsi_reg.h", alongside the definition of the CH_C_CNTXT_0 register offset and its fields. Add a comment near the definition of the EV_CH_E_CNTXT_0 register indicating this type is used for its EV_CHTYPE field. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
The numeric values that represent the event ring channel type are identical to the values that represent the matching protocol used for a channel. Use a new gsi_channel_type enumerated type to represent the values programmed for both cases, using "CHANNEL_TYPE" in member names in place of "EVT_CHTYPE" and "CHANNEL_PROTOCOL". Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
Define the GSI global interrupt types with an enumerated type whose values are the bit positions representing the global interrupt types. Similarly, define the GSI general interrupt types with an enumerated type whose values are the bit positions of general interrupt types. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Wenlin Kang authored
Replace strncpy() with strscpy(), fixes the following warning: In function 'bearer_name_validate', inlined from 'tipc_enable_bearer' at net/tipc/bearer.c:246:7: net/tipc/bearer.c:141:2: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation] strncpy(name_copy, name, TIPC_MAX_BEARER_NAME); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Wenlin Kang <wenlin.kang@windriver.com> Acked-by: Ying Xue <ying.xue@windriver.com> Link: https://lore.kernel.org/r/20201112093442.8132-1-wenlin.kang@windriver.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Merge tag 'mac80211-next-for-net-next-2020-11-13' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== Some updates: * injection/radiotap updates for new test capabilities * remove WDS support - even years ago when we turned it off by default it was already basically unusable * support for HE (802.11ax) rates for beacons * support for some vendor-specific HE rates * many other small features/cleanups * tag 'mac80211-next-for-net-next-2020-11-13' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next: (21 commits) nl80211: fix kernel-doc warning in the new SAE attribute cfg80211: remove WDS code mac80211: remove WDS-related code rt2x00: remove WDS code b43legacy: remove WDS code b43: remove WDS code carl9170: remove WDS code ath9k: remove WDS code wireless: remove CONFIG_WIRELESS_WDS mac80211: assure that certain drivers adhere to DONT_REORDER flag mac80211: don't overwrite QoS TID of injected frames mac80211: adhere to Tx control flag that prevents frame reordering mac80211: add radiotap flag to assure frames are not reordered mac80211: save HE oper info in BSS config for mesh cfg80211: add support to configure HE MCS for beacon rate nl80211: fix beacon tx rate mask validation nl80211/cfg80211: fix potential infinite loop cfg80211: Add support to calculate and report 4096-QAM HE rates cfg80211: Add support to configure SAE PWE value to drivers ieee80211: Add definition for WFA DPP ... ==================== Link: https://lore.kernel.org/r/20201113101148.25268-1-johannes@sipsolutions.netSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Guillaume Nault authored
When working on the rp_filter problem, I didn't realise that disabling it on the network devices didn't cover all cases: rp_filter could also be enabled globally in the namespace, in which case it would drop packets, even if the net device has rp_filter=0. Fixes: 1ccd5833 ("selftests: disable rp_filter when testing bareudp") Fixes: bbbc7aa4 ("selftests: add test script for bareudp tunnels") Signed-off-by: Guillaume Nault <gnault@redhat.com> Link: https://lore.kernel.org/r/f2d459346471f163b239aa9d63ce3e2ba9c62895.1605107012.git.gnault@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 12 Nov, 2020 28 commits
-
-
Jakub Kicinski authored
Ido Schimmel says: ==================== mlxsw: spectrum: Prepare for XM implementation - prefix insertion and removal Jiri says: This is a preparation patchset for follow-up support of boards with extended mezzanine (XM), which is going to allow extended (scale-wise) router offload. XM requires a separate PRM register named XMDR to be used instead of RALUE to insert/update/remove FIB entries. Therefore, this patchset extends the previously introduces low-level ops to be able to have XM-specific FIB entry config implementation. Currently the existing original RALUE implementation is moved to "basic" low-level ops. Unlike legacy router, insertion/update/removal of FIB entries into XM could be done in bulks up to 4 items in a single PRM register write. That is why this patchset implements "an op context", that allows the future XM ops implementation to squash multiple FIB events to single register write. For that, the way in which the FIB events are processed by the work queue has to be changed. The conversion from 1:1 FIB event - work callback call to event queue is implemented in patch #3. Patch #4 introduces "an op context" that will allow in future to squash multiple FIB events into one XMDR register write. Patch #12 converts it from stack to be allocated per instance. Existing RALUE manipulations are pushed to ops in patch #10. Patch #13 is introducing a possibility for low-level implementation to have per FIB entry private memory. The rest of the patches are either cosmetics or smaller preparations. ==================== Link: https://lore.kernel.org/r/20201110094900.1920158-1-idosch@idosch.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Follow-up patchset introducing XMDR implementation is going to need to distinguish write and update ops. Therefore introduce "update op" and call "write op" only when new FIB entry is inserted. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
In case bulking is used, the entry that was previously added may not be yet committed to the HW as it waits in the queue for bulk send. For such entries, skip the deletion. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Prepare for the low-level ops that need to store some data alongside the fib_entry and introduce a per-fib_entry priv for ll ops. The priv is reference counted as in the follow-up patch it is going to be saved in pack() function and used later on in commit() even in case the related fib_entry gets freed in the middle. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Get the max size needed for FIB entry op context and allocate it once for the instance. Use it repeatedly from the scheduled work. By this, allow to extend the context to hold more data than it is wise to do when it was on the stack. Make sure to signalize that the context needs to be initialized in case families of subsequent FIB entries differ. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
For XMDR register it is possible to carry multiple FIB entry operations in a single write. However the FW does not restrict mixing the types of operations, make the code easier and indicate the bulking is ok only in case the bulk contains FIB operations of the same family and event. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
With follow-up introduction of XM implementation, XMDR register is going to be optionally used instead of RALUE register. Push the RALUE packing helpers and write call into low-level router ops. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Unify the RALUE register payload packing and use the __mlxsw_sp_fib_entry_ralue_pack() helper from __mlxsw_sp_router_set_abort_trap(). Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
In preparation for the change that is going to be done in the next patch, allow to pass NULL pointer to mlxsw_reg_ralue_pack4() and mlxsw_reg_ralue_pack6() helpers. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Instead of passing destination IP as a u32 value, pass it as pointer to u32. Avoid using local variable for the pointer store. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
As the RALUE packing is going to be put into op, make the user from IPIP code use the same helper as the router code does. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
As the RALUE packing is going to be pushed into an op, in preparation for that push the code into a separate function in the meantime. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Currently, RALUE payload is defined locally in the function that is calling the register write. With introduction of alternative register to RALUE, XMDR, it has to be possible to put multiple FIB entry operations into single register write. So in order to prepare for that, have per-work entry operation context and propagate it all the way down to the functions writing RALUE. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Currently, every FIB event is queued-up as a separate work to be processed. However, that allows to process only one FIB entry per work callback. In preparation of future XMDR register bulking of multiple FIB entries, convert to FIB event queue. Implement this by a list_head, adding new events to the end of the list in the FIB notify callback. That allows to process multiple events from the list inside the work callback. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Since the write/delete of FIB entry is going to be implemented by XMDR register for XM implementation, introduce RALUE-independent enum for op so the enum could be used in both RALUE and XMDR. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Don't pass RALXX register enum and rather pass enum mlxsw_sp_l3proto to __mlxsw_sp_router_set_abort_trap(). This is in preparation to fib entry pack implementation by XMDR register. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Randy Dunlap authored
Fix kconfig warning when CONFIG_NET is not set/enabled: WARNING: unmet direct dependencies detected for SKB_EXTENSIONS Depends on [n]: NET [=n] Selected by [y]: - KCOV [=y] && ARCH_HAS_KCOV [=y] && (CC_HAS_SANCOV_TRACE_PC [=y] || GCC_PLUGINS [=n]) Fixes: 6370cc3b ("net: add kcov handle to skb extensions") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Aleksandr Nogikh <nogikh@google.com> Cc: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20201110175746.11437-1-rdunlap@infradead.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Merge branch 'net-switch-further-drivers-to-core-functionality-for-handling-per-cpu-byte-packet-counters' Heiner Kallweit says: ==================== net: switch further drivers to core functionality for handling per-cpu byte/packet counters Switch further drivers to core functionality for handling per-cpu byte/packet counters. All changes are compile-tested only. ==================== Link: https://lore.kernel.org/r/5fbe3a1f-6625-eadc-b1c9-f76f78debb94@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Heiner Kallweit authored
Replace usbnet_get_stats64() with new identical core function dev_get_tstats64() in all users and remove usbnet_get_stats64(). Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Acked-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Heiner Kallweit authored
Use netdev->tstats instead of a member of usbnet for storing a pointer to the per-cpu counters. This allows us to use core functionality for statistics handling. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Heiner Kallweit authored
Use netdev->tstats instead of a member of qtnf_vif for storing a pointer to the per-cpu counters. This allows us to use core functionality for statistics handling. The driver sets netdev->needs_free_netdev, therefore freeing the per-cpu counters at the right point in time is a little bit tricky. Best option seems to be to use the ndo_init/ndo_uninit callbacks. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Acked-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Heiner Kallweit authored
Use netdev->tstats instead of a member of qmimux_priv for storing a pointer to the per-cpu counters. This allows us to use core functionality for statistics handling. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Acked-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Heiner Kallweit authored
Use netdev->tstats instead of a member of hfi1_ipoib_dev_priv for storing a pointer to the per-cpu counters. This allows us to use core functionality for statistics handling. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Acked-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Thierry Reding authored
When dumping the name and NTP servers advertised by DHCP, a blank line is emitted if either of the lists is empty. This can lead to confusing issues such as the blank line getting flagged as warning. This happens because the blank line is the result of pr_cont("\n") and that may see its level corrupted by some other driver concurrently writing to the console. Fix this by making sure that the terminating newline is only emitted if at least one entry in the lists was printed before. Reported-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20201110073757.1284594-1-thierry.reding@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Andrew Lunn says: ==================== smsc W=1 warning fixes Fixup various W=1 warnings, and then add COMPILE_TEST support, which explains why these where missed on the previous pass. v2: Use while (0) Rework buffer alignment to make it clearer v3: Access the length from the hardware and Use __always_unused to tell the compiler we want to discard the value. ==================== Link: https://lore.kernel.org/r/20201110030248.1480413-1-andrew@lunn.chSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Andrew Lunn authored
Improve the build testing of these SMSC drivers by enabling them when COMPILE_TEST is selected. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Andrew Lunn authored
drivers/net/ethernet/smsc/smc911x.c: In function ‘smc911x_hardware_send_pkt’: drivers/net/ethernet/smsc/smc911x.c:471:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 471 | cmdA = (((u32)skb->data & 0x3) << 16) | When built on 64bit targets, the skb->data pointer cannot be cast to a u32 in a meaningful way. Use uintptr_t instead. Suggested-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Andrew Lunn authored
Now that the compiler always sees the parameters passed to the DBG() macro, it gives an error message about wrong parameters. The comment says it all: /* ndev is not valid yet, so avoid passing it in. */ DBG(SMC_DEBUG_FUNC, "--> %s\n", __func__); You cannot not just pass a parameter! The DBG does not seem to have any real value, to just remove it. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-