Skip to content

cloud-kernel
cloud-kernel

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

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 14 5月, 2018 1 次提交
  3. 15 3月, 2018 1 次提交
  5. 24 1月, 2018 1 次提交
  7. 22 1月, 2018 1 次提交
  9. 29 11月, 2017 1 次提交
  11. 14 9月, 2017 1 次提交
  13. 03 6月, 2017 1 次提交
  15. 17 5月, 2017 1 次提交
    • T
      misc: pci_endpoint_test: select CRC32 · a20cfc1c
      由 Tobias Regnery 提交于 
      There is the following link error with CONFIG_PCI_ENDPOINT_TEST=y and
CONFIG_CRC32=m:

drivers/built-in.o: In function 'pci_endpoint_test_ioctl':
pci_endpoint_test.c:(.text+0xf1251): undefined reference to 'crc32_le'
pci_endpoint_test.c:(.text+0xf1322): undefined reference to 'crc32_le'
pci_endpoint_test.c:(.text+0xf13b2): undefined reference to 'crc32_le'
pci_endpoint_test.c:(.text+0xf141e): undefined reference to 'crc32_le'

Fix this by selecting CRC32 in the PCI_ENDPOINT_TEST kconfig entry.

Fixes: 2c156ac7 ("misc: Add host side PCI driver for PCI test function device")
Signed-off-by: NTobias Regnery <tobias.regnery@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a20cfc1c
  17. 28 4月, 2017 1 次提交
  19. 08 4月, 2017 2 次提交
  21. 17 3月, 2017 2 次提交
    • G
      auxdisplay: charlcd: Extract character LCD core from misc/panel · 39f8ea46
      由 Geert Uytterhoeven 提交于 
      Extract the character LCD core from the Parallel port LCD/Keypad Panel
driver in the misc subsystem, and convert it into a subdriver in the
auxdisplay subsystem.  This allows the character LCD core to be used by
other drivers later.

Compilation is controlled by its own Kconfig symbol CHARLCD, which is to
be selected by its users, but can be enabled manually for
compile-testing.

All functions changed their prefix from "lcd_" to "charlcd_", and gained
a "struct charlcd *" parameter to operate on a specific instance.
While the driver API thus is ready to support multiple instances, the
current limitation of a single display (/dev/lcd has a single misc minor
assigned) is retained.

No functional changes intended.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      39f8ea46
    • C
      drivers/misc: Add Aspeed LPC control driver · 6c4e9767
      由 Cyril Bur 提交于 
      In order to manage server systems, there is typically another processor
known as a BMC (Baseboard Management Controller) which is responsible
for powering the server and other various elements, sometimes fans,
often the system flash.

The Aspeed BMC family which is what is used on OpenPOWER machines and a
number of x86 as well is typically connected to the host via an LPC
(Low Pin Count) bus (among others).

The LPC bus is an ISA bus on steroids. It's generally used by the
BMC chip to provide the host with access to the system flash (via MEM/FW
cycles) that contains the BIOS or other host firmware along with a
number of SuperIO-style IOs (via IO space) such as UARTs, IPMI
controllers.

On the BMC chip side, this is all configured via a bunch of registers
whose content is related to a given policy of what devices are exposed
at a per system level, which is system/vendor specific, so we don't want
to bolt that into the BMC kernel. This started with a need to provide
something nicer than /dev/mem for user space to configure these things.

One important aspect of the configuration is how the MEM/FW space is
exposed to the host (ie, the x86 or POWER). Some registers in that
bridge can define a window remapping all or portion of the LPC MEM/FW
space to a portion of the BMC internal bus, with no specific limits
imposed in HW.

I think it makes sense to ensure that this window is configured by a
kernel driver that can apply some serious sanity checks on what it is
configured to map.

In practice, user space wants to control this by flipping the mapping
between essentially two types of portions of the BMC address space:

   - The flash space. This is a region of the BMC MMIO space that
more/less directly maps the system flash (at least for reads, writes
are somewhat more complicated).

   - One (or more) reserved area(s) of the BMC physical memory.

The latter is needed for a number of things, such as avoiding letting
the host manipulate the innards of the BMC flash controller via some
evil backdoor, we want to do flash updates by routing the window to a
portion of memory (under control of a mailbox protocol via some
separate set of registers) which the host can use to write new data in
bulk and then request the BMC to flash it. There are other uses, such
as allowing the host to boot from an in-memory flash image rather than
the one in flash (very handy for continuous integration and test, the
BMC can just download new images).

It is important to note that due to the way the Aspeed chip lets the
kernel configure the mapping between host LPC addresses and BMC ram
addresses the offset within the window must be a multiple of size.
Not doing so will fragment the accessible space rather than simply
moving 'zero' upwards. This is caused by the nature of HICR8 being a
mask and the way host LPC addresses are translated.
Signed-off-by: NCyril Bur <cyrilbur@gmail.com>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Reviewed-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6c4e9767
  23. 10 2月, 2017 2 次提交
  25. 03 2月, 2017 1 次提交
  27. 25 1月, 2017 1 次提交
    • D
      misc: sram: Integrate protect-exec reserved sram area type · 37afff0d
      由 Dave Gerlach 提交于 
      Introduce a new "protect-exec" reserved sram area type which is
makes use of the the existing functionality provided for the "pool"
sram region type for use with the genalloc framework and with the
added requirement that it be maintained as read-only and executable
while allowing for an arbitrary number of drivers to share the space.

This introduces a common way to maintain a region of sram as read-only
and executable and also introduces a helper function, sram_exec_copy,
which allows for copying data to this protected region while maintaining
locking to avoid conflicts between multiple users of the same space. A
region of memory that is marked with the "protect-exec" flag in the
device tree also has the requirement of providing a page aligned block
of memory so that the page attribute manipulation does not affect
surrounding regions.

Also, selectively enable this only for builds that support set_memory_*
calls, for now just ARM, through the use of Kconfig.
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37afff0d
  29. 31 8月, 2016 1 次提交
  31. 15 8月, 2016 1 次提交
  33. 08 2月, 2016 2 次提交
  35. 04 2月, 2016 1 次提交
  37. 21 1月, 2016 1 次提交
  39. 04 10月, 2015 1 次提交
  41. 30 7月, 2015 1 次提交
  43. 25 5月, 2015 1 次提交
  45. 19 11月, 2014 1 次提交
  47. 08 10月, 2014 1 次提交
    • I
      cxl: Add base builtin support · 10542ca0
      由 Ian Munsie 提交于 
      This adds the base cxl support that cannot be built as a module. Specifically
it adds the cxl callbacks that are called from the core powerpc mm code which
must always exist irrespective of if the cxl module is loaded or not. This is
similar to how cell works with CONFIG_SPU_BASE.

This adds a cxl_slbia() call (similar to spu_flush_all_slbs()) which checks if
the cxl module is loaded and in use, returning immediately if it is not. If it
is in use it calls into the cxl SLB invalidation code.
Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      10542ca0
  49. 09 7月, 2014 1 次提交
  51. 25 6月, 2014 1 次提交
  53. 28 5月, 2014 2 次提交
  55. 16 5月, 2014 1 次提交
    • P
      mfd: vexpress: Define the device as MFD cells · 974cc7b9
      由 Pawel Moll 提交于 
      This patch - finally, after over 6 months! :-( - addresses
Samuel's request to split the vexpress-sysreg driver into
smaller portions and define the device in a form of MFD
cells:

* LEDs code has been completely removed and replaced with
  "gpio-leds" nodes in the tree (referencing dedicated
  GPIO subnodes in sysreg - bindings documentation updated);
  this also better fits the reality as some variants of the
  motherboard don't have all the LEDs populated

* syscfg bridge code has been extracted into a separate
  driver (placed in drivers/misc for no better place)

* all the ID & MISC registers are defined as sysconf
  making them available for other drivers should they need
  to use them (and also to the user via /sys/kernel/debug/regmap
  which can be helpful in platform debugging)
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
      974cc7b9
  57. 04 5月, 2014 1 次提交
  59. 17 4月, 2014 1 次提交
  61. 09 3月, 2014 1 次提交
  63. 01 3月, 2014 1 次提交
  65. 19 12月, 2013 1 次提交
  67. 17 10月, 2013 1 次提交
  69. 27 9月, 2013 1 次提交