- 01 Apr, 2023 9 commits
-
-
Daniel Lezcano authored
Currently the TI thermal driver sets the sensor update interval based on the polling of the thermal zone. In order to get the polling rate, the code inspects the thermal zone device structure internals, thus breaking the self-encapsulation of the thermal framework core framework. On the other side, we see the common polling rates set in the device tree for the platforms using this driver are 500 or 1000 ms. Setting the polling rate to 250 ms would be far enough to cover the combination we found in the device tree. Instead of accessing the thermal zone device structure polling rate, let's use a common update interval of 250 ms for the driver. Cc: Keerthy <j-keerthy@ti.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by:
Dhruva Gole <d-gole@ti.com> Acked-by:
Keerthy <j-keerthy@ti.com> Link: https://lore.kernel.org/r/20230307133735.90772-7-daniel.lezcano@linaro.org
-
Daniel Lezcano authored
The thermal->tzp->no_hwmon parameter is only used when calling thermal_zone_device_register(). Setting it to 'false' before calling thermal_add_hwmon_sysfs() has no effect. Remove the call and again prevent the drivers to access the thermal internals. Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by:
-
Daniel Lezcano authored
The db8500 driver uses the thermal zone device instead of the device attached to it. In order to prevent the drivers to access the thermal zone device structure, replace the thermal zone device by the driver to show the debug message. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230307133735.90772-5-daniel.lezcano@linaro.org
-
Daniel Lezcano authored
The traces are exported but only local to the thermal core code. On the other side, the traces take the thermal zone device structure as argument, thus they have to rely on the exported thermal.h header file. As we want to move the structure to the private thermal core header, first we have to relocate those traces to the same place as many drivers do. Cc: Steven Rostedt <rostedt@goodmis.org> Suggested-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Yang Li authored
According to commit 7945f929 ("drivers: provide devm_platform_ioremap_resource()"), convert platform_get_resource(), devm_ioremap_resource() to a single call to Use devm_platform_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/20230308062719.79522-1-yang.lee@linux.alibaba.comSigned-off-by:
-
Daniel Lezcano authored
The thermal framework provides an API to get the trip related to a trip point id. We want to consolidate the generic trip points code, thus preventing the different drivers to deal with the trip points after they registered them. The set_trip_temp ops will be changed regarding the above changes but first we need to rework a bit the different implementation in the drivers. The goal is to prevent using the trip id but use a trip point passed as parameter which will contain all the needed information. As we don't have the trip point passed as parameter yet, we get the trip point using the generic trip thermal framewrok APIs and use it to take exactly the same decisions. The difference with this change and the previous code is from where we get the thermal trip point (which is the same). No functional change intended. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20230309092821.1590586-2-daniel.lezcano@linaro.orgSigned-off-by:
-
Daniel Lezcano authored
The i.MX thermal sensor uses the generic trip points. The thermal framework can return the critical temperature directly. Remove the pointless get_trip_temp ops. Signed-off-by:
-
Wolfram Sang authored
R-Car H3 ES1.* was only available to an internal development group and needed a lot of quirks and workarounds. These become a maintenance burden now, so our development group decided to remove upstream support and disable booting for this SoC. Public users only have ES2 onwards. Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20230307163041.3815-7-wsa+renesas@sang-engineering.comSigned-off-by:
-
Amjad Ouled-Ameur authored
Thermal sensor reads performed immediately after thermal bank initialization returns bogus values. This is currently tackled by returning 0 if the temperature is bogus (exceeding 200000). Instead, add a delay between the bank init and the thermal zone device register to properly fix this. Signed-off-by:
Michael Kao <michael.kao@mediatek.com> Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by:
Amjad Ouled-Ameur <aouledameur@baylibre.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20221018-up-i350-thermal-bringup-v9-5-55a1ae14af74@baylibre.comSigned-off-by:
-
- 13 Mar, 2023 3 commits
-
-
Fabien Parent authored
MT8365 is similar to the other SoCs supported by the driver. It has only one bank and 3 actual sensors that can be multiplexed. There is another one sensor that does not have usable data. Signed-off-by:
Fabien Parent <fparent@baylibre.com> Signed-off-by:
-
Markus Schneider-Pargmann authored
Add logic in order to be able to turn on the control buffer on MT8365. This change now allows to have control buffer support for MTK_THERMAL_V1, and it allows to define the register offset, and mask used to enable it. Signed-off-by:
Markus Schneider-Pargmann <msp@baylibre.com> Signed-off-by:
-
Fabien Parent authored
Add the binding documentation for the thermal support on MT8365 SoC. Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20221018-up-i350-thermal-bringup-v9-1-55a1ae14af74@baylibre.comSigned-off-by:
-
- 08 Mar, 2023 1 commit
-
-
Rafael J. Wysocki authored
Merge thermal control updates for 6.4-rc1: - Add a thermal zone 'devdata' accessor and modify several drivers to use it (Daniel Lezcano). - Prevent drivers from using the 'device' internal thermal zone structure field directly (Daniel Lezcano). - Clean up the hwmon thermal driver (Daniel Lezcano). - Add thermal zone id accessor and thermal zone type accessor and prevent drivers from using thermal zone fields directly (Daniel Lezcano). - Clean up the acerhdf and tegra thermal drivers (Daniel Lezcano). * thermal-core: thermal/drivers/acerhdf: Remove pointless governor test thermal/drivers/acerhdf: Make interval setting only at module load time thermal/drivers/tegra: Remove unneeded lock when setting a trip point thermal/hwmon: Use the thermal_core.h header thermal/drivers/da9062: Don't access the thermal zone device fields thermal: Use thermal_zone_device_type() accessor thermal: Add a thermal zone id accessor thermal/drivers/spear: Don't use tz->device but pdev->dev thermal/core: Add thermal_zone_device structure 'type' accessor thermal: Don't use 'device' internal thermal zone structure field thermal/hwmon: Use the right device for devm_thermal_add_hwmon_sysfs() thermal/hwmon: Do not set no_hwmon before calling thermal_add_hwmon_sysfs() thermal: Remove debug or error messages in get_temp() ops thermal/core: Show a debug message when get_temp() fails thermal/core: Use the thermal zone 'devdata' accessor in remaining drivers thermal/core: Use the thermal zone 'devdata' accessor in hwmon located drivers thermal/core: Use the thermal zone 'devdata' accessor in thermal located drivers thermal/core: Add a thermal zone 'devdata' accessor
-
- 03 Mar, 2023 27 commits
-
-
Daniel Lezcano authored
The thermal zone parameter specifies the bang-bang governor. The Kconfig selects the bang-bang governor. So it is pointless to test if the governor was set for the thermal zone assuming it may not have been compiled-in. Remove the test and prevent another access into the thermal internals. Signed-off-by:
Peter Kaestle <peter@piie.net> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Daniel Lezcano authored
The thermal zone device structure is in the process of being private to the thermal framework core code. This driver is directly accessing and changing the monitoring polling rate. After discussing with the maintainers of this driver, having the polling interval at module loading time is enough for their purpose. Change the code to take into account the interval when the module is loaded but restrict the permissions so the value can not be changed afterwards. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Daniel Lezcano authored
The function tegra_tsensor_enable_hw_channel() takes the thermal zone lock to prevent "a potential" race with a call to set_trips() callback. The driver must not play with the thermal framework core code internals. The tegra_tsensor_enable_hw_channel() is called by: - the suspend / resume callbacks - the probe function after the thermal zones are registered The thermal zone lock taken in this function is supposed to protect from a call to the set_trips() callback which writes in the same register. The potential race is when suspend / resume are called at the same time as set_trips. This one is called only in thermal_zone_device_update(). - At suspend time, the 'in_suspend' is set, thus the thermal_zone_device_update() bails out immediately and set_trips is not called during this moment. - At resume time, the thermal zone is updated at PM_POST_SUSPEND, thus the driver has already set the TH2 temperature. - At probe time, we register the thermal zone and then we set the TH2. The only scenario I can see so far is the interrupt fires, the thermal_zone_update() is called exactly at the moment tegra_tsensor_enable_hw_channel() a few lines after registering it. Enable the channels before setting up the interrupt. We close the potential race window without using the thermal zone's lock. Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Acked-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Daniel Lezcano authored
The thermal_hwmon is playing with the thermal core code internals. Changing the code would be too invasive for now. We can consider the thermal_hwmon.c is part of the thermal core code as it provides a glue to tie the hwmon and the thermal zones. Let's include the thermal_core.h header. No functional change intended. Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
-
Daniel Lezcano authored
The driver is reading the passive polling rate in the thermal zone structure. We want to prevent the drivers to rummage around in the thermal zone structure. On the other side, the delay is what the driver passed to the thermal_zone_device_register() function, so it has already the information. Reuse the information we have instead of reading the information we set. Signed-off-by:
Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com> Signed-off-by:
-
Daniel Lezcano authored
Replace the accesses to 'tz->type' by its accessor version in order to self-encapsulate the thermal_zone_device structure. Signed-off-by:
-
Daniel Lezcano authored
In order to get the thermal zone id but without directly accessing the thermal zone device structure, add an accessor. Use the accessor in the hwmon_scmi and acpi_thermal. No functional change intented. Signed-off-by:
-
Daniel Lezcano authored
Use the spear associated device instead of the thermal zone device which belongs to the thermal framework internals. Signed-off-by:
-
Daniel Lezcano authored
The thermal zone device structure is exposed via the exported thermal.h header. This structure should stay private the thermal core code. In order to encapsulate the structure, let's add an accessor to get the 'type' of the thermal zone. Signed-off-by:
-
Daniel Lezcano authored
Some drivers are directly using the thermal zone's 'device' structure field. Use the driver device pointer instead of the thermal zone device when it is available. Remove the traces when they are duplicate with the traces in the core code. Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Daniel Lezcano authored
The devres variant of thermal_add_hwmon_sysfs() only takes the thermal zone structure pointer as parameter. Actually, it uses the tz->device to add it in the devres list. It is preferable to use the device registering the thermal zone instead of the thermal zone device itself. That prevents the driver accessing the thermal zone structure internals and it is from my POV more correct regarding how devm_ is used. Signed-off-by:
-
Daniel Lezcano authored
The thermal->tzp->no_hwmon parameter is only used when calling thermal_zone_device_register(). Setting it to 'false' before calling thermal_add_hwmon_sysfs() has no effect. Remove the call and again prevent the drivers to access the thermal internals. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> #R-Car Signed-off-by:
-
Daniel Lezcano authored
Some get_temp() ops implementation are showing an error or a debug message if the reading of the sensor fails. The debug message is already displayed from the call site of this ops. So we can remove it. On the other side, the error should not be displayed because in production that can raise tons of messages. Finally, some drivers are showing a debug message with the temperature, this is also accessible through the trace from the core code in the temperature_update() function. Another benefit is the dev_* messages are accessing the thermal zone device field from the structure, so we encapsulate even more the code by preventing these accesses. Remove those messages. Signed-off-by:
-
Daniel Lezcano authored
The different thermal drivers are showing an error in case the get_temp() fails. Actually no traces should be displayed in the backend ops but in the call site of this ops. Furthermore, the message is often a dev_dbg message where the tz->device is used, thus using the internal of the structure from the driver. Show a debug message if the thermal_zone_get_temp() fails to read the sensor temperature, so code showing the message is factored out and the tz->device accesss is in the scope of the thermal core framework. Signed-off-by:
-
Daniel Lezcano authored
The thermal zone device structure is exposed to the different drivers and obviously they access the internals while that should be restricted to the core thermal code. In order to self-encapsulate the thermal core code, we need to prevent the drivers accessing directly the thermal zone structure and provide accessor functions to deal with. Use the devdata accessor introduced in the previous patch. No functional changes intended. Signed-off-by:
Mark Brown <broonie@kernel.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> #mlxsw Acked-by: Gregory Greenman <gregory.greenman@intel.com> #iwlwifi Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> #power_supply Acked-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> #ahci Acked-by:
-
Daniel Lezcano authored
The thermal zone device structure is exposed to the different drivers and obviously they access the internals while that should be restricted to the core thermal code. In order to self-encapsulate the thermal core code, we need to prevent the drivers accessing directly the thermal zone structure and provide accessor functions to deal with. Use the devdata accessor introduced in the previous patch. No functional changes intended. Signed-off-by:
-
Daniel Lezcano authored
The thermal zone device structure is exposed to the different drivers and obviously they access the internals while that should be restricted to the core thermal code. In order to self-encapsulate the thermal core code, we need to prevent the drivers accessing directly the thermal zone structure and provide accessor functions to deal with. Use the devdata accessor introduced in the previous patch. No functional changes intended. Signed-off-by:
-
Daniel Lezcano authored
The thermal zone device structure is exposed to the different drivers and obviously they access the internals while that should be restricted to the core thermal code. In order to self-encapsulate the thermal core code, we need to prevent the drivers accessing directly the thermal zone structure and provide accessor functions to deal with. Provide an accessor to the 'devdata' structure and make use of it in the different drivers. No functional changes intended. Signed-off-by:
-
Srinivas Pandruvada authored
When user space updates the trip point there is a deadlock, which results in caller gets blocked forever. Commit 05eeee2b ("thermal/core: Protect sysfs accesses to thermal operations with thermal zone mutex"), added a mutex for tz->lock in the function trip_point_temp_store(). Hence, trip set callback() can't call any thermal zone API as they are protected with the same mutex lock. The callback here calling thermal_zone_device_enable(), which will result in deadlock. Move the thermal_zone_device_enable() to proc_thermal_pci_probe() to avoid this deadlock. Fixes: 05eeee2b ("thermal/core: Protect sysfs accesses to thermal operations with thermal zone mutex") Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@intel.com> Cc: 6.2+ <stable@vger.kernel.org> # 6.2+ Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull more thermal control updates from Rafael Wysocki: "These fix two issues in the Intel thermal control drivers. Specifics: - Fix an error pointer dereference in the quark_dts Intel thermal driver (Dan Carpenter) - Fix the intel_bxt_pmic_thermal driver Kconfig entry to select REGMAP which is not user-visible instead of depending on it (Randy Dunlap)" * tag 'thermal-6.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal: intel: BXT_PMIC: select REGMAP instead of depending on it thermal: intel: quark_dts: fix error pointer dereference -
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull more ACPI updates from Rafael Wysocki: "These update ACPI quirks for some x86 platforms and add an IRQ override quirk for one more system. Specifics: - Add an ACPI IRQ override quirk for Asus Expertbook B2402FBA (Vojtech Hejsek) - Drop a suspend-to-idle quirk for HP Elitebook G9 that is not needed any more after a firmware update (Mario Limonciello) - Add all Cezanne systems to the list for forcing StorageD3Enable, because they all need the same quirk (Mario Limonciello)" * tag 'acpi-6.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: x86: utils: Add Cezanne to the list for forcing StorageD3Enable ACPI: x86: Drop quirk for HP Elitebook ACPI: resource: Skip IRQ override on Asus Expertbook B2402FBA -
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull more power management updates from Rafael Wysocki: "These update power capping (new hardware support and cleanup) and cpufreq (bug fixes, cleanups and intel_pstate adjustment for a new platform). Specifics: - Fix error handling in the apple-soc cpufreq driver (Dan Carpenter) - Change the log level of a message in the amd-pstate cpufreq driver so it is more visible to users (Kai-Heng Feng) - Adjust the balance_performance EPP value for Sapphire Rapids in the intel_pstate cpufreq driver (Srinivas Pandruvada) - Remove MODULE_LICENSE from 3 pieces of non-modular code (Nick Alcock) - Make a read-only kobj_type structure in the schedutil cpufreq governor constant (Thomas Weißschuh) - Add Add Power Limit4 support for Meteor Lake SoC to the Intel RAPL power capping driver (Sumeet Pawnikar)" * tag 'pm-6.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: apple-soc: Fix an IS_ERR() vs NULL check powercap: remove MODULE_LICENSE in non-modules cpufreq: intel_pstate: remove MODULE_LICENSE in non-modules powercap: RAPL: Add Power Limit4 support for Meteor Lake SoC cpufreq: amd-pstate: remove MODULE_LICENSE in non-modules cpufreq: schedutil: make kobj_type structure constant cpufreq: amd-pstate: Let user know amd-pstate is disabled cpufreq: intel_pstate: Adjust balance_performance EPP for Sapphire Rapids -
git://git.kernel.dk/linuxLinus Torvalds authored
Pull more io_uring updates from Jens Axboe: "Here's a set of fixes/changes that didn't make the first cut, either because they got queued before I sent the early merge request, or fixes that came in afterwards. In detail: - Don't set MSG_NOSIGNAL on recv/recvmsg opcodes, as AF_PACKET will error out (David) - Fix for spurious poll wakeups (me) - Fix for a file leak for buffered reads in certain conditions (Joseph) - Don't allow registered buffers of mixed types (Pavel) - Improve handling of huge pages for registered buffers (Pavel) - Provided buffer ring size calculation fix (Wojciech) - Minor cleanups (me)" * tag 'io_uring-6.3-2023-03-03' of git://git.kernel.dk/linux: io_uring/poll: don't pass in wake func to io_init_poll_iocb() io_uring: fix fget leak when fs don't support nowait buffered read io_uring/poll: allow some retries for poll triggering spuriously io_uring: remove MSG_NOSIGNAL from recvmsg io_uring/rsrc: always initialize 'folio' to NULL io_uring/rsrc: optimise registered huge pages io_uring/rsrc: optimise single entry advance io_uring/rsrc: disallow multi-source reg buffers io_uring: remove unused wq_list_merge io_uring: fix size calculation when registering buf ring io_uring/rsrc: fix a comment in io_import_fixed() io_uring: rename 'in_idle' to 'in_cancel' io_uring: consolidate the put_ref-and-return section of adding work -
git://git.kernel.dk/linuxLinus Torvalds authored
Pull block fixes from Jens Axboe: - NVMe pull request via Christoph: - Don't access released socket during error recovery (Akinobu Mita) - Bring back auto-removal of deleted namespaces during sequential scan (Christoph Hellwig) - Fix an error code in nvme_auth_process_dhchap_challenge (Dan Carpenter) - Show well known discovery name (Daniel Wagner) - Add a missing endianess conversion in effects masking (Keith Busch) - Fix for a regression introduced in blk-rq-qos during init in this merge window (Breno) - Reorder a few fields in struct blk_mq_tag_set, eliminating a few holes and shrinking it (Christophe) - Remove redundant bdev_get_queue() NULL checks (Juhyung) - Add sed-opal single user mode support flag (Luca) - Remove SQE128 check in ublk as it isn't needed, saving some memory (Ming) - Op specific segment checking for cloned requests (Uday) - Exclusive open partition scan fixes (Yu) - Loop offset/size checking before assigning them in the device (Zhong) - Bio polling fixes (me) * tag 'block-6.3-2023-03-03' of git://git.kernel.dk/linux: blk-mq: enforce op-specific segment limits in blk_insert_cloned_request nvme-fabrics: show well known discovery name nvme-tcp: don't access released socket during error recovery nvme-auth: fix an error code in nvme_auth_process_dhchap_challenge() nvme: bring back auto-removal of deleted namespaces during sequential scan blk-iocost: Pass gendisk to ioc_refresh_params nvme: fix sparse warning on effects masking block: be a bit more careful in checking for NULL bdev while polling block: clear bio->bi_bdev when putting a bio back in the cache loop: loop_set_status_from_info() check before assignment ublk: remove check IO_URING_F_SQE128 in ublk_ch_uring_cmd block: remove more NULL checks after bdev_get_queue() blk-mq: Reorder fields in 'struct blk_mq_tag_set' block: fix scan partition for exclusively open device again block: Revert "block: Do not reread partition table on exclusively open device" sed-opal: add support flag for SUM in status ioctl -
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libataLinus Torvalds authored
Pull ATA fix from Damien Le Moal: - Revert commit 104ff59a ("ata: ahci: Add Tiger Lake UP{3,4} AHCI controller") as it is causing serious regressions (failure to boot) on some laptops * tag 'ata-6.3-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata: ata: ahci: Revert "ata: ahci: Add Tiger Lake UP{3,4} AHCI controller"
-
Rafael J. Wysocki authored
Merge additional ACPI quirks for x86 systems: - Drop a suspend-to-idle quirk for HP Elitebook G9 that is not needed any more after a firmware update (Mario Limonciello). - Add all Cezanne systems to the list for forcing StorageD3Enable, because they all need the same quirk (Mario Limonciello). * acpi-pm: ACPI: x86: Drop quirk for HP Elitebook * acpi-x86: ACPI: x86: utils: Add Cezanne to the list for forcing StorageD3Enable
-
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxLinus Torvalds authored
Pull more s390 updates from Heiko Carstens: - Add empty command line parameter handling stubs to kernel for all command line parameters which are handled in the decompressor. This avoids invalid "Unknown kernel command line parameters" messages from the kernel, and also avoids that these will be incorrectly passed to user space. This caused already confusion, therefore add the empty stubs - Add missing phys_to_virt() handling to machine check handler - Introduce and use a union to be used for zcrypt inline assemblies. This makes sure that only a register wide member of the union is passed as input and output parameter to inline assemblies, while usual C code uses other members of the union to access bit fields of it - Add and use a READ_ONCE_ALIGNED_128() macro, which can be used to atomically read a 128-bit value from memory. This replaces the (mis-)use of the 128-bit cmpxchg operation to do the same in cpum_sf code. Currently gcc does not generate the used lpq instruction if __READ_ONCE() is used for aligned 128-bit accesses, therefore use this s390 specific helper - Simplify machine check handler code if a task needs to be killed because of e.g. register corruption due to a machine malfunction - Perform CPU reset to clear pending interrupts and TLB entries on an already stopped target CPU before delegating work to it - Generate arch/s390/boot/vmlinux.map link map for the decompressor, when CONFIG_VMLINUX_MAP is enabled for debugging purposes - Fix segment type handling for dcssblk devices. It incorrectly always returned type "READ/WRITE" even for read-only segements, which can result in a kernel panic if somebody tries to write to a read-only device - Sort config S390 select list again - Fix two kprobe reenter bugs revealed by a recently added kprobe kunit test * tag 's390-6.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/kprobes: fix current_kprobe never cleared after kprobes reenter s390/kprobes: fix irq mask clobbering on kprobe reenter from post_handler s390/Kconfig: sort config S390 select list again s390/extmem: return correct segment type in __segment_load() s390/decompressor: add link map saving s390/smp: perform cpu reset before delegating work to target cpu s390/mcck: cleanup user process termination path s390/cpum_sf: use READ_ONCE_ALIGNED_128() instead of 128-bit cmpxchg s390/rwonce: add READ_ONCE_ALIGNED_128() macro s390/ap,zcrypt,vfio: introduce and use ap_queue_status_reg union s390/nmi: fix virtual-physical address confusion s390/setup: do not complain about parameters handled in decompressor
-
