1. 26 Mar, 2020 2 commits
  2. 25 Mar, 2020 2 commits
  3. 18 Mar, 2020 14 commits
    • Mauro Carvalho Chehab's avatar
      net: core: dev.c: fix a documentation warning · 2de9780f
      Mauro Carvalho Chehab authored
      There's a markup for link with is "foo_". On this kernel-doc
      comment, we don't want this, but instead, place a literal
      reference. So, escape the literal with ``foo``, in order to
      avoid this warning:
      
      	./net/core/dev.c:5195: WARNING: Unknown target name: "page_is".
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2de9780f
    • Mauro Carvalho Chehab's avatar
      net: phy: sfp-bus.c: get rid of docs warnings · 6497ca07
      Mauro Carvalho Chehab authored
      The indentation for the returned values are weird, causing those
      warnings:
      
      	./drivers/net/phy/sfp-bus.c:579: WARNING: Unexpected indentation.
      	./drivers/net/phy/sfp-bus.c:619: WARNING: Unexpected indentation.
      
      Use a list and change the identation for it to be properly
      parsed by the documentation toolchain.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6497ca07
    • David S. Miller's avatar
      Merge branch 'ENA-driver-bug-fixes' · 15538575
      David S. Miller authored
      Arthur Kiyanovski says:
      
      ====================
      ENA driver bug fixes
      ====================
      Acked-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15538575
    • Arthur Kiyanovski's avatar
      net: ena: fix continuous keep-alive resets · dfdde134
      Arthur Kiyanovski authored
      last_keep_alive_jiffies is updated in probe and when a keep-alive
      event is received.  In case the driver times-out on a keep-alive event,
      it has high chances of continuously timing-out on keep-alive events.
      This is because when the driver recovers from the keep-alive-timeout reset
      the value of last_keep_alive_jiffies is very old, and if a keep-alive
      event is not received before the next timer expires, the value of
      last_keep_alive_jiffies will cause another keep-alive-timeout reset
      and so forth in a loop.
      
      Solution:
      Update last_keep_alive_jiffies whenever the device is restored after
      reset.
      
      Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
      Signed-off-by: default avatarNoam Dagan <ndagan@amazon.com>
      Signed-off-by: default avatarArthur Kiyanovski <akiyano@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dfdde134
    • Arthur Kiyanovski's avatar
      net: ena: avoid memory access violation by validating req_id properly · 30623e1e
      Arthur Kiyanovski authored
      Rx req_id is an index in struct ena_eth_io_rx_cdesc_base.
      The driver should validate that the Rx req_id it received from
      the device is in range [0, ring_size -1].  Failure to do so could
      yield to potential memory access violoation.
      The validation was mistakenly done when refilling
      the Rx submission queue and not in Rx completion queue.
      
      Fixes: ad974bae ("net: ena: add support for out of order rx buffers refill")
      Signed-off-by: default avatarNoam Dagan <ndagan@amazon.com>
      Signed-off-by: default avatarArthur Kiyanovski <akiyano@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      30623e1e
    • Arthur Kiyanovski's avatar
      net: ena: fix request of incorrect number of IRQ vectors · e02ae6ed
      Arthur Kiyanovski authored
      Bug:
      In short the main issue is caused by the fact that the number of queues
      is changed using ethtool after ena_probe() has been called and before
      ena_up() was executed. Here is the full scenario in detail:
      
      * ena_probe() is called when the driver is loaded, the driver is not up
        yet at the end of ena_probe().
      * The number of queues is changed -> io_queue_count is changed as well -
        ena_up() is not called since the "dev_was_up" boolean in
        ena_update_queue_count() is false.
      * ena_up() is called by the kernel (it's called asynchronously some
        time after ena_probe()). ena_setup_io_intr() is called by ena_up() and
        it uses io_queue_count to get the suitable irq lines for each msix
        vector. The function ena_request_io_irq() is called right after that
        and it uses msix_vecs - This value only changes during ena_probe() and
        ena_restore() - to request the irq vectors. This results in "Failed to
        request I/O IRQ" error for i > io_queue_count.
      
      Numeric example:
      * After ena_probe() io_queue_count = 8, msix_vecs = 9.
      * The number of queues changes to 4 -> io_queue_count = 4, msix_vecs = 9.
      * ena_up() is executed for the first time:
        ** ena_setup_io_intr() inits the vectors only up to io_queue_count.
        ** ena_request_io_irq() calls request_irq() and fails for i = 5.
      
      How to reproduce:
      simply run the following commands:
          sudo rmmod ena && sudo insmod ena.ko;
          sudo ethtool -L eth1 combined 3;
      
      Fix:
      Use ENA_MAX_MSIX_VEC(adapter->num_io_queues + adapter->xdp_num_queues)
      instead of adapter->msix_vecs. We need to take XDP queues into
      consideration as they need to have msix vectors assigned to them as well.
      Note that the XDP cannot be attached before the driver is up and running
      but in XDP mode the issue might occur when the number of queues changes
      right after a reset trigger.
      The ENA_MAX_MSIX_VEC simply adds one to the argument since the first msix
      vector is reserved for management queue.
      
      Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
      Signed-off-by: default avatarSameeh Jubran <sameehj@amazon.com>
      Signed-off-by: default avatarArthur Kiyanovski <akiyano@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e02ae6ed
    • Arthur Kiyanovski's avatar
      net: ena: fix incorrect setting of the number of msix vectors · ce1f3521
      Arthur Kiyanovski authored
      Overview:
      We don't frequently change the msix vectors throughout the life cycle of
      the driver. We do so in two functions: ena_probe() and ena_restore().
      ena_probe() is only called when the driver is loaded. ena_restore() on the
      other hand is called during device reset / resume operations.
      
      We use num_io_queues for calculating and allocating the number of msix
      vectors. At ena_probe() this value is equal to max_num_io_queues and thus
      this is not an issue, however ena_restore() might be called after the
      number of io queues has changed.
      
      A possible bug scenario is as follows:
      
      * Change number of queues from 8 to 4.
        (num_io_queues = 4, max_num_io_queues = 8, msix_vecs = 9,)
      * Trigger reset occurs -> ena_restore is called.
        (num_io_queues = 4, max_num_io_queues =8 , msix_vecs = 5)
      * Change number of queues from 4 to 6.
        (num_io_queues = 6, max_num_io_queues = 8, msix_vecs = 5)
      * The driver will reset due to failure of check_for_rx_interrupt_queue()
      
      Fix:
      This can be easily fixed by always using max_num_io_queues to init the
      msix_vecs, since this number won't change as opposed to num_io_queues.
      
      Fixes: 4d192660 ("net: ena: multiple queue creation related cleanups")
      Signed-off-by: default avatarSameeh Jubran <sameehj@amazon.com>
      Signed-off-by: default avatarArthur Kiyanovski <akiyano@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce1f3521
    • Rayagonda Kokatanur's avatar
      net: phy: mdio-mux-bcm-iproc: check clk_prepare_enable() return value · 872307ab
      Rayagonda Kokatanur authored
      Check clk_prepare_enable() return value.
      
      Fixes: 2c723044 ("net: phy: Add pm support to Broadcom iProc mdio mux driver")
      Signed-off-by: default avatarRayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      872307ab
    • David S. Miller's avatar
      Merge branch 'net-bcmgenet-revisit-MAC-reset' · af4e6671
      David S. Miller authored
      Doug Berger says:
      
      ====================
      net: bcmgenet: revisit MAC reset
      
      Commit 3a55402c ("net: bcmgenet: use RGMII loopback for MAC
      reset") was intended to resolve issues with reseting the UniMAC
      core within the GENET block by providing better control over the
      clocks used by the UniMAC core. Unfortunately, it is not
      compatible with all of the supported system configurations so an
      alternative method must be applied.
      
      This commit set provides such an alternative. The first commit
      reverts the previous change and the second commit provides the
      alternative reset sequence that addresses the concerns observed
      with the previous implementation.
      
      This replacement implementation should be applied to the stable
      branches wherever commit 3a55402c ("net: bcmgenet: use RGMII
      loopback for MAC reset") has been applied.
      
      Unfortunately, reverting that commit may conflict with some
      restructuring changes introduced by commit 4f8d81b7 ("net:
      bcmgenet: Refactor register access in bcmgenet_mii_config").
      The first commit in this set has been manually edited to
      resolve the conflict on net/master. I would be happy to help
      stable maintainers with resolving any such conflicts if they
      occur. However, I do not expect that commit to have been
      backported to stable branch so hopefully the revert can be
      applied cleanly.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      af4e6671
    • Doug Berger's avatar
      net: bcmgenet: keep MAC in reset until PHY is up · 88f6c8bf
      Doug Berger authored
      As noted in commit 28c2d1a7 ("net: bcmgenet: enable loopback
      during UniMAC sw_reset") the UniMAC must be clocked at least 5
      cycles while the sw_reset is asserted to ensure a clean reset.
      
      That commit enabled local loopback to provide an Rx clock from the
      GENET sourced Tx clk. However, when connected in MII mode the Tx
      clk is sourced by the PHY so if an EPHY is not supplying clocks
      (e.g. when the link is down) the UniMAC does not receive the
      necessary clocks.
      
      This commit extends the sw_reset window until the PHY reports that
      the link is up thereby ensuring that the clocks are being provided
      to the MAC to produce a clean reset.
      
      One consequence is that if the system attempts to enter a Wake on
      LAN suspend state when the PHY link has not been active the MAC
      may not have had a chance to initialize cleanly. In this case, we
      remove the sw_reset and enable the WoL reception path as normal
      with the hope that the PHY will provide the necessary clocks to
      drive the WoL blocks if the link becomes active after the system
      has entered suspend.
      
      Fixes: 1c1008c7 ("net: bcmgenet: add main driver file")
      Signed-off-by: default avatarDoug Berger <opendmb@gmail.com>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      88f6c8bf
    • Doug Berger's avatar
      Revert "net: bcmgenet: use RGMII loopback for MAC reset" · 612eb1c3
      Doug Berger authored
      This reverts commit 3a55402c.
      
      This is not a good solution when connecting to an external switch
      that may not support the isolation of the TXC signal resulting in
      output driver contention on the pin.
      
      A different solution is necessary.
      Signed-off-by: default avatarDoug Berger <opendmb@gmail.com>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      612eb1c3
    • David S. Miller's avatar
      Merge branch 'net-mvmdio-avoid-error-message-for-optional-IRQ' · d36963b8
      David S. Miller authored
      Chris Packham says:
      
      ====================
      net: mvmdio: avoid error message for optional IRQ
      
      I've gone ahead an sent a revert. This is the same as the original v1 except
      I've added Andrew's review to the commit message.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d36963b8
    • Chris Packham's avatar
      net: mvmdio: avoid error message for optional IRQ · fa2632f7
      Chris Packham authored
      Per the dt-binding the interrupt is optional so use
      platform_get_irq_optional() instead of platform_get_irq(). Since
      commit 7723f4c5 ("driver core: platform: Add an error message to
      platform_get_irq*()") platform_get_irq() produces an error message
      
        orion-mdio f1072004.mdio: IRQ index 0 not found
      
      which is perfectly normal if one hasn't specified the optional property
      in the device tree.
      Signed-off-by: default avatarChris Packham <chris.packham@alliedtelesis.co.nz>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa2632f7
    • Chris Packham's avatar
      Revert "net: mvmdio: avoid error message for optional IRQ" · 028fd76b
      Chris Packham authored
      This reverts commit e1f550dc.
      platform_get_irq_optional() will still return -ENXIO when no interrupt
      is provided so the additional error handling caused the driver prone to
      fail when no interrupt was specified. Revert the change so we can apply
      the correct minimal fix.
      Signed-off-by: default avatarChris Packham <chris.packham@alliedtelesis.co.nz>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      028fd76b
  4. 17 Mar, 2020 1 commit
  5. 16 Mar, 2020 21 commits