Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 16 8月, 2019 1 次提交
  3. 03 7月, 2019 1 次提交
  5. 21 6月, 2019 1 次提交
  7. 25 5月, 2019 2 次提交
  9. 21 5月, 2019 1 次提交
  11. 03 5月, 2019 2 次提交
  13. 30 4月, 2019 1 次提交
  15. 26 4月, 2019 1 次提交
    • P
      drivers/misc: Add Aspeed P2A control driver · 01c60dce
      由 Patrick Venture 提交于 
      The ASPEED AST2400, and AST2500 in some configurations include a
PCI-to-AHB MMIO bridge.  This bridge allows a server to read and write
in the BMC's physical address space.  This feature is especially useful
when using this bridge to send large files to the BMC.

The host may use this to send down a firmware image by staging data at a
specific memory address, and in a coordinated effort with the BMC's
software stack and kernel, transmit the bytes.

This driver enables the BMC to unlock the PCI bridge on demand, and
configure it via ioctl to allow the host to write bytes to an agreed
upon location.  In the primary use-case, the region to use is known
apriori on the BMC, and the host requests this information.  Once this
request is received, the BMC's software stack will enable the bridge and
the region and then using some software flow control (possibly via IPMI
packets), copy the bytes down.  Once the process is complete, the BMC
will disable the bridge and unset any region involved.

The default behavior of this bridge when present is: enabled and all
regions marked read-write.  This driver will fix the regions to be
read-only and then disable the bridge entirely.

The memory regions protected are:
 * BMC flash MMIO window
 * System flash MMIO windows
 * SOC IO (peripheral MMIO)
 * DRAM

The DRAM region itself is all of DRAM and cannot be further specified.
Once the PCI bridge is enabled, the host can read all of DRAM, and if
the DRAM section is write-enabled, then it can write to all of it.
Signed-off-by: NPatrick Venture <venture@google.com>
Reviewed-by: NAndrew Jeffery <andrew@aj.id.au>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      01c60dce
  17. 19 2月, 2019 1 次提交
    • S
      misc: fastrpc: select CONFIG_DMA_SHARED_BUFFER · c0fae22f
      由 Srinivas Kandagatla 提交于 
      Fastrpc is a dma buf exporter as well, so select the corresponding
DMA_SHARED_BUFFER config to fix below compilation errors on platforms
without this config.

ld: drivers/misc/fastrpc.o: in function 'fastrpc_free_map':
fastrpc.c:(.text+0xbe): undefined reference to 'dma_buf_unmap_attachment'
ld: fastrpc.c:(.text+0xcb): undefined reference to 'dma_buf_detach'
ld: fastrpc.c:(.text+0xd4): undefined reference to 'dma_buf_put'
ld: drivers/misc/fastrpc.o: in function 'fastrpc_map_create':
fastrpc.c:(.text+0xb2b): undefined reference to 'dma_buf_get'
ld: fastrpc.c:(.text+0xb47): undefined reference to 'dma_buf_attach'
ld: fastrpc.c:(.text+0xb61): undefined reference to 'dma_buf_map_attachment'
ld: fastrpc.c:(.text+0xc36): undefined reference to 'dma_buf_put'
ld: fastrpc.c:(.text+0xc48): undefined reference to 'dma_buf_detach'
ld: drivers/misc/fastrpc.o: in function 'fastrpc_device_ioctl':
fastrpc.c:(.text+0x1756): undefined reference to 'dma_buf_get'
ld: fastrpc.c:(.text+0x1776): undefined reference to 'dma_buf_put'
ld: fastrpc.c:(.text+0x1780): undefined reference to 'dma_buf_put'
ld: fastrpc.c:(.text+0x1abf): undefined reference to 'dma_buf_export'
ld: fastrpc.c:(.text+0x1ae7): undefined reference to 'dma_buf_fd'
ld: fastrpc.c:(.text+0x1cb5): undefined reference to 'dma_buf_put'
ld: fastrpc.c:(.text+0x1cca): undefined reference to 'dma_buf_put'
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0fae22f
  19. 18 2月, 2019 1 次提交
  21. 12 2月, 2019 1 次提交
  23. 27 11月, 2018 1 次提交
  25. 07 11月, 2018 2 次提交
  27. 14 5月, 2018 1 次提交
  29. 15 3月, 2018 1 次提交
  31. 24 1月, 2018 1 次提交
  33. 22 1月, 2018 1 次提交
  35. 29 11月, 2017 1 次提交
  37. 14 9月, 2017 1 次提交
  39. 03 6月, 2017 1 次提交
  41. 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
  43. 28 4月, 2017 1 次提交
  45. 08 4月, 2017 2 次提交
  47. 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
  49. 10 2月, 2017 2 次提交
  51. 03 2月, 2017 1 次提交
  53. 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
  55. 31 8月, 2016 1 次提交
  57. 15 8月, 2016 1 次提交
  59. 08 2月, 2016 2 次提交
  61. 04 2月, 2016 1 次提交
  63. 21 1月, 2016 1 次提交
  65. 04 10月, 2015 1 次提交