1. 24 9月, 2019 1 次提交
  2. 23 9月, 2019 1 次提交
  3. 21 9月, 2019 1 次提交
  4. 18 9月, 2019 3 次提交
  5. 17 9月, 2019 3 次提交
    • B
      mailbox: mediatek: cmdq: clear the event in cmdq initial flow · 6058f118
      Bibby Hsieh 提交于
      GCE hardware stored event information in own internal sysram,
      if the initial value in those sysram is not zero value
      it will cause a situation that gce can wait the event immediately
      after client ask gce to wait event but not really trigger the
      corresponding hardware.
      
      In order to make sure that the wait event function is
      exactly correct, we need to clear the sysram value in
      cmdq initial flow.
      
      Fixes: 623a6143 ("mailbox: mediatek: Add Mediatek CMDQ driver")
      Signed-off-by: NBibby Hsieh <bibby.hsieh@mediatek.com>
      Reviewed-by: NCK Hu <ck.hu@mediatek.com>
      Reviewed-by: NMatthias Brugger <matthias.bgg@gmail.com>
      Signed-off-by: NJassi Brar <jaswinder.singh@linaro.org>
      6058f118
    • V
      taprio: Add support for hardware offloading · 9c66d156
      Vinicius Costa Gomes 提交于
      This allows taprio to offload the schedule enforcement to capable
      network cards, resulting in more precise windows and less CPU usage.
      
      The gate mask acts on traffic classes (groups of queues of same
      priority), as specified in IEEE 802.1Q-2018, and following the existing
      taprio and mqprio semantics.
      It is up to the driver to perform conversion between tc and individual
      netdev queues if for some reason it needs to make that distinction.
      
      Full offload is requested from the network interface by specifying
      "flags 2" in the tc qdisc creation command, which in turn corresponds to
      the TCA_TAPRIO_ATTR_FLAG_FULL_OFFLOAD bit.
      
      The important detail here is the clockid which is implicitly /dev/ptpN
      for full offload, and hence not configurable.
      
      A reference counting API is added to support the use case where Ethernet
      drivers need to keep the taprio offload structure locally (i.e. they are
      a multi-port switch driver, and configuring a port depends on the
      settings of other ports as well). The refcount_t variable is kept in a
      private structure (__tc_taprio_qopt_offload) and not exposed to drivers.
      
      In the future, the private structure might also be expanded with a
      backpointer to taprio_sched *q, to implement the notification system
      described in the patch (of when admin became oper, or an error occurred,
      etc, so the offload can be monitored with 'tc qdisc show').
      Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@intel.com>
      Signed-off-by: NVoon Weifeng <weifeng.voon@intel.com>
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c66d156
    • P
      cifs: Add support for root file systems · 8eecd1c2
      Paulo Alcantara (SUSE) 提交于
      Introduce a new CONFIG_CIFS_ROOT option to handle root file systems
      over a SMB share.
      
      In order to mount the root file system during the init process, make
      cifs.ko perform non-blocking socket operations while mounting and
      accessing it.
      
      Cc: Steve French <smfrench@gmail.com>
      Reviewed-by: NAurelien Aptel <aaptel@suse.com>
      Signed-off-by: NPaulo Alcantara (SUSE) <paulo@paulo.ac>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      8eecd1c2
  6. 16 9月, 2019 6 次提交
  7. 14 9月, 2019 1 次提交
    • M
      export.h, genksyms: do not make genksyms calculate CRC of trimmed symbols · 69a94abb
      Masahiro Yamada 提交于
      Arnd Bergmann reported false-positive modpost warnings detected by his
      randconfig testing of linux-next.
      
      Actually, this happens under the combination of CONFIG_MODVERSIONS
      and CONFIG_TRIM_UNUSED_KSYMS since commit 15bfc234 ("modpost:
      check for static EXPORT_SYMBOL* functions").
      
      For example, arch/arm/config/multi_v7_defconfig + CONFIG_MODVERSIONS
      + CONFIG_TRIM_UNUSED_KSYMS produces the following false-positives:
      
      WARNING: "__lshrdi3" [vmlinux] is a static (unknown)
      WARNING: "__ashrdi3" [vmlinux] is a static (unknown)
      WARNING: "__aeabi_lasr" [vmlinux] is a static (unknown)
      WARNING: "__aeabi_llsr" [vmlinux] is a static (unknown)
      WARNING: "ftrace_set_clr_event" [vmlinux] is a static (unknown)
      WARNING: "__muldi3" [vmlinux] is a static (unknown)
      WARNING: "__aeabi_ulcmp" [vmlinux] is a static (unknown)
      WARNING: "__ucmpdi2" [vmlinux] is a static (unknown)
      WARNING: "__aeabi_lmul" [vmlinux] is a static (unknown)
      WARNING: "__bswapsi2" [vmlinux] is a static (unknown)
      WARNING: "__bswapdi2" [vmlinux] is a static (unknown)
      WARNING: "__ashldi3" [vmlinux] is a static (unknown)
      WARNING: "__aeabi_llsl" [vmlinux] is a static (unknown)
      
      The root cause of the problem is not in the modpost, but in the
      implementation of CONFIG_TRIM_UNUSED_KSYMS.
      
      If there is at least one untrimmed symbol in the file, genksyms is
      invoked to calculate CRC of *all* the exported symbols in that file
      even if some of them have been trimmed due to no caller existing.
      
      As a result, .tmp_*.ver files contain CRC of trimmed symbols, thus
      unneeded, orphan __crc* symbols are added to objects. It had been
      harmless until recently.
      
      With commit 15bfc234 ("modpost: check for static EXPORT_SYMBOL*
      functions"), it is now harmful because the bogus __crc* symbols make
      modpost call sym_update_crc() to add the symbols to the hash table,
      but there is no one that clears the ->is_static member.
      
      I gave Fixes to the first commit that uncovered the issue, but the
      potential problem has long existed since commit f2355416
      ("export.h: allow for per-symbol configurable EXPORT_SYMBOL()").
      
      Fixes: 15bfc234 ("modpost: check for static EXPORT_SYMBOL* functions")
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: NArnd Bergmann <arnd@arndb.de>
      69a94abb
  8. 13 9月, 2019 15 次提交
  9. 12 9月, 2019 5 次提交
  10. 11 9月, 2019 4 次提交