1. 06 Jun, 2017 24 commits
  2. 05 Jun, 2017 16 commits
    • Colin Ian King's avatar
      mdio: mux: fix an incorrect less than zero error check using a u32 · 9d15e5cc
      Colin Ian King authored
      The u32 variable v is being checked to see if an error return is
      less than zero and this check has no effect because it is unsigned.
      Fix this by making v and int (this also matches the type of
      cb->bus_number which is assigned to the value in v).
      
      Detected by CoverityScan, CID#1440454 ("Unsigned compared against zero")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d15e5cc
    • Icenowy Zheng's avatar
      net-next: stmmac: dwmac-sun8i: ensure the EPHY is properly reseted · 2f878491
      Icenowy Zheng authored
      The EPHY may be already enabled by bootloaders which have Ethernet
      capability (e.g. current U-Boot). Thus it should be reseted properly
      before doing the enabling sequence in the dwmac-sun8i driver, otherwise
      the EMAC reset process may fail if no cable is plugged, and then fail
      the dwmac-sun8i probing.
      
      Tested on Orange Pi PC, One and Zero. All the boards fail to have
      dwmac-sun8i probed with "EMAC reset timeout" without cable plugged
      before, and with this fix they're now all able to successfully probe the
      EMAC without cable plugged and then use the connection after a cable is
      hot-plugged in.
      
      Fixes: 9f93ac8d ("net-next: stmmac: Add dwmac-sun8i")
      Signed-off-by: default avatarIcenowy Zheng <icenowy@aosc.io>
      Tested-by: default avatarCorentin Labbe <clabbe.montjoie@gmail.com>
      Acked-by: default avatarCorentin Labbe <clabbe.montjoie@gmail.com>
      Reviewed-by: default avatarCorentin Labbe <clabbe.montjoie@gmail.com>
      Acked-by: is not as formal as Signed-off-by:.  It is a record that the acker
      Reviewed-by: is similar.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2f878491
    • yuval.shaia@oracle.com's avatar
      net/3com: Make el3_netdev_get_ecmd return void · 697dae1e
      yuval.shaia@oracle.com authored
      Make return value void since function never returns meaningfull value.
      Signed-off-by: default avatarYuval Shaia <yuval.shaia@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      697dae1e
    • yuval.shaia@oracle.com's avatar
      net/{mii, smsc}: Make mii_ethtool_get_link_ksettings and smc_netdev_get_ecmd return void · 82c01a84
      yuval.shaia@oracle.com authored
      Make return value void since functions never returns meaningfull value.
      Signed-off-by: default avatarYuval Shaia <yuval.shaia@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82c01a84
    • yuval.shaia@oracle.com's avatar
      net/dec: Make __de_get_link_ksettings return void · c7c6b871
      yuval.shaia@oracle.com authored
      Make return value void since function never return meaningfull value
      Signed-off-by: default avatarYuval Shaia <yuval.shaia@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7c6b871
    • Jiri Pirko's avatar
      net: sched: select cls when cls_act is enabled · 8ec1507d
      Jiri Pirko authored
      It really makes no sense to have cls_act enabled without cls. In that
      case, the cls_act code is dead. So select it.
      
      This also fixes an issue recently reported by kbuild robot:
      [linux-next:master 1326/4151] net/sched/act_api.c:37:18: error: implicit declaration of function 'tcf_chain_get'
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ec1507d
    • Rosen, Rami's avatar
      genetlink: remove ops_list from genetlink header. · 4e2ec436
      Rosen, Rami authored
      commit d91824c0 ("genetlink: register family ops as array") removed the
      ops_list member from both genl_family and genl_ops; while the
      documentation of genl_family was updated accordingly by this patch,
      ops_list remained in the documentation of the genl_ops object.
      This patch fixes it by removing ops_list from genl_ops documentation.
      Signed-off-by: default avatarRami Rosen <rami.rosen@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e2ec436
    • David Howells's avatar
      rxrpc: Add service upgrade support for client connections · 4e255721
      David Howells authored
      Make it possible for a client to use AuriStor's service upgrade facility.
      
      The client does this by adding an RXRPC_UPGRADE_SERVICE control message to
      the first sendmsg() of a call.  This takes no parameters.
      
      When recvmsg() starts returning data from the call, the service ID field in
      the returned msg_name will reflect the result of the upgrade attempt.  If
      the upgrade was ignored, srx_service will match what was set in the
      sendmsg(); if the upgrade happened the srx_service will be altered to
      indicate the service the server upgraded to.
      
      Note that:
      
       (1) The choice of upgrade service is up to the server
      
       (2) Further client calls to the same server that would share a connection
           are blocked if an upgrade probe is in progress.
      
       (3) This should only be used to probe the service.  Clients should then
           use the returned service ID in all subsequent communications with that
           server (and not set the upgrade).  Note that the kernel will not
           retain this information should the connection expire from its cache.
      
       (4) If a server that supports upgrading is replaced by one that doesn't,
           whilst a connection is live, and if the replacement is running, say,
           OpenAFS 1.6.4 or older or an older IBM AFS, then the replacement
           server will not respond to packets sent to the upgraded connection.
      
           At this point, calls will time out and the server must be reprobed.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      4e255721
    • David Howells's avatar
      rxrpc: Implement service upgrade · 4722974d
      David Howells authored
      Implement AuriStor's service upgrade facility.  There are three problems
      that this is meant to deal with:
      
       (1) Various of the standard AFS RPC calls have IPv4 addresses in their
           requests and/or replies - but there's no room for including IPv6
           addresses.
      
       (2) Definition of IPv6-specific RPC operations in the standard operation
           sets has not yet been achieved.
      
       (3) One could envision the creation a new service on the same port that as
           the original service.  The new service could implement improved
           operations - and the client could try this first, falling back to the
           original service if it's not there.
      
           Unfortunately, certain servers ignore packets addressed to a service
           they don't implement and don't respond in any way - not even with an
           ABORT.  This means that the client must then wait for the call timeout
           to occur.
      
      What service upgrade does is to see if the connection is marked as being
      'upgradeable' and if so, change the service ID in the server and thus the
      request and reply formats.  Note that the upgrade isn't mandatory - a
      server that supports only the original call set will ignore the upgrade
      request.
      
      In the protocol, the procedure is then as follows:
      
       (1) To request an upgrade, the first DATA packet in a new connection must
           have the userStatus set to 1 (this is normally 0).  The userStatus
           value is normally ignored by the server.
      
       (2) If the server doesn't support upgrading, the reply packets will
           contain the same service ID as for the first request packet.
      
       (3) If the server does support upgrading, all future reply packets on that
           connection will contain the new service ID and the new service ID will
           be applied to *all* further calls on that connection as well.
      
       (4) The RPC op used to probe the upgrade must take the same request data
           as the shadow call in the upgrade set (but may return a different
           reply).  GetCapability RPC ops were added to all standard sets for
           just this purpose.  Ops where the request formats differ cannot be
           used for probing.
      
       (5) The client must wait for completion of the probe before sending any
           further RPC ops to the same destination.  It should then use the
           service ID that recvmsg() reported back in all future calls.
      
       (6) The shadow service must have call definitions for all the operation
           IDs defined by the original service.
      
      
      To support service upgrading, a server should:
      
       (1) Call bind() twice on its AF_RXRPC socket before calling listen().
           Each bind() should supply a different service ID, but the transport
           addresses must be the same.  This allows the server to receive
           requests with either service ID.
      
       (2) Enable automatic upgrading by calling setsockopt(), specifying
           RXRPC_UPGRADEABLE_SERVICE and passing in a two-member array of
           unsigned shorts as the argument:
      
      	unsigned short optval[2];
      
           This specifies a pair of service IDs.  They must be different and must
           match the service IDs bound to the socket.  Member 0 is the service ID
           to upgrade from and member 1 is the service ID to upgrade to.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      4722974d
    • David Howells's avatar
      rxrpc: Permit multiple service binding · 28036f44
      David Howells authored
      Permit bind() to be called on an AF_RXRPC socket more than once (currently
      maximum twice) to bind multiple listening services to it.  There are some
      restrictions:
      
       (1) All bind() calls involved must have a non-zero service ID.
      
       (2) The service IDs must all be different.
      
       (3) The rest of the address (notably the transport part) must be the same
           in all (a single UDP socket is shared).
      
       (4) This must be done before listen() or sendmsg() is called.
      
      This allows someone to connect to the service socket with different service
      IDs and lays the foundation for service upgrading.
      
      The service ID used by an incoming call can be extracted from the msg_name
      returned by recvmsg().
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      28036f44
    • David Howells's avatar
      rxrpc: Separate the connection's protocol service ID from the lookup ID · 68d6d1ae
      David Howells authored
      Keep the rxrpc_connection struct's idea of the service ID that is exposed
      in the protocol separate from the service ID that's used as a lookup key.
      
      This allows the protocol service ID on a client connection to get upgraded
      without making the connection unfindable for other client calls that also
      would like to use the upgraded connection.
      
      The connection's actual service ID is then returned through recvmsg() by
      way of msg_name.
      
      Whilst we're at it, we get rid of the last_service_id field from each
      channel.  The service ID is per-connection, not per-call and an entire
      connection is upgraded in one go.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      68d6d1ae
    • David S. Miller's avatar
      Merge branch 'mlxsw-Minor-cleanup' · aae1a2ce
      David S. Miller authored
      Jiri Pirko says:
      
      ====================
      mlxsw: Minor cleanup
      
      Fix small issues I noticed during the refactoring.
      
      First patch adds file name comments in the header file to make it clear
      what goes where. Second patch fixes a typo and third patch simply aligns
      RIF index allocation with similar allocations in the driver.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aae1a2ce
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Align RIF index allocation with existing code · de5ed99e
      Ido Schimmel authored
      The way we usually allocate an index is by letting the allocation
      function return an error instead of an invalid index.
      
      Do the same for RIF index.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de5ed99e
    • Ido Schimmel's avatar
      da0abcf9
    • Ido Schimmel's avatar
      mlxsw: spectrum: Tidy up header file · cb4cc0e0
      Ido Schimmel authored
      Make it clear where functions are defined and move misplaced declaration
      to their correct place.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cb4cc0e0
    • Yotam Gigi's avatar
      mlxsw: spectrum: Rename the firmware file · a4e1ce24
      Yotam Gigi authored
      Change the firmware file name to be in "mellanox" directory.
      
      This commit is a followup to the linux-firmware commit a4c72696f5f4
      ("Mellanox: Add firmware for mlxsw_spectrum")
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4e1ce24