* Re: [PATCH V2 2/3] arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
From: sashiko-bot @ 2026-06-16 13:15 UTC (permalink / raw)
To: Monish Chunara; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260616130347.3096034-3-monish.chunara@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The device tree overlay fails to clear the inherited eMMC configuration (`no-sd`, `non-removable`) from the base DT, resulting in completely broken SD card support.
- [Medium] The overlay configures a 1.8V-capable regulator and UHS-I OPPs, but explicitly disables 1.8V signaling, rendering the UHS-I configuration unreachable dead code.
--
commit 5cd7b1bc67719c7d2577b7397199af1024203df8
Author: Monish Chunara <monish.chunara@oss.qualcomm.com>
arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
The monaco EVK board supports either eMMC or SD-card, but only one can be
active at a time. This commit enables the SDHCI on the monaco EVK board to
support SD Card storage via a device tree overlay, allowing eMMC to be
enabled via a separate overlay.
> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
> new file mode 100644
> index 0000000000000..bc4ea12587a2e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
[ ... ]
> +&sdhc_1 {
> + vmmc-supply = <&vmmc_sdc>;
> + vqmmc-supply = <&vreg_sdc>;
> +
> + pinctrl-0 = <&sdc1_state_on>, <&sd_cd>;
> + pinctrl-1 = <&sdc1_state_off>, <&sd_cd>;
> + pinctrl-names = "default", "sleep";
> +
> + cap-sd-highspeed;
> + no-1-8-v;
[Severity: Medium]
Will the no-1-8-v property prevent the UHS-I configuration from working?
The overlay configures a 1.8V-capable regulator (vreg_sdc) and adds
high-frequency OPPs (100MHz, 202MHz) to sdhc1_opp_table below, but explicitly
disabling 1.8V signaling forbids the MMC core from initiating the 1.8V
voltage switch.
This appears to limit the host to standard High Speed and makes the 1.8V
regulator state and UHS-I OPPs unreachable.
> +
> + bus-width = <4>;
> + cd-gpios = <&tlmm 11 GPIO_ACTIVE_LOW>;
> + no-mmc;
> + no-sdio;
[Severity: High]
Does this overlay properly clear the inherited eMMC configuration from the
base device tree?
The base device tree (monaco-evk.dts) configures &sdhc_1 with no-sd and
non-removable for default eMMC support. Since device tree overlays merge
properties, and this overlay doesn't use /delete-property/ for no-sd and
non-removable, the resulting node will have both no-sd and no-mmc
simultaneously.
Could this cause the MMC core to refuse to probe both SD and MMC cards?
> +
> + status = "okay";
> +};
> +
> +&sdhc1_opp_table {
> + opp-100000000 {
> + opp-hz = /bits/ 64 <100000000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + };
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616130347.3096034-1-monish.chunara@oss.qualcomm.com?part=2
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: i2c: i2c-mux-pinctrl: change maintainer
From: Andi Shyti @ 2026-06-16 13:14 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Thierry Reding, Peter Rosin, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260616060910.1480-2-wsa+renesas@sang-engineering.com>
Hi Wolfram,
On Tue, Jun 16, 2026 at 08:07:59AM +0200, Wolfram Sang wrote:
> The YAML conversion added me as maintainer but I can't recall being
> asked nor do I want to maintain it. Thierry has created the YAML file
> and works for the company which contributed the driver.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Acked-by: Thierry Reding <thierry.reding@kernel.org>
with Conor's ack, merged to i2c/i2c-host.
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH V2 1/3] arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT
From: sashiko-bot @ 2026-06-16 13:14 UTC (permalink / raw)
To: Monish Chunara; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260616130347.3096034-2-monish.chunara@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incomplete genericization of `sdhc_1` leaves conflicting eMMC-specific properties in the SoC DT, breaking SD card compatibility.
- [Medium] Removing the `supports-cqe` property from the SoC-level `monaco.dtsi` without explicitly adding it back to all eMMC-based boards causes a silent performance regression by disabling Command Queue Engine (CQE) support.
--
commit 05fd7920ab031fea94cd493a589a30892353cf08
Author: Monish Chunara <monish.chunara@oss.qualcomm.com>
arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT
This commit removes the supports-cqe property from the generic Monaco SoC
device tree and moves it to the qcs8300-ride board device tree. The stated
goal is to allow SD card compatibility in the base SoC definition, since the
Command Queue Engine conflicts with SD card operation.
> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index 7b1d57460f1e6..e5f316897706b 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -4828,7 +4828,6 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> qcom,dll-config = <0x000f64ee>;
> qcom,ddr-config = <0x80040868>;
> bus-width = <8>;
> - supports-cqe;
[Severity: Medium]
Removing supports-cqe from the SoC DT without adding it back to all
eMMC-based boards appears to cause a performance regression by disabling the
Command Queue Engine for those boards.
For example, arch/arm64/boot/dts/qcom/monaco-monza-som.dtsi and
arch/arm64/boot/dts/qcom/monaco-evk.dts both configure sdhc_1 as an eMMC
device (using no-sd and non-removable). Since they rely on the SoC DT for
the supports-cqe property, won't omitting it from this patch silently degrade
their performance?
[Severity: High]
The commit message states the goal is to ensure the SoC definition remains
generic for SD card compatibility by removing supports-cqe. However, does
leaving the other eMMC-specific properties in the SoC DT defeat this purpose?
Properties like bus-width = <8>, mmc-hs400-1_8v, mmc-hs400-enhanced-strobe,
qcom,dll-config, and qcom,ddr-config remain in the base monaco.dtsi. Since
device tree overlays do not automatically delete base boolean properties or
override tuning parameters unless explicitly redefined, won't these
incorrectly inherit to SD card configurations and cause the MMC core to
misconfigure the interface?
Should these properties be moved to the eMMC-specific board files as well?
> dma-coherent;
>
> mmc-ddr-1_8v;
> diff --git a/arch/arm64/boot/dts/qcom/qcs8300-ride.dts b/arch/arm64/boot/dts/qcom/qcs8300-ride.dts
> index e9a8553a8d821..3090eba0317ac 100644
> --- a/arch/arm64/boot/dts/qcom/qcs8300-ride.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs8300-ride.dts
> @@ -719,6 +719,7 @@ &sdhc_1 {
> vmmc-supply = <&vreg_l8a>;
> vqmmc-supply = <&vreg_s4a>;
>
> + supports-cqe;
> non-removable;
> no-sd;
> no-sdio;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616130347.3096034-1-monish.chunara@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH V2 3/3] arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay
From: sashiko-bot @ 2026-06-16 13:13 UTC (permalink / raw)
To: Monish Chunara; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260616130347.3096034-4-monish.chunara@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] Device Tree resource duplication for the vreg_s2s regulator.
Pre-existing issues:
- [High] Incomplete base DT refactoring leaves mutually exclusive eMMC properties, breaking the SD card overlay.
--
commit 457596ee7fdadc67892c938f430cbd6d76fabaf4
Author: Monish Chunara <monish.chunara@oss.qualcomm.com>
arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay
Enable the SDHCI controller for eMMC functionality on the Monaco EVK
using a device tree overlay.
> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso
> new file mode 100644
> index 0000000000000..cb2566ac6923c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso
> @@ -0,0 +1,37 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +/ {
> + vreg_s2s: regulator-vreg-s2s {
> + compatible = "regulator-fixed";
> + regulator-name = "regulator-s2s";
> +
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +};
[Severity: Medium]
Does this create a duplicate regulator node?
The base device tree in arch/arm64/boot/dts/qcom/monaco-evk.dts already
provisions this exact 1.8V fixed regulator as vreg-s2s with the vreg_s2s
label:
arch/arm64/boot/dts/qcom/monaco-evk.dts:
vreg_s2s: vreg-s2s {
compatible = "regulator-fixed";
regulator-name = "vreg_s2s";
Since the node names differ, applying this overlay instantiates a duplicate
physical regulator node instead of referencing the existing one.
> +
> +&sdhc_1 {
> + vmmc-supply = <&vreg_l8a>;
> + vqmmc-supply = <&vreg_s2s>;
> +
> + supports-cqe;
> +
> + pinctrl-0 = <&sdc1_state_on>;
> + pinctrl-1 = <&sdc1_state_off>;
> +
> + pinctrl-names = "default", "sleep";
> +
> + non-removable;
> +
> + bus-width = <8>;
> + no-sd;
> + no-sdio;
> +
> + status = "okay";
> +};
[Severity: High]
This isn't a bug introduced by this patch, but this commit fails to address
it while supposedly completing the eMMC overlay separation.
The base device tree arch/arm64/boot/dts/qcom/monaco-evk.dts retains
hardcoded eMMC properties for sdhc_1:
arch/arm64/boot/dts/qcom/monaco-evk.dts:sdhc_1
no-sd;
no-sdio;
non-removable;
Because overlays cannot easily delete properties, applying the previously
merged SD card overlay arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
inherits no-sd from the base DT while appending its own no-mmc. This causes
the MMC core to skip probing entirely, rendering the SD card controller
non-functional.
Should the base DT be stripped of these media-specific properties to properly
implement mutually exclusive overlays?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616130347.3096034-1-monish.chunara@oss.qualcomm.com?part=3
^ permalink raw reply
* [PATCH v2 2/3] dt-bindings: iio: st,st-sensors: add st,fullscale-milligauss
From: Herman van Hazendonk @ 2026-06-16 13:02 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Denis Ciocca, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Denis Ciocca, Linus Walleij
Cc: linux-iio, linux-kernel, llvm, devicetree, Herman van Hazendonk
In-Reply-To: <20260616-submit-iio-lsm303dlh-magn-fixes-v2-0-063edcf74e60@herrie.org>
Add an optional st,fullscale-milligauss property that selects the
initial magnetometer full-scale range at probe time, expressed in
milligauss.
The motivating case is the LSM303DLH magnetometer on the HP TouchPad
(apq8060 / tenderloin) where the kernel's chip-default +/-1.3 G range
saturates the X axis to the chip's 0xF000 overflow sentinel out of
probe, because the chip is mounted close to surrounding power planes
and picks up enough DC bias to exceed the smallest range.
The chip is not wedged by the saturation: a sysfs write of a wider
range to in_magn_x_scale recovers it on the next conversion, and a
UDEV rule on add of the IIO device is a viable steady-state
workaround. What the DT property buys is the probe-time window: the
in-tree consumers we use (sensorfw's iio-sensors-adaptor and the
geomagnetic / orientation services on top of it) start polling
in_magn_x_raw essentially as soon as the device node appears and
treat the 0xF000 sentinel as a legitimate sample. Until a UDEV rule
fires and commits the wider range, every read returns the stuck
sentinel, and on slow-boot paths the consumer may have already
cached a bogus calibration baseline by the time UDEV catches up.
st,fullscale-milligauss lets the device tree declare a wider
initial range up-front so the correct range is in effect before any
IIO consumer can open the device, and keeps the board-specific
magnetometer calibration alongside the rest of the hardware
description rather than splitting it between DTS and per-distro
UDEV rules.
The full property name is spelled out rather than abbreviated to
"-mg" because this same binding file already covers ST accelerometers
where the conventional shorthand "mg" reads as milli-g (acceleration);
the explicit "-milligauss" suffix makes the unit unambiguous if a
similar tunable is ever introduced for the accel/gyro/pressure
families.
The property is scoped to magnetometer compatibles via allOf/if-then
clauses, with per-family enum lists of the accepted milligauss
values (1300..8100 for LSM303DLH/DLHC/DLM, 4000..16000 for
LIS3MDL/LSM9DS1/LSM303C). LSM303AGR / LIS2MDL / IIS2MDC have a
single fixed full-scale (15000 mg) with no register to switch
ranges, so the property is rejected outright for them. DTSes that
misspell the value, place the property on an accelerometer /
gyroscope / pressure node, or set it on a fixed-FS magnetometer
fail dt_binding_check rather than emitting a runtime warning.
The property is purely additive: if absent, drivers fall back to
their existing chip default. No existing in-tree DTS is affected.
Assisted-by: Claude:claude-opus-4-7 dt_binding_check checkpatch
Assisted-by: Sashiko:claude-opus-4-7
Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
---
.../devicetree/bindings/iio/st,st-sensors.yaml | 71 ++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
index a1a958215cdb..f0805604c849 100644
--- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
+++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
@@ -126,6 +126,13 @@ properties:
mount-matrix:
description: an optional 3x3 mounting rotation matrix.
+ st,fullscale-milligauss:
+ description:
+ Initial magnetometer full-scale at probe time, in milligauss.
+ Per-chip allowed values are enumerated in the allOf clauses
+ below.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
allOf:
- if:
properties:
@@ -163,6 +170,70 @@ allOf:
maxItems: 1
st,drdy-int-pin: false
+ # Per-chip enum lists for st,fullscale-milligauss. Out-of-range
+ # values fail dt_binding_check instead of being demoted to a
+ # runtime warning by the driver.
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,lsm303dlh-magn
+ - st,lsm303dlhc-magn
+ - st,lsm303dlm-magn
+ then:
+ properties:
+ st,fullscale-milligauss:
+ enum: [1300, 1900, 2500, 4000, 4700, 5600, 8100]
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,lis3mdl-magn
+ - st,lsm303c-magn
+ - st,lsm9ds1-magn
+ then:
+ properties:
+ st,fullscale-milligauss:
+ enum: [4000, 8000, 12000, 16000]
+
+ # Single fixed full-scale, no register to switch: reject.
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,iis2mdc
+ - st,lis2mdl
+ - st,lsm303agr-magn
+ then:
+ properties:
+ st,fullscale-milligauss: false
+
+ # Reject st,fullscale-milligauss on non-magnetometer compatibles.
+ # Keep this enum in sync with the three magn clauses above when
+ # adding a new magnetometer compatible.
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,iis2mdc
+ - st,lis2mdl
+ - st,lis3mdl-magn
+ - st,lsm303agr-magn
+ - st,lsm303c-magn
+ - st,lsm303dlh-magn
+ - st,lsm303dlhc-magn
+ - st,lsm303dlm-magn
+ - st,lsm9ds1-magn
+ then:
+ properties:
+ st,fullscale-milligauss: false
+
required:
- compatible
- reg
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] iio: common: st_sensors: honour channel endianness in read_axis_data
From: Herman van Hazendonk @ 2026-06-16 13:02 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Denis Ciocca, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Denis Ciocca, Linus Walleij
Cc: linux-iio, linux-kernel, llvm, devicetree, stable,
Herman van Hazendonk
In-Reply-To: <20260616-submit-iio-lsm303dlh-magn-fixes-v2-0-063edcf74e60@herrie.org>
st_sensors_read_axis_data() unconditionally decoded multi-byte
results with get_unaligned_le16() / get_unaligned_le24() regardless
of the channel's declared scan_type.endianness.
For every ST sensor that has used this helper since it was introduced
this happened to be fine because the ST IMU/accel/gyro/pressure
families publish their data registers as little-endian and the
channel specs in those drivers declare IIO_LE accordingly.
The LSM303DLH magnetometer however publishes its X/Y/Z output as a
pair of big-endian bytes (the H register sits at the lower address,
0x03/0x05/0x07, and the L register immediately after), and its
channel specs in st_magn_core.c correctly declare IIO_BE -- but
read_axis_data() ignored that and decoded as little-endian, swapping
the high and low bytes of every magnetometer sample. The LSM303DLHC
and LSM303DLM share the same st_magn_16bit_channels (IIO_BE) and
were therefore byte-swapped by the same bug; users of those parts
will see different in_magn_*_raw values after this fix lands.
The bug is most visible on a stationary chip: in earth's field the
true X reading is small and the high byte sits at 0x00, so swapping
the bytes pins sysfs X at exactly the low byte's pattern (e.g. 0x00F0
= 240). Y and Z still appear "to vary" because their magnitudes are
larger and the noise in the low byte produces big swings in the
swapped high byte:
before (LSM303DLH flat, sysfs in_magn_*_raw):
X=240 (stuck), Y= 12032..23296, Z=-16128..-9728
after (direct i2c-dev big-endian decode, same chip same orientation):
X≈-4096, Y≈210, Z≈80 (sensible values reflecting earth's
ambient field at low gauss range)
Fix read_axis_data() to dispatch on ch->scan_type.endianness and
call get_unaligned_be16() / get_unaligned_be24() when the channel
declares IIO_BE. Existing IIO_LE consumers (st_accel, st_gyro,
st_pressure, st_lsm6dsx and others) are unaffected because their
channel specs already declare IIO_LE and the LE path is unchanged.
While restructuring the branches, replace the previously implicit
silent-success-with-uninitialised-*data fall-through for
byte_for_channel outside 1..3 with an explicit return -EINVAL. No
in-tree ST sensor publishes such a channel, but the new behaviour
is strictly safer than handing userspace garbage.
Fixes: 23491b513bcd ("iio:common: Add STMicroelectronics common library")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7 sparse smatch clang-analyzer coccinelle checkpatch
Assisted-by: Sashiko:claude-opus-4-7
Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
---
drivers/iio/common/st_sensors/st_sensors_core.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c b/drivers/iio/common/st_sensors/st_sensors_core.c
index dbc5e16fbde4..76f91696f66a 100644
--- a/drivers/iio/common/st_sensors/st_sensors_core.c
+++ b/drivers/iio/common/st_sensors/st_sensors_core.c
@@ -498,6 +498,7 @@ static int st_sensors_read_axis_data(struct iio_dev *indio_dev,
u8 *outdata;
struct st_sensor_data *sdata = iio_priv(indio_dev);
unsigned int byte_for_channel;
+ u32 tmp;
byte_for_channel = DIV_ROUND_UP(ch->scan_type.realbits +
ch->scan_type.shift, 8);
@@ -508,12 +509,22 @@ static int st_sensors_read_axis_data(struct iio_dev *indio_dev,
if (err < 0)
return err;
- if (byte_for_channel == 1)
- *data = (s8)*outdata;
- else if (byte_for_channel == 2)
- *data = (s16)get_unaligned_le16(outdata);
- else if (byte_for_channel == 3)
- *data = (s32)sign_extend32(get_unaligned_le24(outdata), 23);
+ if (byte_for_channel == 1) {
+ tmp = *outdata;
+ } else if (byte_for_channel == 2) {
+ if (ch->scan_type.endianness == IIO_BE)
+ tmp = get_unaligned_be16(outdata);
+ else
+ tmp = get_unaligned_le16(outdata);
+ } else if (byte_for_channel == 3) {
+ if (ch->scan_type.endianness == IIO_BE)
+ tmp = get_unaligned_be24(outdata);
+ else
+ tmp = get_unaligned_le24(outdata);
+ } else {
+ return -EINVAL;
+ }
+ *data = sign_extend32(tmp, BYTES_TO_BITS(byte_for_channel) - 1);
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/3] iio: lsm303dlh-magn: endianness + boot-time fullscale selection
From: Herman van Hazendonk @ 2026-06-16 13:02 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Denis Ciocca, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Denis Ciocca, Linus Walleij
Cc: linux-iio, linux-kernel, llvm, devicetree, stable,
Herman van Hazendonk
This series fixes two independent issues that together prevent the
LSM303DLH magnetometer from delivering usable readings out of the
box on at least the HP TouchPad (apq8060), and adds a small generic
extension to the ST sensors device-tree binding to allow boards to
declare a non-default initial full-scale.
PATCH 1/3 fixes st_sensors_core's read_axis_data() helper to honour
the channel's declared scan_type.endianness. The helper has
unconditionally decoded multi-byte results as little-endian since
it was introduced. Every other in-tree ST sensor declares IIO_LE
and was unaffected, but the LSM303DLH / LSM303DLHC / LSM303DLM
magnetometers all bind st_magn_16bit_channels (IIO_BE) and publish
their X / Y / Z words as big-endian pairs (high byte at the lower
register address, 0x03 / 0x05 / 0x07). The mismatch swapped the
high and low bytes of every magnetometer sample on these three
parts. The fix only affects the IIO_BE branch; existing IIO_LE
consumers are untouched.
PATCH 2/3 adds an optional st,fullscale-milligauss device-tree
property to the ST sensors binding. The driver core hardcodes
fs_avl[0] (the highest-sensitivity range) as the starting
full-scale, which is the right default for a desk-noise floor but
leaves no margin for boards that pick up DC bias from nearby PCB
structures. The property is scoped to magnetometer compatibles
via per-family enum clauses so DTSes with a misspelled value, or
that put the property on accel/gyro/pressure or fixed-FS magn
nodes, fail dt_binding_check rather than being silently no-op'd at
runtime.
PATCH 3/3 parses st,fullscale-milligauss in the magnetometer
common probe and selects the matching fs_avl entry. The LSM303DLH
on the HP TouchPad picks up enough DC bias from the surrounding
power planes that the chip-default +/-1.3 G range saturates the X
axis to the chip's 0xF000 overflow sentinel on every sample, while
Y and Z fall within range. Empirically any fs_avl >= 1 (+/-1.9 G
and up) works; on tenderloin the appropriate value is 2500 mg
(+/-2.5 G).
PATCH 1/3 is a standalone bug fix and is now Cc'd to stable;
PATCHES 2/3 and 3/3 form a unit.
Changes since v1
~~~~~~~~~~~~~~~~
PATCH 1/3 (endianness):
- Restructure around a single u32 tmp + one trailing
sign_extend32(tmp, BYTES_TO_BITS(byte_for_channel) - 1), drop
the (s16) / (s32) casts (Andy Shevchenko).
- Make byte_for_channel == 0 || >= 4 an explicit -EINVAL return
(no in-tree caller hits this, but the prior code silently left
*data uninitialised).
- Add Fixes: 23491b513bcd ("iio:common: Add STMicroelectronics
common library") and Cc: stable@vger.kernel.org (Jonathan
Cameron). The bug has been present since the helper was
introduced in 2013.
- Spell out that the fix changes in_magn_*_raw decoding for
LSM303DLHC and LSM303DLM too (same IIO_BE channel set), not
only LSM303DLH.
PATCH 2/3 (binding):
- Rename st,fullscale-mg to st,fullscale-milligauss. "-mg" is
the DT unit-suffix convention but already names milli-g in
the accelerometer parts of this same binding file; spelling
milligauss out keeps the unit unambiguous if a similar
tunable is ever added for accel/gyro/pressure.
- Scope the property to magnetometer compatibles via per-family
allOf:if-then enum clauses:
LSM303DLH/DLHC/DLM: enum [1300, 1900, 2500, 4000, 4700,
5600, 8100]
LIS3MDL/LSM9DS1/LSM303C: enum [4000, 8000, 12000, 16000]
LSM303AGR/LIS2MDL/IIS2MDC (fixed FS): rejected outright
everything else (accel/gyro/pressure/IMU): rejected outright
- Drop the "(or analogous engineering units for other sensor
families that may grow this property in the future)" hand-wave
from the description (Jonathan Cameron); the property is now
positively bound to magnetometers only.
- Drop the overstated "userspace cannot recover without racing
the driver" wording; document the actual probe-time window
(the in-tree IIO consumers cache the saturation sentinel
before any UDEV rule fires).
- Add an in-file maintenance comment before the catch-all NOT
clause so future contributors who add a new magnetometer
compatible know all four clauses must be updated together.
PATCH 3/3 (driver):
- Honour the rename to st,fullscale-milligauss.
- Restructure per Andy: const char *propname at the top,
device_property_present() pre-check, device_property_read_u32()
error path with explicit return.
- Gate the parse block on mdata->sensor_settings->fs.addr != 0
as defence in depth; the binding already rejects the property
on fixed-FS magnetometers, the gate keeps the code path
self-contained against stale DTBs.
To: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
To: Nuno Sá <nuno.sa@analog.com>
To: Andy Shevchenko <andy@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
To: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
To: Bill Wendling <morbo@google.com>
To: Justin Stitt <justinstitt@google.com>
To: Denis Ciocca <denis.ciocca@gmail.com>
To: Lars-Peter Clausen <lars@metafoo.de>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Denis Ciocca <denis.ciocca@st.com>
To: Linus Walleij <linusw@kernel.org>
Cc: linux-iio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: llvm@lists.linux.dev
Cc: devicetree@vger.kernel.org
v1: https://lore.kernel.org/linux-iio/cover.1780652883.git.github.com@herrie.org/
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260616-submit-iio-lsm303dlh-magn-fixes-48153433b301
---
Herman van Hazendonk (3):
iio: common: st_sensors: honour channel endianness in read_axis_data
dt-bindings: iio: st,st-sensors: add st,fullscale-milligauss
iio: magnetometer: st_magn: honour st,fullscale-milligauss DT property
.../devicetree/bindings/iio/st,st-sensors.yaml | 71 ++++++++++++++++++++++
drivers/iio/common/st_sensors/st_sensors_core.c | 23 +++++--
drivers/iio/magnetometer/st_magn_core.c | 32 ++++++++++
3 files changed, 120 insertions(+), 6 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260616-submit-iio-lsm303dlh-magn-fixes-48153433b301
Best regards,
--
Herman van Hazendonk <github.com@herrie.org>
^ permalink raw reply
* Re: [PATCH v3 05/10] ARM: dts: qcom: msm8960: add RPM clock controller and fix USB clocks
From: Antony Kurniawan Soemardi @ 2026-06-16 13:04 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta
In-Reply-To: <1d15a420-7360-429e-a451-ec1f012a0346@oss.qualcomm.com>
On 6/9/2026 7:21 PM, Konrad Dybcio wrote:
> On 6/1/26 10:51 AM, Antony Kurniawan Soemardi via B4 Relay wrote:
>> From: Antony Kurniawan Soemardi <linux@smankusors.com>
>> @@ -507,8 +519,12 @@ usb1: usb@12500000 {
>> reg = <0x12500000 0x200>,
>> <0x12500200 0x200>;
>> interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
>> - clocks = <&gcc USB_HS1_XCVR_CLK>, <&gcc USB_HS1_H_CLK>;
>> - clock-names = "core", "iface";
>> + clocks = <&gcc USB_HS1_H_CLK>,
>> + <&rpmcc RPM_DAYTONA_FABRIC_CLK>,
>> + <&gcc USB_HS1_XCVR_CLK>;
>> + clock-names = "iface",
>> + "core",
>> + "fs";
>
> The bindings change you sent changes the expectations - "core" used
> to be the first clock. And I would guesstimate that the
> DAYTONA_FABRIC clock is not really "core" - does downstream do any
> ratesetting on the other two?
Looking at the downstream, I can only find HS1_XCVR being set to 60MHz,
DAYTONA_FABRIC being set to the max rate (just for voting purposes?). I
don't see any clk_set_rate for HS1_P though.
Would you rather the other way around? Like "core", "iface", and "fs"?
My concern is that such a change would result in a large number of
warnings for newer SoC device trees.
--
Thanks,
Antony K. S.
^ permalink raw reply
* [PATCH V2 3/3] arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay
From: Monish Chunara @ 2026-06-16 13:03 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Manivannan Sadhasivam
Cc: linux-arm-msm, devicetree, linux-kernel, Sarthak Garg,
Pradeep Pragallapati, Nitin Rawat, Shiraz Hashim, Monish Chunara
In-Reply-To: <20260616130347.3096034-1-monish.chunara@oss.qualcomm.com>
Enable the SDHCI controller for eMMC functionality on the Monaco EVK
using a device tree overlay.
Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 3 ++
arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso | 37 +++++++++++++++++++
2 files changed, 40 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 3c5983bff00c..e9a21c83001c 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -73,6 +73,9 @@ dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-ifp-mezzanine.dtb
monaco-evk-sd-card-dtbs := monaco-evk.dtb monaco-evk-sd-card.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-sd-card.dtb
+monaco-evk-emmc-dtbs := monaco-evk.dtb monaco-evk-emmc.dtbo
+dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-emmc.dtb
+
dtb-$(CONFIG_ARCH_QCOM) += msm8216-samsung-fortuna3g.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-acer-a1-724.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-alcatel-idol347.dtb
diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso
new file mode 100644
index 000000000000..cb2566ac6923
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+/plugin/;
+
+/ {
+ vreg_s2s: regulator-vreg-s2s {
+ compatible = "regulator-fixed";
+ regulator-name = "regulator-s2s";
+
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+};
+
+&sdhc_1 {
+ vmmc-supply = <&vreg_l8a>;
+ vqmmc-supply = <&vreg_s2s>;
+
+ supports-cqe;
+
+ pinctrl-0 = <&sdc1_state_on>;
+ pinctrl-1 = <&sdc1_state_off>;
+
+ pinctrl-names = "default", "sleep";
+
+ non-removable;
+
+ bus-width = <8>;
+ no-sd;
+ no-sdio;
+
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH V2 2/3] arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
From: Monish Chunara @ 2026-06-16 13:03 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Manivannan Sadhasivam
Cc: linux-arm-msm, devicetree, linux-kernel, Sarthak Garg,
Pradeep Pragallapati, Nitin Rawat, Shiraz Hashim, Monish Chunara
In-Reply-To: <20260616130347.3096034-1-monish.chunara@oss.qualcomm.com>
The monaco EVK board supports either eMMC or SD-card, but only one
can be active at a time.
Enable the SD Host Controller Interface (SDHCI) on the monaco EVK board
to support SD Card for storage via a device tree overlay. This allows
eMMC support to be enabled through a separate overlay when required.
Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 4 ++
.../boot/dts/qcom/monaco-evk-sd-card.dtso | 72 +++++++++++++++++++
2 files changed, 76 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 6f33c4e2f09c..3c5983bff00c 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -69,6 +69,10 @@ monaco-evk-el2-dtbs := monaco-evk.dtb monaco-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-el2.dtb
monaco-evk-ifp-mezzanine-dtbs := monaco-evk.dtb monaco-evk-ifp-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-ifp-mezzanine.dtb
+
+monaco-evk-sd-card-dtbs := monaco-evk.dtb monaco-evk-sd-card.dtbo
+dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-sd-card.dtb
+
dtb-$(CONFIG_ARCH_QCOM) += msm8216-samsung-fortuna3g.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-acer-a1-724.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-alcatel-idol347.dtb
diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
new file mode 100644
index 000000000000..bc4ea12587a2
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ vmmc_sdc: regulator-mmc-sdc {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vmmc_sdc";
+ regulator-min-microvolt = <2950000>;
+ regulator-max-microvolt = <2950000>;
+ };
+
+ vreg_sdc: regulator-sdc {
+ compatible = "regulator-gpio";
+
+ regulator-name = "vreg_sdc";
+ regulator-type = "voltage";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2950000>;
+
+ gpios = <&expander1 7 GPIO_ACTIVE_HIGH>;
+ states = <1800000 1>, <2950000 0>;
+
+ startup-delay-us = <100>;
+ };
+};
+
+&sdhc_1 {
+ vmmc-supply = <&vmmc_sdc>;
+ vqmmc-supply = <&vreg_sdc>;
+
+ pinctrl-0 = <&sdc1_state_on>, <&sd_cd>;
+ pinctrl-1 = <&sdc1_state_off>, <&sd_cd>;
+ pinctrl-names = "default", "sleep";
+
+ cap-sd-highspeed;
+ no-1-8-v;
+
+ bus-width = <4>;
+ cd-gpios = <&tlmm 11 GPIO_ACTIVE_LOW>;
+ no-mmc;
+ no-sdio;
+
+ status = "okay";
+};
+
+&sdhc1_opp_table {
+ opp-100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-202000000 {
+ opp-hz = /bits/ 64 <202000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+};
+
+&tlmm {
+ sd_cd: sd-cd-state {
+ pins = "gpio11";
+ function = "gpio";
+ bias-pull-up;
+ };
+};
--
2.34.1
^ permalink raw reply related
* [PATCH V2 1/3] arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT
From: Monish Chunara @ 2026-06-16 13:03 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Manivannan Sadhasivam
Cc: linux-arm-msm, devicetree, linux-kernel, Sarthak Garg,
Pradeep Pragallapati, Nitin Rawat, Shiraz Hashim, Monish Chunara
In-Reply-To: <20260616130347.3096034-1-monish.chunara@oss.qualcomm.com>
The Monaco SoC SDHC controller supports both eMMC and SD cards. However,
the 'supports-cqe' property (Command Queue Engine) is specific to eMMC
and conflicts with SD card operation.
Remove 'supports-cqe' from the SoC device tree to ensure compatibility
with SD cards. Simultaneously, add the property explicitly to the
qcs8300-ride board device tree, as this board uses the controller in
eMMC mode.
This ensures the SoC definition remains generic while enabling features
correctly at the board level.
Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 1 -
arch/arm64/boot/dts/qcom/qcs8300-ride.dts | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index e4c8466f941b..e82cba350842 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -4832,7 +4832,6 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
qcom,dll-config = <0x000f64ee>;
qcom,ddr-config = <0x80040868>;
bus-width = <8>;
- supports-cqe;
dma-coherent;
mmc-ddr-1_8v;
diff --git a/arch/arm64/boot/dts/qcom/qcs8300-ride.dts b/arch/arm64/boot/dts/qcom/qcs8300-ride.dts
index e9a8553a8d82..3090eba0317a 100644
--- a/arch/arm64/boot/dts/qcom/qcs8300-ride.dts
+++ b/arch/arm64/boot/dts/qcom/qcs8300-ride.dts
@@ -719,6 +719,7 @@ &sdhc_1 {
vmmc-supply = <&vreg_l8a>;
vqmmc-supply = <&vreg_s4a>;
+ supports-cqe;
non-removable;
no-sd;
no-sdio;
--
2.34.1
^ permalink raw reply related
* [PATCH V2 0/3] arm64: dts: qcom: Monaco: Enable SDHCI storage support
From: Monish Chunara @ 2026-06-16 13:03 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Manivannan Sadhasivam
Cc: linux-arm-msm, devicetree, linux-kernel, Sarthak Garg,
Pradeep Pragallapati, Nitin Rawat, Shiraz Hashim, Monish Chunara
Hello respected Maintainers,
This is v2 of the Monaco SDHCI storage support series.
V1 was sent here:
https://lore.kernel.org/all/20260227105055.2364348-1-monish.chunara@oss.qualcomm.com/
Compared to v1, this revision makes the storage split more explicit and keeps
the SoC description generic:
- Avoids using the reference to direct supplies as dummy
- Updates the eMMC overlay to remove the static UFS host disablement and
vreg_l8a voltage override, allowing DT-fixup to manage the UFS-eMMC mutual
exclusion dynamically for flexible UFS/eMMC configurations.
Validated on Qualcomm Monaco EVK with both SD card and eMMC modules.
Monish Chunara (3):
arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT
arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay
arch/arm64/boot/dts/qcom/Makefile | 7 ++
arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso | 37 ++++++++++
.../boot/dts/qcom/monaco-evk-sd-card.dtso | 72 +++++++++++++++++++
arch/arm64/boot/dts/qcom/monaco.dtsi | 1 -
arch/arm64/boot/dts/qcom/qcs8300-ride.dts | 1 +
5 files changed, 117 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso
create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
--
2.34.1
^ permalink raw reply
* [PATCH v2 3/3] iio: magnetometer: st_magn: honour st,fullscale-milligauss DT property
From: Herman van Hazendonk @ 2026-06-16 13:02 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Denis Ciocca, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Denis Ciocca, Linus Walleij
Cc: linux-iio, linux-kernel, llvm, devicetree, Herman van Hazendonk
In-Reply-To: <20260616-submit-iio-lsm303dlh-magn-fixes-v2-0-063edcf74e60@herrie.org>
The ST magnetometer core's common probe hardcodes fs_avl[0] -- the
highest-sensitivity full-scale supported by the chip -- as the
starting range. For the LSM303DLH that is +/-1.3 G; for the
LSM303DLHC and LSM303DLM it is +/-2 G; for the LIS3MDL it is +/-4 G.
That is the right default for "minimal noise floor at a desk", but
it leaves no margin for boards that pick up appreciable DC bias from
nearby PCB structures. On the HP TouchPad (apq8060 / tenderloin) the
LSM303DLH magnetometer is mounted close enough to the surrounding
power planes that X reads back as the chip's 0xF000 overflow
sentinel (== -4096 raw, the value the chip publishes when the ADC
saturates) on every sample at the chip-default range, while Y and Z
fall well within the +/-1.3 G window.
Parse the st,fullscale-milligauss device-tree property (documented
separately in dt-bindings/iio/st,st-sensors.yaml) in the
magnetometer common probe to select the initial fs_avl entry by its
mg value. The DT binding pins the accepted value set per compatible
via allOf/if-then enum clauses, so a malformed mg value fails
dt_binding_check rather than reaching the driver. Sensors with a
fixed full-scale (fs.addr == 0: LSM303AGR, LIS2MDL, IIS2MDC) have no
register to switch and the property is rejected outright for them
in the binding; the parse block is additionally gated on fs.addr as
defence in depth against stale DTBs.
Per-sensor mg ranges are listed in st_magn_sensors_settings[]. For
LSM303DLH and LSM303DLHC/DLM the valid values are 1300, 1900, 2500,
4000, 4700, 5600 and 8100; for LIS3MDL, LSM9DS1-magn and LSM303C-magn
they are 4000, 8000, 12000, 16000.
Empirical scale sweep on the HP TouchPad confirmed that on this
board any fs_avl >= 1 produces non-saturated X readings:
scale (0.001 G/LSB) | X raw Y raw Z raw
--------------------+-------------------------------
1.100 | -4096 44 46 (X saturated)
0.855 | -547 37 37 (clean)
0.670 | -433 94 103 (clean)
0.450 | -266 44 71 (clean)
0.400 | -235 34 65 (clean)
0.330 | -196 27 56 (clean)
0.230 | -145 15 40 (clean)
2500 mg is the natural choice for tenderloin: comfortably outside
the saturation regime while keeping useful precision for compass
applications.
Assisted-by: Claude:claude-opus-4-7 sparse smatch clang-analyzer coccinelle checkpatch
Assisted-by: Sashiko:claude-opus-4-7
Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
---
drivers/iio/magnetometer/st_magn_core.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/iio/magnetometer/st_magn_core.c b/drivers/iio/magnetometer/st_magn_core.c
index ef348d316c00..6f369e8dddea 100644
--- a/drivers/iio/magnetometer/st_magn_core.c
+++ b/drivers/iio/magnetometer/st_magn_core.c
@@ -10,6 +10,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#include <linux/property.h>
#include <linux/sysfs.h>
#include <linux/iio/iio.h>
#include <linux/iio/sysfs.h>
@@ -608,6 +609,7 @@ int st_magn_common_probe(struct iio_dev *indio_dev)
struct st_sensor_data *mdata = iio_priv(indio_dev);
struct device *parent = indio_dev->dev.parent;
struct st_sensors_platform_data *pdata = dev_get_platdata(parent);
+ const char *propname;
int err;
indio_dev->modes = INDIO_DIRECT_MODE;
@@ -628,6 +630,36 @@ int st_magn_common_probe(struct iio_dev *indio_dev)
mdata->current_fullscale = &mdata->sensor_settings->fs.fs_avl[0];
mdata->odr = mdata->sensor_settings->odr.odr_avl[0].hz;
+ /*
+ * Skip fixed-FS chips (fs.addr == 0): no register to switch.
+ * The binding rejects the property on these compatibles too;
+ * the gate guards stale DTBs.
+ */
+ propname = "st,fullscale-milligauss";
+ if (mdata->sensor_settings->fs.addr &&
+ device_property_present(parent, propname)) {
+ struct st_sensor_fullscale *fs = &mdata->sensor_settings->fs;
+ u32 fs_mg;
+ int i;
+
+ err = device_property_read_u32(parent, propname, &fs_mg);
+ if (err)
+ return err;
+
+ for (i = 0; i < ST_SENSORS_FULLSCALE_AVL_MAX; i++) {
+ if (!fs->fs_avl[i].num)
+ break;
+ if (fs->fs_avl[i].num == fs_mg) {
+ mdata->current_fullscale = &fs->fs_avl[i];
+ break;
+ }
+ }
+ if (mdata->current_fullscale->num != fs_mg)
+ dev_warn(parent, "%s=%u not supported, using %u\n",
+ propname, fs_mg,
+ mdata->current_fullscale->num);
+ }
+
if (!pdata)
pdata = (struct st_sensors_platform_data *)&default_magn_pdata;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/3] arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
From: Konrad Dybcio @ 2026-06-16 13:01 UTC (permalink / raw)
To: Monish Chunara
Cc: Dmitry Baryshkov, andersson, konradybcio, robh, krzk+dt, conor+dt,
mani, linux-arm-msm, devicetree, linux-kernel, sarthak.garg,
pradeep.pragallapati, nitin.rawat
In-Reply-To: <ajFB7FVlqp3qCA0i@hu-mchunara-hyd.qualcomm.com>
On 6/16/26 2:30 PM, Monish Chunara wrote:
> On Mon, Mar 23, 2026 at 03:15:09PM +0100, Konrad Dybcio wrote:
>> On 3/2/26 3:24 PM, Monish Chunara wrote:
>>> On Fri, Feb 27, 2026 at 10:03:10PM +0200, Dmitry Baryshkov wrote:
>>>> On Fri, Feb 27, 2026 at 04:20:54PM +0530, Monish Chunara wrote:
>>>>> The monaco EVK board supports either eMMC or SD-card, but only one
>>>>> can be active at a time.
>>>>>
>>>>> Enable the SD Host Controller Interface (SDHCI) on the monaco EVK board
>>>>> to support SD Card for storage via a device tree overlay. This allows
>>>>> eMMC support to be enabled through a separate overlay when required.
>>>>>
>>>>> Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/Makefile | 4 ++
>>>>> .../boot/dts/qcom/monaco-evk-sd-card.dtso | 72 +++++++++++++++++++
>>>>> 2 files changed, 76 insertions(+)
>>>>> create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
>>>>> index 317af937d038..c86242a1631d 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/Makefile
>>>>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>>>>> @@ -46,6 +46,10 @@ lemans-evk-el2-dtbs := lemans-evk.dtb lemans-el2.dtbo
>>>>> dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-el2.dtb
>>>>> dtb-$(CONFIG_ARCH_QCOM) += milos-fairphone-fp6.dtb
>>>>> dtb-$(CONFIG_ARCH_QCOM) += monaco-evk.dtb
>>>>> +
>>>>> +monaco-evk-sd-card-dtbs := monaco-evk.dtb monaco-evk-sd-card.dtbo
>>>>> +dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-sd-card.dtb
>>>>> +
>>>>> dtb-$(CONFIG_ARCH_QCOM) += msm8216-samsung-fortuna3g.dtb
>>>>> dtb-$(CONFIG_ARCH_QCOM) += msm8916-acer-a1-724.dtb
>>>>> dtb-$(CONFIG_ARCH_QCOM) += msm8916-alcatel-idol347.dtb
>>>>> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
>>>>> new file mode 100644
>>>>> index 000000000000..a0bc5c47d40b
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
>>>>> @@ -0,0 +1,72 @@
>>>>> +// SPDX-License-Identifier: BSD-3-Clause
>>>>> +/*
>>>>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>>>>> + */
>>>>> +
>>>>> +/dts-v1/;
>>>>> +/plugin/;
>>>>> +
>>>>> +#include <dt-bindings/gpio/gpio.h>
>>>>> +
>>>>> +/ {
>>>>> + vmmc_sdc: regulator-dummy {
>>>>
>>>> No dummy regulators, please.
>>>
>>> ACK, these will be renamed as per the schematic. Since these are direct supplies
>>> on hardware, used fixed-regulator configuration.
>>>
>>>>
>>>>> + compatible = "regulator-fixed";
>>>>> +
>>>>> + regulator-name = "vmmc_sdc";
>>>>> + regulator-min-microvolt = <2950000>;
>>>>> + regulator-max-microvolt = <2950000>;
>>>>> + };
>>>>> +
>>>>> + vreg_sdc: regulator-sdc {
>>>>> + compatible = "regulator-gpio";
>>>>> +
>>>>> + regulator-name = "vreg_sdc";
>>>>> + regulator-type = "voltage";
>>>>> + regulator-min-microvolt = <1800000>;
>>>>> + regulator-max-microvolt = <2950000>;
>>>>> +
>>>>> + gpios = <&expander1 7 GPIO_ACTIVE_HIGH>;
>>>>> + states = <1800000 1>, <2950000 0>;
>>>>> +
>>>>> + startup-delay-us = <100>;
>>>>> + };
>>>>> +};
>>>>> +
>>>>> +&sdhc_1 {
>>>>> + vmmc-supply = <&vmmc_sdc>;
>>>>> + vqmmc-supply = <&vreg_sdc>;
>>>>> +
>>>>> + pinctrl-0 = <&sdc1_state_on>, <&sd_cd>;
>>>>> + pinctrl-1 = <&sdc1_state_off>, <&sd_cd>;
>>>>> + pinctrl-names = "default", "sleep";
>>>>> +
>>>>> + cap-sd-highspeed;
>>>>> + no-1-8-v;
>>>>> +
>>>>> + bus-width = <4>;
>>>>> + cd-gpios = <&tlmm 11 GPIO_ACTIVE_LOW>;
>>>>> + no-mmc;
>>>>> + no-sdio;
>>>>> +
>>>>> + status = "okay";
>>>>> +};
>>>>> +
>>>>> +&sdhc1_opp_table {
>>>>
>>>> Why? Is it specific to the device or to the chip? In the latter case,
>>>> please define a separate table in the monaco.dtsi and switch to it here.
>>>>
>>>
>>> As per the previous review, it was suggested to use an existing table. But yes,
>>> this is specific to the Host controller and the corresponding voltage corners on
>>> the chip and can be defined as a separate entity for SD card use-case.
>>
>> The SDC programming guide I have access to does not seem to have bene
>> updated for any recent chips. Are you sure these different corners are
>> *actually* valid? The clock-side documentation doesn't mention that
>>
>
> There seems a gap in the clock documentation. This is being communicated to the
> corresponding stakeholders. However, the corners mentioned are as per the
> reference platform and will be updated in the subsequent series based on the
> updates from the clock-plan PoC as required.
Thanks for chasing this down
Konrad
^ permalink raw reply
* Re: [PATCH v3 02/12] dt-bindings: iio: dac: ad5696: rework on power supplies
From: Rob Herring @ 2026-06-16 12:50 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: Michael Auchter, linux, linux-iio, devicetree, linux-kernel,
linux-hardening, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Kees Cook, Gustavo A. R. Silva, Conor Dooley
In-Reply-To: <20260616-ad5686-new-features-v3-2-f829fb7e9262@analog.com>
On Tue, Jun 16, 2026 at 09:21:08AM +0100, Rodrigo Alencar wrote:
> Add supplies for VDD, VLOGIC and VREF input voltage pins. The vcc-supply
> property is deprecated, once it does not really exist as none of the
> devices describe any power input with that name. VCC is also misleading as
> it sounds like the input power supply, but it is being used as an external
> voltage reference, which should be called VREF. Certain devices require
> vref-supply to be available once an internal reference voltage is absent.
> For correct operation vdd and vlogic supplies are required.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> ---
> .../devicetree/bindings/iio/dac/adi,ad5696.yaml | 34 ++++++++++++++++++++--
> 1 file changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
> index c55158c464fd..7b936824917e 100644
> --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
> +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
> @@ -33,9 +33,22 @@ properties:
> reg:
> maxItems: 1
>
> + vdd-supply:
> + description: Input power supply.
> +
> + vlogic-supply:
> + description:
> + Digital power supply. On some tiny package variants for single-channel
> + devices, this supply is internally connected to vdd; in that case, specify
> + this property with the same regulator as vdd.
> +
> + vref-supply:
> + description:
> + Reference voltage supply. If not supplied the internal reference is used.
> +
> vcc-supply:
> - description: |
> - The regulator supply for DAC reference voltage.
> + deprecated: true
> + description: Use vref-supply instead.
>
> reset-gpios:
> description: Active-low RESET pin to reset the device.
> @@ -62,8 +75,21 @@ properties:
> required:
> - compatible
> - reg
> + - vdd-supply
> + - vlogic-supply
>
> allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + anyOf:
> + - const: adi,ad5693
> + - const: adi,ad5694
> + - const: adi,ad5696
enum rather than anyOf+const.
Rob
^ permalink raw reply
* Re: [PATCH 1/5] arm64: dts: qcom: msm8998-sony-yoshino: Drop extra bias-disable
From: Konrad Dybcio @ 2026-06-16 12:50 UTC (permalink / raw)
To: Krzysztof Kozlowski, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, André Apitzsch,
Luca Weiss, Gabriela David
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <2229ec5a-f89f-47e0-a489-9d127528e4e3@kernel.org>
On 6/10/26 2:00 PM, Krzysztof Kozlowski wrote:
> On 10/06/2026 13:43, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> The msm8998-common i2c5 pin sleep state is defined with a pull-up. The
>> Sony Yoshino DTSI attempts to override that to bias-disable without
>> removing the existing bias-pull-up. Remove the override and use the
>> common definition to resolve a dt checker warning.
>
> Maybe the bias-pull-up should be simply removed? At least you should
> document here why you chosen that way to fix the warning.
Seems that way. Unfortunately it was yours truly who set it up that way
back in 2021.. but I don't see a reason for the pull-up to be there when
the I2C controller is disabled. Maa-a-aybe for some obscure wake up
notifications but that's beyond me.
msm-4.4 sets bias-disabled for all sleep states for all i2c controllers
and e.g. msm8998-xiaomi-sagit overrides that back.
I think the right thing to do would be to set bias-disabled by default
and that's what I'm gonna do for v2
Konrad
^ permalink raw reply
* Re: [PATCH v3 01/12] dt-bindings: iio: dac: ad5696: add reset/ldac/gain support
From: Rob Herring @ 2026-06-16 12:48 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: Michael Auchter, linux, linux-iio, devicetree, linux-kernel,
linux-hardening, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Kees Cook, Gustavo A. R. Silva, Conor Dooley
In-Reply-To: <20260616-ad5686-new-features-v3-1-f829fb7e9262@analog.com>
On Tue, Jun 16, 2026 at 09:21:07AM +0100, Rodrigo Alencar wrote:
> Add GPIO property for RESET, LDAC and GAIN pin. RESET is active-low, LDAC
> is used to load DAC channels with values from input registers and GAIN
> can double the voltage in output channels. The gain-gpios property is
> not available to all supported parts. The adi,range-double property
> indicates that GAIN pin is hardwired to high in case gain-gpios is not
> set, otherwise it sets the initial value for the gain setting.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> ---
> .../devicetree/bindings/iio/dac/adi,ad5696.yaml | 41 +++++++++++++++++++++-
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
> index b5a88b03dc2f..c55158c464fd 100644
> --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
> +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
> @@ -37,14 +37,52 @@ properties:
> description: |
> The regulator supply for DAC reference voltage.
>
> + reset-gpios:
> + description: Active-low RESET pin to reset the device.
> + maxItems: 1
> +
> + ldac-gpios:
> + description:
> + Active-low LDAC pin used to asynchronously update the DAC channels.
> + maxItems: 1
> +
> + gain-gpios:
> + description:
> + GAIN pin that sets a multiplier for the DAC output voltage. When high,
> + the DAC output voltage is multiplied by 2, otherwise it is unchanged.
> + maxItems: 1
> +
> + adi,range-double:
> + description:
> + Sets the initial voltage output range from 0 to 2xVREF. On devices that
> + have a GAIN pin and no gain-gpios property is set, this indicates the pin
> + is hardwired high.
> + type: boolean
> +
> required:
> - compatible
> - reg
>
> -additionalProperties: false
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + anyOf:
> + - const: adi,ad5311r
> + - const: adi,ad5691r
> + - const: adi,ad5692r
> + - const: adi,ad5693
> + - const: adi,ad5693r
Just 'enum' instead of anyOf+const.
> + then:
> + properties:
> + gain-gpios: false
> +
> +unevaluatedProperties: false
sashiko is correct. No need for unevaluatedProperties here.
Rob
^ permalink raw reply
* Re: [PATCH v3 4/4] arm64: dts: qcom: sm8550: add UART11 node
From: Konrad Dybcio @ 2026-06-16 12:38 UTC (permalink / raw)
To: azkali.limited, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260517-pocketds-v3-4-d5910c801756@gmail.com>
On 5/17/26 3:14 PM, Alexandre Hamamdjian via B4 Relay wrote:
> From: Alexandre Hamamdjian <azkali.limited@gmail.com>
>
> Add the QUPv3_2 SE3 High Speed UART (UART11) controller node and its
> default pinctrl state to sm8550.dtsi, so boards can enable it through
> &uart11 instead of open-coding the controller in their own dts.
The latter part of the sentence is rather implicit, that approach
wouldn't be accepted
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 3/4] arm64: dts: qcom: Add HONOR MagicBook Art 14 device tree
From: Konrad Dybcio @ 2026-06-16 12:37 UTC (permalink / raw)
To: Konstantin Shabanov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260515172926.16597-4-mail@etehtsea.me>
On 5/15/26 7:29 PM, Konstantin Shabanov wrote:
> Introduce support for the HONOR MagicBook Art 14 laptop.
> This version is based on the initial work by Kirill A. Korinsky [1]
> and Valentin Manea [2].
>
> Supported:
>
> - Sound (with alsa-ucm-conf config [3])
> - Speakers
> - Headphone jack
> - Bluetooth
> - Battery
> - HDMI
> - Touchpad
> - Keyboard (with backlight)
> - Touchscreen
> - WiFi
> - USB-C ports
> - USB-A port
> - UFS
> - H/W accel
> - DP over USB-C
>
> Untested:
>
> - Camera
> - Fingerprint reader
> - Sleep/Suspend
>
> Broken:
>
> - eDP
>
> [1]: https://lore.kernel.org/all/871px910m1.wl-kirill@korins.ky/
> [2]: https://github.com/vamanea/linux-magicbook/blob/x1e80100-magicbook-6.19/arch/arm64/boot/dts/qcom/x1e80100-honor-magicbook-art-14.dts
> [3]: https://github.com/alsa-project/alsa-ucm-conf/pull/755
>
> Signed-off-by: Konstantin Shabanov <mail@etehtsea.me>
> ---
[...]
> + sound {
> + compatible = "qcom,x1e80100-sndcard";
> + model = "X1E80100-CRD";
This should point to the actual name of the board, then you can make a
""symlink"" in ALSA UCM (there's a file that binds compatible soundcards
in there)
[...]
> + wcd-playback-dai-link {
> + link-name = "WCD Playback";
> +
> + cpu {
> + sound-dai = <&q6apmbedai RX_CODEC_DMA_RX_0>;
> + };
> +
> + codec {
> + sound-dai = <&wcd938x 0>, <&swr1 0>, <&lpass_rxmacro 0>;
> + };
'co'dec < 'cp'u
[...]
> + vreg_misc_3p3: regulator-misc-3p3 {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "VREG_MISC_3P3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&pm8550ve_8_gpios 6 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&misc_3p3_reg_en>;
property-n
property-names
in this order, please
[...]
> +&iris {
> + status = "okay";
> + firmware-name = "qcom/x1e80100/HONOR/MRO-XXX/qcvss8380.mbn";
status should be the last property, and it would be neat to keep a \n before it
[...]
> +&mdss_dp0_out {
> + data-lanes = <0 1>;
If you change this to <0 1 2 3>, you should get 4-lane DP working
[...]
> + eusb5_reset_n: eusb5-reset-n-state {
> + pins = "gpio7";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + output-low;
> + };
> +
> + eusb6_reset_n: eusb6-reset-n-state {
> + pins = "gpio184";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + output-low;
> + };
drop the output-foo properties from these two, they are controlled
by the driver
[...]
> + wcd_default: wcd-reset-n-active-state {
> + pins = "gpio191";
> + function = "gpio";
> + drive-strength = <16>;
> + bias-disable;
> + output-low;
ditto
[...]
> +/* usb1 covers left side typec ports */
> +/* back (towards the display) typec port */
This is already described in a comment near pmic-glink {}
[...]
> +/* MP0 goes to the USB-A port(USB3) and FPC */
"MP0" refers to the first USB3+USB2 port on the multiport controller.
Is there a hub inbetween? Should we describe it? Do we know if VBUS on
the USB-A port is controllable?
[...]
> +&usb_2_hsphy {
"usb_2" < "usb_mp"
> + vdd-supply = <&vreg_l3j_0p8>;
> + vdda12-supply = <&vreg_l2j_1p2>;
> + phys = <&eusb5_repeater>;
> + status = "okay";
Let's keep an \n before status
Konrad
^ permalink raw reply
* Re: [PATCH 0/3] arm64: dts: qcom: monaco: Enable SDHCI storage support
From: Monish Chunara @ 2026-06-16 12:32 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: andersson, konradybcio, robh, krzk+dt, conor+dt, mani,
linux-arm-msm, devicetree, linux-kernel, sarthak.garg,
pradeep.pragallapati, nitin.rawat
In-Reply-To: <4gg2xq7mdx7bni2acicavtq3ogwupe4ok6tehh7rmjarldwb3x@j3cgohnd764i>
On Thu, Mar 05, 2026 at 06:51:09AM +0200, Dmitry Baryshkov wrote:
> On Mon, Mar 02, 2026 at 08:35:06PM +0530, Monish Chunara wrote:
> > On Mon, Mar 02, 2026 at 04:47:41PM +0200, Dmitry Baryshkov wrote:
> > > On Mon, Mar 02, 2026 at 08:07:23PM +0530, Monish Chunara wrote:
> > > > On Fri, Feb 27, 2026 at 10:05:32PM +0200, Dmitry Baryshkov wrote:
> > > > > On Fri, Feb 27, 2026 at 04:20:52PM +0530, Monish Chunara wrote:
> > > > > > This series enables SDHCI storage support for both SD Card and eMMC on the
> > > > > > Qualcomm Monaco EVK platform.
> > > > > >
> > > > > > The Monaco SoC shares the SDHCI controller between SD Card and eMMC use
> > > > > > cases. Previously, the common SoC dtsi unconditionally enabled the
> > > > > > 'supports-cqe' property. This causes regression for SD cards, resulting
> > > > > > in timeouts and initialization failures during the probe sequence, as
> > > > > > the driver attempts to enable Command Queueing (CQE) logic incompatible
> > > > > > with the SD protocol.
> > > > > >
> > > > > > To resolve this and enable full storage support, this series:
> > > > > >
> > > > > > 1. Moves the 'supports-cqe' property out of the common SoC dtsi. It is
> > > > > > now only enabled in the specific eMMC configuration where it is
> > > > > > supported.
> > > > > > 2. Adds a device tree overlay to enable SD Card support (SDR/DDR modes).
> > > > > > 3. Adds a device tree overlay to enable eMMC support. This configuration
> > > > > > also explicitly disables the UFS controller to prevent power leakage,
> > > > > > as the VCC regulator is shared between the UFS and eMMC rails on this
> > > > > > platform.
> > > > > >
> > > > > > Validated on Qualcomm Monaco EVK with both SD Card and eMMC modules.
> > > > > >
> > > > > > Monish Chunara (3):
> > > > > > arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT
> > > > > > arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
> > > > > > arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay
> > > > >
> > > > > You are adding two overlays. But what does it mean? Does EVK has no uSD
> > > > > / eMMC at all, having both attachable via some kind of mezzanine? Is one
> > > > > of them attachable? Or are both cases present onboard with the correct
> > > > > one being selected by the DIP switch?
> > > > >
> > > >
> > > > The monaco EVK has both storage devices present onboard and the desired one is
> > > > selected via a DIP switch. The overlay selection logic would be based on a
> > > > fitImage metadata entry that gets populated at UEFI level by determining the
> > > > currently selected storage device (eMMC/SD) on the device.
> > > >
> > > > Hence, this approach becomes robust to enable the user for using either of the
> > > > two mediums, without any additional requirement of reflashing any images.
> > >
> > > You are answering a different question :-)
> > >
> > > Let me formulate my question as a review comment:
> > > - identify the default DIP switch position
> > > - squash corresponding dtso into the dts
> > > - leave only the default dts and non-default dtso to be applied by UEFI
> > > if necessary.
> > >
> >
> > Thanks for clarifying.
> >
> > Default switch position is on eMMC on Monaco EVK. But as mentioned in the other
> > thread, there are a few boolean (flag) properties like 'no-sd', that conflicts
> > with SD card use case and cannot be deleted in an overlay file as
> > /delete-property/ cannot be used. Also cd-gpio and regulators used for SD card
> > would be redundant for eMMC.
> >
> > And similarly 'no-mmc' added by default would be inappropriate for eMMC. This
> > being the reason, two separate overlays were added.
>
> This only means one thing to me: UEFI mechanism needs to be changed from
> applying the dtso into directly modifying the FDT in the DT_FIXUP protocol.
>
> There are three options which needs to be removed this way:
> - supported-cqe
> - non-removable
> - no-sd
>
As per latest discussions and the approach finalized, will be updated in the V2
series, such that the default scenario is honoured and no-sd-no-emmc case is
also avoided.
Thanks for the detailed discussion and suggestions.
Thanks and Regards,
Monish
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
From: Monish Chunara @ 2026-06-16 12:30 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Dmitry Baryshkov, andersson, konradybcio, robh, krzk+dt, conor+dt,
mani, linux-arm-msm, devicetree, linux-kernel, sarthak.garg,
pradeep.pragallapati, nitin.rawat
In-Reply-To: <3aaf273a-c7da-4740-a68a-49f5d2f5309f@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 03:15:09PM +0100, Konrad Dybcio wrote:
> On 3/2/26 3:24 PM, Monish Chunara wrote:
> > On Fri, Feb 27, 2026 at 10:03:10PM +0200, Dmitry Baryshkov wrote:
> >> On Fri, Feb 27, 2026 at 04:20:54PM +0530, Monish Chunara wrote:
> >>> The monaco EVK board supports either eMMC or SD-card, but only one
> >>> can be active at a time.
> >>>
> >>> Enable the SD Host Controller Interface (SDHCI) on the monaco EVK board
> >>> to support SD Card for storage via a device tree overlay. This allows
> >>> eMMC support to be enabled through a separate overlay when required.
> >>>
> >>> Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
> >>> ---
> >>> arch/arm64/boot/dts/qcom/Makefile | 4 ++
> >>> .../boot/dts/qcom/monaco-evk-sd-card.dtso | 72 +++++++++++++++++++
> >>> 2 files changed, 76 insertions(+)
> >>> create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> >>> index 317af937d038..c86242a1631d 100644
> >>> --- a/arch/arm64/boot/dts/qcom/Makefile
> >>> +++ b/arch/arm64/boot/dts/qcom/Makefile
> >>> @@ -46,6 +46,10 @@ lemans-evk-el2-dtbs := lemans-evk.dtb lemans-el2.dtbo
> >>> dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-el2.dtb
> >>> dtb-$(CONFIG_ARCH_QCOM) += milos-fairphone-fp6.dtb
> >>> dtb-$(CONFIG_ARCH_QCOM) += monaco-evk.dtb
> >>> +
> >>> +monaco-evk-sd-card-dtbs := monaco-evk.dtb monaco-evk-sd-card.dtbo
> >>> +dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-sd-card.dtb
> >>> +
> >>> dtb-$(CONFIG_ARCH_QCOM) += msm8216-samsung-fortuna3g.dtb
> >>> dtb-$(CONFIG_ARCH_QCOM) += msm8916-acer-a1-724.dtb
> >>> dtb-$(CONFIG_ARCH_QCOM) += msm8916-alcatel-idol347.dtb
> >>> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
> >>> new file mode 100644
> >>> index 000000000000..a0bc5c47d40b
> >>> --- /dev/null
> >>> +++ b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
> >>> @@ -0,0 +1,72 @@
> >>> +// SPDX-License-Identifier: BSD-3-Clause
> >>> +/*
> >>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> >>> + */
> >>> +
> >>> +/dts-v1/;
> >>> +/plugin/;
> >>> +
> >>> +#include <dt-bindings/gpio/gpio.h>
> >>> +
> >>> +/ {
> >>> + vmmc_sdc: regulator-dummy {
> >>
> >> No dummy regulators, please.
> >
> > ACK, these will be renamed as per the schematic. Since these are direct supplies
> > on hardware, used fixed-regulator configuration.
> >
> >>
> >>> + compatible = "regulator-fixed";
> >>> +
> >>> + regulator-name = "vmmc_sdc";
> >>> + regulator-min-microvolt = <2950000>;
> >>> + regulator-max-microvolt = <2950000>;
> >>> + };
> >>> +
> >>> + vreg_sdc: regulator-sdc {
> >>> + compatible = "regulator-gpio";
> >>> +
> >>> + regulator-name = "vreg_sdc";
> >>> + regulator-type = "voltage";
> >>> + regulator-min-microvolt = <1800000>;
> >>> + regulator-max-microvolt = <2950000>;
> >>> +
> >>> + gpios = <&expander1 7 GPIO_ACTIVE_HIGH>;
> >>> + states = <1800000 1>, <2950000 0>;
> >>> +
> >>> + startup-delay-us = <100>;
> >>> + };
> >>> +};
> >>> +
> >>> +&sdhc_1 {
> >>> + vmmc-supply = <&vmmc_sdc>;
> >>> + vqmmc-supply = <&vreg_sdc>;
> >>> +
> >>> + pinctrl-0 = <&sdc1_state_on>, <&sd_cd>;
> >>> + pinctrl-1 = <&sdc1_state_off>, <&sd_cd>;
> >>> + pinctrl-names = "default", "sleep";
> >>> +
> >>> + cap-sd-highspeed;
> >>> + no-1-8-v;
> >>> +
> >>> + bus-width = <4>;
> >>> + cd-gpios = <&tlmm 11 GPIO_ACTIVE_LOW>;
> >>> + no-mmc;
> >>> + no-sdio;
> >>> +
> >>> + status = "okay";
> >>> +};
> >>> +
> >>> +&sdhc1_opp_table {
> >>
> >> Why? Is it specific to the device or to the chip? In the latter case,
> >> please define a separate table in the monaco.dtsi and switch to it here.
> >>
> >
> > As per the previous review, it was suggested to use an existing table. But yes,
> > this is specific to the Host controller and the corresponding voltage corners on
> > the chip and can be defined as a separate entity for SD card use-case.
>
> The SDC programming guide I have access to does not seem to have bene
> updated for any recent chips. Are you sure these different corners are
> *actually* valid? The clock-side documentation doesn't mention that
>
There seems a gap in the clock documentation. This is being communicated to the
corresponding stakeholders. However, the corners mentioned are as per the
reference platform and will be updated in the subsequent series based on the
updates from the clock-plan PoC as required.
Regards,
Monish
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: soc: qcom: Document CDSP Power Management
From: Konrad Dybcio @ 2026-06-16 12:27 UTC (permalink / raw)
To: Vignesh Viswanathan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <8d9f78d2-d414-4ffb-bdf2-e2e7bda73aaf@oss.qualcomm.com>
On 5/26/26 9:38 AM, Vignesh Viswanathan wrote:
>
>
> On 5/20/2026 3:29 PM, Konrad Dybcio wrote:
>> On 5/19/26 9:05 PM, Vignesh Viswanathan wrote:
>>> Add documentation for the CDSP Power Management driver, which handles
>>> Dynamic Clock and Voltage Scaling (DCVS) requests via SMEM, manages Low
>>> Power Mode (LPM) transitions via MPM handshake, and provides virtual
>>> regulators for the remoteproc driver to control CDSP power rails.
>>>
>>> Signed-off-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com>
>>> ---
[...]
>> MPM is a top-level peripheral, but this is a slice dedicated to the
>> CDSP so maybe it'd pass, but..
>>
>>> + <0x0 0x26018018 0x0 0x4>;
>>
>> This is a single random register within the CDSP's register space, so
>> we should definitely be able to describe this better..
>
> Will document this more clearly in the next version.
By "describe" I meant "represent in DTS" - it may be that we need to expose
a syscon or something similar
Konrad
^ permalink raw reply
* Re: [PATCH v2 3/4] arm64: dts: qcom: x1-dell-thena: mark l12b and l15b always-on
From: Konrad Dybcio @ 2026-06-16 12:22 UTC (permalink / raw)
To: Michael Scott, linux-arm-msm
Cc: vkoul, neil.armstrong, dmitry.baryshkov, wesley.cheng, abelvesa,
faisal.hassan, linux-phy, andersson, konradybcio, robh, krzk+dt,
conor+dt, devicetree, val, bryan.odonoghue, laurentiu.tudor1,
alex.vinarskis, linux-kernel, stable
In-Reply-To: <20260521010935.1333494-4-mike.scott@oss.qualcomm.com>
On 5/21/26 3:09 AM, Michael Scott wrote:
> The l12b and l15b supplies are used by components that are not (fully)
> described (and some never will be) and must never be disabled.
>
> Mark the regulators as always-on to prevent them from being disabled,
> for example, when consumers probe defer or suspend.
>
> Note that these supplies currently have no consumers described in
> mainline for dell-thena beyond the audio codec (vdd-buck/vdd-rxtx/
> vdd-io on wcd938x), which can release them when the codec goes idle.
> The board-level gpio-fixed regulators that feed the Type-C retimer's
> VDDIO and other rails are not described with a vin-supply link, so
> the kernel cannot keep their parent LDOs alive on its own.
>
> This mirrors the same change Johan Hovold applied to every other
> X1E80100 board in a March 2025 series; commit 63169c07d740
> ("arm64: dts: qcom: x1e80100-dell-xps13-9345: mark l12b and l15b always-on")
> is representative. The dell-thena board file was introduced four months
> later and did not inherit that change; this patch closes the gap.
>
> Fixes: e7733b42111c ("arm64: dts: qcom: Add support for Dell Inspiron 7441 / Latitude 7455")
> Cc: stable@vger.kernel.org
> Signed-off-by: Michael Scott <mike.scott@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH RESEND] dt-bindings: remoteproc: qcom,sm8550-pas: Add Qualcomm Maili ADSP and CDSP
From: Konrad Dybcio @ 2026-06-16 12:19 UTC (permalink / raw)
To: Yijie Yang, Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20260615-remoteproc-v1-1-67721b4b052a@oss.qualcomm.com>
On 6/15/26 10:30 AM, Yijie Yang wrote:
> Document compatible strings for the ADSP and CDSP Peripheral Authentication
> Services on the Qualcomm Maili SoC. Both are compatible with the Qualcomm
> SM8550 PAS and can fallback to SM8550 except for one additional interrupt
> ("shutdown-ack"). For CDSP, similar to Kaanapali, "global_sync_mem" is
> not managed by the kernel.
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v7 3/5] iio: adc: versal-sysmon: add I2C driver
From: Erim, Salih @ 2026-06-16 12:17 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <ajD_MMpiVQIwtbV3@ashevche-desk.local>
Hi Andy,
On 16/06/2026 08:45, Andy Shevchenko wrote:
> On Mon, Jun 15, 2026 at 04:42:43PM +0100, Erim, Salih wrote:
>> On 15/06/2026 15:30, Andy Shevchenko wrote:
>>> On Mon, Jun 15, 2026 at 12:37:20AM +0100, Salih Erim wrote:
>
> ...
>
>>>> +static const struct regmap_config sysmon_i2c_regmap_config = {
>>>> + .reg_bits = 32,
>>>> + .val_bits = 32,
>>>> + .reg_stride = SYSMON_REG_STRIDE,
>>>> + .max_register = SYSMON_MAX_REG,
>>>> + .reg_read = sysmon_i2c_reg_read,
>>>> + .reg_write = sysmon_i2c_reg_write,
>>>> +};
>>>
>>> No cache?
>>
>> No, the registers are live ADC readings and interrupt status.
>> Caching would return stale voltage and temperature data.
>
> So, basically what you are saying is this:
> "All registers are volatile in this HW."
> Or alternatively:
> "Almost all registers are volatile in this HW. The rest is not being accessed
> too often to cache."
>
> Choose the one that fits and add on top of this regmap_config initialiser.
The second one fits. Will add a comment in v8:
/*
* Almost all registers are volatile (live ADC readings, interrupt
* status). The rest are not accessed often enough to benefit from
* caching.
*/
Thanks,
Salih
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox