summaryrefslogtreecommitdiff
path: root/drivers/peci
AgeCommit message (Collapse)AuthorFilesLines
2024-10-03move asm/unaligned.h to linux/unaligned.hAl Viro2-2/+2
asm/unaligned.h is always an include of asm-generic/unaligned.h; might as well move that thing to linux/unaligned.h and include that - there's nothing arch-specific in that header. auto-generated by the following: for i in `git grep -l -w asm/unaligned.h`; do sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i done for i in `git grep -l -w asm-generic/unaligned.h`; do sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i done git mv include/asm-generic/unaligned.h include/linux/unaligned.h git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
2024-07-25Merge tag 'driver-core-6.11-rc1' of ↵Linus Torvalds2-6/+3
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the big set of driver core changes for 6.11-rc1. Lots of stuff in here, with not a huge diffstat, but apis are evolving which required lots of files to be touched. Highlights of the changes in here are: - platform remove callback api final fixups (Uwe took many releases to get here, finally!) - Rust bindings for basic firmware apis and initial driver-core interactions. It's not all that useful for a "write a whole driver in rust" type of thing, but the firmware bindings do help out the phy rust drivers, and the driver core bindings give a solid base on which others can start their work. There is still a long way to go here before we have a multitude of rust drivers being added, but it's a great first step. - driver core const api changes. This reached across all bus types, and there are some fix-ups for some not-common bus types that linux-next and 0-day testing shook out. This work is being done to help make the rust bindings more safe, as well as the C code, moving toward the end-goal of allowing us to put driver structures into read-only memory. We aren't there yet, but are getting closer. - minor devres cleanups and fixes found by code inspection - arch_topology minor changes - other minor driver core cleanups All of these have been in linux-next for a very long time with no reported problems" * tag 'driver-core-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (55 commits) ARM: sa1100: make match function take a const pointer sysfs/cpu: Make crash_hotplug attribute world-readable dio: Have dio_bus_match() callback take a const * zorro: make match function take a const pointer driver core: module: make module_[add|remove]_driver take a const * driver core: make driver_find_device() take a const * driver core: make driver_[create|remove]_file take a const * firmware_loader: fix soundness issue in `request_internal` firmware_loader: annotate doctests as `no_run` devres: Correct code style for functions that return a pointer type devres: Initialize an uninitialized struct member devres: Fix memory leakage caused by driver API devm_free_percpu() devres: Fix devm_krealloc() wasting memory driver core: platform: Switch to use kmemdup_array() driver core: have match() callback in struct bus_type take a const * MAINTAINERS: add Rust device abstractions to DRIVER CORE device: rust: improve safety comments MAINTAINERS: add Danilo as FIRMWARE LOADER maintainer MAINTAINERS: add Rust FW abstractions to FIRMWARE LOADER firmware: rust: improve safety comments ...
2024-07-03driver core: have match() callback in struct bus_type take a const *Greg Kroah-Hartman2-6/+3
In the match() callback, the struct device_driver * should not be changed, so change the function callback to be a const *. This is one step of many towards making the driver core safe to have struct device_driver in read-only memory. Because the match() callback is in all busses, all busses are modified to handle this properly. This does entail switching some container_of() calls to container_of_const() to properly handle the constant *. For some busses, like PCI and USB and HV, the const * is cast away in the match callback as those busses do want to modify those structures at this point in time (they have a local lock in the driver structure.) That will have to be changed in the future if they wish to have their struct device * in read-only-memory. Cc: Rafael J. Wysocki <rafael@kernel.org> Reviewed-by: Alex Elder <elder@kernel.org> Acked-by: Sumit Garg <sumit.garg@linaro.org> Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-17peci: aspeed: Clear clock_divider value before setting itIwona Winiarska1-0/+1
PECI clock divider is programmed on 10:8 bits of PECI Control register. Before setting a new value, clear bits read from hardware. Reviewed-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20240417134849.5793-1-iwona.winiarska@intel.com Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
2024-06-17peci, hwmon: Switch to new Intel CPU model definesTony Luck4-23/+12
Update peci subsystem to use the same vendor-family-model combined definition that core x86 code uses. Signed-off-by: Tony Luck <tony.luck@intel.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20240529171920.62571-1-tony.luck@intel.com Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
2024-04-16peci: constify the struct device_type usageRicardo B. Marliere3-4/+4
Since commit aed65af1cc2f ("drivers: make device_type const"), the driver core can properly handle constant struct device_type. Move the peci_controller_type and peci_device_type variables to be constant structures as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Reviewed-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20240219-device_cleanup-peci-v1-1-0727662616f7@marliere.net Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
2024-04-16peci: Make peci_bus_type constRicardo B. Marliere2-2/+2
Now that the driver core can properly handle constant struct bus_type, move the peci_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Link: https://lore.kernel.org/r/20240210-bus_cleanup-peci-v1-1-1e64bef6efc0@marliere.net Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
2023-08-08Merge tag 'peci-next-6.6-rc1' of ↵Greg Kroah-Hartman4-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
2023-08-07peci: Add peci-npcm controller driverTomer Maimon3-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
2023-08-07peci: cpu: Add Intel Sapphire Rapids supportNaresh Solanki1-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
2023-08-04peci: Constify struct peci_controller_opsZev Weiss2-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>
2023-03-23driver core: bus: mark the struct bus_type for sysfs callbacks as constantGreg Kroah-Hartman1-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>
2022-08-15peci: cpu: Fix use-after-free in adev_release()Iwona Winiarska1-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
2022-08-15peci: aspeed: fix error check return value of platform_get_irq()Lv Ruyi1-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>
2022-02-09peci: Add peci-cpu driverIwona Winiarska6-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>
2022-02-09peci: Add support for PECI device driversIwona Winiarska4-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>
2022-02-09peci: Add sysfs interface for PECI busIwona Winiarska5-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>
2022-02-09peci: Add device detectionIwona Winiarska5-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>
2022-02-09peci: Add peci-aspeed controller driverJae Hyun Yoo5-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>
2022-02-09peci: Add core infrastructureIwona Winiarska4-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>
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-21 17:35:13 +0300