- 04 Aug, 2021 1 commit
-
-
Ioana Ciornei authored
Request all interrupt sources to be read and then cleared on the DPSW object. In the next patches we'll also add support for treating other interrupts. Signed-off-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 03 Aug, 2021 39 commits
-
-
Joakim Zhang authored
This patch intends to fix MAC internal delay doesn't work, due to use of_property_read_u32() incorrectly, and improve this feature a bit: 1) check the delay value if valid, only program register when it's 2000ps. 2) only enable "enet_2x_txclk" clock when require MAC internal delay. Fixes: fc539459 ("net: fec: add MAC internal delayed clock feature support") Signed-off-by:
Joakim Zhang <qiangqing.zhang@nxp.com> Link: https://lore.kernel.org/r/20210803052424.19008-1-qiangqing.zhang@nxp.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Vladimir Oltean authored
Dan Carpenter's smatch tests report that the "vid" variable, populated by sja1105_vlan_rcv when an skb is received by the tagger that has a VLAN ID which cannot be decoded by tag_8021q, may be uninitialized when used here: if (source_port == -1 || switch_id == -1) skb->dev = dsa_find_designated_bridge_port_by_vid(netdev, vid); The sja1105 driver, by construction, sets up the switch in a way that all data plane packets sent towards the CPU port are VLAN-tagged. So it is practically impossible, in a functional system, for a packet to be processed by sja1110_rcv() which is not a control packet and does not have a VLAN header either. However, it would be nice if the sja1105 tagging driver could consistently do something valid, for example fail, even if presented with packets that do not hold valid sja1105 tags. Currently it is a bit hard to argue that it does that, given the fact that a data plane packet with no VLAN tag will trigger a call to dsa_find_designated_bridge_port_by_vid with a vid argument that is an uninitialized stack variable. To fix this, we can initialize the u16 vid variable with 0, a value that can never be a bridge VLAN, so dsa_find_designated_bridge_port_by_vid will always return a NULL skb->dev. Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20210802195137.303625-1-vladimir.oltean@nxp.comSigned-off-by:
-
Vladimir Oltean authored
Nikolay points out that it is incorrect to assume that it is impossible to have an fdb entry with fdb->dst == NULL and the BR_FDB_LOCAL bit in fdb->flags not set. This is because there are reader-side places that test_bit(BR_FDB_LOCAL, &fdb->flags) without the br->hash_lock, and if the updating of the FDB entry happens on another CPU, there are no memory barriers at writer or reader side which would ensure that the reader sees the updates to both fdb->flags and fdb->dst in the same order, i.e. the reader will not see an inconsistent FDB entry. So we must be prepared to deal with FDB entries where fdb->dst and fdb->flags are in a potentially inconsistent state, and that means that fdb->dst == NULL should remain a condition to pick the net_device that we report to switchdev as being the bridge device, which is what the code did prior to the blamed patch. Fixes: 52e4bec1 ("net: bridge: switchdev: treat local FDBs the same as entries towards the bridge") Suggested-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
Alex Elder authored
This reverts commit b79c6fba, reversing these changes made to 0ac26271: commit 6a0eb6c9 ("dt-bindings: net: qcom,ipa: make imem interconnect optional") commit f8bd3c82 ("arm64: dts: qcom: sc7280: add IPA information") commit fd0f72c3 ("arm64: dts: qcom: sc7180: define ipa_fw_mem node") I intend for these commits to go through the Qualcomm repository, to avoid conflicting with other activity being merged there. Signed-off-by:
Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20210802233019.800250-1-elder@linaro.orgSigned-off-by:
-
Colin Ian King authored
There is a spelling mistake in a NL_SET_ERR_MSG_MOD message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210803105617.338546-1-colin.king@canonical.comSigned-off-by:
-
Yajun Deng authored
fib_treeref needs to be set after kzalloc. The old code had a ++ which led to the confusion when the int was replaced by a refcount_t. Fixes: 79976892 ("net: convert fib_treeref from int to refcount_t") Signed-off-by:
Yajun Deng <yajun.deng@linux.dev> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20210803073739.22339-1-yajun.deng@linux.devSigned-off-by:
-
David S. Miller authored
Arnd Bergmann says: ==================== drivers/net/Space.c cleanup I discovered that there are still a couple of drivers that rely on beiong statically initialized from drivers/net/Space.c the way we did in the last century. As it turns out, there are a couple of simplifications that can be made here, as well as some minor bugfixes. There are four classes of drivers that use this: - most 10mbit ISA bus ethernet drivers (and one 100mbit one) - both ISA localtalk drivers - several m68k ethernet drivers - one obsolete WAN driver I found that the drivers using in arch/m68k/ don't actually benefit from being probed this way as they do not rely on the netdev= command line arguments, they have simply never been changed to work like a modern driver. I had previously sent a patch to remove the sbni/granch driver, and there were no objections to this patch but forgot to resend it after some discussion about another patch in the same series. For the ISA drivers, there is usually no way to probe multiple devices at boot time other than the netdev= arguments, so all that logic is left in place for the moment, but centralized in a single file that only gets included in the kernel build if one or more of the drivers are built-in. I'm also changing the old-style init_module() functions in these drivers to static functions with a module_init() annotation, to more closely resemble modern drivers. These are the last drivers in the kernel to still use init_module/cleanup_module, removing those may enable future cleanups to the module loading process. Arnd Changes in v2: - replace xsurf100 change with Michael's version - make it PATCH instead of RFC - rebase to net-next as of August 3 ==================== Signed-off-by: -
Arnd Bergmann authored
There are a couple of ISA ethernet drivers that use the old init_module/cleanup_module function names for the main entry points, nothing else uses those any more. Change them to the documented method with module_init() and module_exit() markers next to static functions. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
This is one of very few drivers using the old init_module/cleanup_module function names. Change it over to the modern method. Signed-off-by:
-
Arnd Bergmann authored
The driver was merged in 1999 and has only ever seen treewide cleanups since then, with no indication whatsoever that anyone has actually had access to hardware for testing the patches. >From the information in the link below, it appears that the hardware is for some leased line system in Russia that has since been discontinued, and useless without any remote end to connect to. As the driver still feels like a Linux-2.2 era artifact today, it appears that the best way forward is to just delete it. Link: https://www.tms.ru/%D0%90%D0%B4%D0%B0%D0%BF%D1%82%D0%B5%D1%80_%D0%B4%D0%BB%D1%8F_%D0%B2%D1%8B%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%BD%D1%8B%D1%85_%D0%BB%D0%B8%D0%BD%D0%B8%D0%B9_Granch_SBNI12-10Signed-off-by:
-
Arnd Bergmann authored
The dscc4 driver was removed in 2019 but these Kconfig entries remain, so remove them as well. Fixes: 28c9eb90 ("net/wan: dscc4: remove broken dscc4 driver") Signed-off-by:
-
Arnd Bergmann authored
There are very few ISA drivers left that rely on the static probing from drivers/net/Space.o. Make them all select a new CONFIG_NETDEV_LEGACY_INIT symbol, and drop the entire probe logic when that is disabled. The 9 drivers that are called from Space.c are the same set that calls netdev_boot_setup_check(). Signed-off-by:
-
Arnd Bergmann authored
This is now only used by a handful of old ISA drivers, and can be moved into the file they already all depend on. Signed-off-by:
-
Michael Schmitz authored
Now that ax88796.c exports the ax_NS8390_reinit() symbol, we can include 8390.h instead of lib8390.c, avoiding duplication of that function and killing a few compile warnings in the bargain. Fixes: 861928f4 ("net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)") Signed-off-by:
Michael Schmitz <schmitzmic@gmail.com> Signed-off-by:
-
Michael Schmitz authored
The block I/O code for the new X-Surf 100 ax88796 driver needs ax_NS8390_init() for error fixup in its block_output function. Export this static function through the ax_NS8390_reinit() wrapper so we can lose the lib8380.c include in the X-Surf 100 driver. [arnd: add the declaration in the header to avoid a -Wmissing-prototypes warning] Fixes: 861928f4 ("net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)") Signed-off-by:
-
Arnd Bergmann authored
There are six m68k specific drivers that use the legacy probe method in drivers/net/Space.c. However, all of these only support a single device, and they completely ignore the command line settings from netdev_boot_setup_check, so there is really no point at all. Aside from sun3_82586, these already have a module_init function that can be used for built-in mode as well, simply by removing the #ifdef. Note that the 82596 driver was previously used on ISA as well, but that got dropped long ago. Reviewed-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Arnd Bergmann authored
There are two drivers in the cs89x0 file, with the CONFIG_CS89x0_PLATFORM symbol deciding which one is getting built. This is somewhat confusing and makes it more likely ton configure a driver that works nowhere. Split up the Kconfig option into separate ISA and PLATFORM drivers, with the ISA symbol explicitly connecting to the static probing in drivers/net/Space.c The two drivers are still mutually incompatible at compile time, which could be lifted by splitting them into multiple files, but in practice this will make no difference. The platform driver can now be enabled for compile-testing on non-ARM machines. Signed-off-by:
-
Arnd Bergmann authored
This driver never uses the information returned by netdev_boot_setup_check, and is not called by the boot-time probing from driver/net/Space.c, so just remove these stale references. Signed-off-by:
-
Arnd Bergmann authored
This driver never relies on the netdev_boot_setup_check() to get its configuration, so it can just as well do its own probing all the time. Signed-off-by:
-
Arnd Bergmann authored
The data from the kernel command line is no longer used since the probe function gets it from the platform device resources instead. The jazz version was changed to be like this in 2007, the xtensa version apparently copied the code from there. Fixes: ed9f0e0b ("remove setup of platform device from jazzsonic.c") Signed-off-by:
-
Arnd Bergmann authored
The driver has never used the netdev->{irq,base_addr,mem_start} members, so this call is completely unnecessary. Acked-by:Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== ethtool: runtime-resume netdev parent before ethtool ops If a network device is runtime-suspended then: - network device may be flagged as detached and all ethtool ops (even if not accessing the device) will fail because netif_device_present() returns false - ethtool ops may fail because device is not accessible (e.g. because being in D3 in case of a PCI device) It may not be desirable that userspace can't use even simple ethtool ops that not access the device if interface or link is down. To be more friendly to userspace let's ensure that device is runtime-resumed when executing ethtool ops in kernel. This patch series covers the typical case that the netdev parent is power- managed, e.g. a PCI device. Not sure whether cases exist where the netdev itself is power-managed. If yes then we may need an extension for this. But the series as-is at least shouldn't cause problems in that case. ==================== Signed-off-by: -
Heiner Kallweit authored
If a network device is runtime-suspended then: - network device may be flagged as detached and all ethtool ops (even if not accessing the device) will fail because netif_device_present() returns false - ethtool ops may fail because device is not accessible (e.g. because being in D3 in case of a PCI device) It may not be desirable that userspace can't use even simple ethtool ops that not access the device if interface or link is down. To be more friendly to userspace let's ensure that device is runtime-resumed when executing the respective ethtool op in kernel. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
If device is runtime-suspended and not accessible then it may be flagged as not present. If checking whether device is present is done too early then we may bail out before we have the chance to runtime-resume the device. Therefore move this check to ethnl_ops_begin(). This is in preparation of a follow-up patch that tries to runtime-resume the device before executing ethtool ops. Signed-off-by:
-
Heiner Kallweit authored
In preparation of subsequent extensions to both functions move the implementations from netlink.h to netlink.c. Signed-off-by:
-
Heiner Kallweit authored
If a network device is runtime-suspended then: - network device may be flagged as detached and all ethtool ops (even if not accessing the device) will fail because netif_device_present() returns false - ethtool ops may fail because device is not accessible (e.g. because being in D3 in case of a PCI device) It may not be desirable that userspace can't use even simple ethtool ops that not access the device if interface or link is down. To be more friendly to userspace let's ensure that device is runtime-resumed when executing the respective ethtool op in kernel. Signed-off-by:
-
Jakub Kicinski authored
We ended up merging two versions of the same patch set: commit 8fb7da9e ("virtio_net: get build_skb() buf by data ptr") commit 5c37711d ("virtio-net: fix for unable to handle page fault for address") into net, and commit 7bf64460 ("virtio-net: get build_skb() buf by data ptr") commit 6c66c147 ("virtio-net: fix for unable to handle page fault for address") into net-next. Redo the merge from commit 12628565 ("Merge ra.kernel.org:/pub/scm/linux/kernel/git/netdev/net"), so that the most recent code remains. Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: Increase maximum RX ring size when jumbo ring is unused The RX jumbo ring is automatically enabled when HW GRO/LRO is enabled or when the MTU exceeds the page size. The RX jumbo ring provides a lot more RX buffer space when it is in use. When the RX jumbo ring is not in use, some users report that the current maximum of 2K buffers is too limiting. This patchset increases the maximum to 8K buffers when the RX jumbo ring is not used. The default RX ring size is unchanged at 511. ==================== Signed-off-by: -
Michael Chan authored
The current maximum RX ring size is defined assuming the RX jumbo ring (aka aggregation ring) is used. The RX jumbo ring is automicatically used when the MTU exceeds a threshold or when rx-gro-hw/lro is enabled. The RX jumbo ring is automatically sized up to 4 times the size of the RX ring size. The BNXT_MAX_RX_DESC_CNT constant is the upper limit on the size of the RX ring whether or not the RX jumbo ring is used. Obviously, the maximum amount of RX buffer space is significantly less when the RX jumbo ring is not used. To increase flexibility for the user who does not use the RX jumbo ring, we now define a bigger maximum RX ring size when the RX jumbo ring is not used. The maximum RX ring size is now up to 8K when the RX jumbo ring is not used. The maximum completion ring size also needs to be scaled up to accomodate the larger maximum RX ring size. Note that when the RX jumbo ring is re-enabled, the RX ring size will automatically drop if it exceeds the maximum. Reviewed-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Michael Chan authored
We currently store these page addresses and DMA addreses in static arrays. On systems with 4K pages, we support up to 64 pages per completion ring. The actual number of pages for each completion ring may be much less than 64. For example, when the RX ring size is set to the default 511 entries, only 16 completion ring pages are needed per ring. In the next patch, we'll be doubling the maximum number of completion pages. So we convert to allocate these arrays as needed instead of declaring them statically. Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by:
Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by:
-
Yajun Deng authored
Those files under /proc/net/stat/ don't have vertical alignment, it looks very difficult. Modify the seq_printf statement, keep vertical alignment. v2: - Use seq_puts() and seq_printf() correctly. Reported-by:
-
Hangbin Liu authored
Add an option lacp_active, which is similar with team's runner.active. This option specifies whether to send LACPDU frames periodically. If set on, the LACPDU frames are sent along with the configured lacp_rate setting. If set off, the LACPDU frames acts as "speak when spoken to". Note, the LACPDU state frames still will be sent when init or unbind port. v2: remove module parameter Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Signed-off-by:
-
zhouchuangao authored
Duplicate include header file <linux/kernel.h> line 4: #include <linux/kernel.h> line 7: #include <linux/kernel.h> Signed-off-by:
zhouchuangao <zhouchuangao@vivo.com> Signed-off-by:
-
Len Baker authored
strcpy() performs no bounds checking on the destination buffer. This could result in linear overflows beyond the end of the buffer, leading to all kinds of misbehaviors. The safe replacement is strscpy(). Signed-off-by:
Len Baker <len.baker@gmx.com> Signed-off-by:
-
Shai Malin authored
Remove redundant prints from the iWARP SYN handling. Signed-off-by:
Ariel Elior <aelior@marvell.com> Signed-off-by:
Shai Malin <smalin@marvell.com> Signed-off-by:
-
Shai Malin authored
The device recovery flow will reset the entire HW device, in that case the DORQ HW block attention is redundant. Signed-off-by:
-
Shai Malin authored
Avoid calling the qed doorbell recovery - qed_db_rec_handler() during device recovery. Signed-off-by:
-
David S. Miller authored
Vasily Averin says: ==================== skbuff: introduce skb_expand_head() currently if skb does not have enough headroom skb_realloc_headrom is called. It is not optimal because it creates new skb. this patch set introduces new helper skb_expand_head() Unlike skb_realloc_headroom, it does not allocate a new skb if possible; copies skb->sk on new skb when as needed and frees original skb in case of failures. This helps to simplify ip[6]_finish_output2(), ip6_xmit() and few other functions in vrf, ax25 and bpf. There are few other cases where this helper can be used but it requires an additional investigations. v3 changes: - ax25 compilation warning fixed - v5.14-rc4 rebase - now it does not depend on non-committed pathces v2 changes: - helper's name was changed to skb_expand_head - fixed few mistakes inside skb_expand_head(): skb_set_owner_w should set sk on nskb kfree was replaced by kfree_skb() improved warning message - added minor refactoring in changed functions in vrf and bpf patches - removed kfree_skb() in ax25_rt_build_path caller ax25_ip_xmit ==================== Signed-off-by: -
Vasily Averin authored
Unlike skb_realloc_headroom, new helper skb_expand_head does not allocate a new skb if possible. Additionally this patch replaces commonly used dereferencing with variables. Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Signed-off-by:
-
