aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-01-11net: dsa: mv88e6xxx: deny vid 0 on the CPU port and DSA links tooVladimir Oltean1-6/+3
mv88e6xxx apparently has a problem offloading VID 0, which the 8021q module tries to install as part of commit ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)"). That mv88e6xxx restriction seems to have been introduced by the "VTU GetNext VID-1 trick to retrieve a single entry" - see commit 2fb5ef09de7c ("net: dsa: mv88e6xxx: extract single VLAN retrieval"). There is one more problem. The mv88e6xxx CPU port and DSA links do not report properly in the prepare phase what are the VLANs that they can offload. They'll say they can offload everything: mv88e6xxx_port_vlan_prepare -> mv88e6xxx_port_check_hw_vlan: /* DSA and CPU ports have to be members of multiple vlans */ if (dsa_is_dsa_port(ds, port) || dsa_is_cpu_port(ds, port)) return 0; Except that if you actually try to commit to it, they'll error out and print this message: [ 32.802438] mv88e6085 d0032004.mdio-mii:12: p9: failed to add VLAN 0t which comes from: mv88e6xxx_port_vlan_add -> mv88e6xxx_port_vlan_join: if (!vid) return -EOPNOTSUPP; What prevents this condition from triggering in real life? The fact that when a DSA_NOTIFIER_VLAN_ADD is emitted, it never targets a DSA link directly. Instead, the notifier will always target either a user port or a CPU port. DSA links just happen to get dragged in by: static bool dsa_switch_vlan_match(struct dsa_switch *ds, int port, struct dsa_notifier_vlan_info *info) { ... if (dsa_is_dsa_port(ds, port)) return true; ... } So for every DSA VLAN notifier, during the prepare phase, it will just so happen that there will be somebody to say "no, don't do that". This will become a problem when the switchdev prepare/commit transactional model goes away. Every port needs to think on its own. DSA links can no longer bluff and rely on the fact that the prepare phase will not go through to the end, because there will be no prepare phase any longer. Fix this issue before it becomes a problem, by having the "vid == 0" check earlier than the check whether we are a CPU port / DSA link or not. Also, the "vid == 0" check becomes unnecessary in the .port_vlan_add callback, so we can remove it. 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-11net: switchdev: remove vid_begin -> vid_end range from VLAN objectsVladimir Oltean19-550/+314
The call path of a switchdev VLAN addition to the bridge looks something like this today: nbp_vlan_init | __br_vlan_set_default_pvid | | | | | br_afspec | | | | | | | v | | | br_process_vlan_info | | | | | | | v | | | br_vlan_info | | | / \ / | | / \ / | | / \ / | | / \ / v v v v v nbp_vlan_add br_vlan_add ------+ | ^ ^ | | | / | | | | / / / | \ br_vlan_get_master/ / v \ ^ / / br_vlan_add_existing \ | / / | \ | / / / \ | / / / \ | / / / \ | / / / v | | v / __vlan_add / / | / / | / v | / __vlan_vid_add | / \ | / v v v br_switchdev_port_vlan_add The ranges UAPI was introduced to the bridge in commit bdced7ef7838 ("bridge: support for multiple vlans and vlan ranges in setlink and dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec) have always been passed one by one, through struct bridge_vlan_info tmp_vinfo, to br_vlan_info. So the range never went too far in depth. Then Scott Feldman introduced the switchdev_port_bridge_setlink function in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink"). That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made full use of the range. But switchdev_port_bridge_setlink was called like this: br_setlink -> br_afspec -> switchdev_port_bridge_setlink Basically, the switchdev and the bridge code were not tightly integrated. Then commit 41c498b9359e ("bridge: restore br_setlink back to original") came, and switchdev drivers were required to implement .ndo_bridge_setlink = switchdev_port_bridge_setlink for a while. In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op first in __vlan_vid_add/del") finally made switchdev penetrate the br_vlan_info() barrier and start to develop the call path we have today. But remember, br_vlan_info() still receives VLANs one by one. Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit 29ab586c3d83 ("net: switchdev: Remove bridge bypass support from switchdev") so that drivers would not implement .ndo_bridge_setlink any longer. The switchdev_port_bridge_setlink also got deleted. This refactoring removed the parallel bridge_setlink implementation from switchdev, and left the only switchdev VLAN objects to be the ones offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add (the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about bridge VLANs")). That is to say, today the switchdev VLAN object ranges are not used in the kernel. Refactoring the above call path is a bit complicated, when the bridge VLAN call path is already a bit complicated. Let's go off and finish the job of commit 29ab586c3d83 by deleting the bogus iteration through the VLAN ranges from the drivers. Some aspects of this feature never made too much sense in the first place. For example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID flag supposed to mean, when a port can obviously have a single pvid? This particular configuration _is_ denied as of commit 6623c60dc28e ("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API perspective, the driver still has to play pretend, and only offload the vlan->vid_end as pvid. And the addition of a switchdev VLAN object can modify the flags of another, completely unrelated, switchdev VLAN object! (a VLAN that is PVID will invalidate the PVID flag from whatever other VLAN had previously been offloaded with switchdev and had that flag. Yet switchdev never notifies about that change, drivers are supposed to guess). Nonetheless, having a VLAN range in the API makes error handling look scarier than it really is - unwinding on errors and all of that. When in reality, no one really calls this API with more than one VLAN. It is all unnecessary complexity. And despite appearing pretentious (two-phase transactional model and all), the switchdev API is really sloppy because the VLAN addition and removal operations are not paired with one another (you can add a VLAN 100 times and delete it just once). The bridge notifies through switchdev of a VLAN addition not only when the flags of an existing VLAN change, but also when nothing changes. There are switchdev drivers out there who don't like adding a VLAN that has already been added, and those checks don't really belong at driver level. But the fact that the API contains ranges is yet another factor that prevents this from being addressed in the future. Of the existing switchdev pieces of hardware, it appears that only Mellanox Spectrum supports offloading more than one VLAN at a time, through mlxsw_sp_port_vlan_set. I have kept that code internal to the driver, because there is some more bookkeeping that makes use of it, but I deleted it from the switchdev API. But since the switchdev support for ranges has already been de facto deleted by a Mellanox employee and nobody noticed for 4 years, I'm going to assume it's not a biggie. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-11r8169: deprecate support for RTL_GIGA_MAC_VER_27Heiner Kallweit1-2/+6
RTL8168dp is ancient anyway, and I haven't seen any trace of its early version 27 yet. This chip versions needs quite some special handling, therefore it would facilitate driver maintenance if support for it could be dropped. For now just disable detection of this chip version. If nobody complains we can remove support for it in the near future. v2: - extend unknown chip version error message Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/ca98f018-a0e1-8762-e95c-f0ad773a0271@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09net: dsa: bcm_sf2: support BCM4908's integrated switchRafał Miłecki4-3/+49
BCM4908 family SoCs come with integrated Starfighter 2 switch. Its registers layout it a mix of BCM7278 and BCM7445. It has 5 integrated PHYs and 8 ports. It also supports RGMII and SerDes. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210106213202.17459-3-zajec5@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09r8169: don't wakeup-enable device on shutdown if WOL is disabledHeiner Kallweit1-1/+1
If WOL isn't enabled, then there's no need to enable wakeup from D3 on system shutdown. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09r8169: improve rtl_ocp_reg_failureHeiner Kallweit1-11/+6
Use WARN_ONCE here to get a call trace in case of a problem. This facilitates finding the offending code part. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09r8169: replace BUG_ON with WARN in _rtl_eri_writeHeiner Kallweit1-1/+3
Use WARN here to avoid stopping the system. In addition print the addr and mask values that triggered the warning. v2: - return on WARN to avoid an invalid register write Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09dpaa2-mac: remove a comment regarding pause settingsIoana Ciornei1-3/+0
The MC firmware takes these PAUSE/ASYM_PAUSE flags provided by the driver, transforms them back into rx/tx pause enablement status and applies them to hardware. We are not losing information by this transformation, thus remove the comment. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09dpaa2-mac: remove an unnecessary checkIoana Ciornei1-24/+19
The dpaa2-eth driver has phylink integration only if the connected dpmac object is in TYPE_PHY (aka the PCS/PHY etc link status is managed by Linux instead of the firmware). The check is thus unnecessary because the code path that reaches the .mac_link_up() callback is only with TYPE_PHY dpmac objects. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09dpaa2-eth: retry the probe when the MAC is not yet discovered on the busIoana Ciornei1-1/+5
The fsl_mc_get_endpoint() function now returns -EPROBE_DEFER when the dpmac device was not yet discovered by the fsl-mc bus. When this happens, pass the error code up so that we can retry the probe at a later time. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09bus: fsl-mc: return -EPROBE_DEFER when a device is not yet discoveredIoana Ciornei1-0/+9
The fsl_mc_get_endpoint() should return a pointer to the connected fsl_mc device, if there is one. By interrogating the MC firmware, we know if there is an endpoint or not so when the endpoint device is actually searched on the fsl-mc bus and not found we are hitting the case in which the device has not been yet discovered by the bus. Return -EPROBE_DEFER so that callers can differentiate this case. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Acked-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09dpaa2-mac: export MAC counters even when in TYPE_FIXEDIoana Ciornei4-53/+39
If the network interface object is connected to a MAC of TYPE_FIXED, the link status management is handled exclusively by the firmware. This does not mean that the driver cannot access the MAC counters and export them in ethtool. For this to happen, we open the attached dpmac device and keep a pointer to it in priv->mac. Because of this, all the checks in the driver of the following form 'if (priv->mac)' have to be updated to actually check the dpmac attribute and not rely on the presence of a non-NULL value. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09dpaa2-mac: split up initializing the MAC object from connecting to itIoana Ciornei3-29/+59
Split up the initialization phase of the dpmac object from actually configuring the phylink instance, connecting to it and configuring the MAC. This is done so that even though the dpni object is connected to a dpmac which has link management handled by the firmware we are still able to export the MAC counters. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09ice: drop dead code in ice_receive_skb()Eric Dumazet1-6/+1
napi_gro_receive() can never return GRO_DROP GRO_DROP can only be returned from napi_gro_frags() which is the other NAPI GRO entry point. Followup patch will remove GRO_DROP, because drivers are not supposed to call napi_gro_frags() if prior napi_get_frags() has failed. Note that I have left the gro_dropped variable. I leave to ice maintainers the decision to further remove it from ethtool -S results. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09net: ipa: support COMPILE_TESTAlex Elder1-4/+6
Arrange for the IPA driver to be built when COMPILE_TEST is enabled. Update the help text to reflect that we support two Qualcomm SoCs. Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09net: ipa: declare the page pointer type in "gsi_trans.h"Alex Elder1-0/+1
The second argument to gsi_trans_page_add() is a page pointer. That declaration is found in header files used by "gsi_trans.h" for (at least) arm64 and x86 builds, but apparently not for alpha builds. Fix this by adding a declaration of struct page to the top of "gsi_trans.h". Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-09ibmvnic: merge do_change_param_reset into do_resetLijun Pan1-110/+44
Commit b27507bb59ed ("net/ibmvnic: unlock rtnl_lock in reset so linkwatch_event can run") introduced do_change_param_reset function to solve the rtnl lock issue. Majority of the code in do_change_param_reset duplicates do_reset. Also, we can handle the rtnl lock issue in do_reset itself. Hence merge do_change_param_reset back into do_reset to clean up the code. Signed-off-by: Lijun Pan <ljp@linux.ibm.com> Link: https://lore.kernel.org/r/20210106213514.76027-1-ljp@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-08ppp: clean up endianness conversionsJulian Wiedmann1-5/+3
sparse complains about some harmless endianness issues: > drivers/net/ppp/pptp.c:281:21: warning: incorrect type in assignment (different base types) > drivers/net/ppp/pptp.c:281:21: expected unsigned int [usertype] ack > drivers/net/ppp/pptp.c:281:21: got restricted __be32 > drivers/net/ppp/pptp.c:283:23: warning: cast to restricted __be32 Here 'ack' is assigned a value in network-order, and then also the byte-swapped value in host-order. Clean this up by doing the byte-swap as part of the assignment. > drivers/net/ppp/pptp.c:358:26: warning: cast from restricted __be16 > drivers/net/ppp/pptp.c:358:26: warning: incorrect type in argument 1 (different base types) > drivers/net/ppp/pptp.c:358:26: expected unsigned short [usertype] call_id > drivers/net/ppp/pptp.c:358:26: got restricted __be16 [usertype] Here we use the wrong flavour of byte-swap. Use ntohs(), which of course gives the same result. Cc: Dmitry Kozlov <xeb@mail.ru> Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Link: https://lore.kernel.org/r/20210107143956.25549-1-jwi@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-08net: broadcom: share header defining UniMAC registersRafał Miłecki6-186/+130
UniMAC is integrated into multiple Broadcom's Ethernet controllers so use a shared header file for it and avoid some code duplication. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Doug Berger <opendmb@gmail.com> Link: https://lore.kernel.org/r/20210107180051.1542-2-zajec5@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-08bgmac: add bgmac_umac_*() helpers for accessing UniMAC registersRafał Miłecki2-40/+55
UniMAC is a hardware block commonly used in Broadcom Ethernet controllers that should get its own header file. Not every controller has it mapped at the 0x800 offset so add bgmac access helpers. They will allow using shared register defines. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210107180051.1542-1-zajec5@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-08ravb: update "undocumented" annotationsSergey Shtylyov1-13/+13
The "undocumented" annotations in the EtherAVB driver were done against the R-Car gen2 manuals; most of these registers/bits were then described in the R-Car gen3 manuals -- reflect this fact in the annotations (note that ECSIPR.LCHNGIP was documented in the recent R-Car gen2 manual)... Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-08ravb: remove APSR_DMSergey Shtylyov2-9/+8
According to the R-Car Series, 3rd Generation User's Manual: Hardware, Rev. 1.50, there's no APSR.DM field, instead there are 2 independent RX/TX clock internal delay bits. Follow the suit: remove #define APSR_DM and rename #define's APSR_DM_{R|T}DM to APSR_{R|T}DM. While at it, do several more things to the declaration of *enum* APSR_BIT: - remove superfluous indentation; - annotate APSR_MEMS as undocumented; - annotate APSR as R-Car Gen3 only. Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski56-292/+602
Trivial conflict in CAN on file rename. Conflicts: drivers/net/can/m_can/tcan4x5x-core.c Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-08Merge tag 'net-5.11-rc3-2' of ↵Linus Torvalds43-244/+345
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull more networking fixes from Jakub Kicinski: "Slightly lighter pull request to get back into the Thursday cadence. Current release - always broken: - can: mcp251xfd: fix Tx/Rx ring buffer driver race conditions - dsa: hellcreek: fix led_classdev build errors Previous releases - regressions: - ipv6: fib: flush exceptions when purging route to avoid netdev reference leak - ip_tunnels: fix pmtu check in nopmtudisc mode - ip: always refragment ip defragmented packets to avoid MTU issues when forwarding through tunnels, correct "packet too big" message is prohibitively tricky to generate - s390/qeth: fix locking for discipline setup / removal and during recovery to prevent both deadlocks and races - mlx5: Use port_num 1 instead of 0 when delete a RoCE address Previous releases - always broken: - cdc_ncm: correct overhead calculation in delayed_ndp_size to prevent out of bound accesses with Huawei 909s-120 LTE module - fix stmmac dwmac-sun8i suspend/resume: - PHY being left powered off - MAC syscon configuration being reset - reference to the reset controller being improperly dropped - qrtr: fix null-ptr-deref in qrtr_ns_remove - can: tcan4x5x: fix bittiming const, use common bittiming from m_can driver - mlx5e: CT: Use per flow counter when CT flow accounting is enabled - mlx5e: Fix SWP offsets when vlan inserted by driver Misc: - bpf: Fix a task_iter bug caused by a bpf -> net merge conflict resolution And the usual many fixes to various error paths" * tag 'net-5.11-rc3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (69 commits) net: dsa: lantiq_gswip: Exclude RMII from modes that report 1 GbE s390/qeth: fix L2 header access in qeth_l3_osa_features_check() s390/qeth: fix locking for discipline setup / removal s390/qeth: fix deadlock during recovery selftests: fib_nexthops: Fix wrong mausezahn invocation nexthop: Bounce NHA_GATEWAY in FDB nexthop groups nexthop: Unlink nexthop group entry in error path nexthop: Fix off-by-one error in error path octeontx2-af: fix memory leak of lmac and lmac->name chtls: Fix chtls resources release sequence chtls: Added a check to avoid NULL pointer dereference chtls: Replace skb_dequeue with skb_peek chtls: Avoid unnecessary freeing of oreq pointer chtls: Fix panic when route to peer not configured chtls: Remove invalid set_tcb call chtls: Fix hardware tid leak net: ip: always refragment ip defragmented packets net: fix pmtu check in nopmtudisc mode selftests: netfilter: add selftest for ipip pmtu discovery with enabled connection tracking docs: octeontx2: tune rst markup ...
2021-01-08Revert "init/console: Use ttynull as a fallback when there is no console"Petr Mladek3-19/+16
This reverts commit 757055ae8dedf5333af17b3b5b4b70ba9bc9da4e. The commit caused that ttynull was used as the default console on several systems[1][2][3]. As a result, the console was blank even when a better alternative existed. It happened when there was no console configured on the command line and ttynull_init() was the first initcall calling register_console(). Or it happened when /dev/ did not exist when console_on_rootfs() was called. It was not able to open /dev/console even though a console driver was registered. It tried to add ttynull console but it obviously did not help. But ttynull became the preferred console and was used by /dev/console when it was available later. The commit tried to fix a historical problem that have been there for ages. The primary motivation was the commit 3cffa06aeef7ece30f6 ("printk/console: Allow to disable console output by using console="" or console=null"). It provided a clean solution for a workaround that was widely used and worked only by chance. This revert causes that the console="" or console=null command line options will again work only by chance. These options will cause that a particular console will be preferred and the default (tty) ones will not get enabled. There will be no console registered at all. As a result there won't be stdin, stdout, and stderr for the init process. But it worked exactly this way even before. The proper solution has to fulfill many conditions: + Register ttynull only when explicitly required or as the ultimate fallback. + ttynull should get associated with /dev/console but it must not become preferred console when used as a fallback. Especially, it must still be possible to replace it by a better console later. Such a change requires clean up of the register_console() code. Otherwise, it would be even harder to follow. Especially, the use of has_preferred_console and CON_CONSDEV flag is tricky. The clean up is risky. The ordering of consoles is not well defined. And any changes tend to break existing user settings. Do the revert at the least risky solution for now. [1] https://lore.kernel.org/linux-kselftest/20201221144302.GR4077@smile.fi.intel.com/ [2] https://lore.kernel.org/lkml/d2a3b3c0-e548-7dd1-730f-59bc5c04e191@synopsys.com/ [3] https://patchwork.ozlabs.org/project/linux-um/patch/20210105120128.10854-1-thomas@m3y3r.de/ Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reported-by: Vineet Gupta <vgupta@synopsys.com> Reported-by: Thomas Meyer <thomas@m3y3r.de> Signed-off-by: Petr Mladek <pmladek@suse.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-01-07Merge tag 'mlx5-fixes-2021-01-07' of ↵Jakub Kicinski12-65/+120
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5 fixes 2021-01-07 * tag 'mlx5-fixes-2021-01-07' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux: net/mlx5e: Fix memleak in mlx5e_create_l2_table_groups net/mlx5e: Fix two double free cases net/mlx5: Release devlink object if adev fails net/mlx5e: ethtool, Fix restriction of autoneg with 56G net/mlx5e: In skb build skip setting mark in switchdev mode net/mlx5: E-Switch, fix changing vf VLANID net/mlx5e: Fix SWP offsets when vlan inserted by driver net/mlx5e: CT: Use per flow counter when CT flow accounting is enabled net/mlx5: Use port_num 1 instead of 0 when delete a RoCE address net/mlx5e: Add missing capability check for uplink follow net/mlx5: Check if lag is supported before creating one ==================== Link: https://lore.kernel.org/r/20210107202845.470205-1-saeed@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07net: dsa: lantiq_gswip: Exclude RMII from modes that report 1 GbEAleksander Jan Bajkowski1-3/+4
Exclude RMII from modes that report 1 GbE support. Reduced MII supports up to 100 MbE. Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210107195818.3878-1-olek2@wp.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07s390/qeth: fix L2 header access in qeth_l3_osa_features_check()Julian Wiedmann1-1/+1
ip_finish_output_gso() may call .ndo_features_check() even before the skb has a L2 header. This conflicts with qeth_get_ip_version()'s attempt to inspect the L2 header via vlan_eth_hdr(). Switch to vlan_get_protocol(), as already used further down in the common qeth_features_check() path. Fixes: f13ade199391 ("s390/qeth: run non-offload L3 traffic over common xmit path") Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07s390/qeth: fix locking for discipline setup / removalJulian Wiedmann3-10/+7
Due to insufficient locking, qeth_core_set_online() and qeth_dev_layer2_store() can run in parallel, both attempting to load & setup the discipline (and stepping on each other toes along the way). A similar race can also occur between qeth_core_remove_device() and qeth_dev_layer2_store(). Access to .discipline is meant to be protected by the discipline_mutex, so add/expand the locking in qeth_core_remove_device() and qeth_core_set_online(). Adjust the locking in qeth_l*_remove_device() accordingly, as it's now handled by the callers in a consistent manner. Based on an initial patch by Ursula Braun. Fixes: 9dc48ccc68b9 ("qeth: serialize sysfs-triggered device configurations") Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07s390/qeth: fix deadlock during recoveryJulian Wiedmann4-18/+34
When qeth_dev_layer2_store() - holding the discipline_mutex - waits inside qeth_l*_remove_device() for a qeth_do_reset() thread to complete, we can hit a deadlock if qeth_do_reset() concurrently calls qeth_set_online() and thus tries to aquire the discipline_mutex. Move the discipline_mutex locking outside of qeth_set_online() and qeth_set_offline(), and turn the discipline into a parameter so that callers understand the dependency. To fix the deadlock, we can now relax the locking: As already established, qeth_l*_remove_device() waits for qeth_do_reset() to complete. So qeth_do_reset() itself is under no risk of having card->discipline ripped out while it's running, and thus doesn't need to take the discipline_mutex. Fixes: 9dc48ccc68b9 ("qeth: serialize sysfs-triggered device configurations") Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07octeontx2-af: fix memory leak of lmac and lmac->nameColin Ian King1-3/+11
Currently the error return paths don't kfree lmac and lmac->name leading to some memory leaks. Fix this by adding two error return paths that kfree these objects Addresses-Coverity: ("Resource leak") Fixes: 1463f382f58d ("octeontx2-af: Add support for CGX link management") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210107123916.189748-1-colin.king@canonical.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07chtls: Fix chtls resources release sequenceAyush Sawal1-4/+4
CPL_ABORT_RPL is sent after releasing the resources by calling chtls_release_resources(sk); and chtls_conn_done(sk); eventually causing kernel panic. Fixing it by calling release in appropriate order. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07chtls: Added a check to avoid NULL pointer dereferenceAyush Sawal1-0/+5
In case of server removal lookup_stid() may return NULL pointer, which is used as listen_ctx. So added a check before accessing this pointer. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07chtls: Replace skb_dequeue with skb_peekAyush Sawal1-1/+1
The skb is unlinked twice, one in __skb_dequeue in function chtls_reset_synq() and another in cleanup_syn_rcv_conn(). So in this patch using skb_peek() instead of __skb_dequeue(), so that unlink will be handled only in cleanup_syn_rcv_conn(). Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07chtls: Avoid unnecessary freeing of oreq pointerAyush Sawal1-3/+1
In chtls_pass_accept_request(), removing the chtls_reqsk_free() call to avoid oreq freeing twice. Here oreq is the pointer to struct request_sock. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Rohit Maheshwari <rohitm@chelsio.com> Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07chtls: Fix panic when route to peer not configuredAyush Sawal1-2/+12
If route to peer is not configured, we might get non tls devices from dst_neigh_lookup() which is invalid, adding a check to avoid it. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Rohit Maheshwari <rohitm@chelsio.com> Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07chtls: Remove invalid set_tcb callAyush Sawal1-3/+0
At the time of SYN_RECV, connection information is not initialized at FW, updating tcb flag over uninitialized connection causes adapter crash. We don't need to update the flag during SYN_RECV state, so avoid this. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Rohit Maheshwari <rohitm@chelsio.com> Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07chtls: Fix hardware tid leakAyush Sawal1-36/+3
send_abort_rpl() is not calculating cpl_abort_req_rss offset and ends up sending wrong TID with abort_rpl WR causng tid leaks. Replaced send_abort_rpl() with chtls_send_abort_rpl() as it is redundant. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Rohit Maheshwari <rohitm@chelsio.com> Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07tap/tun: add skb_zcopy_init() helper for initialization.Jonathan Lemon3-4/+3
Replace direct assignments with skb_zcopy_init() for zerocopy cases where a new skb is initialized, without changing the reference counts. Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07net: group skb_shinfo zerocopy related bits together.Jonathan Lemon3-6/+4
In preparation for expanded zerocopy (TX and RX), move the zerocopy related bits out of tx_flags into their own flag word. Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07skbuff: Add skb parameter to the ubuf zerocopy callbackJonathan Lemon5-6/+9
Add an optional skb parameter to the zerocopy callback parameter, which is passed down from skb_zcopy_clear(). This gives access to the original skb, which is needed for upcoming RX zero-copy error handling. Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07net: stmmac: dwmac-meson8b: add support for the RGMII RX delay on G12AMartin Blumenstingl1-13/+48
Amlogic Meson G12A (and newer: G12B, SM1) SoCs have a more advanced RX delay logic. Instead of fine-tuning the delay in the nanoseconds range it now allows tuning in 200 picosecond steps. This support comes with new bits in the PRG_ETH1[19:16] register. Add support for validating the RGMII RX delay as well as configuring the register accordingly on these platforms. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07net: stmmac: dwmac-meson8b: move RGMII delays into a separate functionMartin Blumenstingl1-1/+12
Newer SoCs starting with the Amlogic Meson G12A have more a precise RGMII RX delay configuration register. This means more complexity in the code. Extract the existing RGMII delay configuration code into a separate function to make it easier to read/understand even when adding more logic in the future. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07net: stmmac: dwmac-meson8b: use picoseconds for the RGMII RX delayMartin Blumenstingl1-8/+13
Amlogic Meson G12A, G12B and SM1 SoCs have a more advanced RGMII RX delay register which allows picoseconds precision. Parse the new "rx-internal-delay-ps" property or fall back to the value from the old "amlogic,rx-delay-ns" property. No upstream DTB uses the old "amlogic,rx-delay-ns" property (yet). Only include minimalistic logic to fall back to the old property, without any special validation (for example if the old and new property are given at the same time). Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07net: stmmac: dwmac-meson8b: fix enabling the timing-adjustment clockMartin Blumenstingl1-1/+1
The timing-adjustment clock only has to be enabled when a) there is a 2ns RX delay configured using device-tree and b) the phy-mode indicates that the RX delay should be enabled. Only enable the RX delay if both are true, instead of (by accident) also enabling it when there's the 2ns RX delay configured but the phy-mode incicates that the RX delay is not used. Fixes: 9308c47640d515 ("net: stmmac: dwmac-meson8b: add support for the RX delay configuration") Reported-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07net: systemport: use standard netdevice notifier to detect DSA presenceVladimir Oltean2-46/+37
The SYSTEMPORT driver maps each port of the embedded Broadcom DSA switch port to a certain queue of the master Ethernet controller. For that it currently uses a dedicated notifier infrastructure which was added in commit 60724d4bae14 ("net: dsa: Add support for DSA specific notifiers"). However, since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), DSA is actually an upper of the Broadcom SYSTEMPORT as far as the netdevice adjacency lists are concerned. So naturally, the plain NETDEV_CHANGEUPPER net device notifiers are emitted. It looks like there is enough API exposed by DSA to the outside world already to make the call_dsa_notifiers API redundant. So let's convert its only user to plain netdev notifiers. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07net: dsa: move the Broadcom tag information in a separate header fileVladimir Oltean1-0/+1
It is a bit strange to see something as specific as Broadcom SYSTEMPORT bits in the main DSA include file. Move these away into a separate header, and have the tagger and the SYSTEMPORT driver include them. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07net: dsa: ocelot: request DSA to fix up lack of address learning on CPU portVladimir Oltean1-0/+1
Given the following setup: ip link add br0 type bridge ip link set eno0 master br0 ip link set swp0 master br0 ip link set swp1 master br0 ip link set swp2 master br0 ip link set swp3 master br0 Currently, packets received on a DSA slave interface (such as swp0) which should be routed by the software bridge towards a non-switch port (such as eno0) are also flooded towards the other switch ports (swp1, swp2, swp3) because the destination is unknown to the hardware switch. This patch addresses the issue by monitoring the addresses learnt by the software bridge on eno0, and adding/deleting them as static FDB entries on the CPU port accordingly. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07r8169: improve RTL8168g PHY suspend quirkHeiner Kallweit1-26/+26
According to Realtek the ERI register 0x1a8 quirk is needed to work around a hw issue with the PHY on RTL8168g. The register needs to be changed before powering down the PHY. Currently we don't meet this requirement, however I'm not aware of any problems caused by this. Therefore I see the change as an improvement. The PHY driver has no means to access the chip ERI registers, therefore we have to intercept MDIO writes to BMCR register. If the BMCR_PDOWN bit is going to be set, then let's apply the quirk before actually powering down the PHY. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-07r8169: move ERI access functions to avoid forward declarationHeiner Kallweit1-64/+64
No functional change here. We just move a code block to avoid a function forward declaration in a subsequent change. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Powered by cgit, Gruvboxed by Blaster4385.