1. 20 Sep, 2021 7 commits
    • Jiaran Zhang's avatar
      net: hns3: fix misuse vf id and vport id in some logs · 311c0aaa
      Jiaran Zhang authored
      vport_id include PF and VFs, vport_id = 0 means PF, other values mean VFs.
      So the actual vf id is equal to vport_id minus 1.
      
      Some VF print logs are actually vport, and logs of vf id actually use
      vport id, so this patch fixes them.
      
      Fixes: ac887be5 ("net: hns3: change print level of RAS error log from warning to error")
      Fixes: adcf738b ("net: hns3: cleanup some print format warning")
      Signed-off-by: default avatarJiaran Zhang <zhangjiaran@huawei.com>
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      311c0aaa
    • Jian Shen's avatar
      net: hns3: fix inconsistent vf id print · 91bc0d52
      Jian Shen authored
      The vf id from ethtool is added 1 before configured to driver.
      So it's necessary to minus 1 when printing it, in order to
      keep consistent with user's configuration.
      
      Fixes: dd74f815 ("net: hns3: Add support for rule add/delete for flow director")
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      91bc0d52
    • Jian Shen's avatar
      net: hns3: fix change RSS 'hfunc' ineffective issue · e184cec5
      Jian Shen authored
      When user change rss 'hfunc' without set rss 'hkey' by ethtool
      -X command, the driver will ignore the 'hfunc' for the hkey is
      NULL. It's unreasonable. So fix it.
      
      Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support")
      Fixes: 374ad291 ("net: hns3: Add RSS general configuration support for VF")
      Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e184cec5
    • Arnd Bergmann's avatar
      ptp: ocp: add COMMON_CLK dependency · 42a99a0b
      Arnd Bergmann authored
      Without CONFIG_COMMON_CLK, this fails to link:
      
      arm-linux-gnueabi-ld: drivers/ptp/ptp_ocp.o: in function `ptp_ocp_register_i2c':
      ptp_ocp.c:(.text+0xcc0): undefined reference to `__clk_hw_register_fixed_rate'
      arm-linux-gnueabi-ld: ptp_ocp.c:(.text+0xcf4): undefined reference to `devm_clk_hw_register_clkdev'
      arm-linux-gnueabi-ld: drivers/ptp/ptp_ocp.o: in function `ptp_ocp_detach':
      ptp_ocp.c:(.text+0x1c24): undefined reference to `clk_hw_unregister_fixed_rate'
      
      Fixes: a7e1abad ("ptp: Add clock driver for the OpenCompute TimeCard.")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      42a99a0b
    • Michael Chan's avatar
      bnxt_en: Fix TX timeout when TX ring size is set to the smallest · 5bed8b07
      Michael Chan authored
      The smallest TX ring size we support must fit a TX SKB with MAX_SKB_FRAGS
      + 1.  Because the first TX BD for a packet is always a long TX BD, we
      need an extra TX BD to fit this packet.  Define BNXT_MIN_TX_DESC_CNT with
      this value to make this more clear.  The current code uses a minimum
      that is off by 1.  Fix it using this constant.
      
      The tx_wake_thresh to determine when to wake up the TX queue is half the
      ring size but we must have at least BNXT_MIN_TX_DESC_CNT for the next
      packet which may have maximum fragments.  So the comparison of the
      available TX BDs with tx_wake_thresh should be >= instead of > in the
      current code.  Otherwise, at the smallest ring size, we will never wake
      up the TX queue and will cause TX timeout.
      
      Fixes: c0c050c5 ("bnxt_en: New Broadcom ethernet driver.")
      Reviewed-by: default avatarPavan Chebbi <pavan.chebbi@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadocm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5bed8b07
    • Ido Schimmel's avatar
      nexthop: Fix division by zero while replacing a resilient group · 563f23b0
      Ido Schimmel authored
      The resilient nexthop group torture tests in fib_nexthop.sh exposed a
      possible division by zero while replacing a resilient group [1]. The
      division by zero occurs when the data path sees a resilient nexthop
      group with zero buckets.
      
      The tests replace a resilient nexthop group in a loop while traffic is
      forwarded through it. The tests do not specify the number of buckets
      while performing the replacement, resulting in the kernel allocating a
      stub resilient table (i.e, 'struct nh_res_table') with zero buckets.
      
      This table should never be visible to the data path, but the old nexthop
      group (i.e., 'oldg') might still be used by the data path when the stub
      table is assigned to it.
      
      Fix this by only assigning the stub table to the old nexthop group after
      making sure the group is no longer used by the data path.
      
      Tested with fib_nexthops.sh:
      
      Tests passed: 222
      Tests failed:   0
      
      [1]
       divide error: 0000 [#1] PREEMPT SMP KASAN
       CPU: 0 PID: 1850 Comm: ping Not tainted 5.14.0-custom-10271-ga86eb53057fe #1107
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014
       RIP: 0010:nexthop_select_path+0x2d2/0x1a80
      [...]
       Call Trace:
        fib_select_multipath+0x79b/0x1530
        fib_select_path+0x8fb/0x1c10
        ip_route_output_key_hash_rcu+0x1198/0x2da0
        ip_route_output_key_hash+0x190/0x340
        ip_route_output_flow+0x21/0x120
        raw_sendmsg+0x91d/0x2e10
        inet_sendmsg+0x9e/0xe0
        __sys_sendto+0x23d/0x360
        __x64_sys_sendto+0xe1/0x1b0
        do_syscall_64+0x35/0x80
        entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Cc: stable@vger.kernel.org
      Fixes: 283a72a5 ("nexthop: Add implementation of resilient next-hop groups")
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      563f23b0
    • Xuan Zhuo's avatar
      napi: fix race inside napi_enable · 3765996e
      Xuan Zhuo authored
      The process will cause napi.state to contain NAPI_STATE_SCHED and
      not in the poll_list, which will cause napi_disable() to get stuck.
      
      The prefix "NAPI_STATE_" is removed in the figure below, and
      NAPI_STATE_HASHED is ignored in napi.state.
      
                            CPU0       |                   CPU1       | napi.state
      ===============================================================================
      napi_disable()                   |                              | SCHED | NPSVC
      napi_enable()                    |                              |
      {                                |                              |
          smp_mb__before_atomic();     |                              |
          clear_bit(SCHED, &n->state); |                              | NPSVC
                                       | napi_schedule_prep()         | SCHED | NPSVC
                                       | napi_poll()                  |
                                       |   napi_complete_done()       |
                                       |   {                          |
                                       |      if (n->state & (NPSVC | | (1)
                                       |               _BUSY_POLL)))  |
                                       |           return false;      |
                                       |     ................         |
                                       |   }                          | SCHED | NPSVC
                                       |                              |
          clear_bit(NPSVC, &n->state); |                              | SCHED
      }                                |                              |
                                       |                              |
      napi_schedule_prep()             |                              | SCHED | MISSED (2)
      
      (1) Here return direct. Because of NAPI_STATE_NPSVC exists.
      (2) NAPI_STATE_SCHED exists. So not add napi.poll_list to sd->poll_list
      
      Since NAPI_STATE_SCHED already exists and napi is not in the
      sd->poll_list queue, NAPI_STATE_SCHED cannot be cleared and will always
      exist.
      
      1. This will cause this queue to no longer receive packets.
      2. If you encounter napi_disable under the protection of rtnl_lock, it
         will cause the entire rtnl_lock to be locked, affecting the overall
         system.
      
      This patch uses cmpxchg to implement napi_enable(), which ensures that
      there will be no race due to the separation of clear two bits.
      
      Fixes: 2d8bff12 ("netpoll: Close race condition between poll_one_napi and napi_disable")
      Signed-off-by: default avatarXuan Zhuo <xuanzhuo@linux.alibaba.com>
      Reviewed-by: default avatarDust Li <dust.li@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3765996e
  2. 19 Sep, 2021 22 commits
    • Shuah Khan's avatar
      selftests: net: af_unix: Fix makefile to use TEST_GEN_PROGS · e30cd812
      Shuah Khan authored
      Makefile uses TEST_PROGS instead of TEST_GEN_PROGS to define
      executables. TEST_PROGS is for shell scripts that need to be
      installed and run by the common lib.mk framework. The common
      framework doesn't touch TEST_PROGS when it does build and clean.
      
      As a result "make kselftest-clean" and "make clean" fail to remove
      executables. Run and install work because the common framework runs
      and installs TEST_PROGS. Build works because the Makefile defines
      "all" rule which is unnecessary if TEST_GEN_PROGS is used.
      
      Use TEST_GEN_PROGS so the common framework can handle build/run/
      install/clean properly.
      Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e30cd812
    • Lama Kayal's avatar
      net/mlx4_en: Resolve bad operstate value · 72a3c58d
      Lama Kayal authored
      Any link state change that's done prior to net device registration
      isn't reflected on the state, thus the operational state is left
      obsolete, with 'UNKNOWN' status.
      
      To resolve the issue, query link state from FW upon open operations
      to ensure operational state is updated.
      
      Fixes: c27a02cd ("mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC")
      Signed-off-by: default avatarLama Kayal <lkayal@nvidia.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72a3c58d
    • Shuah Khan's avatar
      selftests: net: af_unix: Fix incorrect args in test result msg · 48514a22
      Shuah Khan authored
      Fix the args to fprintf(). Splitting the message ends up passing
      incorrect arg for "sigurg %d" and an extra arg overall. The test
      result message ends up incorrect.
      
      test_unix_oob.c: In function ‘main’:
      test_unix_oob.c:274:43: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘char *’ [-Wformat=]
        274 |   fprintf(stderr, "Test 3 failed, sigurg %d len %d OOB %c ",
            |                                          ~^
            |                                           |
            |                                           int
            |                                          %s
        275 |   "atmark %d\n", signal_recvd, len, oob, atmark);
            |   ~~~~~~~~~~~~~
            |   |
            |   char *
      test_unix_oob.c:274:19: warning: too many arguments for format [-Wformat-extra-args]
        274 |   fprintf(stderr, "Test 3 failed, sigurg %d len %d OOB %c ",
      Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48514a22
    • Christian Lamparter's avatar
      net: bgmac-bcma: handle deferred probe error due to mac-address · 029497e6
      Christian Lamparter authored
      Due to the inclusion of nvmem handling into the mac-address getter
      function of_get_mac_address() by
      commit d01f449c ("of_net: add NVMEM support to of_get_mac_address")
      it is now possible to get a -EPROBE_DEFER return code. Which did cause
      bgmac to assign a random ethernet address.
      
      This exact issue happened on my Meraki MR32. The nvmem provider is
      an EEPROM (at24c64) which gets instantiated once the module
      driver is loaded... This happens once the filesystem becomes available.
      
      With this patch, bgmac_probe() will propagate the -EPROBE_DEFER error.
      Then the driver subsystem will reschedule the probe at a later time.
      
      Cc: Petr Štetiar <ynezz@true.cz>
      Cc: Michael Walle <michael@walle.cc>
      Fixes: d01f449c ("of_net: add NVMEM support to of_get_mac_address")
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      029497e6
    • Vladimir Oltean's avatar
      net: dsa: tear down devlink port regions when tearing down the devlink port on error · fd292c18
      Vladimir Oltean authored
      Commit 86f8b1c0 ("net: dsa: Do not make user port errors fatal")
      decided it was fine to ignore errors on certain ports that fail to
      probe, and go on with the ports that do probe fine.
      
      Commit fb6ec87f ("net: dsa: Fix type was not set for devlink port")
      noticed that devlink_port_type_eth_set(dlp, dp->slave); does not get
      called, and devlink notices after a timeout of 3600 seconds and prints a
      WARN_ON. So it went ahead to unregister the devlink port. And because
      there exists an UNUSED port flavour, we actually re-register the devlink
      port as UNUSED.
      
      Commit 08156ba4 ("net: dsa: Add devlink port regions support to
      DSA") added devlink port regions, which are set up by the driver and not
      by DSA.
      
      When we trigger the devlink port deregistration and reregistration as
      unused, devlink now prints another WARN_ON, from here:
      
      devlink_port_unregister:
      	WARN_ON(!list_empty(&devlink_port->region_list));
      
      So the port still has regions, which makes sense, because they were set
      up by the driver, and the driver doesn't know we're unregistering the
      devlink port.
      
      Somebody needs to tear them down, and optionally (actually it would be
      nice, to be consistent) set them up again for the new devlink port.
      
      But DSA's layering stays in our way quite badly here.
      
      The options I've considered are:
      
      1. Introduce a function in devlink to just change a port's type and
         flavour. No dice, devlink keeps a lot of state, it really wants the
         port to not be registered when you set its parameters, so changing
         anything can only be done by destroying what we currently have and
         recreating it.
      
      2. Make DSA cache the parameters passed to dsa_devlink_port_region_create,
         and the region returned, keep those in a list, then when the devlink
         port unregister needs to take place, the existing devlink regions are
         destroyed by DSA, and we replay the creation of new regions using the
         cached parameters. Problem: mv88e6xxx keeps the region pointers in
         chip->ports[port].region, and these will remain stale after DSA frees
         them. There are many things DSA can do, but updating mv88e6xxx's
         private pointers is not one of them.
      
      3. Just let the driver do it (i.e. introduce a very specific method
         called ds->ops->port_reinit_as_unused, which unregisters its devlink
         port devlink regions, then the old devlink port, then registers the
         new one, then the devlink port regions for it). While it does work,
         as opposed to the others, it's pretty horrible from an API
         perspective and we can do better.
      
      4. Introduce a new pair of methods, ->port_setup and ->port_teardown,
         which in the case of mv88e6xxx must register and unregister the
         devlink port regions. Call these 2 methods when the port must be
         reinitialized as unused.
      
      Naturally, I went for the 4th approach.
      
      Fixes: 08156ba4 ("net: dsa: Add devlink port regions support to DSA")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd292c18
    • Krzysztof Kozlowski's avatar
      net: freescale: drop unneeded MODULE_ALIAS · fdb47583
      Krzysztof Kozlowski authored
      The MODULE_DEVICE_TABLE already creates proper alias for platform
      driver.  Having another MODULE_ALIAS causes the alias to be duplicated.
      Signed-off-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fdb47583
    • David S. Miller's avatar
      Merge branch 'ocelot-phylink-fixes' · d614489f
      David S. Miller authored
      Colin Foster says:
      
      ====================
      ocelot phylink fixes
      
      When the ocelot driver was migrated to phylink, e6e12df6 ("net:
      mscc: ocelot: convert to phylink") there were two additional writes to
      registers that became stale. One write was to DEV_CLOCK_CFG and one was
      to ANA_PFC_PCF_CFG.
      
      Both of these writes referenced the variable "speed" which originally
      was set to OCELOT_SPEED_{10,100,1000,2500}. These macros expand to
      values of 3, 2, 1, or 0, respectively. After the update, the variable
      speed is set to SPEED_{10,100,1000,2500} which expand to 10, 100, 1000,
      and 2500. So invalid values were getting written to the two registers,
      which would lead to either a lack of functionality or undefined
      funcationality.
      
      Fixing these values was the intent of v1 of this patch set - submitted
      as "[PATCH v1 net] net: ethernet: mscc: ocelot: bug fix when writing MAC
      speed"
      
      During that review it was determined that both writes were actually
      unnecessary. DEV_CLOCK_CFG is a duplicate write, so can be removed
      entirely. This was accidentally submitted as as a new, lone patch titled
      "[PATCH v1 net] net: mscc: ocelot: remove buggy duplicate write to
      DEV_CLOCK_CFG". This is part of what is considered v2 of this patch set.
      
      Additionally, the write to ANA_PFC_PFC_CFG is also unnecessary. Priority
      flow contol is disabled, so configuring it is useless and should be
      removed. This was also submitted as a new, lone patch titled "[PATCH v1
      net] net: mscc: ocelot: remove buggy and useless write to ANA_PFC_PFC_CFG".
      This is the rest of what is considered v2 of this patch set.
      
      v3
      Identical to v2, but fixes the patch numbering to v3 and submitting the
      two changes as a patch set.
      
      v2
      Note: I misunderstood and submitted two new "v1" patches instead of a
      single "v2" patch set.
      - Remove the buggy writes altogher
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d614489f
    • Colin Foster's avatar
      net: mscc: ocelot: remove buggy duplicate write to DEV_CLOCK_CFG · ba68e994
      Colin Foster authored
      When updating ocelot to use phylink, a second write to DEV_CLOCK_CFG was
      mistakenly left in. It used the variable "speed" which, previously, would
      would have been assigned a value of OCELOT_SPEED_1000. In phylink the
      variable is be SPEED_1000, which is invalid for the
      DEV_CLOCK_LINK_SPEED macro. Removing it as unnecessary and buggy.
      
      Fixes: e6e12df6 ("net: mscc: ocelot: convert to phylink")
      Signed-off-by: default avatarColin Foster <colin.foster@in-advantage.com>
      Reviewed-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba68e994
    • Colin Foster's avatar
      net: mscc: ocelot: remove buggy and useless write to ANA_PFC_PFC_CFG · 163957c4
      Colin Foster authored
      A useless write to ANA_PFC_PFC_CFG was left in while refactoring ocelot to
      phylink. Since priority flow control is disabled, writing the speed has no
      effect.
      
      Further, it was using ethtool.h SPEED_ instead of OCELOT_SPEED_ macros,
      which are incorrectly offset for GENMASK.
      
      Lastly, for priority flow control to properly function, some scenarios
      would rely on the rate adaptation from the PCS while the MAC speed would
      be fixed. So it isn't used, and even if it was, neither "speed" nor
      "mac_speed" are necessarily the correct values to be used.
      
      Fixes: e6e12df6 ("net: mscc: ocelot: convert to phylink")
      Signed-off-by: default avatarColin Foster <colin.foster@in-advantage.com>
      Reviewed-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      163957c4
    • Thomas Gleixner's avatar
      net: core: Correct the sock::sk_lock.owned lockdep annotations · 2dcb96ba
      Thomas Gleixner authored
      lock_sock_fast() and lock_sock_nested() contain lockdep annotations for the
      sock::sk_lock.owned 'mutex'. sock::sk_lock.owned is not a regular mutex. It
      is just lockdep wise equivalent. In fact it's an open coded trivial mutex
      implementation with some interesting features.
      
      sock::sk_lock.slock is a regular spinlock protecting the 'mutex'
      representation sock::sk_lock.owned which is a plain boolean. If 'owned' is
      true, then some other task holds the 'mutex', otherwise it is uncontended.
      As this locking construct is obviously endangered by lock ordering issues as
      any other locking primitive it got lockdep annotated via a dedicated
      dependency map sock::sk_lock.dep_map which has to be updated at the lock
      and unlock sites.
      
      lock_sock_nested() is a straight forward 'mutex' lock operation:
      
        might_sleep();
        spin_lock_bh(sock::sk_lock.slock)
        while (!try_lock(sock::sk_lock.owned)) {
            spin_unlock_bh(sock::sk_lock.slock);
            wait_for_release();
            spin_lock_bh(sock::sk_lock.slock);
        }
      
      The lockdep annotation for sock::sk_lock.owned is for unknown reasons
      _after_ the lock has been acquired, i.e. after the code block above and
      after releasing sock::sk_lock.slock, but inside the bottom halves disabled
      region:
      
        spin_unlock(sock::sk_lock.slock);
        mutex_acquire(&sk->sk_lock.dep_map, subclass, 0, _RET_IP_);
        local_bh_enable();
      
      The placement after the unlock is obvious because otherwise the
      mutex_acquire() would nest into the spin lock held region.
      
      But that's from the lockdep perspective still the wrong place:
      
       1) The mutex_acquire() is issued _after_ the successful acquisition which
          is pointless because in a dead lock scenario this point is never
          reached which means that if the deadlock is the first instance of
          exposing the wrong lock order lockdep does not have a chance to detect
          it.
      
       2) It only works because lockdep is rather lax on the context from which
          the mutex_acquire() is issued. Acquiring a mutex inside a bottom halves
          and therefore non-preemptible region is obviously invalid, except for a
          trylock which is clearly not the case here.
      
          This 'works' stops working on RT enabled kernels where the bottom halves
          serialization is done via a local lock, which exposes this misplacement
          because the 'mutex' and the local lock nest the wrong way around and
          lockdep complains rightfully about a lock inversion.
      
      The placement is wrong since the initial commit a5b5bb9a ("[PATCH]
      lockdep: annotate sk_locks") which introduced this.
      
      Fix it by moving the mutex_acquire() in front of the actual lock
      acquisition, which is what the regular mutex_lock() operation does as well.
      
      lock_sock_fast() is not that straight forward. It looks at the first glance
      like a convoluted trylock operation:
      
        spin_lock_bh(sock::sk_lock.slock)
        if (!sock::sk_lock.owned)
            return false;
        while (!try_lock(sock::sk_lock.owned)) {
            spin_unlock_bh(sock::sk_lock.slock);
            wait_for_release();
            spin_lock_bh(sock::sk_lock.slock);
        }
        spin_unlock(sock::sk_lock.slock);
        mutex_acquire(&sk->sk_lock.dep_map, subclass, 0, _RET_IP_);
        local_bh_enable();
        return true;
      
      But that's not the case: lock_sock_fast() is an interesting optimization
      for short critical sections which can run with bottom halves disabled and
      sock::sk_lock.slock held. This allows to shortcut the 'mutex' operation in
      the non contended case by preventing other lockers to acquire
      sock::sk_lock.owned because they are blocked on sock::sk_lock.slock, which
      in turn avoids the overhead of doing the heavy processing in release_sock()
      including waking up wait queue waiters.
      
      In the contended case, i.e. when sock::sk_lock.owned == true the behavior
      is the same as lock_sock_nested().
      
      Semantically this shortcut means, that the task acquired the 'mutex' even
      if it does not touch the sock::sk_lock.owned field in the non-contended
      case. Not telling lockdep about this shortcut acquisition is hiding
      potential lock ordering violations in the fast path.
      
      As a consequence the same reasoning as for the above lock_sock_nested()
      case vs. the placement of the lockdep annotation applies.
      
      The current placement of the lockdep annotation was just copied from
      the original lock_sock(), now renamed to lock_sock_nested(),
      implementation.
      
      Fix this by moving the mutex_acquire() in front of the actual lock
      acquisition and adding the corresponding mutex_release() into
      unlock_sock_fast(). Also document the fast path return case with a comment.
      Reported-by: default avatarSebastian Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: netdev@vger.kernel.org
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2dcb96ba
    • Alejandro Concepcion-Rodriguez's avatar
      docs: net: dsa: sja1105: fix reference to sja1105.txt · 48e6d083
      Alejandro Concepcion-Rodriguez authored
      The file sja1105.txt was converted to nxp,sja1105.yaml.
      Signed-off-by: default avatarAlejandro Concepcion-Rodriguez <asconcepcion@acoro.eu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48e6d083
    • Randy Dunlap's avatar
      igc: fix build errors for PTP · 87758511
      Randy Dunlap authored
      When IGC=y and PTP_1588_CLOCK=m, the ptp_*() interface family is
      not available to the igc driver. Make this driver depend on
      PTP_1588_CLOCK_OPTIONAL so that it will build without errors.
      
      Various igc commits have used ptp_*() functions without checking
      that PTP_1588_CLOCK is enabled. Fix all of these here.
      
      Fixes these build errors:
      
      ld: drivers/net/ethernet/intel/igc/igc_main.o: in function `igc_msix_other':
      igc_main.c:(.text+0x6494): undefined reference to `ptp_clock_event'
      ld: igc_main.c:(.text+0x64ef): undefined reference to `ptp_clock_event'
      ld: igc_main.c:(.text+0x6559): undefined reference to `ptp_clock_event'
      ld: drivers/net/ethernet/intel/igc/igc_ethtool.o: in function `igc_ethtool_get_ts_info':
      igc_ethtool.c:(.text+0xc7a): undefined reference to `ptp_clock_index'
      ld: drivers/net/ethernet/intel/igc/igc_ptp.o: in function `igc_ptp_feature_enable_i225':
      igc_ptp.c:(.text+0x330): undefined reference to `ptp_find_pin'
      ld: igc_ptp.c:(.text+0x36f): undefined reference to `ptp_find_pin'
      ld: drivers/net/ethernet/intel/igc/igc_ptp.o: in function `igc_ptp_init':
      igc_ptp.c:(.text+0x11cd): undefined reference to `ptp_clock_register'
      ld: drivers/net/ethernet/intel/igc/igc_ptp.o: in function `igc_ptp_stop':
      igc_ptp.c:(.text+0x12dd): undefined reference to `ptp_clock_unregister'
      ld: drivers/platform/x86/dell/dell-wmi-privacy.o: in function `dell_privacy_wmi_probe':
      
      Fixes: 64433e5b ("igc: Enable internal i225 PPS")
      Fixes: 60dbede0 ("igc: Add support for ethtool GET_TS_INFO command")
      Fixes: 87938851 ("igc: enable auxiliary PHC functions for the i225")
      Fixes: 5f295805 ("igc: Add basic skeleton for PTP")
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Ederson de Souza <ederson.desouza@intel.com>
      Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
      Cc: Vinicius Costa Gomes <vinicius.gomes@intel.com>
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Cc: intel-wired-lan@lists.osuosl.org
      Acked-by: default avatarVinicius Costa Gomes <vinicius.gomes@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      87758511
    • Claudiu Manoil's avatar
      enetc: Fix uninitialized struct dim_sample field usage · 9f7afa05
      Claudiu Manoil authored
      The only struct dim_sample member that does not get
      initialized by dim_update_sample() is comp_ctr. (There
      is special API to initialize comp_ctr:
      dim_update_sample_with_comps(), and it is currently used
      only for RDMA.) comp_ctr is used to compute curr_stats->cmps
      and curr_stats->cpe_ratio (see dim_calc_stats()) which in
      turn are consumed by the rdma_dim_*() API.  Therefore,
      functionally, the net_dim*() API consumers are not affected.
      Nevertheless, fix the computation of statistics based
      on an uninitialized variable, even if the mentioned statistics
      are not used at the moment.
      
      Fixes: ae0e6a5d ("enetc: Add adaptive interrupt coalescing")
      Signed-off-by: default avatarClaudiu Manoil <claudiu.manoil@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f7afa05
    • Claudiu Manoil's avatar
      enetc: Fix illegal access when reading affinity_hint · 7237a494
      Claudiu Manoil authored
      irq_set_affinity_hit() stores a reference to the cpumask_t
      parameter in the irq descriptor, and that reference can be
      accessed later from irq_affinity_hint_proc_show(). Since
      the cpu_mask parameter passed to irq_set_affinity_hit() has
      only temporary storage (it's on the stack memory), later
      accesses to it are illegal. Thus reads from the corresponding
      procfs affinity_hint file can result in paging request oops.
      
      The issue is fixed by the get_cpu_mask() helper, which provides
      a permanent storage for the cpumask_t parameter.
      
      Fixes: d4fd0404 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
      Signed-off-by: default avatarClaudiu Manoil <claudiu.manoil@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7237a494
    • Jason Wang's avatar
      virtio-net: fix pages leaking when building skb in big mode · afd92d82
      Jason Wang authored
      We try to use build_skb() if we had sufficient tailroom. But we forget
      to release the unused pages chained via private in big mode which will
      leak pages. Fixing this by release the pages after building the skb in
      big mode.
      
      Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
      Fixes: fb32856b ("virtio-net: page_to_skb() use build_skb when there's sufficient tailroom")
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Reviewed-by: default avatarXuan Zhuo <xuanzhuo@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      afd92d82
    • Jan Beulich's avatar
      xen-netback: correct success/error reporting for the SKB-with-fraglist case · 3ede7f84
      Jan Beulich authored
      When re-entering the main loop of xenvif_tx_check_gop() a 2nd time, the
      special considerations for the head of the SKB no longer apply. Don't
      mistakenly report ERROR to the frontend for the first entry in the list,
      even if - from all I can tell - this shouldn't matter much as the overall
      transmit will need to be considered failed anyway.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Reviewed-by: default avatarPaul Durrant <paul@xen.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ede7f84
    • David S. Miller's avatar
      Merge branch 'dsa-shutdown' · 564df7ab
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Make DSA switch drivers compatible with masters which unregister on shutdown
      
      Changes in v2:
      - fix build for b53_mmap
      - use unregister_netdevice_many
      
      It was reported by Lino here:
      
      https://lore.kernel.org/netdev/20210909095324.12978-1-LinoSanfilippo@gmx.de/
      
      that when the DSA master attempts to unregister its net_device on
      shutdown, DSA should prevent that operation from succeeding because it
      holds a reference to it. This hangs the shutdown process.
      
      This issue was essentially introduced in commit 2f1e8ea7 ("net: dsa:
      link interfaces with the DSA master to get rid of lockdep warnings").
      The present series patches all DSA drivers to handle that case,
      depending on whether those drivers were introduced before or after the
      offending commit, a different Fixes: tag is specified for them.
      
      The approach taken by this series solves the issue in essentially the
      same way as Lino's patches, except for three key differences:
      
      - this series takes a more minimal approach in what is done on shutdown,
        we do not attempt a full tree teardown as that is not strictly
        necessary. I might revisit this if there are compelling reasons to do
        otherwise
      
      - this series fixes the issues for all DSA drivers, not just KSZ9897
      
      - this series works even if the ->remove driver method gets called for
        the same device too, not just ->shutdown. This is really possible to
        happen for SPI device drivers, and potentially possible for other bus
        device drivers too.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      564df7ab
    • Vladimir Oltean's avatar
      net: dsa: xrs700x: be compatible with masters which unregister on shutdown · a68e9da4
      Vladimir Oltean authored
      Since commit 2f1e8ea7 ("net: dsa: link interfaces with the DSA
      master to get rid of lockdep warnings"), DSA gained a requirement which
      it did not fulfill, which is to unlink itself from the DSA master at
      shutdown time.
      
      Since the Arrow SpeedChips XRS700x driver was introduced after the bad
      commit, it has never worked with DSA masters which decide to unregister
      their net_device on shutdown, effectively hanging the reboot process.
      To fix that, we need to call dsa_switch_shutdown.
      
      These devices can be connected by I2C or by MDIO, and if I search for
      I2C or MDIO bus drivers that implement their ->shutdown by redirecting
      it to ->remove I don't see any, however this does not mean it would not
      be possible. To be compatible with that pattern, it is necessary to
      implement an "if this then not that" scheme, to avoid ->remove and
      ->shutdown from being called both for the same struct device.
      
      Fixes: ee00b24f ("net: dsa: add Arrow SpeedChips XRS700x driver")
      Link: https://lore.kernel.org/netdev/20210909095324.12978-1-LinoSanfilippo@gmx.de/Reported-by: default avatarLino Sanfilippo <LinoSanfilippo@gmx.de>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarGeorge McCollister <george.mccollister@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a68e9da4
    • Vladimir Oltean's avatar
      net: dsa: microchip: ksz8863: be compatible with masters which unregister on shutdown · fe405307
      Vladimir Oltean authored
      Since commit 2f1e8ea7 ("net: dsa: link interfaces with the DSA
      master to get rid of lockdep warnings"), DSA gained a requirement which
      it did not fulfill, which is to unlink itself from the DSA master at
      shutdown time.
      
      Since the Microchip sub-driver for KSZ8863 was introduced after the bad
      commit, it has never worked with DSA masters which decide to unregister
      their net_device on shutdown, effectively hanging the reboot process.
      To fix that, we need to call dsa_switch_shutdown.
      
      Since this driver expects the MDIO bus to be backed by mdio_bitbang, I
      don't think there is currently any MDIO bus driver which implements its
      ->shutdown by redirecting it to ->remove, but in any case, to be
      compatible with that pattern, it is necessary to implement an "if this
      then not that" scheme, to avoid ->remove and ->shutdown from being
      called both for the same struct device.
      
      Fixes: 60a36476 ("net: dsa: microchip: Add Microchip KSZ8863 SMI based driver support")
      Link: https://lore.kernel.org/netdev/20210909095324.12978-1-LinoSanfilippo@gmx.de/Reported-by: default avatarLino Sanfilippo <LinoSanfilippo@gmx.de>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe405307
    • Vladimir Oltean's avatar
      net: dsa: hellcreek: be compatible with masters which unregister on shutdown · 46baae56
      Vladimir Oltean authored
      Since commit 2f1e8ea7 ("net: dsa: link interfaces with the DSA
      master to get rid of lockdep warnings"), DSA gained a requirement which
      it did not fulfill, which is to unlink itself from the DSA master at
      shutdown time.
      
      Since the hellcreek driver was introduced after the bad commit, it has
      never worked with DSA masters which decide to unregister their
      net_device on shutdown, effectively hanging the reboot process.
      
      Hellcreek is a platform device driver, so we probably cannot have the
      oddities of ->shutdown and ->remove getting both called for the exact
      same struct device. But to be in line with the pattern from the other
      device drivers which are on slow buses, implement the same "if this then
      not that" pattern of either running the ->shutdown or the ->remove hook.
      The driver's current ->remove implementation makes that very easy
      because it already zeroes out its device_drvdata on ->remove.
      
      Fixes: e4b27ebc ("net: dsa: Add DSA driver for Hirschmann Hellcreek switches")
      Link: https://lore.kernel.org/netdev/20210909095324.12978-1-LinoSanfilippo@gmx.de/Reported-by: default avatarLino Sanfilippo <LinoSanfilippo@gmx.de>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: Kurt Kanzenbach's avatarKurt Kanzenbach <kurt@linutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      46baae56
    • Vladimir Oltean's avatar
      net: dsa: be compatible with masters which unregister on shutdown · 0650bf52
      Vladimir Oltean authored
      Lino reports that on his system with bcmgenet as DSA master and KSZ9897
      as a switch, rebooting or shutting down never works properly.
      
      What does the bcmgenet driver have special to trigger this, that other
      DSA masters do not? It has an implementation of ->shutdown which simply
      calls its ->remove implementation. Otherwise said, it unregisters its
      network interface on shutdown.
      
      This message can be seen in a loop, and it hangs the reboot process there:
      
      unregister_netdevice: waiting for eth0 to become free. Usage count = 3
      
      So why 3?
      
      A usage count of 1 is normal for a registered network interface, and any
      virtual interface which links itself as an upper of that will increment
      it via dev_hold. In the case of DSA, this is the call path:
      
      dsa_slave_create
      -> netdev_upper_dev_link
         -> __netdev_upper_dev_link
            -> __netdev_adjacent_dev_insert
               -> dev_hold
      
      So a DSA switch with 3 interfaces will result in a usage count elevated
      by two, and netdev_wait_allrefs will wait until they have gone away.
      
      Other stacked interfaces, like VLAN, watch NETDEV_UNREGISTER events and
      delete themselves, but DSA cannot just vanish and go poof, at most it
      can unbind itself from the switch devices, but that must happen strictly
      earlier compared to when the DSA master unregisters its net_device, so
      reacting on the NETDEV_UNREGISTER event is way too late.
      
      It seems that it is a pretty established pattern to have a driver's
      ->shutdown hook redirect to its ->remove hook, so the same code is
      executed regardless of whether the driver is unbound from the device, or
      the system is just shutting down. As Florian puts it, it is quite a big
      hammer for bcmgenet to unregister its net_device during shutdown, but
      having a common code path with the driver unbind helps ensure it is well
      tested.
      
      So DSA, for better or for worse, has to live with that and engage in an
      arms race of implementing the ->shutdown hook too, from all individual
      drivers, and do something sane when paired with masters that unregister
      their net_device there. The only sane thing to do, of course, is to
      unlink from the master.
      
      However, complications arise really quickly.
      
      The pattern of redirecting ->shutdown to ->remove is not unique to
      bcmgenet or even to net_device drivers. In fact, SPI controllers do it
      too (see dspi_shutdown -> dspi_remove), and presumably, I2C controllers
      and MDIO controllers do it too (this is something I have not researched
      too deeply, but even if this is not the case today, it is certainly
      plausible to happen in the future, and must be taken into consideration).
      
      Since DSA switches might be SPI devices, I2C devices, MDIO devices, the
      insane implication is that for the exact same DSA switch device, we
      might have both ->shutdown and ->remove getting called.
      
      So we need to do something with that insane environment. The pattern
      I've come up with is "if this, then not that", so if either ->shutdown
      or ->remove gets called, we set the device's drvdata to NULL, and in the
      other hook, we check whether the drvdata is NULL and just do nothing.
      This is probably not necessary for platform devices, just for devices on
      buses, but I would really insist for consistency among drivers, because
      when code is copy-pasted, it is not always copy-pasted from the best
      sources.
      
      So depending on whether the DSA switch's ->remove or ->shutdown will get
      called first, we cannot really guarantee even for the same driver if
      rebooting will result in the same code path on all platforms. But
      nonetheless, we need to do something minimally reasonable on ->shutdown
      too to fix the bug. Of course, the ->remove will do more (a full
      teardown of the tree, with all data structures freed, and this is why
      the bug was not caught for so long). The new ->shutdown method is kept
      separate from dsa_unregister_switch not because we couldn't have
      unregistered the switch, but simply in the interest of doing something
      quick and to the point.
      
      The big question is: does the DSA switch's ->shutdown get called earlier
      than the DSA master's ->shutdown? If not, there is still a risk that we
      might still trigger the WARN_ON in unregister_netdevice that says we are
      attempting to unregister a net_device which has uppers. That's no good.
      Although the reference to the master net_device won't physically go away
      even if DSA's ->shutdown comes afterwards, remember we have a dev_hold
      on it.
      
      The answer to that question lies in this comment above device_link_add:
      
       * A side effect of the link creation is re-ordering of dpm_list and the
       * devices_kset list by moving the consumer device and all devices depending
       * on it to the ends of these lists (that does not happen to devices that have
       * not been registered when this function is called).
      
      so the fact that DSA uses device_link_add towards its master is not
      exactly for nothing. device_shutdown() walks devices_kset from the back,
      so this is our guarantee that DSA's shutdown happens before the master's
      shutdown.
      
      Fixes: 2f1e8ea7 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings")
      Link: https://lore.kernel.org/netdev/20210909095324.12978-1-LinoSanfilippo@gmx.de/Reported-by: default avatarLino Sanfilippo <LinoSanfilippo@gmx.de>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0650bf52
    • Vladimir Oltean's avatar
      net: mdio: introduce a shutdown method to mdio device drivers · cf957997
      Vladimir Oltean authored
      MDIO-attached devices might have interrupts and other things that might
      need quiesced when we kexec into a new kernel. Things are even more
      creepy when those interrupt lines are shared, and in that case it is
      absolutely mandatory to disable all interrupt sources.
      
      Moreover, MDIO devices might be DSA switches, and DSA needs its own
      shutdown method to unlink from the DSA master, which is a new
      requirement that appeared after commit 2f1e8ea7 ("net: dsa: link
      interfaces with the DSA master to get rid of lockdep warnings").
      
      So introduce a ->shutdown method in the MDIO device driver structure.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cf957997
  3. 17 Sep, 2021 3 commits
  4. 16 Sep, 2021 8 commits
    • Linus Torvalds's avatar
      Merge tag 'net-5.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · fc0c0548
      Linus Torvalds authored
      Pull networking fixes from Jakub Kicinski:
       "Including fixes from bpf.
      
        Current release - regressions:
      
         - vhost_net: fix OoB on sendmsg() failure
      
         - mlx5: bridge, fix uninitialized variable usage
      
         - bnxt_en: fix error recovery regression
      
        Current release - new code bugs:
      
         - bpf, mm: fix lockdep warning triggered by stack_map_get_build_id_offset()
      
        Previous releases - regressions:
      
         - r6040: restore MDIO clock frequency after MAC reset
      
         - tcp: fix tp->undo_retrans accounting in tcp_sacktag_one()
      
         - dsa: flush switchdev workqueue before tearing down CPU/DSA ports
      
        Previous releases - always broken:
      
         - ptp: dp83640: don't define PAGE0, avoid compiler warning
      
         - igc: fix tunnel segmentation offloads
      
         - phylink: update SFP selected interface on advertising changes
      
         - stmmac: fix system hang caused by eee_ctrl_timer during suspend/resume
      
         - mlx5e: fix mutual exclusion between CQE compression and HW TS
      
        Misc:
      
         - bpf, cgroups: fix cgroup v2 fallback on v1/v2 mixed mode
      
         - sfc: fallback for lack of xdp tx queues
      
         - hns3: add option to turn off page pool feature"
      
      * tag 'net-5.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (67 commits)
        mlxbf_gige: clear valid_polarity upon open
        igc: fix tunnel offloading
        net/{mlx5|nfp|bnxt}: Remove unnecessary RTNL lock assert
        net: wan: wanxl: define CROSS_COMPILE_M68K
        selftests: nci: replace unsigned int with int
        net: dsa: flush switchdev workqueue before tearing down CPU/DSA ports
        Revert "net: phy: Uniform PHY driver access"
        net: dsa: destroy the phylink instance on any error in dsa_slave_phy_setup
        ptp: dp83640: don't define PAGE0
        bnx2x: Fix enabling network interfaces without VFs
        Revert "Revert "ipv4: fix memory leaks in ip_cmsg_send() callers""
        tcp: fix tp->undo_retrans accounting in tcp_sacktag_one()
        net-caif: avoid user-triggerable WARN_ON(1)
        bpf, selftests: Add test case for mixed cgroup v1/v2
        bpf, selftests: Add cgroup v1 net_cls classid helpers
        bpf, cgroups: Fix cgroup v2 fallback on v1/v2 mixed mode
        bpf: Add oversize check before call kvcalloc()
        net: hns3: fix the timing issue of VF clearing interrupt sources
        net: hns3: fix the exception when query imp info
        net: hns3: disable mac in flr process
        ...
      fc0c0548
    • Guenter Roeck's avatar
      net: 6pack: Fix tx timeout and slot time · 3c0d2a46
      Guenter Roeck authored
      tx timeout and slot time are currently specified in units of HZ.  On
      Alpha, HZ is defined as 1024.  When building alpha:allmodconfig, this
      results in the following error message.
      
        drivers/net/hamradio/6pack.c: In function 'sixpack_open':
        drivers/net/hamradio/6pack.c:71:41: error:
        	unsigned conversion from 'int' to 'unsigned char'
        	changes value from '256' to '0'
      
      In the 6PACK protocol, tx timeout is specified in units of 10 ms and
      transmitted over the wire:
      
          https://www.linux-ax25.org/wiki/6PACK
      
      Defining a value dependent on HZ doesn't really make sense, and
      presumably comes from the (very historical) situation where HZ was
      originally 100.
      
      Note that the SIXP_SLOTTIME use explicitly is about 10ms granularity:
      
              mod_timer(&sp->tx_t, jiffies + ((when + 1) * HZ) / 100);
      
      and the SIXP_TXDELAY walue is sent as a byte over the wire.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3c0d2a46
    • Arnd Bergmann's avatar
      drm/rockchip: cdn-dp-core: Make cdn_dp_core_resume __maybe_unused · 040b8907
      Arnd Bergmann authored
      With the new static annotation, the compiler warns when the functions
      are actually unused:
      
         drivers/gpu/drm/rockchip/cdn-dp-core.c:1123:12: error: 'cdn_dp_resume' defined but not used [-Werror=unused-function]
          1123 | static int cdn_dp_resume(struct device *dev)
               |            ^~~~~~~~~~~~~
      
      Mark them __maybe_unused to suppress that warning as well.
      
      [ Not so 'new' static annotations any more, and I removed the part of
        the patch that added __maybe_unused to cdn_dp_suspend(), because it's
        used by the shutdown/remove code.
      
        So only the resume function ends up possibly unused if CONFIG_PM isn't
        set     - Linus ]
      
      Fixes: 7c49abb4 ("drm/rockchip: cdn-dp-core: Make cdn_dp_core_suspend/resume static")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      040b8907
    • Guenter Roeck's avatar
      cpufreq: vexpress: Drop unused variable · b60cee5b
      Guenter Roeck authored
      arm:allmodconfig fails to build with the following error.
      
        drivers/cpufreq/vexpress-spc-cpufreq.c:454:13: error:
      					unused variable 'cur_cluster'
      
      Remove the unused variable.
      
      Fixes: bb8c26d9 ("cpufreq: vexpress: Set CPUFREQ_IS_COOLING_DEV flag")
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b60cee5b
    • Guenter Roeck's avatar
      alpha: Declare virt_to_phys and virt_to_bus parameter as pointer to volatile · 35a3f4ef
      Guenter Roeck authored
      Some drivers pass a pointer to volatile data to virt_to_bus() and
      virt_to_phys(), and that works fine.  One exception is alpha.  This
      results in a number of compile errors such as
      
        drivers/net/wan/lmc/lmc_main.c: In function 'lmc_softreset':
        drivers/net/wan/lmc/lmc_main.c:1782:50: error:
      	passing argument 1 of 'virt_to_bus' discards 'volatile'
      	qualifier from pointer target type
      
        drivers/atm/ambassador.c: In function 'do_loader_command':
        drivers/atm/ambassador.c:1747:58: error:
      	passing argument 1 of 'virt_to_bus' discards 'volatile'
      	qualifier from pointer target type
      
      Declare the parameter of virt_to_phys and virt_to_bus as pointer to
      volatile to fix the problem.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      35a3f4ef
    • Linus Torvalds's avatar
      3com 3c515: make it compile on 64-bit architectures · db71f8fb
      Linus Torvalds authored
      This driver isn't enabled most places because of the ISA config
      dependency, but alpha still has it.  And I think the 'Jensen' actually
      did have an ISA slot.
      
      However, it doesn't build cleanly, because the "Vortex bus master" code
      just casts the skb->data pointer to 'int':
      
              outl((int) (skb->data), ioaddr + Wn7_MasterAddr);
      
      which is all kinds of broken.  Even on a good old traditional PC/AT it
      would be broken because the high bits will be random kernel address
      bits, but presumably the hardware ignores those bits.  I mean, it's ISA.
      We're talking 16MB dma limits. The "good old days".
      
      Make the build happy with this kind of craziness by using the proper
      isa_virt_to_bus() handling that the full bus master code uses anyway
      (the Vortex bus mastering is a limited special case).
      
      Who knows, this might even work.
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      db71f8fb
    • Linus Torvalds's avatar
      Merge tag 'for-5.15/parisc-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 5fe983d3
      Linus Torvalds authored
      Pull parisc fix from Helge Deller:
       "Fix a build warning when using the PAGE0 pointer"
      
      * tag 'for-5.15/parisc-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: Use absolute_pointer() to define PAGE0
      5fe983d3
    • Linus Torvalds's avatar
      Merge tag 'm68k-for-v5.15-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k · 077a6ccf
      Linus Torvalds authored
      Pull m68k fixes from Geert Uytterhoeven:
      
       - Warning fixes to mitigate CONFIG_WERROR=y
      
      * tag 'm68k-for-v5.15-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
        m68k: mvme: Remove overdue #warnings in RTC handling
        m68k: Double cast io functions to unsigned long
      077a6ccf