BMC/Intel-BMC/linux.git/drivers/Kconfig, branch dev-5.1

peci: Add support for PECI bus driver core

2019-05-06T04:13:01+00:00

This commit adds driver implementation for PECI bus core into linux driver framework. PECI (Platform Environment Control Interface) is a one-wire bus interface that provides a communication channel from Intel processors and chipset components to external monitoring or control devices. PECI is designed to support the following sideband functions: * Processor and DRAM thermal management - Processor fan speed control is managed by comparing Digital Thermal Sensor (DTS) thermal readings acquired via PECI against the processor-specific fan speed control reference point, or TCONTROL. Both TCONTROL and DTS thermal readings are accessible via the processor PECI client. These variables are referenced to a common temperature, the TCC activation point, and are both defined as negative offsets from that reference. - PECI based access to the processor package configuration space provides a means for Baseboard Management Controllers (BMC) or other platform management devices to actively manage the processor and memory power and thermal features. * Platform Manageability - Platform manageability functions including thermal, power, and error monitoring. Note that platform 'power' management includes monitoring and control for both the processor and DRAM subsystem to assist with data center power limiting. - PECI allows read access to certain error registers in the processor MSR space and status monitoring registers in the PCI configuration space within the processor and downstream devices. - PECI permits writes to certain registers in the processor PCI configuration space. * Processor Interface Tuning and Diagnostics - Processor interface tuning and diagnostics capabilities (Intel Interconnect BIST). The processors Intel Interconnect Built In Self Test (Intel IBIST) allows for infield diagnostic capabilities in the Intel UPI and memory controller interfaces. PECI provides a port to execute these diagnostics via its PCI Configuration read and write capabilities. * Failure Analysis - Output the state of the processor after a failure for analysis via Crashdump. PECI uses a single wire for self-clocking and data transfer. The bus requires no additional control lines. The physical layer is a self-clocked one-wire bus that begins each bit with a driven, rising edge from an idle level near zero volts. The duration of the signal driven high depends on whether the bit value is a logic '0' or logic '1'. PECI also includes variable data transfer rate established with every message. In this way, it is highly flexible even though underlying logic is simple. The interface design was optimized for interfacing between an Intel processor and chipset components in both single processor and multiple processor environments. The single wire interface provides low board routing overhead for the multiple load connections in the congested routing area near the processor and chipset components. Bus speed, error checking, and low protocol overhead provides adequate link bandwidth and reliability to transfer critical device operating conditions and configuration information. This implementation provides the basic framework to add PECI extensions to the Linux bus and device models. A hardware specific 'Adapter' driver can be attached to the PECI bus to provide sideband functions described above. It is also possible to access all devices on an adapter from userspace through the /dev interface. A device specific 'Client' driver also can be attached to the PECI bus so each processor client's features can be supported by the 'Client' driver through an adapter connection in the bus. OpenBMC-Staging-Count: 3 Signed-off-by: Jae Hyun Yoo Signed-off-by: Fengguang Wu Reviewed-by: Haiyue Wang Reviewed-by: James Feist Reviewed-by: Vernon Mauery [joel: Fix access_ok usage for 5.0] Signed-off-by: Joel Stanley

interconnect: Add generic on-chip interconnect API

2019-01-22T12:37:25+00:00

This patch introduces a new API to get requirements and configure the interconnect buses across the entire chipset to fit with the current demand. The API is using a consumer/provider-based model, where the providers are the interconnect buses and the consumers could be various drivers. The consumers request interconnect resources (path) between endpoints and set the desired constraints on this data flow path. The providers receive requests from consumers and aggregate these requests for all master-slave pairs on that path. Then the providers configure each node along the path to support a bandwidth that satisfies all bandwidth requests that cross through that node. The topology could be complicated and multi-tiered and is SoC specific. Reviewed-by: Evan Green Signed-off-by: Georgi Djakov Signed-off-by: Greg Kroah-Hartman

Merge tag 'kconfig-v4.21-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

2018-12-29T21:40:29+00:00

Pull Kconfig file consolidation from Masahiro Yamada: "Consolidation of bus (PCI, PCMCIA, EISA, RapidIO) config entries by Christoph Hellwig. Currently, every architecture that wants to provide common peripheral busses needs to add some boilerplate code and include the right Kconfig files. This series instead just selects the presence (when needed) and then handles everything in the bus-specific Kconfig file under drivers/" * tag 'kconfig-v4.21-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: pcmcia: remove per-arch PCMCIA config entry eisa: consolidate EISA Kconfig entry in drivers/eisa rapidio: consolidate RAPIDIO config entry in drivers/rapidio pcmcia: allow PCMCIA support independent of the architecture PCI: consolidate the PCI_SYSCALL symbol PCI: consolidate the PCI_DOMAINS and PCI_DOMAINS_GENERIC config options PCI: consolidate PCI config entry in drivers/pci MIPS: remove the HT_PCI config option

eisa: consolidate EISA Kconfig entry in drivers/eisa

2018-11-23T02:46:22+00:00

Let architectures opt into EISA support by selecting HAVE_EISA and handle everything else in drivers/eisa. Signed-off-by: Christoph Hellwig Acked-by: Thomas Gleixner Acked-by: Paul Burton Signed-off-by: Masahiro Yamada

rapidio: consolidate RAPIDIO config entry in drivers/rapidio

2018-11-23T02:46:13+00:00

There is no good reason to duplicate the RAPIDIO menu in various architectures. Instead provide a selectable HAVE_RAPIDIO symbol that indicates native availability of RAPIDIO support and the handle the rest in drivers/pci. This also means we now provide support for PCI(e) to Rapidio bridges for every architecture instead of a limited subset. Signed-off-by: Christoph Hellwig Acked-by: Thomas Gleixner Acked-by: Paul Burton Signed-off-by: Masahiro Yamada

pcmcia: allow PCMCIA support independent of the architecture

2018-11-23T02:46:00+00:00

There is nothing architecture specific in the PCMCIA core, so allow building it everywhere. The actual host controllers will depend on ISA, PCI or a specific SOC. Signed-off-by: Christoph Hellwig Acked-by: Dominik Brodowski Acked-by: Thomas Gleixner Acked-by: Paul Burton Signed-off-by: Masahiro Yamada

PCI: consolidate PCI config entry in drivers/pci

2018-11-23T02:45:34+00:00

There is no good reason to duplicate the PCI menu in every architecture. Instead provide a selectable HAVE_PCI symbol that indicates availability of PCI support, and a FORCE_PCI symbol to for PCI on and the handle the rest in drivers/pci. Signed-off-by: Christoph Hellwig Reviewed-by: Palmer Dabbelt Acked-by: Max Filippov Acked-by: Thomas Gleixner Acked-by: Bjorn Helgaas Acked-by: Geert Uytterhoeven Acked-by: Paul Burton Signed-off-by: Masahiro Yamada

i3c: Add core I3C infrastructure

2018-11-12T09:33:49+00:00

Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon Reviewed-by: Arnd Bergmann Acked-by: Greg Kroah-Hartman

gnss: add GNSS receiver subsystem

2018-06-28T11:29:47+00:00

Add a new subsystem for GNSS (e.g. GPS) receivers. While GNSS receivers are typically accessed using a UART interface they often also support other I/O interfaces such as I2C, SPI and USB, while yet other devices use iomem or even some form of remote-processor messaging (rpmsg). The new GNSS subsystem abstracts the underlying interface and provides a new "gnss" class type, which exposes a character-device interface (e.g. /dev/gnss0) to user space. This allows GNSS receivers to have a representation in the Linux device model, something which is important not least for power management purposes. Note that the character-device interface provides raw access to whatever protocol the receiver is (currently) using, such as NMEA 0183, UBX or SiRF Binary. These protocols are expected to be continued to be handled by user space for the time being, even if some hybrid solutions are also conceivable (e.g. to have kernel drivers issue management commands). This will still allow for better platform integration by allowing GNSS devices and their resources (e.g. regulators and enable-gpios) to be described by firmware and managed by kernel drivers rather than platform-specific scripts and services. While the current interface is kept minimal, it could be extended using IOCTLs, sysfs or uevents as needs and proper abstraction levels are identified and determined (e.g. for device and feature identification). Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

hwtracing: Add HW tracing support menu

2018-03-29T10:38:10+00:00

Make a "HW tracing support" menu and move 2 entries into it. (No change in Coresight, which is ARM-specific and is only listed for ARM & ARM64.) This makes the Device Drivers menu more consistent and prevents these drivers from being listed at the top level of the Device Drivers menu. Signed-off-by: Randy Dunlap Signed-off-by: Alexander Shishkin