The blocker tracking mechanism assumes that lock pointers are at least
4-byte aligned to use their lower bits for type encoding.
However, as reported by Eero Tamminen, some architectures like m68k
only guarantee 2-byte alignment of 32-bit values. This breaks the
assumption and causes two related WARN_ON_ONCE checks to trigger.
To fix this, the runtime checks are adjusted to silently ignore any lock
that is not 4-byte aligned, effectively disabling the feature in such
cases and avoiding the related warnings.
Thanks to Geert Uytterhoeven for bisecting!
Link: https://lkml.kernel.org/r/20250909145243.17119-1-lance.yang@linux.dev
Fixes: e711faaafb ("hung_task: replace blocker_mutex with encoded blocker")
Signed-off-by: Lance Yang <lance.yang@linux.dev>
Reported-by: Eero Tamminen <oak@helsinkinet.fi>
Closes: https://lore.kernel.org/lkml/CAMuHMdW7Ab13DdGs2acMQcix5ObJK0O2dG_Fxzr8_g58Rc1_0g@mail.gmail.com
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Anna Schumaker <anna.schumaker@oracle.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Finn Thain <fthain@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Joel Granados <joel.granados@kernel.org>
Cc: John Stultz <jstultz@google.com>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Lance Yang <lance.yang@linux.dev>
Cc: Mingzhe Yang <mingzhe.yang@ly.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Tomasz Figa <tfiga@chromium.org>
Cc: Waiman Long <longman@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: Yongliang Gao <leonylgao@tencent.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Both the read and write side use kiocb_done() to finish a request, and
kiocb_done() will call io_put_kbuf() in case a provided buffer was used
for the request. Provided buffers are not supported for writes, hence
NULL is being passed in. This normally works fine, as io_put_kbuf()
won't actually use the value unless REQ_F_BUFFER_RING or
REQ_F_BUFFER_SELECTED is set in the request flags. But depending on
compiler (or whether or not CONFIG_CC_OPTIMIZE_FOR_SIZE is set), that
may be done even though the value is never used. This will then cause a
NULL pointer dereference.
Make it a bit more obvious and check for a NULL io_br_sel, and don't
even bother calling io_put_kbuf() for that case.
Fixes: 5fda512554 ("io_uring/kbuf: switch to storing struct io_buffer_list locally")
Reported-by: David Howells <dhowells@redhat.com>
Tested-by: David Howells <dhowells@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The S5_RESET_STATUS register is parsed on boot and printed to kmsg.
However, this could sometimes be misleading and lead to users wasting a
lot of time on meaningless debugging for two reasons:
* Some bits are never cleared by hardware. It's the software's
responsibility to clear them as per the Processor Programming Reference
(see [1]).
* Some rare hardware-initiated platform resets do not update the
register at all.
In both cases, a previous reboot could leave its trace in the register,
resulting in users seeing unrelated reboot reasons while debugging random
reboots afterward.
Write the read value back to the register in order to clear all reason bits
since they are write-1-to-clear while the others must be preserved.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=206537#attach_303991
[ bp: Massage commit message. ]
Fixes: ab81310287 ("x86/CPU/AMD: Print the reason for the last reset")
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/all/20250913144245.23237-1-i@rong.moe/
Add support for PMH0101/PMCX0102/PMH0110/PMH0104 PMIC voltage
regulators which are present on Glymur boards.
Introduce new LDOs & SMPSs under them (PMIC5 subtype 530 for
both).
For these new LDOs support a new optimum power mode(OPM). In
this mode LDO will automatically switch between high power mode
(HPM) and low power mode (LPM) based on the real-time LDO load
current. Its operation is analogous to SMPS AUTO mode.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Co-developed-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20250918-glymur-rpmh-regulator-driver-v3-4-184c09678be3@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently rpmh-regulator resource name inside CMD-DB follows this
format: `^(ldo|smp|bob|vs)[a-n][1-9][0-9]?$`
(eg - ldob11, smpa2, bobc1 etc)
Here `[a-n]` in the resource name signifies the `pmic-id`.
However, newer firmware follows a different format that also
includes the `bus_id` as well in the resource name.
New format:
`^(L|S|B)[1-9][0-9]?[A-N]_E[0-3]$`
(eg - L11B_E1, S2A_E0, B1C_E0 etc)
Here `_E[0-3]` at the end is the `bus_id`, and upper case `[A-N]`
is used to denote `pmic-id`, while the regulator `(ldo|smp|bob)`
is replaced with their initials in upper case `(L|S|B|VA)`.
To handle this properly, do the following:
- Remove the `resource_name` member from vreg init data
- Add `index` and `regulator_hw_type` new members, which will
contain the index number and the regulator hardware type
(SMPS/LDO/BOB/VS) which can be combined with the pmic-id read
from the devicetree to generate the resource_name.
- Choose new resource name format if `pmic-id` contains `_E`
in it, else fallback to old format.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20250918-glymur-rpmh-regulator-driver-v3-3-184c09678be3@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, CMD-DB names for RPMH regulators follow this format:
`^(smps|ldo|bob|vs)[a-n][1-9][0-9]?$`
Here, the `[a-n]` value is read from the `pmic-id` DT property,
which is unique to each PMIC present on the board.
Note that in this older CMD-DB name format the SPMI bus on which
a particular PMIC regulator exists was not apparent from its
CMD-DB name.
New targets like Glymur, where we have multiple SPMI buses,
overcome this limitation by following a new CMD-DB name format:
`^(L|S|B)[1-9][0-9]?[A-N]_E[0-3]$`
Here `[A-N]_E[0-3]` part will now be read from the `pmic-id` DT
prop and it includes the SPMI bus id `[0-3]` as well.
However, the PMIC ID part `[A-N]` of the CMD-DB name is now
unique only to the SPMI bus that the PMIC regulator is present
on. which means `L1B_E0` and `L1B_E1` are both possible CMD-DB
names for two different regulator LDOs present on two different
SPMI buses (bus id 0 and 1) on the same board.
Note that since the new `pmic-id` DT property is a combo of
PMIC ID and SPMI bus ID, so its still unique to each PMIC
present on the board.
Update the `pmic-id` property pattern information to reflect this
change in the driver handling to support this new CMD-DB naming
format while maintaining backward compatiblilty with old CMD-DB
naming format which is still supported for older/existing
targets.
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20250918-glymur-rpmh-regulator-driver-v3-2-184c09678be3@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add rpmh-regulator driver compatibles strings for below PMICs:
- PMH0101
- PMH0104
- PMH0110
- PMCX0102
Also add the supply name properties for the regulators
present on these PMICs.
Co-developed-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20250918-glymur-rpmh-regulator-driver-v3-1-184c09678be3@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
devm_kasprintf() may return NULL on memory allocation failure,
but the debug message prints cpus->dai_name before checking it.
Move the dev_dbg() call after the NULL check to prevent potential
NULL pointer dereference.
Fixes: cb8ea62e64 ("ASoC: amd/sdw_utils: add sof based soundwire generic machine driver")
Signed-off-by: Li Qiang <liqiang01@kylinos.cn>
Link: https://patch.msgid.link/20251015075530.146851-1-liqiang01@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
The widgets DMIC3_ENA and DMIC4_ENA must be defined in the DAPM
suppy widget, just like DMICL_ENA and DMICR_ENA. Whenever they
are turned on or off, the required startup or shutdown sequences
must be taken care by the max98090_shdn_event.
Signed-off-by: Sharique Mohammad <sharq0406@gmail.com>
Link: https://patch.msgid.link/20251015134215.750001-1-sharq0406@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add compatible string fsl,imx-audio-tlv320 to fix below CHECK_DTBS warning:
arch/arm/boot/dts/nxp/imx/imx6dl-gw5903.dtb: /sound: failed to match any schema with compatible: ['fsl,imx-audio-tlv320']
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251010160321.2130093-1-Frank.Li@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Haibo Chen <haibo.chen@nxp.com>:
PATCH 1: different operations maybe require different max frequency, so
add flexspi to handle such case, re-config the clock rate when
new coming operation require new clock frequency.
Patch 2: add workaround for erratum ERR050272. Since only add 4us dealy
in nxp_fspi_dll_calibration(), so do not distinguish different
platforms.
Patch 3: add max frequency limitation for different sample clock source
selection. Datasheet give max 66MHz for mode 0 and 166MHz for
mode 3. And IC suggest to add this limitation on all SoCs for
safety and stability.
The SCMI specification states that SENSOR_CONFIG_SET is used to
enable/disable the sensors. The sensors can be disabled by default,
which is the case at least on NXP i.MX95. Explicitly trigger the
SENSOR_CONFIG_SET to enable the sensors, otherwise sensor read may
fail and won't return valid data.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Link: https://lore.kernel.org/r/20251015114953.148706-1-marek.vasut@mailbox.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver does not perform any locking and does not create sysfs
attributes. Drop the unnecessary include files.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
While at it, drop unnecessary include of hwmon-sysfs.c.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver does not perform any locking and does not create sysfs
attributes. Drop the unnecessary include files.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver does not perform any locking, does not sleep or check the time,
and does not create sysfs attributes. Drop the unnecessary include files.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
While at it, drop the unnecessary include of hwmon-sysfs.h.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking n the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Attribute access is now serialized in the hardware monitoring core,
so locking in the driver code is no longer necessary. Drop it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for mp9945 device from Monolithic Power Systems, Inc.
(MPS) vendor. This is a single phase digital step down converter.
Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com>
Link: https://lore.kernel.org/r/20251009205458.396368-2-chou.cosmo@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use the energy64 attribute type instead of a locally defined sysfs
attribute to report the accumulated energy.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20251012211625.533791-2-linux@roeck-us.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use the energy64 attribute type instead of a locally defined sysfs
attribute to report the accumulated energy.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20251012211625.533791-1-linux@roeck-us.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support to read DTS for reading Intel Emerald Rapids platform.
Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/r/20251006215321.5036-4-fr0st61te@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Extend the functionality of hwmon (peci/dimmtemp) for Emerald Rapids
platform.
The patch has been tested on a 5S system with 16 DIMMs installed.
Verified read of DIMM temperature thresholds & temperature.
Using Sapphire's callbacks about getting thresholds because it's same
platform/socket.
Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/r/20251006215321.5036-3-fr0st61te@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for detection of Intel Emerald Rapids processor based on
CPU model.
Emerald Rapids Xeon processors with the model set to
INTEL_EMERALDRAPIDS_X. The data field for this entry is "emr".
Tested the patch series with AST2600 BMC with 5S Intel Emerald Rapids
processors & verified by reading cpu & dimm temperature which matches
host sensor values from lmsensors.
Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/r/20251006215321.5036-2-fr0st61te@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The board has a similar sensor configuration as the ROG STRIX X870E-E
GAMING WIFI, with an additional temperature sensor header.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20251003081002.1013313-3-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
ADPM12200 is a quarter brick DC/DC Power Module. It is a high power
non-isolated converter capable of delivering regulated 12V with
continuous power level of 2000W. Uses PMBus.
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Link: https://lore.kernel.org/r/20251001-hwmon-next-v1-2-f8ca6a648203@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Since fan properties can include reg, the fan controller should be
able to specify address-cells and size-cells properties and use
an addressed fan child node.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20251001144441.310950-6-eajames@linux.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The binding for the max31785 is the same as the max31790, so just add
some compatible strings for the max31785 chip.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20251001144441.310950-5-eajames@linux.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for the Murata NCP18WM474 NTC.
Compensation table has been constructed by linear interpolation between
well defined points[1] on the resistance vs. temperature graph in the
datasheet[2]. The readouts of the graph has been done to the best of my
abilities, but the compensation table will be subject to inaccuracies
nonetheless.
[1] -40, -25, 0, 25, 50, 75, 100, 125 degrees
[2] https://www.murata.com/en-eu/api/pdfdownloadapi?cate=&partno=NCP18WM474E03RB
Signed-off-by: Emil Dahl Juhl <juhl.emildahl@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20251001-ntc-thermistor-ncp18wm474-v1-1-2c64b9b509ff@pengutronix.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
