summaryrefslogtreecommitdiffstats
path: root/drivers/peci
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'peci-next-6.6-rc1' of ↵Greg Kroah-Hartman2023-08-084-0/+320
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/iwi/linux into char-misc-next Iwona writes: Update peci-next for v6.6-rc1 * Add Intel Sapphire Rapids support. * Add Nuvoton controller driver. * tag 'peci-next-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/iwi/linux: arm64: dts: nuvoton: Add PECI controller node ARM: dts: nuvoton: Add PECI controller node peci: Add peci-npcm controller driver dt-bindings: Add bindings for peci-npcm hwmon: (peci/dimmtemp) Add Sapphire Rapids support hwmon: (peci/cputemp) Add Intel Sapphire Rapids support peci: cpu: Add Intel Sapphire Rapids support
| * peci: Add peci-npcm controller driverTomer Maimon2023-08-073-0/+315
| | | | | | | | | | | | | | | | | | | | | | Add support for Nuvoton NPCM BMC hardware to the Platform Environment Control Interface (PECI) subsystem. Signed-off-by: Tomer Maimon <tmaimon77@gmail.com> Signed-off-by: Tyrone Ting <warp5tw@gmail.com> Co-developed-by: Iwona Winiarska <iwona.winiarska@intel.com> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20230727202126.1477515-3-iwona.winiarska@intel.com
| * peci: cpu: Add Intel Sapphire Rapids supportNaresh Solanki2023-08-071-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for detection of Intel Sapphire Rapids processor based on CPU family & model. Sapphire Rapids Xeon processors with the family set to 6 and the model set to INTEL_FAM6_SAPPHIRERAPIDS_X. The data field for this entry is "spr". Tested the patch series with AST2600 BMC with 4S Intel Sapphire Rapids processors & verified by reading cpu & dimm temperature. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com> Reviewed-by: Iwona Winiarska <iwona.winiarska@intel.com> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20230725104354.33920-1-Naresh.Solanki@9elements.com
* | peci: Constify struct peci_controller_opsZev Weiss2023-08-042-3/+3
|/ | | | | | | | | | | | | As with most ops structs, we never modify it at runtime, and keeping function pointers in read-only memory is generally a good thing security-wise. Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20230327224315.11135-1-zev@bewilderbeest.net Reviewed-by: Iwona Winiarska <iwona.winiarska@intel.com> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20230623142805.577612-1-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver core: bus: mark the struct bus_type for sysfs callbacks as constantGreg Kroah-Hartman2023-03-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | struct bus_type should never be modified in a sysfs callback as there is nothing in the structure to modify, and frankly, the structure is almost never used in a sysfs callback, so mark it as constant to allow struct bus_type to be moved to read-only memory. Cc: "David S. Miller" <davem@davemloft.net> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Alexandre Bounine <alex.bou9@gmail.com> Cc: Alison Schofield <alison.schofield@intel.com> Cc: Ben Widawsky <bwidawsk@kernel.org> Cc: Dexuan Cui <decui@microsoft.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Harald Freudenberger <freude@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Hu Haowen <src.res@email.cn> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Stuart Yoder <stuyoder@gmail.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Yanteng Si <siyanteng@loongson.cn> Acked-by: Ilya Dryomov <idryomov@gmail.com> # rbd Acked-by: Ira Weiny <ira.weiny@intel.com> # cxl Reviewed-by: Alex Shi <alexs@kernel.org> Acked-by: Iwona Winiarska <iwona.winiarska@intel.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # pci Acked-by: Wei Liu <wei.liu@kernel.org> Acked-by: Martin K. Petersen <martin.petersen@oracle.com> # scsi Link: https://lore.kernel.org/r/20230313182918.1312597-23-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* peci: cpu: Fix use-after-free in adev_release()Iwona Winiarska2022-08-151-2/+1
| | | | | | | | | | | | | | | When auxiliary_device_add() returns an error, auxiliary_device_uninit() is called, which causes refcount for device to be decremented and .release callback will be triggered. Because adev_release() re-calls auxiliary_device_uninit(), it will cause use-after-free: [ 1269.455172] WARNING: CPU: 0 PID: 14267 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15 [ 1269.464007] refcount_t: underflow; use-after-free. Reported-by: Jianglei Nie <niejianglei2021@163.com> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20220705101501.298395-1-iwona.winiarska@intel.com
* peci: aspeed: fix error check return value of platform_get_irq()Lv Ruyi2022-08-151-1/+1
| | | | | | | | | | | | platform_get_irq() return negative value on failure, so null check of priv->irq is incorrect. Fix it by comparing whether it is less than zero. Fixes: a85e4c52086c ("peci: Add peci-aspeed controller driver") Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn> Link: https://lore.kernel.org/r/20220413010425.2534887-1-lv.ruyi@zte.com.cn Reviewed-by: Iwona Winiarska <iwona.winiarska@intel.com> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
* peci: Add peci-cpu driverIwona Winiarska2022-02-096-0/+601
| | | | | | | | | | | | | PECI is an interface that may be used by different types of devices. Add a peci-cpu driver compatible with Intel processors. The driver is responsible for handling auxiliary devices that can subsequently be used by other drivers (e.g. hwmons). Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20220208153639.255278-10-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* peci: Add support for PECI device driversIwona Winiarska2022-02-094-0/+462
| | | | | | | | | | | | | | | Add support for PECI device drivers, which unlike PECI controller drivers are actually able to provide functionalities to userspace. Also, extend peci_request API to allow querying more details about PECI device (e.g. model/family), that's going to be used to find a compatible peci_driver. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20220208153639.255278-9-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* peci: Add sysfs interface for PECI busIwona Winiarska2022-02-095-2/+91
| | | | | | | | | | | | | | | | | | | | | PECI devices may not be discoverable at the time when PECI controller is being added (e.g. BMC can boot up when the Host system is still in S5). Since we currently don't have the capabilities to figure out the Host system state inside the PECI subsystem itself, we have to rely on userspace to do it for us. In the future, PECI subsystem may be expanded with mechanisms that allow us to avoid depending on userspace interaction (e.g. CPU presence could be detected using GPIO, and the information on whether it's discoverable could be obtained over IPMI). Unfortunately, those methods may ultimately not be available (support will vary from platform to platform), which means that we still need platform independent method triggered by userspace. Acked-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20220208153639.255278-8-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* peci: Add device detectionIwona Winiarska2022-02-095-1/+223
| | | | | | | | | | | | | | | Since PECI devices are discoverable, we can dynamically detect devices that are actually available in the system. This change complements the earlier implementation by rescanning PECI bus to detect available devices. For this purpose, it also introduces the minimal API for PECI requests. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20220208153639.255278-7-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* peci: Add peci-aspeed controller driverJae Hyun Yoo2022-02-095-0/+629
| | | | | | | | | | | | | | | | | ASPEED AST24xx/AST25xx/AST26xx SoCs support the PECI electrical interface (a.k.a PECI wire) that provides a communication channel with Intel processors. This driver allows BMC to discover devices connected to it and communicate with them using PECI protocol. Co-developed-by: Iwona Winiarska <iwona.winiarska@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Acked-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20220208153639.255278-6-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* peci: Add core infrastructureIwona Winiarska2022-02-094-0/+194
Intel processors provide access for various services designed to support processor and DRAM thermal management, platform manageability and processor interface tuning and diagnostics. Those services are available via the Platform Environment Control Interface (PECI) that provides a communication channel between the processor and the Baseboard Management Controller (BMC) or other platform management device. This change introduces PECI subsystem by adding the initial core module and API for controller drivers. Co-developed-by: Jason M Bills <jason.m.bills@linux.intel.com> Co-developed-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Jason M Bills <jason.m.bills@linux.intel.com> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20220208153639.255278-5-iwona.winiarska@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>