talos-obmc-linux/drivers/misc, branch dev-4.10

drivers/misc: (aspeed-lpc-snoop): Add ast2400 to compat

2017-07-03T02:15:19+00:00

This driver can be used on the aspeed ast2400. Tested: ast2400 on quanta-q71l OpenBMC-Staging-Count: 1 Signed-off-by: Patrick Venture Signed-off-by: Joel Stanley

drivers/misc: add Aspeed LPC snoop driver

2017-06-05T04:14:58+00:00

This driver enables the LPC snoop hardware on the ASPEED BMC which generates an interrupt upon every write to an I/O port by the host. This is typically used to monitor BIOS boot progress by listening to well-known debug port 80h. The functionality in this commit just saves all snooped values to a circular 2K buffer in the kernel, subsequent commits can act on the values to do things with them. OpenBMC-Staging-Count: 1 Signed-off-by: Robert Lippert Signed-off-by: Joel Stanley

Merge tag 'v4.10.17' into dev-4.10

2017-06-05T02:24:15+00:00

This is the 4.10.17 stable release

mei: don't wait for os version message reply

2017-03-30T07:44:06+00:00

commit c6240cacdb2c3cb56a21fb3ea0c105154ab87a2a upstream. The driver still struggles with firmwares that do not replay to the OS version request. It is safe not waiting for the replay. First, the driver doesn't do anything with the replay second the connection is closed immediately, hence the packet will be just safely discarded in case it is received and last the driver won't get stuck if the firmware won't reply. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman

mei: fix deadlock on mei reset

2017-03-30T07:44:06+00:00

commit a733ded50b6ea846200073e7381a302df71e13b3 upstream. This patch fixes 'mei: synchronize irq before initiating a reset' The patch had introduced a deadlock between irq thread and mei_reset() as they are both holding the same device lock. ---> device_lock: mei_reset() <---- interrupt thread device_lock ---> synchornize_irq() wait on interrupt thread == (dead lock) The fix is to call synchronize_irq prior to call locked mei_reset function. Fixes: f302bb0de6ac (mei: synchronize irq before initiating a reset) Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman

drivers/misc: Aspeed LPC control fix compile error and warning

2017-03-22T14:57:49+00:00

pgprot_dmachoerent() is not defined on every architecture. Having COMPILE_TEST set for the driver causes it to be compiled on architectures which do not have pgprot_dmachoerent(): drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_mmap': drivers/misc/aspeed-lpc-ctrl.c:51:9: error: implicit declaration of function 'pgprot_dmacoherent' [-Werror=implicit-function-declaration] prot = pgprot_dmacoherent(prot); There are two possible solutions: 1. Remove COMPILE_TEST to ensure the driver is only compiled on ARM 2. Use pgprot_noncached() instead of pgprot_dmachoerent() The first option results in less compile testing of the LPC control driver which is undesirable. The second option uses a function that is declared on all architectures and therefore should always build. Currently there is no practical difference between pgprot_noncached() and pgprot_dmachoerent() for the aspeed chips that this driver is compatible with. The reason for pgprot_dmachoerent() was that there may be chips made at some point in the future that could include hardware that pgprot_dmachoerent() could optimise for. As none of this hardware has even been announced there isn't really a need for pgprot_dmachoerent(). Using pgprot_noncached() is completely correct and optimal for all existing hardware on which the LPC control driver will run. This commit also addresses that phys_addr_t should be printed using %pap rather than %x: In file included from include/linux/miscdevice.h:6:0, from drivers/misc/aspeed-lpc-ctrl.c:11: drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_probe': drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'phys_addr_t {aka long long unsigned int}' [-Wformat=] dev_info(dev, "Loaded at 0x%08x (0x%08x)\n", Signed-off-by: Cyril Bur Reported-by: kbuild test robot Signed-off-by: Greg Kroah-Hartman (cherry picked from commit 132c93d4215c5ea12f8bb291249ede159d507b6e) Signed-off-by: Joel Stanley

drivers/misc: Add Aspeed LPC control driver

2017-03-22T14:57:49+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 Reviewed-by: Joel Stanley Reviewed-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman (cherry picked from commit 6c4e976785011dfbe461821d0bfc58cfd60eac56) Signed-off-by: Joel Stanley

cxl: fix nested locking hang during EEH hotplug

2017-03-15T02:20:08+00:00

commit 171ed0fcd8966d82c45376f1434678e7b9d4d9b1 upstream. Commit 14a3ae34bfd0 ("cxl: Prevent read/write to AFU config space while AFU not configured") introduced a rwsem to fix an invalid memory access that occurred when someone attempts to access the config space of an AFU on a vPHB whilst the AFU is deconfigured, such as during EEH recovery. It turns out that it's possible to run into a nested locking issue when EEH recovery fails and a full device hotplug is required. cxl_pci_error_detected() deconfigures the AFU, taking a writer lock on configured_rwsem. When EEH recovery fails, the EEH code calls pci_hp_remove_devices() to remove the device, which in turn calls cxl_remove() -> cxl_pci_remove_afu() -> pci_deconfigure_afu(), which tries to grab the writer lock that's already held. Standard rwsem semantics don't express what we really want to do here and don't allow for nested locking. Fix this by replacing the rwsem with an atomic_t which we can control more finely. Allow the AFU to be locked multiple times so long as there are no readers. Fixes: 14a3ae34bfd0 ("cxl: Prevent read/write to AFU config space while AFU not configured") Signed-off-by: Andrew Donnellan Acked-by: Frederic Barrat Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman

cxl: Prevent read/write to AFU config space while AFU not configured

2017-03-15T02:20:08+00:00

commit 14a3ae34bfd0bcb1cc12d55b06a8584c11fac6fc upstream. During EEH recovery, we deconfigure all AFUs whilst leaving the corresponding vPHB and virtual PCI device in place. If something attempts to interact with the AFU's PCI config space (e.g. running lspci) after the AFU has been deconfigured and before it's reconfigured, cxl_pcie_{read,write}_config() will read invalid values from the deconfigured struct cxl_afu and proceed to Oops when they try to dereference pointers that have been set to NULL during deconfiguration. Add a rwsem to struct cxl_afu so we can prevent interaction with config space while the AFU is deconfigured. Reported-by: Pradipta Ghosh Suggested-by: Frederic Barrat Signed-off-by: Andrew Donnellan Signed-off-by: Vaibhav Jain Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman

mei: remove support for broken parallel read

2017-03-12T05:44:13+00:00

commit cb97fbbcac15982406e0c74cd5512a8b6fcf10b3 upstream. Parallel reads from multiple threads on a file descriptor are not well defined and racy. It is safer to return to original behavior and simply fail the additional read. The solution is to remove request for next read credit. Fixes: ff1586a7ea57 ("mei: enqueue consecutive reads") Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman