* Re: [PATCH 6/9] nvmem: imx-ocotp-ele: Support the ELE API
From: sashiko-bot @ 2026-06-16 12:04 UTC (permalink / raw)
To: Frieder Schrempf; +Cc: robh, devicetree, Frank.Li, conor+dt, imx
In-Reply-To: <20260616-upstreaming-next-20260609-imx-ocotp-ele-v1-6-cb7f3698c3e6@kontron.de>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The dynamically allocated read buffer `p` is leaked when `imx_se_read_fuse()` returns an error in `imx_ocotp_reg_read()`.
- [High] Lack of unbind protection for the supplier Secure Enclave (`se_dev`) device leads to a potential Use-After-Free of its cached private data.
--
commit ce01a1e44e5619e1342b66aca8b1bf267d01e93e
Author: Frieder Schrempf <frieder.schrempf@kontron.de>
nvmem: imx-ocotp-ele: Support the ELE API
The fuses inside the Edgelock Secure Enclave are currently not accessed via
its API but through the FSB block which provides limited access to some
fuses. The ELE API allows us to access all fuses with read/write
permissions.
> diff --git a/drivers/nvmem/imx-ocotp-ele.c b/drivers/nvmem/imx-ocotp-ele.c
> index 9d3f94e35508f..92cc061b9b347 100644
> --- a/drivers/nvmem/imx-ocotp-ele.c
> +++ b/drivers/nvmem/imx-ocotp-ele.c
[ ... ]
> @@ -92,6 +97,19 @@ static int imx_ocotp_reg_read(void *context, unsigned int offset, void *val, siz
> buf = p;
>
> for (i = index; i < (index + count); i++) {
> + /*
> + * All fuse registers can be read via ELE. If the SE device is
> + * available, always prefer it.
> + */
> + if (priv->se_data) {
> + ret = imx_se_read_fuse(priv->se_data, i, buf++);
> + if (ret) {
> + mutex_unlock(&priv->lock);
> + return ret;
[Severity: High]
Does this error path leak the memory allocated for p earlier in the function?
The allocation happens here:
p = kzalloc(num_bytes, GFP_KERNEL);
if (!p)
return -ENOMEM;
Returning directly here will bypass the kfree(p) at the end of the function.
> + }
> + continue;
> + }
> +
[ ... ]
> @@ -152,16 +203,36 @@ static int imx_ele_ocotp_probe(struct platform_device *pdev)
> if (IS_ERR(priv->base))
> return PTR_ERR(priv->base);
>
> + np = of_parse_phandle(pdev->dev.of_node, "secure-enclave", 0);
> + if (!np) {
> + dev_info(&pdev->dev, "missing or invalid SE handle, using readonly FSB\n");
> + } else {
> + priv->se_dev = of_find_device_by_node(np);
> + of_node_put(np);
> + if (!priv->se_dev)
> + return dev_err_probe(&pdev->dev, -ENODEV, "failed to find SE device\n");
> +
> + ret = devm_add_action_or_reset(&pdev->dev, imx_ocotp_put_se_dev,
> + priv->se_dev);
> + if (ret)
> + return ret;
> +
> + priv->se_data = platform_get_drvdata(priv->se_dev);
[Severity: High]
Is there anything preventing the SE driver from being unbound via sysfs after we
cache its private data in priv->se_data here?
If the SE driver is unbound, its devres allocations (which likely include the
se_data) would be freed. Since we haven't established a device link
(e.g. using device_link_add) to enforce unbind ordering, we might be left
with a dangling pointer in priv->se_data.
Could this result in a use-after-free when imx_ocotp_reg_read() or
imx_ocotp_reg_write() later attempts to dereference priv->se_data?
> + if (!priv->se_data)
> + return dev_err_probe(&pdev->dev, -EPROBE_DEFER,
> + "SE device not ready\n");
> + }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-upstreaming-next-20260609-imx-ocotp-ele-v1-0-cb7f3698c3e6@kontron.de?part=6
^ permalink raw reply
* Re: [PATCH 3/9] firmware: imx: ele: Add API functions for OCOTP fuse access
From: sashiko-bot @ 2026-06-16 12:06 UTC (permalink / raw)
To: Frieder Schrempf; +Cc: conor+dt, devicetree, robh, Frank.Li, imx
In-Reply-To: <20260616-upstreaming-next-20260609-imx-ocotp-ele-v1-3-cb7f3698c3e6@kontron.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] A timeout or interrupt during `ele_msg_send_rcv()` leaves a dangling pointer in the asynchronous mailbox callback state (`priv->waiting_rsp_clbk_hdl`), leading to a NULL pointer dereference and a Use-After-Free heap corruption upon a late firmware response.
--
commit d740730d233516ecbc0d56af8b1a5f692696bbf0
Author: Frieder Schrempf <frieder.schrempf@kontron.de>
firmware: imx: ele: Add API functions for OCOTP fuse access
This commit adds the ele_read_fuse() and ele_write_fuse() functions to the
ELE S400 API to provide read and write access to OCOTP fuse registers. These
are exposed via imx_se_read_fuse() and imx_se_write_fuse() for use by drivers
such as the OCOTP S400 NVMEM driver.
> diff --git a/drivers/firmware/imx/ele_base_msg.c b/drivers/firmware/imx/ele_base_msg.c
> index ec718d322abcd..281d223aa1447 100644
> --- a/drivers/firmware/imx/ele_base_msg.c
> +++ b/drivers/firmware/imx/ele_base_msg.c
[ ... ]
> @@ -303,3 +304,124 @@ int ele_debug_dump(struct se_if_priv *priv)
>
> return ret;
> }
> +
> +static int ele_read_fuse(struct se_if_priv *priv, uint16_t fuse_id, u32 *value)
> +{
> + struct se_api_msg *tx_msg __free(kfree) = NULL;
> + struct se_api_msg *rx_msg __free(kfree) = NULL;
> + int rx_msg_sz = ELE_READ_FUSE_RSP_MSG_SZ;
> + int ret = 0;
[ ... ]
> + tx_msg->data[0] = fuse_id;
> +
> + ret = ele_msg_send_rcv(priv->priv_dev_ctx, tx_msg,
> + ELE_READ_FUSE_REQ_MSG_SZ, rx_msg, rx_msg_sz);
> + if (ret < 0)
> + return ret;
[Severity: High]
This is a pre-existing issue, but will a late firmware response cause a
use-after-free here if ele_msg_send_rcv() times out or is interrupted?
If ele_msg_send_rcv() returns an error, it clears the dev_ctx but leaves the
dangling rx_msg pointer in the shared callback handle:
drivers/firmware/imx/ele_common.c:ele_msg_send_rcv() {
...
if (priv->waiting_rsp_clbk_hdl.signal_rcvd) {
err = -EINTR;
priv->waiting_rsp_clbk_hdl.signal_rcvd = false;
}
priv->waiting_rsp_clbk_hdl.dev_ctx = NULL;
return err;
}
Because rx_msg is managed with __free(kfree), it is immediately freed when
ele_read_fuse() returns on this error path.
If a late response arrives afterwards, se_if_rx_callback() will process it.
It first causes a NULL pointer dereference if dynamic debug is enabled:
drivers/firmware/imx/ele_common.c:se_if_rx_callback() {
...
dev_dbg(dev, "Selecting resp waiter:%s ...",
se_clbk_hdl->dev_ctx->devname);
Then it unconditionally copies the response into the freed rx_msg buffer:
...
memcpy(se_clbk_hdl->rx_msg, msg, se_clbk_hdl->rx_msg_sz);
}
Does waiting_rsp_clbk_hdl need to be fully cleared (including setting rx_msg
and rx_msg_sz to zero) on error paths in ele_msg_send_rcv() to prevent this
memory corruption?
> +
> + ret = se_val_rsp_hdr_n_status(priv, rx_msg, ELE_READ_FUSE_REQ,
> + rx_msg_sz, true);
> + if (ret)
> + return ret;
> +
> + *value = rx_msg->data[1];
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-upstreaming-next-20260609-imx-ocotp-ele-v1-0-cb7f3698c3e6@kontron.de?part=3
^ permalink raw reply
* Re: [PATCH 7/9] nvmem: imx-ocotp-ele: Remove the FUSE_ELE type
From: sashiko-bot @ 2026-06-16 12:06 UTC (permalink / raw)
To: Frieder Schrempf; +Cc: robh, devicetree, conor+dt, Frank.Li, imx
In-Reply-To: <20260616-upstreaming-next-20260609-imx-ocotp-ele-v1-7-cb7f3698c3e6@kontron.de>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [Critical] ele_msg_send_rcv() fails to clear waiting_rsp_clbk_hdl.rx_msg on error/timeout paths, leading to heap corruption and NULL pointer dereference by the mailbox callback.
- [High] Missing kfree() on the error path in imx_ocotp_reg_read() causes a memory leak of the dynamically allocated read buffer.
- [High] Missing device link between the OCOTP driver and the Secure Enclave (SE) device creates a Use-After-Free risk for priv->se_data.
--
commit 59602650186437e4e8ff55bf4112fcec530ec2ab
Author: Frieder Schrempf <frieder.schrempf@kontron.de>
nvmem: imx-ocotp-ele: Remove the FUSE_ELE type
There is no use in tracking the fuses that are only accessible via
ELE API and the current lists are incomplete. If the ELE API is
available it will be used as primary access method anyway, otherwise
the fuses not listed as accessible through the FSB can be considered
invalid.
> diff --git a/drivers/nvmem/imx-ocotp-ele.c b/drivers/nvmem/imx-ocotp-ele.c
> index 92cc061b9b347..3d6fad149ed5d 100644
> --- a/drivers/nvmem/imx-ocotp-ele.c
> +++ b/drivers/nvmem/imx-ocotp-ele.c
[ ... ]
> @@ -111,7 +110,7 @@ static int imx_ocotp_reg_read(void *context, unsigned int offset, void *val, siz
> }
>
> type = imx_ocotp_fuse_type(context, i);
> - if (type == FUSE_INVALID || type == FUSE_ELE) {
> + if (type == FUSE_INVALID) {
[Severity: High]
This isn't a bug introduced by this patch, but looking at the earlier
part of imx_ocotp_reg_read() where the SE device is checked:
if (priv->se_data) {
ret = imx_se_read_fuse(priv->se_data, i, buf++);
if (ret) {
mutex_unlock(&priv->lock);
return ret;
}
Does this error path leak the dynamically allocated read buffer 'p'?
The function returns immediately without calling kfree(p). This could
allow repeated failing reads, such as from nvmem sysfs, to cause memory
exhaustion.
[ ... ]
[Severity: High]
This is a pre-existing issue, but looking at imx_ele_ocotp_probe() in
drivers/nvmem/imx-ocotp-ele.c:
priv->se_data = platform_get_drvdata(priv->se_dev);
if (!priv->se_data)
return dev_err_probe(&pdev->dev, -EPROBE_DEFER,
"SE device not ready\n");
Is there a use-after-free risk here due to the missing device link?
The driver caches the SE device's driver data locally as priv->se_data
without establishing a device link (e.g., using device_link_add()).
If the Secure Enclave driver unbinds independently, its private data is
freed. Because this driver remains active, could it pass the dangling
priv->se_data pointer to imx_se_read_fuse() during a subsequent read
or write?
[Severity: Critical]
This is a pre-existing issue, but looking at ele_msg_send_rcv() in
drivers/firmware/imx/ele_common.c:
err = ele_msg_send(dev_ctx, tx_msg, tx_msg_sz);
if (err < 0)
return err;
Could this error path leave a dangling pointer in the global state?
The function returns without clearing priv->waiting_rsp_clbk_hdl.rx_msg
or dev_ctx.
If a spurious response arrives later, se_if_rx_callback() copies data
into the freed rx_msg via memcpy(), which could cause heap corruption:
dev_dbg(dev, "Selecting resp waiter:%s for mesg header:0x%x.",
se_clbk_hdl->dev_ctx->devname, *(u32 *)header);
...
memcpy(se_clbk_hdl->rx_msg, msg, se_clbk_hdl->rx_msg_sz);
Additionally, if the message times out, dev_ctx is set to NULL but
rx_msg is not.
Would a delayed response crash in se_if_rx_callback() by dereferencing
se_clbk_hdl->dev_ctx->devname without checking if dev_ctx is NULL?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-upstreaming-next-20260609-imx-ocotp-ele-v1-0-cb7f3698c3e6@kontron.de?part=7
^ permalink raw reply
* Re: [PATCH v4 3/3] arm64: dts: qcom: Add Vicharak Axon Mini
From: Konrad Dybcio @ 2026-06-16 12:10 UTC (permalink / raw)
To: Ajit Singh
Cc: Bjorn Andersson, Bartosz Golaszewski, Dmitry Baryshkov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <aiuGjH4qeOIXXgqq@page.local>
On 6/12/26 6:16 AM, Ajit Singh wrote:
> On Wed, Jun 10, 2026 at 02:58:19PM +0530, Konrad Dybcio wrote:
>> On 6/7/26 1:36 PM, Ajit Singh wrote:
>>> Add DTS for the Vicharak Axon Mini board based on the Qualcomm
>>> QCS6490 SoC.
>>>
>>> This adds debug UART, eMMC, UFS, SDIO WLAN, USB 2.0 host, PCIe
>>> support along with regulators.
>>>
>>> The UFS ICE block is kept disabled because enabling it currently causes
>>> an SError during qcom_ice_create() on this board. UFS works without ICE.
>>>
>>> Signed-off-by: Ajit Singh <blfizzyy@gmail.com>
>>> ---
>>
>> [...]
>>
>>> + vreg_l12c_1p8: ldo12 {
>>> + regulator-name = "vreg_l12c_1p8";
>>> + regulator-min-microvolt = <1800000>;
>>> + regulator-max-microvolt = <2000000>;
>>> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
>>> +
>>> + /*
>>> + * VREG_L12C_1P8 supplies the Ampak WLAN/BT module
>>> + * VDDIO and the external 32.768 kHz oscillator.
>>> + */
>>
>> Sorry for the long review timelines on the previous patch, many of us
>> were out for conferences..
>>
>> Is the oscillator used for that WLAN module? Would you ideally like to
>> be able to turn it on/off?
>
> yes, oscillator is used for WLAN modules. Oscillator is powered from the same
> VREG_L12C rail as WLAN VDDIO, so there is no separate regulator control to put
> in pwrseq. So I think this will work fine?
Probably? My point is that you marked it as always-on, so it will *never*
turn off right now. For e.g. Qualcomm wifi, there's some timing spec that
needs to be met wrt delays between toggling various regulators and GPIOs
going to the module, hence I suggested you may need some pwrseq inbetween
to achieve reliable powering on/off
Konrad
^ permalink raw reply
* Re: [PATCH v7 2/5] iio: adc: add Versal SysMon driver
From: Erim, Salih @ 2026-06-16 12:12 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-iS3nANaXOZty@ashevche-desk.local>
Hi Andy,
On 16/06/2026 08:43, Andy Shevchenko wrote:
> On Mon, Jun 15, 2026 at 04:41:12PM +0100, Erim, Salih wrote:
>> On 15/06/2026 15:22, Andy Shevchenko wrote:
>>> On Mon, Jun 15, 2026 at 12:37:19AM +0100, Salih Erim wrote:
>
> ...
>
>>>> +/**
>>>> + * sysmon_core_probe() - Initialize Versal SysMon core
>>>
>>> It is managed, please name it accordingly: devm_sysmon_core_probe().
>>
>> Will rename to devm_sysmon_core_probe() and update callers.
>
> I believe you also want to have a proper namespace. The sysmon is to broad.
>
> The easiest solution is to name it as devm_versal_sysmon_core_probe().
Agreed, will use devm_versal_sysmon_core_probe() in v8.
Thanks,
Salih
>
>>>> + * @dev: Parent device
>>>> + * @regmap: Register map for hardware access
>>>> + *
>>>> + * Return: 0 on success, negative errno on failure.
>>>> + */
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ 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
* 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 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 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 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 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 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 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 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 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 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 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
* [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
* [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 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 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 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
* 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 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
* [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
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