kernel/linux.git/drivers/peci, branch v6.12.80

move asm/unaligned.h to linux/unaligned.h

2024-10-02T21:23:23+00:00

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

Merge tag 'driver-core-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2024-07-25T17:42:22+00:00

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 ...

driver core: have match() callback in struct bus_type take a const *

2024-07-03T13:16:54+00:00

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 Reviewed-by: Alex Elder Acked-by: Sumit Garg Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman

peci: aspeed: Clear clock_divider value before setting it

2024-06-17T13:18:29+00:00

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 Link: https://lore.kernel.org/r/20240417134849.5793-1-iwona.winiarska@intel.com Signed-off-by: Iwona Winiarska

peci, hwmon: Switch to new Intel CPU model defines

2024-06-17T13:15:46+00:00

Update peci subsystem to use the same vendor-family-model combined definition that core x86 code uses. Signed-off-by: Tony Luck Acked-by: Guenter Roeck Reviewed-by: Iwona Winiarska Link: https://lore.kernel.org/r/20240529171920.62571-1-tony.luck@intel.com Signed-off-by: Iwona Winiarska

peci: constify the struct device_type usage

2024-04-15T22:14:43+00:00

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 Signed-off-by: "Ricardo B. Marliere" Reviewed-by: Iwona Winiarska Link: https://lore.kernel.org/r/20240219-device_cleanup-peci-v1-1-0727662616f7@marliere.net Signed-off-by: Iwona Winiarska

peci: Make peci_bus_type const

2024-04-15T22:14:36+00:00

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 Suggested-by: Greg Kroah-Hartman Signed-off-by: "Ricardo B. Marliere" Link: https://lore.kernel.org/r/20240210-bus_cleanup-peci-v1-1-1e64bef6efc0@marliere.net Signed-off-by: Iwona Winiarska

Merge tag 'peci-next-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/iwi/linux into char-misc-next

2023-08-08T08:53:30+00:00

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 driver

2023-08-07T16:27:55+00:00

Add support for Nuvoton NPCM BMC hardware to the Platform Environment Control Interface (PECI) subsystem. Signed-off-by: Tomer Maimon Signed-off-by: Tyrone Ting Co-developed-by: Iwona Winiarska Signed-off-by: Iwona Winiarska Link: https://lore.kernel.org/r/20230727202126.1477515-3-iwona.winiarska@intel.com

peci: cpu: Add Intel Sapphire Rapids support

2023-08-07T16:27:55+00:00

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 Signed-off-by: Naresh Solanki Reviewed-by: Iwona Winiarska Signed-off-by: Iwona Winiarska Link: https://lore.kernel.org/r/20230725104354.33920-1-Naresh.Solanki@9elements.com