1. 06 Nov, 2020 35 commits
    • Ido Schimmel's avatar
      nexthop: Emit a notification when a nexthop group is reduced · 833a1065
      Ido Schimmel authored
      When a single nexthop is deleted, the configuration of all the groups
      using the nexthop is effectively modified. In this case, emit a
      notification in the nexthop notification chain for each modified group
      so that listeners would not need to keep track of which nexthops are
      member in which groups.
      
      In the rare cases where the notification fails, emit an error to the
      kernel log. This is done by allocating extack on the stack and printing
      the error logged by the listener that rejected the notification.
      
      Changes since RFC:
      * Allocate extack on the stack
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      833a1065
    • Ido Schimmel's avatar
      nexthop: Emit a notification when a nexthop group is modified · f17bc33d
      Ido Schimmel authored
      When a single nexthop is replaced, the configuration of all the groups
      using the nexthop is effectively modified. In this case, emit a
      notification in the nexthop notification chain for each modified group
      so that listeners would not need to keep track of which nexthops are
      member in which groups.
      
      The notification can only be emitted after the new configuration (i.e.,
      'struct nh_info') is pointed at by the old shell (i.e., 'struct
      nexthop'). Before that the configuration of the nexthop groups is still
      the same as before the replacement.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f17bc33d
    • Ido Schimmel's avatar
      nexthop: Emit a notification when a single nexthop is replaced · 8c09c9f9
      Ido Schimmel authored
      The notification is emitted after all the validation checks were
      performed, but before the new configuration (i.e., 'struct nh_info') is
      pointed at by the old shell (i.e., 'struct nexthop'). This prevents the
      need to perform rollback in case the notification is vetoed.
      
      The next patch will also emit a replace notification for all the nexthop
      groups in which the nexthop is used.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8c09c9f9
    • Ido Schimmel's avatar
      nexthop: Emit a notification when a nexthop group is replaced · d144cc5f
      Ido Schimmel authored
      Emit a notification in the nexthop notification chain when an existing
      nexthop group is replaced.
      
      The notification is emitted after all the validation checks were
      performed, but before the new configuration (i.e., 'struct nh_grp') is
      pointed at by the old shell (i.e., 'struct nexthop'). This prevents the
      need to perform rollback in case the notification is vetoed.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d144cc5f
    • Ido Schimmel's avatar
      nexthop: Emit a notification when a nexthop is added · 732d167b
      Ido Schimmel authored
      Emit a notification in the nexthop notification chain when a new nexthop
      is added (not replaced). The nexthop can either be a new group or a
      single nexthop.
      
      The notification is sent after the nexthop is inserted into the
      red-black tree, as listeners might need to callback into the nexthop
      code with the nexthop ID in order to mark the nexthop as offloaded.
      
      A 'REPLACE' notification is emitted instead of 'ADD' as the distinction
      between the two is not important for in-kernel listeners. In case the
      listener is not familiar with the encoded nexthop ID, it can simply
      treat it as a new one. This is also consistent with the route offload
      API.
      
      Changes since RFC:
      * Reword commit message
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      732d167b
    • Ido Schimmel's avatar
      nexthop: Allow setting "offload" and "trap" indications on nexthops · e95f2592
      Ido Schimmel authored
      Add a function that can be called by device drivers to set "offload" or
      "trap" indication on nexthops following nexthop notifications.
      
      Changes since RFC:
      * s/nexthop_hw_flags_set/nexthop_set_hw_flags/
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e95f2592
    • Ido Schimmel's avatar
      rtnetlink: Add RTNH_F_TRAP flag · 968a83f8
      Ido Schimmel authored
      The flag indicates to user space that the nexthop is not programmed to
      forward packets in hardware, but rather to trap them to the CPU. This is
      needed, for example, when the MAC of the nexthop neighbour is not
      resolved and packets should reach the CPU to trigger neighbour
      resolution.
      
      The flag will be used in subsequent patches by netdevsim to test nexthop
      objects programming to device drivers and in the future by mlxsw as
      well.
      
      Changes since RFC:
      * Reword commit message
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      968a83f8
    • Ido Schimmel's avatar
      nexthop: vxlan: Convert to new notification info · 1ec69d18
      Ido Schimmel authored
      Convert the sole listener of the nexthop notification chain (the VXLAN
      driver) to the new notification info.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1ec69d18
    • Ido Schimmel's avatar
      nexthop: Prepare new notification info · 5ca474f2
      Ido Schimmel authored
      Prepare the new notification information so that it could be passed to
      listeners in the new patch.
      
      Changes since RFC:
      * Add a blank line in __nh_notifier_single_info_init()
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5ca474f2
    • Ido Schimmel's avatar
      nexthop: Pass extack to nexthop notifier · 3578d53d
      Ido Schimmel authored
      The next patch will add extack to the notification info. This allows
      listeners to veto notifications and communicate the reason to user space.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3578d53d
    • Ido Schimmel's avatar
      nexthop: Add nexthop notification data structures · 1c9cac65
      Ido Schimmel authored
      Add data structures that will be used for nexthop replace and delete
      notifications in the previously introduced nexthop notification chain.
      
      New data structures are added instead of passing the existing nexthop
      code structures directly for several reasons.
      
      First, the existing structures encode a lot of bookkeeping information
      which is irrelevant for listeners of the notification chain.
      
      Second, the existing structures can be changed without worrying about
      introducing regressions in listeners since they are not accessed
      directly by them.
      
      Third, listeners of the notification chain do not need to each parse the
      relatively complex nexthop code structures. They are passing the
      required information in a simplified way.
      
      Note that a single 'has_encap' bit is added instead of the actual
      encapsulation information since current listeners do not support such
      nexthops.
      
      Changes since RFC:
      * s/is_encap/has_encap/
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1c9cac65
    • Jakub Kicinski's avatar
      Merge tag 'mlx5-updates-2020-11-03' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · c9448e82
      Jakub Kicinski authored
      Saeed Mahameed says:
      
      ====================
      mlx5-updates-2020-11-03
      
      This series includes updates to mlx5 software steering component.
      
      1) Few improvements in the DR area, such as removing unneeded checks,
        renaming to better general names, refactor in some places, etc.
      
      2) Software steering (DR) Memory management improvements
      
      This patch series contains SW Steering memory management improvements:
      using buddy allocator instead of an existing bucket allocator, and
      several other optimizations.
      
      The buddy system is a memory allocation and management algorithm
      that manages memory in power of two increments.
      
      The algorithm is well-known and well-described, such as here:
      https://en.wikipedia.org/wiki/Buddy_memory_allocation
      
      Linux uses this algorithm for managing and allocating physical pages,
      as described here:
      https://www.kernel.org/doc/gorman/html/understand/understand009.html
      
      In our case, although the algorithm in principal is similar to the
      Linux physical page allocator, the "building blocks" and the circumstances
      are different: in SW steering, buddy allocator doesn't really allocates
      a memory, but rather manages ICM (Interconnect Context Memory) that was
      previously allocated and registered.
      
      The ICM memory that is used in SW steering is always power
      of 2 (order), so buddy system is a good fit for this.
      
      Patches in this series:
      
      [PATH 4] net/mlx5: DR, Add buddy allocator utilities
        This patch adds a modified implementation of a well-known buddy allocator,
        adjusted for SW steering needs: the algorithm in principal is similar to
        the Linux physical page allocator, but in our case buddy allocator doesn't
        really allocate a memory, but rather manages ICM memory that was previously
        allocated and registered.
      
      [PATH 5] net/mlx5: DR, Handle ICM memory via buddy allocation instead of bucket management
        This patch changes ICM management of SW steering to use buddy-system mechanism
        Instead of the previous bucket management.
      
      [PATH 6] net/mlx5: DR, Sync chunks only during free
        This patch makes syncing happen only when freeing memory chunks.
      
      [PATH 7] net/mlx5: DR, ICM memory pools sync optimization
        This patch adds tracking of pool's "hot" memory and makes the
        check whether steering sync is required much shorter and faster.
      
      [PATH 8] net/mlx5: DR, Free buddy ICM memory if it is unused
        This patch adds tracking buddy's used ICM memory,
        and frees the buddy if all its memory becomes unused.
      
      3) Misc code cleanups
      
      * tag 'mlx5-updates-2020-11-03' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux:
        net: mlx5: Replace in_irq() usage
        net/mlx5: Cleanup kernel-doc warnings
        net/mlx4: Cleanup kernel-doc warnings
        net/mlx5e: Validate stop_room size upon user input
        net/mlx5: DR, Free unused buddy ICM memory
        net/mlx5: DR, ICM memory pools sync optimization
        net/mlx5: DR, Sync chunks only during free
        net/mlx5: DR, Handle ICM memory via buddy allocation instead of buckets
        net/mlx5: DR, Add buddy allocator utilities
        net/mlx5: DR, Rename matcher functions to be more HW agnostic
        net/mlx5: DR, Rename builders HW specific names
        net/mlx5: DR, Remove unused member of action struct
      ====================
      
      Link: https://lore.kernel.org/r/20201105201242.21716-1-saeedm@nvidia.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c9448e82
    • Hayes Wang's avatar
      net/usb/r8153_ecm: support ECM mode for RTL8153 · c1aedf01
      Hayes Wang authored
      Support ECM mode based on cdc_ether with relative mii functions,
      when CONFIG_USB_RTL8152 is not set, or the device is not supported
      by r8152 driver.
      
      Both r8152 and r8153_ecm would check the return value of
      rtl8152_get_version() in porbe(). If rtl8152_get_version()
      return none zero value, the r8152 is used for the device
      with vendor mode. Otherwise, the r8153_ecm is used for the
      device with ECM mode.
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Link: https://lore.kernel.org/r/1394712342-15778-392-Taiwan-albertk@realtek.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c1aedf01
    • Loic Poulain's avatar
      net: Add mhi-net driver · 3ffec6a1
      Loic Poulain authored
      This patch adds a new network driver implementing MHI transport for
      network packets. Packets can be in any format, though QMAP (rmnet)
      is the usual protocol (flow control + PDN mux).
      
      It support two MHI devices, IP_HW0 which is, the path to the IPA
      (IP accelerator) on qcom modem, And IP_SW0 which is the software
      driven IP path (to modem CPU).
      Signed-off-by: default avatarLoic Poulain <loic.poulain@linaro.org>
      Reviewed-by: default avatarManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
      Link: https://lore.kernel.org/r/1604424234-24446-2-git-send-email-loic.poulain@linaro.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3ffec6a1
    • Loic Poulain's avatar
      bus: mhi: Add mhi_queue_is_full function · d8c4a223
      Loic Poulain authored
      This function can be used by client driver to determine whether it's
      possible to queue new elements in a channel ring.
      Signed-off-by: default avatarLoic Poulain <loic.poulain@linaro.org>
      Reviewed-by: default avatarManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
      Link: https://lore.kernel.org/r/1604424234-24446-1-git-send-email-loic.poulain@linaro.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d8c4a223
    • Jakub Kicinski's avatar
      Merge branch 'net-phy-add-support-for-shared-interrupts-part-1' · 5aee9484
      Jakub Kicinski authored
      Ioana Ciornei says:
      
      ====================
      net: phy: add support for shared interrupts (part 1)
      
      This patch set aims to actually add support for shared interrupts in
      phylib and not only for multi-PHY devices. While we are at it,
      streamline the interrupt handling in phylib.
      
      For a bit of context, at the moment, there are multiple phy_driver ops
      that deal with this subject:
      
      - .config_intr() - Enable/disable the interrupt line.
      
      - .ack_interrupt() - Should quiesce any interrupts that may have been
        fired.  It's also used by phylib in conjunction with .config_intr() to
        clear any pending interrupts after the line was disabled, and before
        it is going to be enabled.
      
      - .did_interrupt() - Intended for multi-PHY devices with a shared IRQ
        line and used by phylib to discern which PHY from the package was the
        one that actually fired the interrupt.
      
      - .handle_interrupt() - Completely overrides the default interrupt
        handling logic from phylib. The PHY driver is responsible for checking
        if any interrupt was fired by the respective PHY and choose
        accordingly if it's the one that should trigger the link state machine.
      
      From my point of view, the interrupt handling in phylib has become
      somewhat confusing with all these callbacks that actually read the same
      PHY register - the interrupt status.  A more streamlined approach would
      be to just move the responsibility to write an interrupt handler to the
      driver (as any other device driver does) and make .handle_interrupt()
      the only way to deal with interrupts.
      
      Another advantage with this approach would be that phylib would gain
      support for shared IRQs between different PHY (not just multi-PHY
      devices), something which at the moment would require extending every
      PHY driver anyway in order to implement their .did_interrupt() callback
      and duplicate the same logic as in .ack_interrupt(). The disadvantage
      of making .did_interrupt() mandatory would be that we are slightly
      changing the semantics of the phylib API and that would increase
      confusion instead of reducing it.
      
      What I am proposing is the following:
      
      - As a first step, make the .ack_interrupt() callback optional so that
        we do not break any PHY driver amid the transition.
      
      - Every PHY driver gains a .handle_interrupt() implementation that, for
        the most part, would look like below:
      
      	irq_status = phy_read(phydev, INTR_STATUS);
      	if (irq_status < 0) {
      		phy_error(phydev);
      		return IRQ_NONE;
      	}
      
      	if (!(irq_status & irq_mask))
      		return IRQ_NONE;
      
      	phy_trigger_machine(phydev);
      
      	return IRQ_HANDLED;
      
      - Remove each PHY driver's implementation of the .ack_interrupt() by
        actually taking care of quiescing any pending interrupts before
        enabling/after disabling the interrupt line.
      
      - Finally, after all drivers have been ported, remove the
        .ack_interrupt() and .did_interrupt() callbacks from phy_driver.
      
      This patch set is part 1 and it addresses the changes needed in phylib
      and 7 PHY drivers. The rest can be found on my Github branch here:
      https://github.com/IoanaCiornei/linux/commits/phylib-shared-irq
      
      I do not have access to most of these PHY's, therefore I Cc-ed the
      latest contributors to the individual PHY drivers in order to have
      access, hopefully, to more regression testing.
      
      Changes in v2:
       - Rework the .handle_interrupt() implementation for each driver so that
         only the enabled interrupts are taken into account when
         IRQ_NONE/IRQ_HANDLED it returned. The main idea is so that we avoid
         falsely blaming a device for triggering an interrupt when this is not
         the case.
         The only devices for which I was unable to make this adjustment were
         the BCM8706, BCM8727, BCMAC131 and BCM5241 since I do not have access
         to their datasheets.
       - I also updated the pseudo-code added in the cover-letter so that it's
         more clear how a .handle_interrupt() callback should look like.
      ====================
      Tested-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/20201101125114.1316879-1-ciorneiioana@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5aee9484
    • Ioana Ciornei's avatar
      net: phy: realtek: remove the use of .ack_interrupt() · 8b43357f
      Ioana Ciornei authored
      In preparation of removing the .ack_interrupt() callback, we must replace
      its occurrences (aka phy_clear_interrupt), from the 2 places where it is
      called from (phy_enable_interrupts and phy_disable_interrupts), with
      equivalent functionality.
      
      This means that clearing interrupts now becomes something that the PHY
      driver is responsible of doing, before enabling interrupts and after
      clearing them. Make this driver follow the new contract.
      
      Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
      Cc: Willy Liu <willy.liu@realtek.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8b43357f
    • Ioana Ciornei's avatar
      net: phy: realtek: implement generic .handle_interrupt() callback · 03829163
      Ioana Ciornei authored
      In an attempt to actually support shared IRQs in phylib, we now move the
      responsibility of triggering the phylib state machine or just returning
      IRQ_NONE, based on the IRQ status register, to the PHY driver. Having
      3 different IRQ handling callbacks (.handle_interrupt(),
      .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY
      driver implement directly an IRQ handler like any other device driver.
      Make this driver follow the new convention.
      
      Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
      Cc: Willy Liu <willy.liu@realtek.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      03829163
    • Ioana Ciornei's avatar
      net: phy: add genphy_handle_interrupt_no_ack() · 87de1f05
      Ioana Ciornei authored
      It seems there are cases where the interrupts are handled by another
      entity (ie an IRQ controller embedded inside the PHY) and do not need
      any other interraction from phylib. For this kind of PHYs, like the
      RTL8366RB, add the genphy_handle_interrupt_no_ack() function which just
      triggers the link state machine.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      87de1f05
    • Ioana Ciornei's avatar
      net: phy: davicom: remove the use of .ack_interrupt() · 0d65cc18
      Ioana Ciornei authored
      In preparation of removing the .ack_interrupt() callback, we must replace
      its occurrences (aka phy_clear_interrupt), from the 2 places where it is
      called from (phy_enable_interrupts and phy_disable_interrupts), with
      equivalent functionality.
      
      This means that clearing interrupts now becomes something that the PHY
      driver is responsible of doing, before enabling interrupts and after
      clearing them. Make this driver follow the new contract.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0d65cc18
    • Ioana Ciornei's avatar
      net: phy: davicom: implement generic .handle_interrupt() calback · e954631c
      Ioana Ciornei authored
      In an attempt to actually support shared IRQs in phylib, we now move the
      responsibility of triggering the phylib state machine or just returning
      IRQ_NONE, based on the IRQ status register, to the PHY driver. Having
      3 different IRQ handling callbacks (.handle_interrupt(),
      .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY
      driver implement directly an IRQ handler like any other device driver.
      Make this driver follow the new convention.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e954631c
    • Ioana Ciornei's avatar
      net: phy: cicada: remove the use of .ack_interrupt() · a758087f
      Ioana Ciornei authored
      In preparation of removing the .ack_interrupt() callback, we must replace
      its occurrences (aka phy_clear_interrupt), from the 2 places where it is
      called from (phy_enable_interrupts and phy_disable_interrupts), with
      equivalent functionality.
      
      This means that clearing interrupts now becomes something that the PHY
      driver is responsible of doing, before enabling interrupts and after
      clearing them. Make this driver follow the new contract.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a758087f
    • Ioana Ciornei's avatar
      net: phy: cicada: implement the generic .handle_interrupt() callback · e5d2b0b6
      Ioana Ciornei authored
      In an attempt to actually support shared IRQs in phylib, we now move the
      responsibility of triggering the phylib state machine or just returning
      IRQ_NONE, based on the IRQ status register, to the PHY driver. Having
      3 different IRQ handling callbacks (.handle_interrupt(),
      .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY
      driver implement directly an IRQ handler like any other device driver.
      Make this driver follow the new convention.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e5d2b0b6
    • Ioana Ciornei's avatar
      net: phy: broadcom: remove use of ack_interrupt() · 15772e4d
      Ioana Ciornei authored
      In preparation of removing the .ack_interrupt() callback, we must replace
      its occurrences (aka phy_clear_interrupt), from the 2 places where it is
      called from (phy_enable_interrupts and phy_disable_interrupts), with
      equivalent functionality.
      
      This means that clearing interrupts now becomes something that the PHY
      driver is responsible of doing, before enabling interrupts and after
      clearing them. Make this driver follow the new contract.
      
      Cc: Michael Walle <michael@walle.cc>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      15772e4d
    • Ioana Ciornei's avatar
      net: phy: broadcom: implement generic .handle_interrupt() callback · 4567d5c3
      Ioana Ciornei authored
      In an attempt to actually support shared IRQs in phylib, we now move the
      responsibility of triggering the phylib state machine or just returning
      IRQ_NONE, based on the IRQ status register, to the PHY driver. Having
      3 different IRQ handling callbacks (.handle_interrupt(),
      .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY
      driver implement directly an IRQ handler like any other device driver.
      Make this driver follow the new convention.
      
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Tested-by: default avatarMichael Walle <michael@walle.cc>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4567d5c3
    • Ioana Ciornei's avatar
      net: phy: aquantia: remove the use of .ack_interrupt() · e11ef96d
      Ioana Ciornei authored
      In preparation of removing the .ack_interrupt() callback, we must replace
      its occurrences (aka phy_clear_interrupt), from the 2 places where it is
      called from (phy_enable_interrupts and phy_disable_interrupts), with
      equivalent functionality.
      
      This means that clearing interrupts now becomes something that the PHY
      driver is responsible of doing, before enabling interrupts and after
      clearing them. Make this driver follow the new contract.
      
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e11ef96d
    • Ioana Ciornei's avatar
      net: phy: aquantia: implement generic .handle_interrupt() callback · 6ab930df
      Ioana Ciornei authored
      In an attempt to actually support shared IRQs in phylib, we now move the
      responsibility of triggering the phylib state machine or just returning
      IRQ_NONE, based on the IRQ status register, to the PHY driver. Having
      3 different IRQ handling callbacks (.handle_interrupt(),
      .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY
      driver implement directly an IRQ handler like any other device driver.
      Make this driver follow the new convention.
      
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6ab930df
    • Ioana Ciornei's avatar
      net: phy: mscc: remove the use of .ack_interrupt() · 30446ae4
      Ioana Ciornei authored
      In preparation of removing the .ack_interrupt() callback, we must replace
      its occurrences (aka phy_clear_interrupt), from the 2 places where it is
      called from (phy_enable_interrupts and phy_disable_interrupts), with
      equivalent functionality.
      
      This means that clearing interrupts now becomes something that the PHY
      driver is responsible of doing, before enabling interrupts and after
      clearing them. Make this driver follow the new contract.
      
      Cc: Antoine Tenart <atenart@kernel.org>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Tested-by: Vladimir Oltean <olteanv@gmail.com> # VSC8514
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      30446ae4
    • Ioana Ciornei's avatar
      net: phy: mscc: implement generic .handle_interrupt() callback · 4008f373
      Ioana Ciornei authored
      In an attempt to actually support shared IRQs in phylib, we now move the
      responsibility of triggering the phylib state machine or just returning
      IRQ_NONE, based on the IRQ status register, to the PHY driver. Having
      3 different IRQ handling callbacks (.handle_interrupt(),
      .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY
      driver implement directly an IRQ handler like any other device driver.
      Make this driver follow the new convention.
      
      Also, remove the .did_interrupt() callback since it's not anymore used.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Tested-by: Vladimir Oltean <olteanv@gmail.com> # VSC8514
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4008f373
    • Ioana Ciornei's avatar
      net: phy: mscc: use phy_trigger_machine() to notify link change · f2e90604
      Ioana Ciornei authored
      According to the comment describing the phy_mac_interrupt() function, it
      it intended to be used by MAC drivers which have noticed a link change
      thus its use in the mscc PHY driver is improper and, most probably, was
      added just because phy_trigger_machine() was not exported.
      Now that we have acces to trigger the link state machine, use directly
      the phy_trigger_machine() function to notify a link change detected by
      the PHY driver.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Tested-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f2e90604
    • Ioana Ciornei's avatar
      net: phy: at803x: remove the use of .ack_interrupt() · a3417885
      Ioana Ciornei authored
      In preparation of removing the .ack_interrupt() callback, we must replace
      its occurrences (aka phy_clear_interrupt), from the 2 places where it is
      called from (phy_enable_interrupts and phy_disable_interrupts), with
      equivalent functionality.
      
      This means that clearing interrupts now becomes something that the PHY
      driver is responsible of doing, before enabling interrupts and after
      clearing them. Make this driver follow the new contract.
      
      Cc: Oleksij Rempel <o.rempel@pengutronix.de>
      Cc: Michael Walle <michael@walle.cc>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Tested-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a3417885
    • Ioana Ciornei's avatar
      net: phy: at803x: implement generic .handle_interrupt() callback · 29773097
      Ioana Ciornei authored
      In an attempt to actually support shared IRQs in phylib, we now move the
      responsibility of triggering the phylib state machine or just returning
      IRQ_NONE, based on the IRQ status register, to the PHY driver. Having
      3 different IRQ handling callbacks (.handle_interrupt(),
      .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY
      driver implement directly an IRQ handler like any other device driver.
      Make this driver follow the new convention.
      
      Cc: Oleksij Rempel <o.rempel@pengutronix.de>
      Cc: Michael Walle <michael@walle.cc>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Tested-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      29773097
    • Ioana Ciornei's avatar
      net: phy: make .ack_interrupt() optional · 7b2d5908
      Ioana Ciornei authored
      As a first step into making phylib and all PHY drivers to actually
      have support for shared IRQs, make the .ack_interrupt() callback
      optional.
      
      After all drivers have been moved to implement the generic
      interrupt handle, the phy_drv_supports_irq() check will be
      changed again to only require the .handle_interrupts() callback.
      
      Cc: Alexandru Ardelean <alexandru.ardelean@analog.com>
      Cc: Andre Edich <andre.edich@microchip.com>
      Cc: Antoine Tenart <atenart@kernel.org>
      Cc: Baruch Siach <baruch@tkos.co.il>
      Cc: Christophe Leroy <christophe.leroy@c-s.fr>
      Cc: Dan Murphy <dmurphy@ti.com>
      Cc: Divya Koppera <Divya.Koppera@microchip.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Kavya Sree Kotagiri <kavyasree.kotagiri@microchip.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Marco Felsch <m.felsch@pengutronix.de>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
      Cc: Mathias Kresin <dev@kresin.me>
      Cc: Maxim Kochetkov <fido_max@inbox.ru>
      Cc: Michael Walle <michael@walle.cc>
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Nisar Sayed <Nisar.Sayed@microchip.com>
      Cc: Oleksij Rempel <o.rempel@pengutronix.de>
      Cc: Philippe Schenker <philippe.schenker@toradex.com>
      Cc: Willy Liu <willy.liu@realtek.com>
      Cc: Yuiko Oshino <yuiko.oshino@microchip.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7b2d5908
    • Ioana Ciornei's avatar
      net: phy: add a shutdown procedure · e2f016cf
      Ioana Ciornei authored
      In case of a board which uses a shared IRQ we can easily end up with an
      IRQ storm after a forced reboot.
      
      For example, a 'reboot -f' will trigger a call to the .shutdown()
      callbacks of all devices. Because phylib does not implement that hook,
      the PHY is not quiesced, thus it can very well leave its IRQ enabled.
      
      At the next boot, if that IRQ line is found asserted by the first PHY
      driver that uses it, but _before_ the driver that is _actually_ keeping
      the shared IRQ asserted is probed, the IRQ is not going to be
      acknowledged, thus it will keep being fired preventing the boot process
      of the kernel to continue. This is even worse when the second PHY driver
      is a module.
      
      To fix this, implement the .shutdown() callback and disable the
      interrupts if these are used.
      
      Note that we are still susceptible to IRQ storms if the previous kernel
      exited with a panic or if the bootloader left the shared IRQ active, but
      there is absolutely nothing we can do about these cases.
      
      Cc: Alexandru Ardelean <alexandru.ardelean@analog.com>
      Cc: Andre Edich <andre.edich@microchip.com>
      Cc: Antoine Tenart <atenart@kernel.org>
      Cc: Baruch Siach <baruch@tkos.co.il>
      Cc: Christophe Leroy <christophe.leroy@c-s.fr>
      Cc: Dan Murphy <dmurphy@ti.com>
      Cc: Divya Koppera <Divya.Koppera@microchip.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Kavya Sree Kotagiri <kavyasree.kotagiri@microchip.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Marco Felsch <m.felsch@pengutronix.de>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
      Cc: Mathias Kresin <dev@kresin.me>
      Cc: Maxim Kochetkov <fido_max@inbox.ru>
      Cc: Michael Walle <michael@walle.cc>
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Nisar Sayed <Nisar.Sayed@microchip.com>
      Cc: Oleksij Rempel <o.rempel@pengutronix.de>
      Cc: Philippe Schenker <philippe.schenker@toradex.com>
      Cc: Willy Liu <willy.liu@realtek.com>
      Cc: Yuiko Oshino <yuiko.oshino@microchip.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e2f016cf
    • Ioana Ciornei's avatar
      net: phy: export phy_error and phy_trigger_machine · 293e9a3d
      Ioana Ciornei authored
      These functions are currently used by phy_interrupt() to either signal
      an error condition or to trigger the link state machine. In an attempt
      to actually support shared PHY IRQs, export these two functions so that
      the actual PHY drivers can use them.
      
      Cc: Alexandru Ardelean <alexandru.ardelean@analog.com>
      Cc: Andre Edich <andre.edich@microchip.com>
      Cc: Antoine Tenart <atenart@kernel.org>
      Cc: Baruch Siach <baruch@tkos.co.il>
      Cc: Christophe Leroy <christophe.leroy@c-s.fr>
      Cc: Dan Murphy <dmurphy@ti.com>
      Cc: Divya Koppera <Divya.Koppera@microchip.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Kavya Sree Kotagiri <kavyasree.kotagiri@microchip.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Marco Felsch <m.felsch@pengutronix.de>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
      Cc: Mathias Kresin <dev@kresin.me>
      Cc: Maxim Kochetkov <fido_max@inbox.ru>
      Cc: Michael Walle <michael@walle.cc>
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Nisar Sayed <Nisar.Sayed@microchip.com>
      Cc: Oleksij Rempel <o.rempel@pengutronix.de>
      Cc: Philippe Schenker <philippe.schenker@toradex.com>
      Cc: Willy Liu <willy.liu@realtek.com>
      Cc: Yuiko Oshino <yuiko.oshino@microchip.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      293e9a3d
  2. 05 Nov, 2020 5 commits