2017-11-01 22:09:13 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
|
drivers/misc: Add Aspeed LPC control driver
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: Cyril Bur <cyrilbur@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-17 11:28:49 +08:00
|
|
|
/*
|
|
|
|
|
* Copyright 2017 IBM Corp.
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
|
* as published by the Free Software Foundation; either version
|
|
|
|
|
* 2 of the License, or (at your option) any later version.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _UAPI_LINUX_ASPEED_LPC_CTRL_H
|
|
|
|
|
#define _UAPI_LINUX_ASPEED_LPC_CTRL_H
|
|
|
|
|
|
|
|
|
|
#include <linux/ioctl.h>
|
2017-03-28 22:10:32 +08:00
|
|
|
#include <linux/types.h>
|
drivers/misc: Add Aspeed LPC control driver
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: Cyril Bur <cyrilbur@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-17 11:28:49 +08:00
|
|
|
|
|
|
|
|
/* Window types */
|
|
|
|
|
#define ASPEED_LPC_CTRL_WINDOW_FLASH 1
|
|
|
|
|
#define ASPEED_LPC_CTRL_WINDOW_MEMORY 2
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This driver provides a window for the host to access a BMC resource
|
|
|
|
|
* across the BMC <-> Host LPC bus.
|
|
|
|
|
*
|
|
|
|
|
* window_type: The BMC resource that the host will access through the
|
|
|
|
|
* window. BMC flash and BMC RAM.
|
|
|
|
|
*
|
|
|
|
|
* window_id: For each window type there may be multiple windows,
|
|
|
|
|
* these are referenced by ID.
|
|
|
|
|
*
|
|
|
|
|
* flags: Reserved for future use, this field is expected to be
|
|
|
|
|
* zeroed.
|
|
|
|
|
*
|
|
|
|
|
* addr: Address on the host LPC bus that the specified window should
|
|
|
|
|
* be mapped. This address must be power of two aligned.
|
|
|
|
|
*
|
|
|
|
|
* offset: Offset into the BMC window that should be mapped to the
|
|
|
|
|
* host (at addr). This must be a multiple of size.
|
|
|
|
|
*
|
|
|
|
|
* size: The size of the mapping. The smallest possible size is 64K.
|
|
|
|
|
* This must be power of two aligned.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
struct aspeed_lpc_ctrl_mapping {
|
|
|
|
|
__u8 window_type;
|
|
|
|
|
__u8 window_id;
|
|
|
|
|
__u16 flags;
|
|
|
|
|
__u32 addr;
|
|
|
|
|
__u32 offset;
|
|
|
|
|
__u32 size;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define __ASPEED_LPC_CTRL_IOCTL_MAGIC 0xb2
|
|
|
|
|
|
|
|
|
|
#define ASPEED_LPC_CTRL_IOCTL_GET_SIZE _IOWR(__ASPEED_LPC_CTRL_IOCTL_MAGIC, \
|
|
|
|
|
0x00, struct aspeed_lpc_ctrl_mapping)
|
|
|
|
|
|
|
|
|
|
#define ASPEED_LPC_CTRL_IOCTL_MAP _IOW(__ASPEED_LPC_CTRL_IOCTL_MAGIC, \
|
|
|
|
|
0x01, struct aspeed_lpc_ctrl_mapping)
|
|
|
|
|
|
|
|
|
|
#endif /* _UAPI_LINUX_ASPEED_LPC_CTRL_H */
|