BMC/Intel-BMC/linux.git/drivers/Makefile, branch dev-5.4

peci: Add support for PECI bus driver core

2019-12-18T02:59:11+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: 1 Signed-off-by: Jason M Biils Signed-off-by: Yunge Zhu Signed-off-by: Fengguang Wu Signed-off-by: Jae Hyun Yoo Reviewed-by: Haiyue Wang Reviewed-by: James Feist Reviewed-by: Vernon Mauery Signed-off-by: Joel Stanley

Merge tag 'staging-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging

2019-09-18T18:05:34+00:00

Pull staging and IIO driver updates from Greg KH: "Here is the big staging/iio driver update for 5.4-rc1. Lots of churn here, with a few driver/filesystems moving out of staging finally: - erofs moved out of staging - greybus core code moved out of staging Along with that, a new filesytem has been added: - extfat to provide support for those devices requiring that filesystem (i.e. transfer devices to/from windows systems or printers) Other than that, there a number of new IIO drivers, and lots and lots and lots of staging driver cleanups and minor fixes as people continue to dig into those for easy changes. All of these have been in linux-next for a while with no reported issues" * tag 'staging-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (453 commits) Staging: gasket: Use temporaries to reduce line length. Staging: octeon: Avoid several usecases of strcpy staging: vhciq_core: replace snprintf with scnprintf staging: wilc1000: avoid twice IRQ handler execution for each single interrupt staging: wilc1000: remove unused interrupt status handling code staging: fbtft: make several arrays static const, makes object smaller staging: rtl8188eu: make two arrays static const, makes object smaller staging: rtl8723bs: core: Remove Macro "IS_MAC_ADDRESS_BROADCAST" dt-bindings: anybus-controller: move to staging/ tree staging: emxx_udc: remove local TRUE/FALSE definition staging: wilc1000: look for rtc_clk clock staging: dt-bindings: wilc1000: add optional rtc_clk property staging: nvec: make use of devm_platform_ioremap_resource staging: exfat: drop unused function parameter Staging: exfat: Avoid use of strcpy staging: exfat: use integer constants staging: exfat: cleanup spacing for casts staging: exfat: cleanup spacing for operators staging: rtl8723bs: hal: remove redundant variable n staging: pi433: Fix typo in documentation ...

Merge tag 'usb-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

2019-09-18T17:33:46+00:00

Pull USB updates from Greg KH: "Here is the big set of USB patches for 5.4-rc1. Two major chunks of code are moving out of the tree and into the staging directory, uwb and wusb (wireless USB support), because there are no devices that actually use this protocol anymore, and what we have today probably doesn't work at all given that the maintainers left many many years ago. So move it to staging where it will be removed in a few releases if no one screams. Other than that, lots of little things. The usual gadget and xhci and usb serial driver updates, along with a bunch of sysfs file cleanups due to the driver core changes to support that. Nothing really major, just constant forward progress. All of these have been in linux-next for a while with no reported issues" * tag 'usb-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (159 commits) USB: usbcore: Fix slab-out-of-bounds bug during device reset usb: cdns3: Remove redundant dev_err call in cdns3_probe() USB: rio500: Fix lockdep violation USB: rio500: simplify locking usb: mtu3: register a USB Role Switch for dual role mode usb: common: add USB GPIO based connection detection driver usb: common: create Kconfig file usb: roles: get usb-role-switch from parent usb: roles: Add fwnode_usb_role_switch_get() function device connection: Add fwnode_connection_find_match() usb: roles: Introduce stubs for the exiting functions in role.h dt-bindings: usb: mtu3: add properties about USB Role Switch dt-bindings: usb: add binding for USB GPIO based connection detection driver dt-bindings: connector: add optional properties for Type-B dt-binding: usb: add usb-role-switch property usbip: Implement SG support to vhci-hcd and stub driver usb: roles: intel: Enable static DRD mode for role switch xhci-ext-caps.c: Add property to disable Intel SW switch usb: dwc3: remove generic PHY calibrate() calls usb: core: phy: add support for PHY calibration ...

staging: greybus: move the greybus core to drivers/greybus

2019-08-27T17:03:04+00:00

The Greybus core code has been stable for a long time, and has been shipping for many years in millions of phones. With the advent of a recent Google Summer of Code project, and a number of new devices in the works from various companies, it is time to get the core greybus code out of staging as it really is going to be with us for a while. Cc: Johan Hovold Cc: linux-kernel@vger.kernel.org Cc: greybus-dev@lists.linaro.org Acked-by: Viresh Kumar Acked-by: Alex Elder Link: https://lore.kernel.org/r/20190825055429.18547-9-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

drivers: remove the SGI SN2 IOC3 base support

2019-08-16T18:33:57+00:00

The IOC3 is a multi-function chip seen on SGI SN2 and some SGI MIPS systems. This removes the last bit of SN2 specific support, while the bits used by the mips ports are still around (and being substantially rewritten at the moment). Signed-off-by: Christoph Hellwig Link: https://lkml.kernel.org/r/20190813072514.23299-14-hch@lst.de Signed-off-by: Tony Luck

USB: Move wusbcore and UWB to staging as it is obsolete

2019-08-08T05:52:01+00:00

The UWB and wusbcore code is long obsolete, so let us just move the code out of the real part of the kernel and into the drivers/staging/ location with plans to remove it entirely in a few releases. Link: https://lore.kernel.org/r/20190806101509.GA11280@kroah.com Signed-off-by: Greg Kroah-Hartman

fmc: Delete the FMC subsystem

2019-06-12T12:23:50+00:00

The FMC subsystem was created in 2012 with the ambition to drive development of drivers for this hardware upstream. The current implementation has architectural flaws and would need to be revamped using real hardware to something that can reuse existing kernel abstractions in the subsystems for e.g. I2C, FPGA and GPIO. We have concluded that for the mainline kernel it will be better to delete the subsystem and start over with a clean slate when/if an active maintainer steps up. For details see: https://lkml.org/lkml/2018/10/29/534 Suggested-by: Federico Vaga Cc: Pat Riehecky Acked-by: Alessandro Rubini Signed-off-by: Federico Vaga Signed-off-by: Linus Walleij

counter: Introduce the Generic Counter interface

2019-04-25T19:33:37+00:00

This patch introduces the Generic Counter interface for supporting counter devices. In the context of the Generic Counter interface, a counter is defined as a device that reports one or more "counts" based on the state changes of one or more "signals" as evaluated by a defined "count function." Driver callbacks should be provided to communicate with the device: to read and write various Signals and Counts, and to set and get the "action mode" and "count function" for various Synapses and Counts respectively. To support a counter device, a driver must first allocate the available Counter Signals via counter_signal structures. These Signals should be stored as an array and set to the signals array member of an allocated counter_device structure before the Counter is registered to the system. Counter Counts may be allocated via counter_count structures, and respective Counter Signal associations (Synapses) made via counter_synapse structures. Associated counter_synapse structures are stored as an array and set to the the synapses array member of the respective counter_count structure. These counter_count structures are set to the counts array member of an allocated counter_device structure before the Counter is registered to the system. A counter device is registered to the system by passing the respective initialized counter_device structure to the counter_register function; similarly, the counter_unregister function unregisters the respective Counter. The devm_counter_register and devm_counter_unregister functions serve as device memory-managed versions of the counter_register and counter_unregister functions respectively. Reviewed-by: Jonathan Cameron Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman

Merge tag 'iommu-updates-v5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

2019-03-10T19:29:52+00:00

Pull IOMMU updates from Joerg Roedel: - A big cleanup and optimization patch-set for the Tegra GART driver - Documentation updates and fixes for the IOMMU-API - Support for page request in Intel VT-d scalable mode - Intel VT-d dma_[un]map_resource() support - Updates to the ATS enabling code for PCI (acked by Bjorn) and Intel VT-d to align with the latest version of the ATS spec - Relaxed IRQ source checking in the Intel VT-d driver for some aliased devices, needed for future devices which send IRQ messages from more than on request-ID - IRQ remapping driver for Hyper-V - Patches to make generic IOVA and IO-Page-Table code usable outside of the IOMMU code - Various other small fixes and cleanups * tag 'iommu-updates-v5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (60 commits) iommu/vt-d: Get domain ID before clear pasid entry iommu/vt-d: Fix NULL pointer reference in intel_svm_bind_mm() iommu/vt-d: Set context field after value initialized iommu/vt-d: Disable ATS support on untrusted devices iommu/mediatek: Fix semicolon code style issue MAINTAINERS: Add Hyper-V IOMMU driver into Hyper-V CORE AND DRIVERS scope iommu/hyper-v: Add Hyper-V stub IOMMU driver x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available PCI/ATS: Add inline to pci_prg_resp_pasid_required() iommu/vt-d: Check identity map for hot-added devices iommu: Fix IOMMU debugfs fallout iommu: Document iommu_ops.is_attach_deferred() iommu: Document iommu_ops.iotlb_sync_map() iommu/vt-d: Enable ATS only if the device uses page aligned address. PCI/ATS: Add pci_ats_page_aligned() interface iommu/vt-d: Fix PRI/PASID dependency issue. PCI/ATS: Add pci_prg_resp_pasid_required() interface. iommu/vt-d: Allow interrupts from the entire bus for aliased devices iommu/vt-d: Add helper to set an IRTE to verify only the bus number iommu: Fix flush_tlb_all typo ...

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