1. 08 Sep, 2020 5 commits
    • David Howells's avatar
      rxrpc: Allow multiple client connections to the same peer · 288827d5
      David Howells authored
      Allow the number of parallel connections to a machine to be expanded from a
      single connection to a maximum of four.  This allows up to 16 calls to be
      in progress at the same time to any particular peer instead of 4.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      288827d5
    • David Howells's avatar
      rxrpc: Rewrite the client connection manager · 245500d8
      David Howells authored
      Rewrite the rxrpc client connection manager so that it can support multiple
      connections for a given security key to a peer.  The following changes are
      made:
      
       (1) For each open socket, the code currently maintains an rbtree with the
           connections placed into it, keyed by communications parameters.  This
           is tricky to maintain as connections can be culled from the tree or
           replaced within it.  Connections can require replacement for a number
           of reasons, e.g. their IDs span too great a range for the IDR data
           type to represent efficiently, the call ID numbers on that conn would
           overflow or the conn got aborted.
      
           This is changed so that there's now a connection bundle object placed
           in the tree, keyed on the same parameters.  The bundle, however, does
           not need to be replaced.
      
       (2) An rxrpc_bundle object can now manage the available channels for a set
           of parallel connections.  The lock that manages this is moved there
           from the rxrpc_connection struct (channel_lock).
      
       (3) There'a a dummy bundle for all incoming connections to share so that
           they have a channel_lock too.  It might be better to give each
           incoming connection its own bundle.  This bundle is not needed to
           manage which channels incoming calls are made on because that's the
           solely at whim of the client.
      
       (4) The restrictions on how many client connections are around are
           removed.  Instead, a previous patch limits the number of client calls
           that can be allocated.  Ordinarily, client connections are reaped
           after 2 minutes on the idle queue, but when more than a certain number
           of connections are in existence, the reaper starts reaping them after
           2s of idleness instead to get the numbers back down.
      
           It could also be made such that new call allocations are forced to
           wait until the number of outstanding connections subsides.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      245500d8
    • David Howells's avatar
      rxrpc: Impose a maximum number of client calls · b7a7d674
      David Howells authored
      Impose a maximum on the number of client rxrpc calls that are allowed
      simultaneously.  This will be in lieu of a maximum number of client
      connections as this is easier to administed as, unlike connections, calls
      aren't reusable (to be changed in a subsequent patch)..
      
      This doesn't affect the limits on service calls and connections.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      b7a7d674
    • Vladimir Oltean's avatar
      net: dsa: don't print non-fatal MTU error if not supported · 4349abdb
      Vladimir Oltean authored
      Commit 72579e14 ("net: dsa: don't fail to probe if we couldn't set
      the MTU") changed, for some reason, the "err && err != -EOPNOTSUPP"
      check into a simple "err". This causes the MTU warning to be printed
      even for drivers that don't have the MTU operations implemented.
      Fix that.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4349abdb
    • Vladimir Oltean's avatar
      net: dsa: change PHY error message again · c9ebf126
      Vladimir Oltean authored
      slave_dev->name is only populated at this stage if it was specified
      through a label in the device tree. However that is not mandatory.
      When it isn't, the error message looks like this:
      
      [    5.037057] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d
      [    5.044672] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d
      [    5.052275] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d
      [    5.059877] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d
      
      which is especially confusing since the error gets printed on behalf of
      the DSA master (fsl_enetc in this case).
      
      Printing an error message that contains a valid reference to the DSA
      port's name is difficult at this point in the initialization stage, so
      at least we should print some info that is more reliable, even if less
      user-friendly. That may be the driver name and the hardware port index.
      
      After this change, the error is printed as:
      
      [    6.051587] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 0
      [    6.061192] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 1
      [    6.070765] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 2
      [    6.080324] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 3
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c9ebf126
  2. 07 Sep, 2020 32 commits
  3. 06 Sep, 2020 3 commits
    • Christophe JAILLET's avatar
      enic: switch from 'pci_' to 'dma_' API · 02a20d4f
      Christophe JAILLET authored
      The wrappers in include/linux/pci-dma-compat.h should go away.
      
      The patch has been generated with the coccinelle script below and has been
      hand modified to replace GFP_ with a correct flag.
      It has been compile tested.
      
      When memory is allocated in 'vnic_dev_classifier()', 'vnic_dev_fw_info()',
      'vnic_dev_notify_set()' and 'vnic_dev_stats_dump()' (vnic_dev.c) GFP_ATOMIC
      must be used because its callers take a spinlock before calling these
      functions.
      
      When memory is allocated in '__enic_set_rsskey()' and 'enic_set_rsscpu()'
      GFP_ATOMIC must be used because they can be called with a spinlock.
      The call chain is:
        enic_reset                         <-- takes 'enic->enic_api_lock'
          --> enic_set_rss_nic_cfg
            --> enic_set_rsskey
              --> __enic_set_rsskey        <-- uses dma_alloc_coherent
            --> enic_set_rsscpu            <-- uses dma_alloc_coherent
      
      When memory is allocated in 'vnic_dev_init_prov2()' GFP_ATOMIC must be used
      because a spinlock is hidden in the ENIC_DEVCMD_PROXY_BY_INDEX macro, when
      this function is called in 'enic_set_port_profile()'.
      
      When memory is allocated in 'vnic_dev_alloc_desc_ring()' GFP_KERNEL can be
      used because it is only called from 5 functions ('vnic_dev_init_devcmd2()',
      'vnic_cq_alloc()', 'vnic_rq_alloc()', 'vnic_wq_alloc()' and
      'enic_wq_devcmd2_alloc()'.
      
        'vnic_dev_init_devcmd2()': already uses GFP_KERNEL and no lock is taken
           in the between.
        'enic_wq_devcmd2_alloc()': is called from ' vnic_dev_init_devcmd2()'
           which already uses GFP_KERNEL and no lock is taken in the between.
        'vnic_cq_alloc()', 'vnic_rq_alloc()', 'vnic_wq_alloc()': are called
           from 'enic_alloc_vnic_resources()'
      'enic_alloc_vnic_resources()' has only 2 call chains:
      
        1) enic_probe
            --> enic_dev_init
              --> enic_alloc_vnic_resources
      'enic_probe()' is a probe function and no lock is taken in the between
      
        2) enic_set_ringparam
            --> enic_alloc_vnic_resources
      'enic_set_ringparam()' is a .set_ringparam function (see struct
      ethtool_ops). It seems to only take a mutex and no spinlock.
      
      So all paths are safe to use GFP_KERNEL.
      
      @@
      @@
      -    PCI_DMA_BIDIRECTIONAL
      +    DMA_BIDIRECTIONAL
      
      @@
      @@
      -    PCI_DMA_TODEVICE
      +    DMA_TO_DEVICE
      
      @@
      @@
      -    PCI_DMA_FROMDEVICE
      +    DMA_FROM_DEVICE
      
      @@
      @@
      -    PCI_DMA_NONE
      +    DMA_NONE
      
      @@
      expression e1, e2, e3;
      @@
      -    pci_alloc_consistent(e1, e2, e3)
      +    dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
      
      @@
      expression e1, e2, e3;
      @@
      -    pci_zalloc_consistent(e1, e2, e3)
      +    dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
      
      @@
      expression e1, e2, e3, e4;
      @@
      -    pci_free_consistent(e1, e2, e3, e4)
      +    dma_free_coherent(&e1->dev, e2, e3, e4)
      
      @@
      expression e1, e2, e3, e4;
      @@
      -    pci_map_single(e1, e2, e3, e4)
      +    dma_map_single(&e1->dev, e2, e3, e4)
      
      @@
      expression e1, e2, e3, e4;
      @@
      -    pci_unmap_single(e1, e2, e3, e4)
      +    dma_unmap_single(&e1->dev, e2, e3, e4)
      
      @@
      expression e1, e2, e3, e4, e5;
      @@
      -    pci_map_page(e1, e2, e3, e4, e5)
      +    dma_map_page(&e1->dev, e2, e3, e4, e5)
      
      @@
      expression e1, e2, e3, e4;
      @@
      -    pci_unmap_page(e1, e2, e3, e4)
      +    dma_unmap_page(&e1->dev, e2, e3, e4)
      
      @@
      expression e1, e2, e3, e4;
      @@
      -    pci_map_sg(e1, e2, e3, e4)
      +    dma_map_sg(&e1->dev, e2, e3, e4)
      
      @@
      expression e1, e2, e3, e4;
      @@
      -    pci_unmap_sg(e1, e2, e3, e4)
      +    dma_unmap_sg(&e1->dev, e2, e3, e4)
      
      @@
      expression e1, e2, e3, e4;
      @@
      -    pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
      +    dma_sync_single_for_cpu(&e1->dev, e2, e3, e4)
      
      @@
      expression e1, e2, e3, e4;
      @@
      -    pci_dma_sync_single_for_device(e1, e2, e3, e4)
      +    dma_sync_single_for_device(&e1->dev, e2, e3, e4)
      
      @@
      expression e1, e2, e3, e4;
      @@
      -    pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
      +    dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4)
      
      @@
      expression e1, e2, e3, e4;
      @@
      -    pci_dma_sync_sg_for_device(e1, e2, e3, e4)
      +    dma_sync_sg_for_device(&e1->dev, e2, e3, e4)
      
      @@
      expression e1, e2;
      @@
      -    pci_dma_mapping_error(e1, e2)
      +    dma_mapping_error(&e1->dev, e2)
      
      @@
      expression e1, e2;
      @@
      -    pci_set_dma_mask(e1, e2)
      +    dma_set_mask(&e1->dev, e2)
      
      @@
      expression e1, e2;
      @@
      -    pci_set_consistent_dma_mask(e1, e2)
      +    dma_set_coherent_mask(&e1->dev, e2)
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      02a20d4f
    • Linus Walleij's avatar
      net: gemini: Clean up phy registration · 3e813d61
      Linus Walleij authored
      It's nice if the phy is online before we register the netdev
      so try to do that first.
      
      Stop trying to do "second tried" to register the phy, it
      works perfectly fine the first time.
      
      Stop remvoving the phy in uninit. Remove it when the
      driver is remove():d, symmetric to where it is added, in
      probe().
      Suggested-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reported-by: default avatarDavid Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3e813d61
    • Jonathan Neuschäfer's avatar
      ee1a4c84