BMC/Intel-BMC/linux.git/include/uapi, branch dev-4.7

drivers: fsi: i2c: add driver file operations and bus locking

2017-02-03T00:21:44+00:00

Signed-off-by: Edward A. James Signed-off-by: Joel Stanley

uapi: aspeed-lpc-ctrl: Update userspace structure

2017-01-16T23:46:29+00:00

Benjamin Herrenschmidt wrote: > The implicit padding is a matter of ABI more than C standard, we > already rely on this in a bazillion of places but it *has* bitten us in > a few corner cases (mostly when u64 is involved due to ABI differences > between 32-bit and 64-bit), so explicit padding is indeed preferred. > > Cyril can you respin with: > > struct aspeed_lpc_ctrl_mapping { > __u8 window_type; > __u8 window_id; > __u16 pad; > __u32 addr; > __u32 offset; > __u32 size; > > I prefer that, it makes more sense to keep the window type/id at the > top. Alternatively call "pad", "flags", and describe that clients must > zero it, that way we can use it for future extensions of we ever have > to. We have gone with the flags option. Signed-off-by: Joel Stanley

drivers/misc: Add Aspeed LPC control driver

2017-01-16T00:19:03+00:00

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 [joel: Apply v3 from http://patchwork.ozlabs.org/patch/715545/ with small fixes] Signed-off-by: Joel Stanley

ipmi: add an Aspeed BT IPMI BMC driver

2016-11-10T11:31:14+00:00

Backport from mainline of the main IPMI BMC driver patch plus fixes : - commit d94655b405ba ("ipmi/bt-bmc: remove redundant return value check of platform_get_resource()") - commit a3e6061bad62 ("ipmi/bt-bmc: add a dependency on ARCH_ASPEED") - commit 1a377a79211a ("ipmi: Fix ioremap error handling in bt-bmc") - commit 54f9c4d0778b ("ipmi: add an Aspeed BT IPMI BMC driver") Signed-off-by: Cédric Le Goater Signed-off-by: Joel Stanley

Revert "misc: Add Aspeed BT IPMI host driver"

2016-11-10T11:31:13+00:00

This reverts commit f7b4775fdf656f00f1b692bf3db97b3a8088c057. Signed-off-by: Cédric Le Goater Signed-off-by: Joel Stanley

Merge tag 'v4.7.10' into dev-4.7

2016-10-24T07:02:44+00:00

This is the 4.7.10 stable release

Btrfs: catch invalid free space trees

2016-10-22T10:06:47+00:00

commit 6675df311db87aa2107a04ef97e19420953cbace upstream. There are two separate issues that can lead to corrupted free space trees. 1. The free space tree bitmaps had an endianness issue on big-endian systems which is fixed by an earlier patch in this series. 2. btrfs-progs before v4.7.3 modified filesystems without updating the free space tree. To catch both of these issues at once, we need to force the free space tree to be rebuilt. To do so, add a FREE_SPACE_TREE_VALID compat_ro bit. If the bit isn't set, we know that it was either produced by a broken big-endian kernel or may have been corrupted by btrfs-progs. This also provides us with a way to add rudimentary read-write support for the free space tree to btrfs-progs: it can just clear this bit and have the kernel rebuild the free space tree. Tested-by: Holger Hoffstätte Tested-by: Chandan Rajendra Signed-off-by: Omar Sandoval Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman

misc: Add Aspeed BT IPMI host driver

2016-08-09T06:22:16+00:00

This patch adds a simple device driver to expose the iBT interface on Aspeed chips as a character device (/dev/bt). The iBT interface is used to perform in-band IPMI communication from a BMC to the host. Signed-off-by: Alistair Popple Signed-off-by: Jeremy Kerr Signed-off-by: Joel Stanley

net/ncsi: NCSI command packet handler

2016-08-09T06:22:00+00:00

The NCSI command packets are sent from MC (Management Controller) to remote end. They are used for multiple purposes: probe existing NCSI package/channel, retrieve NCSI channel's capability, configure NCSI channel etc. This defines struct to represent NCSI command packets and introduces function ncsi_xmit_cmd(), which will be used to transmit NCSI command packet according to the request. The request is represented by struct ncsi_cmd_arg. Signed-off-by: Gavin Shan Acked-by: Joel Stanley Signed-off-by: David S. Miller (cherry picked from commit 6389eaa7fa9c3ee6c7d39f6087b86660d17236ac) Signed-off-by: Joel Stanley

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input

2016-07-15T22:04:12+00:00

Pull input fixes from Dmitry Torokhov: "A few last-minute updates for the input subsystem" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: ts4800-ts - add missing of_node_put after calling of_parse_phandle Input: synaptics-rmi4 - use of_get_child_by_name() to fix refcount Revert "Input: wacom_w8001 - drop use of ABS_MT_TOOL_TYPE" Input: xpad - validate USB endpoint count during probe Input: add SW_PEN_INSERTED define