02 Nov, 2017

1 commit

  • Many user space API headers have licensing information, which is either
    incomplete, badly formatted or just a shorthand for referring to the
    license under which the file is supposed to be. This makes it hard for
    compliance tools to determine the correct license.

    Update these files with an SPDX license identifier. The identifier was
    chosen based on the license information in the file.

    GPL/LGPL licensed headers get the matching GPL/LGPL SPDX license
    identifier with the added 'WITH Linux-syscall-note' exception, which is
    the officially assigned exception identifier for the kernel syscall
    exception:

    NOTE! This copyright does *not* cover user programs that use kernel
    services by normal system calls - this is merely considered normal use
    of the kernel, and does *not* fall under the heading of "derived work".

    This exception makes it possible to include GPL headers into non GPL
    code, without confusing license compliance tools.

    Headers which have either explicit dual licensing or are just licensed
    under a non GPL license are updated with the corresponding SPDX
    identifier and the GPLv2 with syscall exception identifier. The format
    is:
    ((GPL-2.0 WITH Linux-syscall-note) OR SPDX-ID-OF-OTHER-LICENSE)

    SPDX license identifiers are a legally binding shorthand, which can be
    used instead of the full boiler plate text. The update does not remove
    existing license information as this has to be done on a case by case
    basis and the copyright holders might have to be consulted. This will
    happen in a separate step.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne. See the previous patch in this series for the
    methodology of how this patch was researched.

    Reviewed-by: Kate Stewart
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

08 Apr, 2017

1 commit

  • The newly added header file triggers a sanity check:

    usr/include/linux/aspeed-lpc-ctrl.h:44: found __[us]{8,16,32,64} type without #include

    We should include linux/types.h explicitly to ensure the header
    can be included from user space.

    Fixes: 6c4e97678501 ("drivers/misc: Add Aspeed LPC control driver")
    Signed-off-by: Arnd Bergmann
    Acked-by: Joel Stanley
    Signed-off-by: Greg Kroah-Hartman

    Arnd Bergmann
     

17 Mar, 2017

1 commit

  • 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
    Reviewed-by: Joel Stanley
    Reviewed-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Cyril Bur