Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 28 11月, 2017 27 次提交
  3. 17 11月, 2017 1 次提交
  5. 16 11月, 2017 2 次提交
  7. 15 11月, 2017 1 次提交
  9. 14 11月, 2017 2 次提交
    • D
      arm64: Make ARMV8_DEPRECATED depend on SYSCTL · 6cfa7cc4
      由 Dave Martin 提交于 
      If CONFIG_SYSCTL=n and CONFIG_ARMV8_DEPRECATED=y, the deprecated
instruction emulation code currently leaks some memory at boot
time, and won't have any runtime control interface.  This does
not feel like useful or intended behaviour...

This patch adds a dependency on CONFIG_SYSCTL, so that such a
kernel can't be built in the first place.

It's probably not worth adding the error-handling / cleanup code
that would be needed to deal with this otherwise: people who
desperately need the emulation can still enable SYSCTL.
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDave Martin <Dave.Martin@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
      6cfa7cc4
    • J
      arm64: Implement __lshrti3 library function · 9bfe7553
      由 Jason A. Donenfeld 提交于 
      Commit fb872273 ("arm64: support __int128 on gcc 5+") added support
for the __int128 data type, but this breaks the build in some configurations
where GCC ends up emitting calls to the __lshrti3 helper in libgcc, which
results in a link error:

  kernel/sched/fair.o: In function `__calc_delta':
  fair.c:(.text+0xca0): undefined reference to `__lshrti3'
  kernel/time/timekeeping.o: In function `timekeeping_resume':
  timekeeping.c:(.text+0x3f60): undefined reference to `__lshrti3'
  make: *** [vmlinux] Error 1

Fix the build by providing an implementation of __lshrti3, like we do
already for __ashlti3 and __ashrti3.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
      9bfe7553
  11. 10 11月, 2017 2 次提交
    • M
      KVM: arm/arm64: GICv4: Add init/teardown of the per-VM vPE irq domain · 74fe55dc
      由 Marc Zyngier 提交于 
      In order to control the GICv4 view of virtual CPUs, we rely
on an irqdomain allocated for that purpose. Let's add a couple
of helpers to that effect.

At the same time, the vgic data structures gain new fields to
track all this... erm... wonderful stuff.

The way we hook into the vgic init is slightly convoluted. We
need the vgic to be initialized (in order to guarantee that
the number of vcpus is now fixed), and we must have a vITS
(otherwise this is all very pointless). So we end-up calling
the init from both vgic_init and vgic_its_create.
Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      74fe55dc
    • M
      kbuild: handle dtb-y and CONFIG_OF_ALL_DTBS natively in Makefile.lib · 7e7962dd
      由 Masahiro Yamada 提交于 
      If CONFIG_OF_ALL_DTBS is enabled, "make ARCH=arm64 dtbs" compiles each
DTB twice; one from arch/arm64/boot/dts/*/Makefile and the other from
the dtb-$(CONFIG_OF_ALL_DTBS) line in arch/arm64/boot/dts/Makefile.
It could be a race problem when building DTBS in parallel.

Another minor issue is CONFIG_OF_ALL_DTBS covers only *.dts in vendor
sub-directories, so this broke when Broadcom added one more hierarchy
in arch/arm64/boot/dts/broadcom/<soc>/.

One idea to fix the issues in a clean way is to move DTB handling
to Kbuild core scripts.  Makefile.dtbinst already recognizes dtb-y
natively, so it should not hurt to do so.

Add $(dtb-y) to extra-y, and $(dtb-) as well if CONFIG_OF_ALL_DTBS is
enabled.  All clutter things in Makefiles go away.

As a bonus clean-up, I also removed dts-dirs.  Just use subdir-y
directly to traverse sub-directories.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
[robh: corrected BUILTIN_DTB to CONFIG_BUILTIN_DTB]
Signed-off-by: NRob Herring <robh@kernel.org>
      7e7962dd
  13. 09 11月, 2017 2 次提交
  15. 07 11月, 2017 3 次提交