Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 24 11月, 2015 1 次提交
  3. 10 11月, 2015 1 次提交
  5. 04 11月, 2015 1 次提交
  7. 12 10月, 2015 1 次提交
  9. 02 10月, 2015 1 次提交
  11. 01 10月, 2015 3 次提交
  13. 14 9月, 2015 1 次提交
  15. 08 9月, 2015 13 次提交
  17. 28 8月, 2015 1 次提交
  19. 19 8月, 2015 1 次提交
    • D
      libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option · 7a67832c
      由 Dan Williams 提交于 
      We currently register a platform device for e820 type-12 memory and
register a nvdimm bus beneath it.  Registering the platform device
triggers the device-core machinery to probe for a driver, but that
search currently comes up empty.  Building the nvdimm-bus registration
into the e820_pmem platform device registration in this way forces
libnvdimm to be built-in.  Instead, convert the built-in portion of
CONFIG_X86_PMEM_LEGACY to simply register a platform device and move the
rest of the logic to the driver for e820_pmem, for the following
reasons:

1/ Letting e820_pmem support be a module allows building and testing
   libnvdimm.ko changes without rebooting

2/ All the normal policy around modules can be applied to e820_pmem
   (unbind to disable and/or blacklisting the module from loading by
   default)

3/ Moving the driver to a generic location and converting it to scan
   "iomem_resource" rather than "e820.map" means any other architecture can
   take advantage of this simple nvdimm resource discovery mechanism by
   registering a resource named "Persistent Memory (legacy)"

Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      7a67832c
  21. 14 8月, 2015 1 次提交
  23. 13 8月, 2015 1 次提交
  25. 06 8月, 2015 1 次提交
  27. 23 7月, 2015 2 次提交
  29. 21 7月, 2015 1 次提交
  31. 10 7月, 2015 1 次提交
  33. 04 7月, 2015 1 次提交
  35. 18 6月, 2015 1 次提交
    • L
      tools/power turbostat: dump CONFIG_TDP · 6fb3143b
      由 Len Brown 提交于 
      Config TDP is a feature that allows parts to be configured
for different thermal limits after they have left the factory.

This can have an effect on the operation of the part,
particularly in determiniing...

Max Non-turbo Ratio
Turbo Activation Ratio
Signed-off-by: NLen Brown <len.brown@intel.com>
      6fb3143b
  37. 07 6月, 2015 2 次提交
  39. 04 6月, 2015 1 次提交
  41. 28 5月, 2015 2 次提交
  43. 27 5月, 2015 1 次提交
  45. 19 5月, 2015 1 次提交
    • I
      x86/fpu: Rename xsave.header::xstate_bv to 'xfeatures' · 400e4b20
      由 Ingo Molnar 提交于 
      'xsave.header::xstate_bv' is a misnomer - what does 'bv' stand for?

It probably comes from the 'XGETBV' instruction name, but I could
not find in the Intel documentation where that abbreviation comes
from. It could mean 'bit vector' - or something else?

But how about - instead of guessing about a weird name - we named
the field in an obvious and descriptive way that tells us exactly
what it does?

So rename it to 'xfeatures', which is a bitmask of the
xfeatures that are fpstate_active in that context structure.

Eyesore like:

           fpu->state->xsave.xsave_hdr.xstate_bv |= XSTATE_FP;

is now much more readable:

           fpu->state->xsave.header.xfeatures |= XSTATE_FP;

Which form is not just infinitely more readable, but is also
shorter as well.
Reviewed-by: NBorislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
      400e4b20