* Re: [PATCH 04/12] clk: qcom: gcc-mdm9607: Fix BIMC PLL definition
From: Konrad Dybcio @ 2026-06-16 10:52 UTC (permalink / raw)
To: Stephan Gerhold, Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Georgi Djakov,
Shawn Guo, Bryan O'Donoghue, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <aimlsgJssczxBGhQ@linaro.org>
On 6/10/26 7:58 PM, Stephan Gerhold wrote:
> On Wed, Jun 10, 2026 at 10:43:12PM +0530, Taniya Das wrote:
>> On 6/9/2026 7:44 PM, Stephan Gerhold wrote:
>>> The gcc-mdm9607 driver was originally based on gcc-msm8916, but a closer
>>> match nowadays is gcc-msm8909. Looking at the differences between
>>> gcc-mdm9607 and gcc-msm8909, there is quite some confusion around the
>>> definitions for the BIMC PLL.
>>>
>>> It turns out the BIMC PLL on MDM9607 is actually an Alpha PLL just like on
>>> MSM8909. We can vote for it using BIT(2), which explains why BIT(3) was
>>> used for GPLL2.
>>
>> BIMC PLL is never controlled from High Level OS (APSS). These are
>> controlled by other subsystems and voting should be via the ICC for BW
>> requirements.
>>
>
> The driver doesn't really control the BIMC PLL here, the PLL is defined
> with fixed/shared/read-only ops so it mostly just exists to model the
> clock tree properly and have the clock rate readable for the PLL itself
> and any downstream consumers.
>
> There are multiple drivers that do it like this (e.g. gcc-msm8916,
> gcc-msm8939), is there a reason why we should drop this?
My fear is that the kernel may have stale data at any point.. perhaps
unless we set CLK_GET_RATE_NOCACHE?
Konrad
^ permalink raw reply
* Re: [PATCH v3 11/12] iio: dac: ad5686: read_raw/write_raw: use guard(mutex)()
From: Andy Shevchenko @ 2026-06-16 10:52 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: Andy Shevchenko, rodrigo.alencar, Michael Auchter, linux,
linux-iio, devicetree, linux-kernel, linux-hardening,
Michael Hennerich, Jonathan Cameron, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Kees Cook, Gustavo A. R. Silva, Maxwell Doose,
Joshua Crofts
In-Reply-To: <bguen4zngbwsnoxbis7mfrmo6q3vbccpntfzr6bsiog76kdhvp@3lcygxwlg2kv>
On Tue, Jun 16, 2026 at 1:50 PM Rodrigo Alencar
<455.rodrigo.alencar@gmail.com> wrote:
> On 16/06/26 13:43, Andy Shevchenko wrote:
> > On Tue, Jun 16, 2026 at 09:21:17AM +0100, Rodrigo Alencar via B4 Relay wrote:
> >
> > > Use guarded mutex lock to facilitate code review when adding new
> > > attributes. This will allow for early returns, avoiding error-prone
> > > locking and unlocking in error paths. This also adds missing include
> > > linux/cleanup.h. Gain-control support will allow the scale attribute
> > > to be configurable.
> >
> > What about interrupt handler? You just added yet another mutex lock/unlock
> > there. Perhaps this patch should be done before the previous one?
>
> Can't add the guard(mutex)() in the trigger handler because of the goto.
It might need a refactoring then?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 RESEND 2/5] arm64: dts: qcom: Add device tree for Nord SoC series
From: Konrad Dybcio @ 2026-06-16 10:57 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Dmitry Baryshkov, Bartosz Golaszewski, Deepti Jaggi, Harshal Dev,
Herbert Xu, devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20260526051300.1669201-3-shengchao.guo@oss.qualcomm.com>
On 5/26/26 7:12 AM, Shawn Guo wrote:
> Add base device tree include (nord.dtsi) for the Nord SoC series
> describing the core hardware components:
>
> - 18 Oryon (qcom,oryon-1-5) cores in three clusters, with PSCI-based
> power management and CPU/cluster idle states
> - ARM GICv3 interrupt controller with ITS
> - TLMM GPIO/pinctrl controller
> - 8 TSENS thermal sensors with thermal zones
> - 3 APPS SMMU-500 instances
> - 3 QUPv3 GENI SE QUP blocks
> - PDP SCMI channel and mailbox
> - Watchdog, TRNG and TCSR
> - Reserved memory, CMD-DB and firmware SCM
> - PSCI and architected timers
[...]
> + dump_mem: mem-dump-region {
> + alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
off-by-1?
[...]
> + intc: interrupt-controller@17000000 {
> + compatible = "arm,gic-v3";
> + reg = <0x0 0x17000000 0x0 0x10000>, /* GICD */
> + <0x0 0x17080000 0x0 0x480000>; /* GICR * 18 */
Please drop these comments
Otherwise looks alright
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v3 RESEND 2/5] arm64: dts: qcom: Add device tree for Nord SoC series
From: Konrad Dybcio @ 2026-06-16 10:58 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Dmitry Baryshkov, Bartosz Golaszewski, Deepti Jaggi, Harshal Dev,
Herbert Xu, devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20260526051300.1669201-3-shengchao.guo@oss.qualcomm.com>
On 5/26/26 7:12 AM, Shawn Guo wrote:
> Add base device tree include (nord.dtsi) for the Nord SoC series
> describing the core hardware components:
>
> - 18 Oryon (qcom,oryon-1-5) cores in three clusters, with PSCI-based
> power management and CPU/cluster idle states
> - ARM GICv3 interrupt controller with ITS
> - TLMM GPIO/pinctrl controller
> - 8 TSENS thermal sensors with thermal zones
> - 3 APPS SMMU-500 instances
> - 3 QUPv3 GENI SE QUP blocks
> - PDP SCMI channel and mailbox
> - Watchdog, TRNG and TCSR
> - Reserved memory, CMD-DB and firmware SCM
> - PSCI and architected timers
>
> Co-developed-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
[...]
> + pdc: interrupt-controller@b220000 {
> + compatible = "qcom,nord-pdc",
> + "qcom,pdc";
> + reg = <0x0 0x0b220000 0x0 0x10000>;
> + qcom,pdc-ranges = <0 745 43>, <67 543 31>,
> + <98 609 32>, <130 717 12>,
> + <142 251 5>, <147 796 16>;
One triple per line would be neat
Konrad
^ permalink raw reply
* Re: [PATCH v3 RESEND 3/5] arm64: dts: qcom: Add device tree for Nord SA8797P SoC
From: Konrad Dybcio @ 2026-06-16 11:00 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Dmitry Baryshkov, Bartosz Golaszewski, Deepti Jaggi, Harshal Dev,
Herbert Xu, devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20260526051300.1669201-4-shengchao.guo@oss.qualcomm.com>
On 5/26/26 7:12 AM, Shawn Guo wrote:
> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>
> Add SoC-level device tree include for SA8797P, an automotive variant
> of the Nord SoC family. The dtsi covers:
>
> - 64 SCMI shared memory regions reserved at 0xd7600000-0xd763f000
> for SMC-based firmware communication channels
> - Three QUPV3 GENI SE QUP blocks (qupv3_0/1/2) with UART controllers
> using SCMI power and performance domains via scmi11
> - UFS host controller with SCMI power domain via scmi3
>
> Also introduce scmi-common.dtsi providing the firmware-level SCMI
> channel nodes shared across SCMI based SoCs.
"across SoCs with GearVM firmware that utilize SCMI for resource
management"
Is the scmi-common.dtsi actually any common? Are e.g. the interrupt
numbers going to be stable?
Konrad
^ permalink raw reply
* Re: [PATCH v3 11/12] iio: dac: ad5686: read_raw/write_raw: use guard(mutex)()
From: Rodrigo Alencar @ 2026-06-16 11:00 UTC (permalink / raw)
To: Andy Shevchenko, Rodrigo Alencar
Cc: Andy Shevchenko, rodrigo.alencar, Michael Auchter, linux,
linux-iio, devicetree, linux-kernel, linux-hardening,
Michael Hennerich, Jonathan Cameron, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Kees Cook, Gustavo A. R. Silva, Maxwell Doose,
Joshua Crofts
In-Reply-To: <CAHp75VeBE12U6dELhtxnL7ah4WEmAMVk-jq7vky1ynzdp_SAZw@mail.gmail.com>
On 16/06/26 13:52, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 1:50 PM Rodrigo Alencar
> <455.rodrigo.alencar@gmail.com> wrote:
> > On 16/06/26 13:43, Andy Shevchenko wrote:
> > > On Tue, Jun 16, 2026 at 09:21:17AM +0100, Rodrigo Alencar via B4 Relay wrote:
> > >
> > > > Use guarded mutex lock to facilitate code review when adding new
> > > > attributes. This will allow for early returns, avoiding error-prone
> > > > locking and unlocking in error paths. This also adds missing include
> > > > linux/cleanup.h. Gain-control support will allow the scale attribute
> > > > to be configurable.
> > >
> > > What about interrupt handler? You just added yet another mutex lock/unlock
> > > there. Perhaps this patch should be done before the previous one?
> >
> > Can't add the guard(mutex)() in the trigger handler because of the goto.
>
> It might need a refactoring then?
It would deviate from other examples... would either repeat the code in the end
inside an if statement, or wrap most of the function implementation inside
one. I suppose the first option would be better.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v3 RESEND 5/5] arm64: dts: qcom: Add device tree for SA8797P Ride board
From: Konrad Dybcio @ 2026-06-16 11:02 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Dmitry Baryshkov, Bartosz Golaszewski, Deepti Jaggi, Harshal Dev,
Herbert Xu, devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20260526051300.1669201-6-shengchao.guo@oss.qualcomm.com>
On 5/26/26 7:13 AM, Shawn Guo wrote:
> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>
> Add initial device tree for the Qualcomm SA8797P Ride reference board.
>
> - Configure UART15 as the primary console and UART4 as the secondary
> serial port
> - Enable UFS storage support
> - Define thermal zones for PMIC dies, UFS, and two SDRAM sensors,
> all sourced from SCMI sensor protocol on channel 23
>
> Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
[...]
> +&thermal_zones {
> + pm_kobra_thermal: pm-a-die-thermal {
> + polling-delay-passive = <100>;
> + polling-delay = <0>;
0 is the default value, you can drop these lines
[...]
> + pm_kai_0_thermal: pm-e-die-thermal {
s/pm/pmic
> + polling-delay-passive = <100>;
> + polling-delay = <0>;
> + thermal-sensors = <&scmi23_sensor 4>;
> +
> + trips {
> + trip0 {
> + temperature = <115000>;
> + hysteresis = <5000>;
> + type = "passive";
> + };
> +
> + trip1 {
> + temperature = <135000>;
> + hysteresis = <5000>;
> + type = "passive";
> + };
Do we need two passive trip points?
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: hamoa: Fix xbl_tmp_buffer_mem size
From: Konrad Dybcio @ 2026-06-16 11:04 UTC (permalink / raw)
To: Hans de Goede, Bjorn Andersson, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, devicetree
In-Reply-To: <7ebbddb0-175b-4023-91ee-93d23e5162ba@oss.qualcomm.com>
On 5/25/26 2:46 PM, Hans de Goede wrote:
> Hi,
>
> On 25-May-26 14:29, Konrad Dybcio wrote:
>> On 5/25/26 1:47 PM, Hans de Goede wrote:
>>> The EFI memtable (shown when booting with efi=debug) shows that the
>>> xbl_tmp_buffer_mem region size is 0x1c0000 bytes large not 0xc00000 bytes:
>>>
>>> efi: 0x000082800000-0x0000829bffff [Reserved |
>>> efi: 0x0000829c0000-0x000083efffff [Conventional|
>>>
>>> This fix aligns the size with the EFI reported size and makes /proc/iomem
>>> correctly show mem blocks matching the EFI memmap:
>>>
>>> 82800000-829bffff : reserved
>>> 829c0000-83efffff : System RAM
>>>
>>> Instead of:
>>>
>>> 82800000-833fffff : reserved
>>> 83400000-83efffff : System RAM
>>>
>>> before this change
>>>
>>> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/hamoa.dtsi | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>> index de0f2346cb38..5a2e84365901 100644
>>> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>> @@ -582,7 +582,7 @@ tz_stat_mem: tz-stat@82700000 {
>>> };
>>>
>>> xbl_tmp_buffer_mem: xbl-tmp-buffer@82800000 {
>>> - reg = <0x0 0x82800000 0x0 0xc00000>;
>>> + reg = <0x0 0x82800000 0x0 0x1c0000>;
>>
>> FWIW the reference memory map shows a contiguous block of:
>>
>> 0x8280_0000 -> "no reclaim XBL scratch_buffer2"
>> 0x829c_0000 -> "reclaimable XBL scratch_buffer"
>> 0x83f0_0000-0x8400_0000 -> "no reclaim xbl scratch_buffer1"
>
> Thanks, so the first part here 0x8280_0000 - 0x829c_0000
> aligns with the EFI reservation and with the dts reservation
> after my patch.
>
> 0x829c_0000 - 0x83f0_0000 being reclaimable matches with
> both EFI + the dts (old and new with a different start)
> having this as usable RAM.
>
> The 0x83f0_0000-0x8400_0000 area seems to be marked as
> reserved by neither EFI nor the current dts...
>
> With the first part of the reference memory map aligning
> with what EFI shows, I think this patch is correct.
>
> I wonder if we should do anything about the 0x83f0_0000-0x8400_0000
> range though ?
The logs in your commit message suggest the UEFI ahd already taken care
of reserving that bit
Could you post the full output of `memmap` in uefi shell on your device?
Konrad
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: i2c-mux-pinctrl: change maintainer
From: Thierry Reding @ 2026-06-16 11:09 UTC (permalink / raw)
To: Andi Shyti
Cc: Wolfram Sang, linux-i2c, Thierry Reding, Peter Rosin, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <ajBq_yjuV-LeqgpI@zenone.zhora.eu>
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
On Mon, Jun 15, 2026 at 11:15:08PM +0200, Andi Shyti wrote:
> Hi Thierry,
>
> > > maintainers:
> > > - - Wolfram Sang <wsa@kernel.org>
> > > + - Thierry Reding <treding@nvidia.com>
> > >
> > > description: |
> > > This binding describes an I2C bus multiplexer that uses pin multiplexing to route the I2C
> >
> > By default I used to list the subsystem maintainer as the bindings
> > maintainer if the binding wasn't Tegra-specific, or in this case the
> > original author wasn't active anymore.
> >
> > I'm fine being listed as the maintainer for this if you don't want to,
> > but I prefer to use the thierry.reding@kernel.org email address for
> > communication.
>
> Just to be clear, are you saying that in this file you want your
> kernel.org e-mail or are you referring to generic communication?
I prefer the kernel.org e-mail for generic communication. The corporate
one is primarily important but inconvenient for mass-communication on
thi lists.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v5 3/6] iio: osf: add protocol decoding
From: Andy Shevchenko @ 2026-06-16 11:09 UTC (permalink / raw)
To: Jinseob Kim
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260616072242.3942-4-kimjinseob88@gmail.com>
On Tue, Jun 16, 2026 at 04:22:39PM +0900, Jinseob Kim wrote:
> Add helpers for validating and decoding Open Sensor Fusion frames and the
> message payloads used by the initial receive path.
...
> +int osf_protocol_sensor_sample_value(const struct osf_sensor_sample *sample,
> + unsigned int index, s32 *value)
> +{
> + if (!sample || !sample->samples || !value)
> + return -EINVAL;
> +
> + if (index >= sample->channel_count)
> + return -ERANGE;
> +
> + /* Samples are little-endian two's-complement signed values. */
> + *value = (s32)get_unaligned_le32(sample->samples + index * sizeof(s32));
This casting does not add anything.
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: qcs615-ride: fix sdhc_2 vqmmc-supply for UHS-I mode
From: Konrad Dybcio @ 2026-06-16 11:13 UTC (permalink / raw)
To: monish.chunara, andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel, linux-mmc, ulf.hansson,
nitin.rawat, pradeep.pragallapati, komal.bajaj, jsodhapa
In-Reply-To: <20260522105020.3588377-1-mchunara@oss.qualcomm.com>
On 5/22/26 12:50 PM, monish.chunara@oss.qualcomm.com wrote:
> From: Monish Chunara <monish.chunara@oss.qualcomm.com>
>
> SD card is detected as SDHS instead of UHS-I because sdhc_2 was
> configured with vreg_s4a as vqmmc-supply, which cannot switch
> between 1.8V and 3.3V.
>
> Switch vqmmc-supply to vreg_l2a and update its voltage range to
> 1800000-2960000 uV to enable proper UHS-I signaling.
The way the commit message is worded almost makes it sound like
switching the supply in DT rewires the hardware power grid..
anyway
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: i2c-mux-pinctrl: change maintainer
From: Thierry Reding @ 2026-06-16 11:15 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Thierry Reding, Peter Rosin, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <ajDnbQJhfeICowkn@shikoro>
[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]
On Tue, Jun 16, 2026 at 08:04:29AM +0200, Wolfram Sang wrote:
> Hi Thierry,
>
> > By default I used to list the subsystem maintainer as the bindings
> > maintainer if the binding wasn't Tegra-specific, or in this case the
> > original author wasn't active anymore.
>
> I understand that. Yet, since I handed I2C over to Andi now, this entry
> becomes kind of stale then. I wanted to drop the maintainers:-property
> completely to avoid changing all the maintainers entry once a subsystem
> gets handed over, but Rob disagreed to that.
>
> > I'm fine being listed as the maintainer for this if you don't want to,
> > but I prefer to use the thierry.reding@kernel.org email address for
> > communication.
>
> Ok, thank you, will fix.
>
> > With that:
> >
> > Acked-by: Thierry Reding <treding@nvidia.com>
>
> I will use your kernel.org address for the ack then as well, I guess.
It was intended as given, but either way works fine. The corporate email
is primarily important for authorship. On the other hand I'm always the
same person, so at the end of the day it probably doesn't matter all
that much either way.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v5 4/6] iio: osf: add stream parser
From: Andy Shevchenko @ 2026-06-16 11:16 UTC (permalink / raw)
To: Jinseob Kim
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260616072242.3942-5-kimjinseob88@gmail.com>
On Tue, Jun 16, 2026 at 04:22:40PM +0900, Jinseob Kim wrote:
> Add a byte-stream parser that resynchronizes on OSF frame magic, validates
> complete frames, and forwards decoded frames to the OSF core.
...
> +static const u8 osf_stream_magic[OSF_STREAM_MAGIC_LEN] = {
> + 'O', 'S', 'F', '0',
> +};
Why?! You have already a definition, use it instead.
...
> +static size_t osf_stream_discard_to_magic(struct osf_stream *stream)
> +{
> + size_t old_len = stream->len;
> + size_t match_len;
> + size_t i;
> +
> + for (i = 0; i < stream->len; i++) {
In current form it's as simple as
for (size_t i = 0; i < stream->len; i++) {
> + match_len = stream->len - i;
> + if (match_len > OSF_STREAM_MAGIC_LEN)
> + match_len = OSF_STREAM_MAGIC_LEN;
> +
> + if (osf_stream_magic_match(stream->buf + i, match_len)) {
> + if (i)
> + osf_stream_discard(stream, i);
> + return i;
> + }
> + }
> +
> + stream->len = 0;
> + return old_len;
> +}
...
> +static int osf_stream_process(struct osf_stream *stream)
> +{
> + size_t discarded;
> + size_t frame_len;
> + u32 payload_len;
> + int first_err = 0;
> + int ret;
> +
> + while (stream->len) {
> + discarded = osf_stream_discard_to_magic(stream);
> + if (discarded) {
> + stream->stats.bad_magic_resyncs++;
> + stream->stats.dropped_bytes += discarded;
> + if (!first_err)
> + first_err = -EPROTO;
> + }
> +
> + if (!stream->len)
> + break;
> +
> + if (stream->len < OSF_FRAME_HEADER_LEN)
> + break;
> + if (get_unaligned_le16(stream->buf + 6) !=
> + OSF_FRAME_HEADER_LEN) {
Make it a single line for readability.
> + stream->stats.dropped_bytes++;
> + osf_stream_drop_invalid_head(stream);
> + if (!first_err)
> + first_err = -EPROTO;
> + continue;
> + }
> +
> + payload_len = get_unaligned_le32(stream->buf + 10);
> + if (payload_len > OSF_STREAM_MAX_PAYLOAD_LEN) {
> + stream->stats.dropped_bytes++;
> + osf_stream_drop_invalid_head(stream);
> + if (!first_err)
> + first_err = -EMSGSIZE;
> + continue;
> + }
> +
> + frame_len = OSF_FRAME_HEADER_LEN + payload_len + OSF_FRAME_CRC_LEN;
> + if (stream->len < frame_len)
> + break;
> +
> + ret = osf_core_receive_frame(stream->osf, stream->buf, frame_len);
> + if (ret) {
> + if (ret == -EBADMSG) {
> + stream->stats.bad_crc_frames++;
> + stream->stats.dropped_bytes++;
> + osf_stream_drop_invalid_head(stream);
> + } else {
> + osf_stream_discard(stream, frame_len);
> + }
> + if (!first_err)
> + first_err = ret;
> + continue;
> + }
> +
> + stream->stats.valid_frames++;
> + osf_stream_discard(stream, frame_len);
> + }
> + return first_err;
Why do we continue on the error and then still return an error?
Same Q for the receive part.
> +}
...
> +void osf_stream_init(struct osf_stream *stream, struct osf_device *osf)
> +{
> + if (!stream)
> + return;
> +
> + stream->osf = osf;
> + stream->len = 0;
> + memset(&stream->stats, 0, sizeof(stream->stats));
> +}
> +
> +void osf_stream_reset(struct osf_stream *stream)
> +{
> + if (stream) {
> + stream->len = 0;
> + memset(&stream->stats, 0, sizeof(stream->stats));
> + }
As per above
if (!stream)
return;
> +}
...
> +struct osf_stream_stats {
> + u64 valid_frames;
> + u64 bad_magic_resyncs;
> + u64 bad_crc_frames;
> + u64 partial_frames;
> + u64 dropped_bytes;
> +};
Don't you want to use linux/u64_stats_sync.h APIs?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH RFC v5 5/6] iio: osf: add UART transport
From: Andy Shevchenko @ 2026-06-16 11:27 UTC (permalink / raw)
To: Jinseob Kim
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260616072242.3942-6-kimjinseob88@gmail.com>
On Tue, Jun 16, 2026 at 04:22:41PM +0900, Jinseob Kim wrote:
> Add the serdev UART transport and the initial OSF core receive path.
>
> Enable the required vcc regulator with devm_regulator_get_enable()
> before opening the UART, keeping power handling limited to the simple
> probe-time requirement for this RFC.
...
> +config OPEN_SENSOR_FUSION
> + tristate "Open Sensor Fusion UART IIO driver"
> + depends on IIO
> + depends on SERIAL_DEV_BUS
> + select CRC32
> + help
> + Build the Open Sensor Fusion UART receive path.
> +
> + The driver receives OSF protocol frames over a serdev UART.
> + Frames are decoded and validated before being passed to the
> + driver core.
> + This patch only adds the transport path.
> + IIO device registration is added separately.
What is this paragraph supposed to mean?
...
> +static int osf_core_validate_capability_report(const struct osf_frame *frame)
> +{
> + struct osf_capability_entry entry;
> + struct osf_capability_report report;
> + unsigned int i;
> + int ret;
> +
> + ret = osf_protocol_decode_capability_report(frame, &report);
> + if (ret)
> + return ret;
> +
> + for (i = 0; i < report.capability_count; i++) {
for (unsigned int i = 0; i < report.capability_count; i++) {
> + ret = osf_protocol_decode_capability_entry(&report, i, &entry);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
...
> +int osf_core_receive_frame(struct osf_device *osf, const u8 *buf, size_t len)
> +{
> + struct osf_frame frame;
> + size_t frame_len;
> + int ret;
> + if (!osf || !buf)
> + return -EINVAL;
How can this be called with osf == NULL?
> + ret = osf_protocol_decode_frame(buf, len, &frame, &frame_len);
> + if (ret)
> + return ret;
> +
> + if (frame_len != len)
> + return -EMSGSIZE;
> +
> + switch (frame.message_type) {
> + case OSF_MSG_SENSOR_SAMPLE:
> + ret = osf_core_validate_sensor_sample(&frame);
> + break;
> + case OSF_MSG_DEVICE_STATUS:
> + ret = osf_core_validate_device_status(&frame);
> + break;
> + case OSF_MSG_CAPABILITY_REPORT:
> + ret = osf_core_validate_capability_report(&frame);
> + break;
> + default:
> + if (frame.message_type >= OSF_RESERVED_MSG_FIRST &&
> + frame.message_type <= OSF_RESERVED_MSG_LAST)
> + ret = 0;
> + else if (frame.message_type >= OSF_VENDOR_PRIVATE_FIRST)
> + ret = 0;
> + else
> + ret = -EOPNOTSUPP;
> + break;
You may invert this and return directly
if ((frame.message_type < OSF_VENDOR_PRIVATE_FIRST) &&
(frame.message_type < OSF_RESERVED_MSG_FIRST ||
frame.message_type > OSF_RESERVED_MSG_LAST))
return -EOPNOTSUPP;
> + }
> + if (!ret)
> + osf->last_sequence = frame.sequence;
> +
> + return ret;
No. Use regular pattern
if (ret)
return ret;
...
return 0;
> +}
...
> +#include <linux/device.h>
> +#include <linux/errno.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
What is this for?
> +#include <linux/regulator/consumer.h>
> +#include <linux/serdev.h>
> +#include <linux/slab.h>
> +#include <linux/types.h>
> +
> +#include "osf_core.h"
> +#include "osf_stream.h"
> +
> +#define OSF_SERDEV_BAUD 115200
> +
> +struct osf_serdev {
> + struct serdev_device *serdev;
> + struct osf_device osf;
> + struct osf_stream stream;
> +};
> +
> +static size_t osf_serdev_receive_buf(struct serdev_device *serdev,
> + const u8 *buf, size_t count)
> +{
> + struct osf_serdev *osf_uart = serdev_device_get_drvdata(serdev);
> + const struct osf_stream_stats *stats;
> + u64 valid_before;
> + int ret;
> +
> + valid_before = osf_uart->stream.stats.valid_frames;
> + ret = osf_stream_receive_bytes(&osf_uart->stream, buf, count);
> + stats = &osf_uart->stream.stats;
> +
> + if (ret || stats->valid_frames != valid_before)
> + dev_dbg_ratelimited(&serdev->dev,
> + "rx count=%zu valid=%llu bad_magic=%llu bad_crc=%llu partial=%llu dropped=%llu ret=%d\n",
> + count,
> + (unsigned long long)stats->valid_frames,
> + (unsigned long long)stats->bad_magic_resyncs,
> + (unsigned long long)stats->bad_crc_frames,
> + (unsigned long long)stats->partial_frames,
> + (unsigned long long)stats->dropped_bytes,
Why casting?
> + ret);
> +
> + return count;
> +}
...
> +static int osf_serdev_probe(struct serdev_device *serdev)
> +{
struct device *dev = &serdev->dev;
makes the below look better.
> + struct osf_serdev *osf_uart;
> + unsigned int baudrate;
> + int ret;
> +
> + osf_uart = devm_kzalloc(&serdev->dev, sizeof(*osf_uart), GFP_KERNEL);
> + if (!osf_uart)
> + return -ENOMEM;
> +
> + osf_uart->serdev = serdev;
> + osf_core_init(&osf_uart->osf, &serdev->dev);
> + osf_stream_init(&osf_uart->stream, &osf_uart->osf);
> +
> + serdev_device_set_drvdata(serdev, osf_uart);
> + serdev_device_set_client_ops(serdev, &osf_serdev_ops);
> +
> + ret = devm_regulator_get_enable(&serdev->dev, "vcc");
> + if (ret)
> + return dev_err_probe(&serdev->dev, ret,
> + "failed to enable vcc regulator\n");
> +
> + ret = serdev_device_open(serdev);
> + if (ret)
> + return ret;
> +
> + baudrate = serdev_device_set_baudrate(serdev, OSF_SERDEV_BAUD);
> + if (baudrate != OSF_SERDEV_BAUD)
> + dev_warn(&serdev->dev, "requested %u baud, controller set %u\n",
> + OSF_SERDEV_BAUD, baudrate);
> +
> + serdev_device_set_flow_control(serdev, false);
> +
> + return 0;
> +}
> +
> +static void osf_serdev_remove(struct serdev_device *serdev)
> +{
> + struct osf_serdev *osf_uart = serdev_device_get_drvdata(serdev);
> +
> + serdev_device_close(serdev);
> + osf_stream_reset(&osf_uart->stream);
> + osf_core_unregister_iio(&osf_uart->osf);
> +}
...
> +static struct serdev_device_driver osf_serdev_driver = {
> + .probe = osf_serdev_probe,
> + .remove = osf_serdev_remove,
> + .driver = {
> + .name = "open-sensor-fusion-uart",
> + .of_match_table = osf_serdev_of_match,
> + },
> +};
> +
No blank line needed here.
> +module_serdev_device_driver(osf_serdev_driver);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: arm: qcom: Add Lenovo Yoga Slim 7x Gen11
From: Konrad Dybcio @ 2026-06-16 11:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski
Cc: Abel Vesa, rob.clark, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Krzysztof Kozlowski, Conor Dooley,
Douglas Anderson, Bjorn Andersson, Konrad Dybcio, dri-devel,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260612160519.GA1118842-robh@kernel.org>
On 6/12/26 6:05 PM, Rob Herring wrote:
> On Thu, Jun 11, 2026 at 03:48:15PM +0200, Krzysztof Kozlowski wrote:
>> On 10/06/2026 15:31, Abel Vesa wrote:
>>>>>>>> @@ -68,6 +68,7 @@ properties:
>>>>>>>>
>>>>>>>> - items:
>>>>>>>> - enum:
>>>>>>>> + - lenovo,yoga-slim7x-gen11
>>>>>>>
>>>>>>> I imagine you might want different panel variants, just like T14s has
>>>>>>> LCD and OLED?
>>>>>>
>>>>>> I expect this will be the case.
>>>>>
>>>>> Then better to prepare for this now, otherwise later you need to change
>>>>> bindings. If unsure what other variants are, then at least make this
>>>>> compatible panel-specific, e.g. lenovo,yoga-slim7x-gen11-oled-foo-bar.
>>>>
>>>> I took another look at psref [1] and there's only OLED SKUs (today?).
>>>> There are however, two different resolutions available and both can be
>>>> touch/notouch.
>>>
>>> If the other SKU doesn't have touch, then you might as well mark now this
>>> one with touch suffix or something like that.
>>
>>
>> If you decide not to have any changes (new compatibles), then at least
>> please document the above reasoning in commit msg.
>
> If the difference is just the panel or touch, then isn't that captured
> by the panel and/or touch nodes?
We already have a couple of DTs for laptops where the touchscreen may
be there or not, with the additional hid-over-i2c node defined
unconditionally and it works out fine
For the panel, it depends.. If it's another "Samsung ATNA"-class panel
(which I would guess is the case, but can't know for sure), and there's
no other changes, then it would work too.
I opened the build configurator on the Lenovo website and I can order
both kinds of panels with both kinds of SoCs (X2 Plus / Elite)
> OTOH, if it's different firmware builds and generally treated as 2
> different devices, then different top-level compatible is probably fine.
I unfortunately don't know the answer to that question..
They all carry the same model number on the website, it seems
Should we go forward with an optimistic, single compatible for the known
variant ("lenovo,yoga-slim7x-gen11", "qcom,glymur") then?
Konrad
^ permalink raw reply
* Re: [PATCH RFC v5 6/6] iio: osf: register IIO devices from capabilities
From: Andy Shevchenko @ 2026-06-16 11:32 UTC (permalink / raw)
To: Jinseob Kim
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260616072242.3942-7-kimjinseob88@gmail.com>
On Tue, Jun 16, 2026 at 04:22:42PM +0900, Jinseob Kim wrote:
> Register IIO devices for supported Open Sensor Fusion capability entries
> and push received samples into IIO buffers when enabled.
...
> help
> - Build the Open Sensor Fusion UART receive path.
> + Build the Open Sensor Fusion UART IIO driver.
>
> - The driver receives OSF protocol frames over a serdev UART.
> - Frames are decoded and validated before being passed to the
> - driver core.
> - This patch only adds the transport path.
> - IIO device registration is added separately.
> + The driver receives OSF protocol frames over a serdev UART and
> + registers IIO devices for supported capability entries.
Can't you fix this in the initial patch?
...
> obj-$(CONFIG_OPEN_SENSOR_FUSION) += open-sensor-fusion.o
>
> -open-sensor-fusion-y := osf_core.o osf_protocol.o osf_serdev.o osf_stream.o
> +open-sensor-fusion-y := osf_core.o osf_iio.o osf_protocol.o osf_serdev.o \
> + osf_stream.o
Modify the original code the way that this will only have a + line.
...
> void osf_core_unregister_iio(struct osf_device *osf)
> {
> + unsigned int i;
> +
> + for (i = 0; i < osf->iio_dev_count; i++)
For all for-loops where it's not going outside it
for (unsigned int i = 0; i < osf->iio_dev_count; i++)
> + osf_iio_unregister_sensor(osf->iio_devs[i].indio_dev);
> +
> + osf->iio_dev_count = 0;
> +}
...
> - ret = osf_core_validate_sensor_sample(&frame);
> - break;
> + return osf_core_handle_sensor_sample(osf, &frame);
> case OSF_MSG_DEVICE_STATUS:
> - ret = osf_core_validate_device_status(&frame);
> - break;
> + return osf_core_handle_device_status(osf, &frame);
> case OSF_MSG_CAPABILITY_REPORT:
> - ret = osf_core_validate_capability_report(&frame);
> - break;
> + return osf_core_handle_capability_report(osf, &frame);
> default:
> if (frame.message_type >= OSF_RESERVED_MSG_FIRST &&
> frame.message_type <= OSF_RESERVED_MSG_LAST)
> - ret = 0;
> - else if (frame.message_type >= OSF_VENDOR_PRIVATE_FIRST)
> - ret = 0;
> - else
> - ret = -EOPNOTSUPP;
> - break;
> + return 0;
> + if (frame.message_type >= OSF_VENDOR_PRIVATE_FIRST)
> + return 0;
> + return -EOPNOTSUPP;
With my suggestion this can be done in the initial patch.
So, this indeed needs a lot of work as for RFC :-)
I stop here.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v10 1/2] dt-bindings: ufs: Document static TX Equalization settings properties
From: Can Guo @ 2026-06-16 11:33 UTC (permalink / raw)
To: krzk, bvanassche, beanhuo, peter.wang, martin.petersen, mani
Cc: linux-scsi, Can Guo, Krzysztof Kozlowski, Alim Akhtar,
Avri Altman, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Ram Kumar Dwivedi,
Zhaoming Luo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list,
moderated list:ARM/Mediatek SoC support:Keyword:mediatek,
moderated list:ARM/Mediatek SoC support:Keyword:mediatek
In-Reply-To: <20260616113348.1168248-1-can.guo@oss.qualcomm.com>
UFS v5.0/UFSHCI v5.0 adds HS-G6 support (46.6 Gbps/lane) via UniPro
v3.0 and M-PHY v6.0. These specs define TX Equalization for all
High-Speed Gears (not only HS-G6) to compensate channel loss and
improve signal integrity at high speed.
For HS-G6, M-PHY uses PAM4 1b1b line coding. Pre-Coding may also be
required depending on channel characteristics.
Document vendor-neutral properties in ufs-common.yaml:
- txeq-preshoot-g[1-6]
- txeq-deemphasis-g[1-6]
- tx-precode-enable-g6
Values are per-lane Host/Device tuples (2 values for x1, 4 values for
x2). PreShoot/DeEmphasis range from 0..7, and Precode is 0/1.
These are board-specific signal-integrity tuning values. They depend on
channel SI/PHY characterization and validation (host PHY, device PHY,
package, and board routing), and are determined by HW/PHY designers.
Although UFSHCI v5.0 supports TX Equalization Training via UniPro v3.0,
which allows host software to determine optimal TX Equalization at
runtime, static board-specific TX Equalization settings in the Device
Tree are still necessary because:
- TX Equalization Training is not supported for HS-G3 and below
- TX Equalization Training is disabled on some platforms
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Signed-off-by: Can Guo <can.guo@oss.qualcomm.com>
---
.../devicetree/bindings/ufs/ufs-common.yaml | 58 +++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/Documentation/devicetree/bindings/ufs/ufs-common.yaml b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
index ed97f5682509..cc32e1189d50 100644
--- a/Documentation/devicetree/bindings/ufs/ufs-common.yaml
+++ b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
@@ -105,6 +105,64 @@ properties:
Restricts the UFS controller to rate-a or rate-b for both TX and
RX directions.
+ tx-precode-enable-g6:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ items:
+ - items:
+ - description: Host_Lane0 precode
+ enum: [0, 1]
+ - description: Device_Lane0 precode
+ enum: [0, 1]
+ - items:
+ - description: Host_Lane1 precode
+ enum: [0, 1]
+ - description: Device_Lane1 precode
+ enum: [0, 1]
+ description:
+ Static TX Precode enable values for HS-G6 only.
+
+patternProperties:
+ "^txeq-preshoot-g[1-6]$":
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ items:
+ - items:
+ - description: Host_Lane0 Preshoot value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ - description: Device_Lane0 Preshoot value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ - items:
+ - description: Host_Lane1 Preshoot value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ - description: Device_Lane1 Preshoot value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ description: |
+ Static TX Equalization PreShoot settings for High Speed Gears. These
+ values are programmed to the corresponding UniPro PA layer attribute
+ PA_TxEQG[1-6]Setting. Each value selects a Pre-Shoot level as defined
+ by the MIPI M-PHY specification (TX_HS_PreShoot_Setting).
+
+ "^txeq-deemphasis-g[1-6]$":
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ items:
+ - items:
+ - description: Host_Lane0 DeEmphasis value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ - description: Device_Lane0 DeEmphasis value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ - items:
+ - description: Host_Lane1 DeEmphasis value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ - description: Device_Lane1 DeEmphasis value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ description: |
+ Static TX Equalization DeEmphasis settings for High Speed Gears. These
+ values are programmed to the corresponding UniPro PA layer attribute
+ PA_TxEQG[1-6]Setting. Each value selects a De-Emphasis level as defined
+ by the MIPI M-PHY specification (TX_HS_DeEmphasis_Setting).
+
dependencies:
freq-table-hz: [ clocks ]
operating-points-v2: [ clocks, clock-names ]
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 3/5] phy: qualcomm: qmp-combo: Add preliminary USB4 support
From: Konrad Dybcio @ 2026-06-16 11:44 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Konrad Dybcio, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, linux-kernel,
linux-phy, linux-arm-msm, devicetree, usb4-upstream,
Raghavendra Thoorpu, Mika Westerberg, Sven Peter
In-Reply-To: <zzs4wgr37wfptzqwgttxdubqnyudyh3am2r6i7b56kd3lwuo2e@bjcyelaxtlq3>
On 5/28/26 10:00 AM, Dmitry Baryshkov wrote:
> On Fri, May 22, 2026 at 02:05:14PM +0200, Konrad Dybcio wrote:
>> On 5/20/26 5:06 PM, Dmitry Baryshkov wrote:
>>> On Tue, May 19, 2026 at 10:12:06AM +0200, Konrad Dybcio wrote:
>>>> On 5/18/26 5:38 PM, Dmitry Baryshkov wrote:
>>>>> On Mon, May 18, 2026 at 04:15:16PM +0200, Konrad Dybcio wrote:
>>>>>> On 5/18/26 3:57 PM, Dmitry Baryshkov wrote:
>>>>>>> On Mon, May 18, 2026 at 12:29:50PM +0200, Konrad Dybcio wrote:
>>>>>>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>>>>>
>>>>>>>> Some Combo PHYs (so far only on SC8280XP, X1E80100 and Glymur), come in
>>>>>>>> a flavor called USB43DP, which as the name implies, features USB4, USB3
>>>>>>>> and DP signal processing capabilities. In that architecture, USB3 and
>>>>>>>> USB4 PHYs share the same USB_PLL while featuring separate logic spaces.
>>>>>>>> The DP part is roughly the same as on the instances without USB4.
>>>>>>>>
>>>>>>>> The USB4 and USB3/DP operation modes of the PHY are mutually exclusive.
>>>>>>>> Only one USB protocol (and flavor of pipe clock) can be active at a
>>>>>>>> given moment (not to be confused with USB3 not being able to be
>>>>>>>> tunneled as USB4 packets - that of course remains possible).
>>>>>>>> The DP PLL is still used for clocking tunneled DP links. It may be
>>>>>>>> turned off to save power when no tunnels are active, but that's left as
>>>>>>>> a TODO item for now.
>>>>>>>>
>>>>>>>> Due to the nature of USB4, the Type-C handling happens entirely inside
>>>>>>>> the Host Router, and as such the QMPPHY's mux_set() function is
>>>>>>>> nullified for the period when USB4 PHY remains active. This is strictly
>>>>>>>> necessary, as the Host Router driver is going to excercise manual
>>>>>>>> control over the USB4 PHY's power state, which is needed by the suspend
>>>>>>>> and resume flows. Failure to control that synchronously with other
>>>>>>>> parts of the code results in a SoC crash by unlocked access.
>>>>>>>>
>>>>>>>> Because of that, a new struct phy is spawned to expose the USB4 mode,
>>>>>>>> along with a .set_mode callback to allow toggling between USB4 and TBT3
>>>>>>>> submodes.
>>>>>>>>
>>>>>>>> Thunderbolt 3, having a number of differences vs USB4, requires a
>>>>>>>> couple specific overrides, pertaining to electrical characteristics,
>>>>>>>> which are easily accommodated for.
>>>>>>>>
>>>>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>>>>> ---
>>>>>>>> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 392 ++++++++++++++++++++++++------
>>>>>>>> 1 file changed, 322 insertions(+), 70 deletions(-)
>>>>>>>>
>>>>>>>
>>>>>>> Overall it looks good. The major question (after looking at TODOs), do
>>>>>>> we need a separate submode for USB+DP / TBT+DP?
>>>>>>
>>>>>> The problem space is as follows:
>>>>>>
>>>>>> After a TBT (collectively TBT3+ and USB4) link has been established and
>>>>>> we have a link partner, we may (based on the HW capabilities and user
>>>>>> config, such as kernel params but not only) start or stop a DP tunnel at
>>>>>> runtime. On Qualcomm hardware, the PHY is kept in USB4 mode and its DP
>>>>>> AUX lines are not used (instead, the encapsulated DP AUX packets are r/w
>>>>>> entirely within the USB4 subsystem via a pair of FIFOs that Linux sees
>>>>>> as a separate DP AUX host)
>>>>>
>>>>> So far so good. But I still don't grok if having a DP-over-USB4 is a
>>>>> separate submode or not. I.e. I see code (and TODOs) to detect and
>>>>> handle DP going on and off. Would it be better if we specify that
>>>>> explicitly?
>>>>
>>>> I really don't want to end up in a situation like we have with:
>>>>
>>>> $ rg _USB include/linux/phy/phy.h
>>>> 29: PHY_MODE_USB_HOST,
>>>> 30: PHY_MODE_USB_HOST_LS,
>>>> 31: PHY_MODE_USB_HOST_FS,
>>>> 32: PHY_MODE_USB_HOST_HS,
>>>> 33: PHY_MODE_USB_HOST_SS,
>>>> 34: PHY_MODE_USB_DEVICE,
>>>> 35: PHY_MODE_USB_DEVICE_LS,
>>>> 36: PHY_MODE_USB_DEVICE_FS,
>>>> 37: PHY_MODE_USB_DEVICE_HS,
>>>> 38: PHY_MODE_USB_DEVICE_SS,
>>>> 39: PHY_MODE_USB_OTG,
>>>>
>>>>>> Then, on hamoa/glymur specifically, any of the 3 USB4-capable DP hosts
>>>>>> can be muxed to either of the 2 DPIN ports on any of the 3 USB4 routers
>>>>>> (and each of these routers is hardwired to one of the PHYs).
>>>>>>
>>>>>> To underline, we have 3 DP producers and 6 consumers. If there's e.g. a
>>>>>> super high-res display at one of the physical ports, or a long
>>>>>> daisy-chain, we may need to use 2 DPTXes to service 1 receptacle. Then,
>>>>>> we would only need one of the PHYs (associated with the router that's
>>>>>> wired to that port) to provide a DP clock.
>>>>>>
>>>>>> This, along with the normal (logical or physical) present/absent status
>>>>>> can change at runtime. My plan is to use phy_set_opts(dp_tunelling=true)
>>>>>> or something along those lines to toggle that bit as necessary
>>>>>
>>>>> I don't see phy_set_opts(). So maybe a submode then...
>>>>
>>>> Sorry, I misremembered the name. The function is phy_configure(), and it
>>>> takes a union phy_configure_opts, hence the confusion
>>>
>>> So, phy_configure() will be called for the DP PHY to set the DP opts,
>>> but how do you plan to determine if DP is on or not? Or do you plan to
>>> add phy_tbt_configure_opts ?
>>>
>>> Another obvious option would be to set the flag if DP PHY is being tuned
>>> on / off. I don't know if that fulfills your needs.
>>
>> Either this or tbt_configure_opts. We still have the muxing question to
>> chew through.
>>
>> The bottom line is that all AUX traffic happens between the "AUX adapters"
>> within USB4SS, talking over thunderbolt to other AUX adapters on the LTTPRs
>> and the far-end device (and anything inbetween in a chained topology) meaning
>> we only need to engage the DP host itself (and therefore the PHY) after we've
>> already performed the capability negotiations
>
> I hope you mean USB link capabilities. DP host still needs to ping LTTPRs
> and read all the DP properties on its own. I don't think we want to leak
> that to the other layers.
I must crush your hopes.
There's some preliminary TBT-layer setup (handled by the tbt driver in
Linux), followed by the expected DPCD (and alike) r/w accesses, which on
our hw must happen through the DP adapters housed inside USB4SS (again,
because the DPTX's auxbus is NOPed out). Think of it as just another
i2c_aux provider.
Konrad
^ permalink raw reply
* Re: [PATCH v3 0/2] regulator: qcom-rpmh: Add off-on-delay support
From: Konrad Dybcio @ 2026-06-16 11:48 UTC (permalink / raw)
To: Kamal Wadhwa, Saikiran, broonie, monish.chunara, jishnu.prakash,
nitin.rawat, Bjorn Andersson
Cc: lgirdwood, andersson, konrad.dybcio, linux-arm-msm, linux-kernel,
robh, krzk+dt, devicetree
In-Reply-To: <20260515111647.qg75thdvcbvvjpoi@hu-kamalw-hyd.qualcomm.com>
On 5/15/26 1:16 PM, Kamal Wadhwa wrote:
> On Wed, Jan 28, 2026 at 12:32:09AM +0530, Saikiran wrote:
>> This series adds support for the standard `regulator-off-on-delay-us`
>> property to the Qualcomm RPMh regulator driver and updates the
>> corresponding Device Tree bindings.
>>
>> Motivation:
>> On the Lenovo Yoga Slim 7x (Snapdragon X Elite), the camera regulators
>> (LDO1, LDO3, LDO7) have large bulk capacitors and rely on passive discharge.
>> When these regulators are disabled, the voltage decays very slowly. If
>> re-enabled too quickly, the sensor experiences a brownout and fails to
>> initialize.
>>
>> Verification:
>> I verified that the core `drivers/regulator/of_regulator.c` does not
>> currently parse `regulator-off-on-delay-us` in `of_get_regulation_constraints()`.
>> Therefore, the driver must parse this property explicitly and populate
>> `rdesc->off_on_delay` so the regulator core can enforce the constraint.
>>
>> Changes in v3:
>> - Added Patch 1/2: Update DT bindings to allow `regulator-off-on-delay-us`
>> for `qcom,rpmh-regulator` (Requested by Mark Brown).
>> - Updated Patch 2/2: Refined commit message to explicitly mention the
>> passive discharge and bulk capacitor mechanism on the Yoga Slim 7x
>> (Requested by Mark Brown).
>>
>> Changes in v2:
>> - Moved the motivation/context from the cover letter into the commit
>> message of the driver patch.
>>
>> Saikiran (2):
>> dt-bindings: regulator: qcom,rpmh: Allow regulator-off-on-delay-us
>> regulator: qcom-rpmh: Add support for regulator-off-on-delay-us
>
> Hi Mark, Bjorn, Konrad and all,
>
> We have another UFS issue on QCS8300 RB4 EVK, where it seems this patch is
> helping.
>
> Issue is seen 2/10 reboots and it happens in the UFS probe defer path:
>
> 1. UFS probe takes regulator handle for VCC(vreg_l8a) of UFS host controller.
> 2. UFS probe enables the regulator
> 3. UFS probe defers (due to some other dependency un-related to regulator)
> 4. UFS regulator disabled on probe exit
> 5. UFS re-attempts probe and re-enables the regulator
> 6. UFS init sequence runs -> UFS NOP OUT command failed (no shell)
>
> Issue Log:
>
> [ 6.583836] ufshcd-qcom 1d84000.ufs: ufshcd_verify_dev_init: NOP OUT failed -11
> [ 6.592780] ufshcd-qcom 1d84000.ufs: ufshcd_async_scan failed: -11
>
> NOTE
> - Issue is not seen in first probe attempt, because UFS regulators are left ON
> from bootloader, which gives enough time between rail turn ON and UFS init
> sequence start. However in issue case, it seems re-probe is happening too
> fast, which causes init sequence to fail and UFS brownouts (similar to camera
> sensor case)
>
> - Also, we compared this board with other RBxx EVK boards for UFS rail, it
> seems that this board has more caps on the VCC regulator, as the board is
> designed to have both EMMC and UFS, and we have DT option to pick one of them.
>
> So for EMMC those extra caps were added and they are impacting rampup on VCC.
>
> Since this is not entirely a UFS part issue, but a board design constraint, it
> seems better if we handle this in the regulator side itself, as adding it in the
> UFS driver may not be acceptable from UFS reviewers.
>
> Please share your opinion, if this seems to be good reason to accept this patch?
Is that board in production already, or is that something that can be fixed?
Konrad
^ permalink raw reply
* [PATCH v2 0/3] iio: magnetometer: add driver for QST QMC5883L Sensor
From: Siratul Islam @ 2026-06-16 11:49 UTC (permalink / raw)
To: jic23, robh, krzk+dt, conor+dt
Cc: siratul.islam, dlechner, nuno.sa, andy, linux-iio, devicetree,
linux-kernel
This patch series introduces the QST QMC5883L 3-Axis Magnetic Sensor
driver. It is a simple device with minimal magnetometer functionalities.
Commonly used as (software incompatible) replacement for the
Honeywell HMC5883L sensor.
This driver implements the basic functionalities of the QMC5883L sensor,
and intentionally leaves out some features like DRDY interrupt pin support
and power management for simplicity, both of which will be addressed
in future patches.
There was an attempt to introduce this device about an year ago but
the author seems to have abandoned the patch series. Since the device
is simple enough, I decided to start from scratch.
Note: I also noticed a patch for the QMC5883P variant. Despite similar
naming, the sensors are different including different register maps,
so these devices are not compatible with each other.
---
Changes in v2:
- Update commit message in binding.
- Reformat header includes.
- Remove iio_device_claim_direct()/iio_device_release_direct()
- Read the measurement registers before checking the OVL status bit
- Replace scoped_guard() with guard()
- Fix function parameter styling
- Replace FIELD_PREP_CONST() with FIELD_PREP()
- Replace qmc5883l_rng_avail[] with a 2D qmc5883l_scales[][2] array
- Update mutex comment
- Add a devm_add_action_or_reset() callback
- Use a named initializer in the i2c_device_id table
- Combine u8 rng, osr, odr; onto one line
- Various styling fixes
- Update maintainer email to siratul.islam@linux.dev
Link to v1: https://lore.kernel.org/linux-iio/20260612124557.13750-1-email@sirat.me/
Siratul Islam (3):
dt-bindings: add entry for qstcorp
dt-bindings: iio: magnetometer: add QST QMC5883L Sensor
iio: magnetometer: add driver for QST QMC5883L Sensor
.../iio/magnetometer/qstcorp,qmc5883l.yaml | 52 ++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 7 +
drivers/iio/magnetometer/Kconfig | 11 +
drivers/iio/magnetometer/Makefile | 2 +
drivers/iio/magnetometer/qmc5883l.c | 516 ++++++++++++++++++
6 files changed, 590 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml
create mode 100644 drivers/iio/magnetometer/qmc5883l.c
--
2.54.0
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: add entry for qstcorp
From: Siratul Islam @ 2026-06-16 11:49 UTC (permalink / raw)
To: jic23, robh, krzk+dt, conor+dt
Cc: siratul.islam, dlechner, nuno.sa, andy, linux-iio, devicetree,
linux-kernel, Conor Dooley
In-Reply-To: <20260616114942.37241-1-siratul.islam@linux.dev>
Add an entry for QST Corporation Limited
Link: https://www.qstcorp.com/
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Siratul Islam <siratul.islam@linux.dev>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 28784d66ae7b..11aac47f90ce 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1355,6 +1355,8 @@ patternProperties:
description: Shenzhen QiShenglong Industrialist Co., Ltd.
"^qnap,.*":
description: QNAP Systems, Inc.
+ "^qstcorp,.*":
+ description: QST Corporation Limited
"^quanta,.*":
description: Quanta Computer Inc.
"^radxa,.*":
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: iio: magnetometer: add QST QMC5883L Sensor
From: Siratul Islam @ 2026-06-16 11:49 UTC (permalink / raw)
To: jic23, robh, krzk+dt, conor+dt
Cc: siratul.islam, dlechner, nuno.sa, andy, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260616114942.37241-1-siratul.islam@linux.dev>
Add devicetree binding for the QST QMC5883L 3-Axis Magnetic Sensor
connected via I2C.
Used enum so that more devices could use this binding
Signed-off-by: Siratul Islam <siratul.islam@linux.dev>
---
.../iio/magnetometer/qstcorp,qmc5883l.yaml | 52 +++++++++++++++++++
MAINTAINERS | 6 +++
2 files changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml b/Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml
new file mode 100644
index 000000000000..38abd083a4fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/qstcorp,qmc5883l.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: QST QMC5883L 3-Axis Magnetic Sensor
+
+maintainers:
+ - Siratul Islam <siratul.islam@linux.dev>
+
+description: |
+ QST QMC5883L 3-Axis Magnetic Sensor on I2C bus.
+ https://www.qstcorp.com/upload/pdf/202512/13-52-04%20QMC5883L%20Datasheet%20Rev.%20B.pdf
+
+properties:
+ compatible:
+ enum:
+ - qstcorp,qmc5883l
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+ vddio-supply: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vddio-supply
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ magnetometer@d {
+ compatible = "qstcorp,qmc5883l";
+ reg = <0x0d>;
+ vdd-supply = <&vdd_3v3_reg>;
+ vddio-supply = <&vdd_3v3_reg>;
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index e035a3be797c..1127403c579b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21787,6 +21787,12 @@ F: Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst
F: drivers/bus/fsl-mc/
F: include/uapi/linux/fsl_mc.h
+QST QMC5883L 3-Axis Magnetic Sensor
+M: Siratul Islam <siratul.islam@linux.dev>
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml
+
QT1010 MEDIA DRIVER
L: linux-media@vger.kernel.org
S: Orphan
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/3] iio: magnetometer: add driver for QST QMC5883L Sensor
From: Siratul Islam @ 2026-06-16 11:49 UTC (permalink / raw)
To: jic23, robh, krzk+dt, conor+dt
Cc: siratul.islam, dlechner, nuno.sa, andy, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260616114942.37241-1-siratul.islam@linux.dev>
Add driver for the QST QMC5883L 3-Axis Magnetic Sensor
connected via i2c.
Signed-off-by: Siratul Islam <siratul.islam@linux.dev>
---
MAINTAINERS | 1 +
drivers/iio/magnetometer/Kconfig | 11 +
drivers/iio/magnetometer/Makefile | 2 +
drivers/iio/magnetometer/qmc5883l.c | 516 ++++++++++++++++++++++++++++
4 files changed, 530 insertions(+)
create mode 100644 drivers/iio/magnetometer/qmc5883l.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1127403c579b..0f9ad3b49a5d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21792,6 +21792,7 @@ M: Siratul Islam <siratul.islam@linux.dev>
L: linux-iio@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/iio/magnetometer/qstcorp,qmc5883l.yaml
+F: drivers/iio/magnetometer/qmc5883l.c
QT1010 MEDIA DRIVER
L: linux-media@vger.kernel.org
diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig
index fb313e591e85..615564174086 100644
--- a/drivers/iio/magnetometer/Kconfig
+++ b/drivers/iio/magnetometer/Kconfig
@@ -198,6 +198,17 @@ config INFINEON_TLV493D
To compile this driver as a module, choose M here: the module
will be called tlv493d.
+config QMC5883L
+ tristate "QST QMC5883L 3-Axis Magnetic Sensor"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Say Y here to add support driver for QST QMC5883L 3-Axis
+ Magnetic Sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called qmc5883l.
+
config SENSORS_HMC5843
tristate
select IIO_BUFFER
diff --git a/drivers/iio/magnetometer/Makefile b/drivers/iio/magnetometer/Makefile
index 5bd227f8c120..552682555d86 100644
--- a/drivers/iio/magnetometer/Makefile
+++ b/drivers/iio/magnetometer/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_IIO_ST_MAGN_SPI_3AXIS) += st_magn_spi.o
obj-$(CONFIG_INFINEON_TLV493D) += tlv493d.o
+obj-$(CONFIG_QMC5883L) += qmc5883l.o
+
obj-$(CONFIG_SENSORS_HMC5843) += hmc5843_core.o
obj-$(CONFIG_SENSORS_HMC5843_I2C) += hmc5843_i2c.o
obj-$(CONFIG_SENSORS_HMC5843_SPI) += hmc5843_spi.o
diff --git a/drivers/iio/magnetometer/qmc5883l.c b/drivers/iio/magnetometer/qmc5883l.c
new file mode 100644
index 000000000000..e1addcaf0551
--- /dev/null
+++ b/drivers/iio/magnetometer/qmc5883l.c
@@ -0,0 +1,516 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+/*
+ * Support for QST QMC5883L 3-Axis Magnetic Sensor on I2C bus.
+ *
+ * Copyright (C) 2026 Siratul Islam <siratul.islam@linux.dev>
+ *
+ * Datasheet available at
+ * <https://www.qstcorp.com/upload/pdf/202512/13-52-04%20QMC5883L%20Datasheet%20Rev.%20B.pdf>
+ *
+ */
+
+#include <linux/array_size.h>
+#include <linux/bits.h>
+#include <linux/bitfield.h>
+#include <linux/cleanup.h>
+#include <linux/delay.h>
+#include <linux/dev_printk.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/time.h>
+
+#include <linux/iio/iio.h>
+
+#include <asm/byteorder.h>
+
+#define QMC5883L_REG_X_LSB 0x00
+#define QMC5883L_REG_STATUS1 0x06
+#define QMC5883L_REG_CTRL1 0x09
+#define QMC5883L_REG_CTRL2 0x0A
+#define QMC5883L_REG_SET_RESET 0x0B
+#define QMC5883L_REG_ID 0x0D
+
+#define QMC5883L_CHIP_ID 0xFF
+
+#define QMC5883L_MODE_MASK GENMASK(1, 0)
+#define QMC5883L_ODR_MASK GENMASK(3, 2)
+#define QMC5883L_RNG_MASK GENMASK(5, 4)
+#define QMC5883L_OSR_MASK GENMASK(7, 6)
+
+#define QMC5883L_MODE_STANDBY 0x00
+#define QMC5883L_MODE_CONT 0x01
+
+#define QMC5883L_ODR_10HZ 0x00
+#define QMC5883L_ODR_50HZ 0x01
+#define QMC5883L_ODR_100HZ 0x02
+#define QMC5883L_ODR_200HZ 0x03
+
+#define QMC5883L_RNG_2G 0x00
+#define QMC5883L_RNG_8G 0x01
+
+#define QMC5883L_OSR_512 0x00
+#define QMC5883L_OSR_256 0x01
+#define QMC5883L_OSR_128 0x02
+#define QMC5883L_OSR_64 0x03
+
+#define QMC5883L_STATUS_DRDY BIT(0)
+#define QMC5883L_STATUS_OVL BIT(1)
+
+#define QMC5883L_SET_RESET_VAL BIT(0)
+#define QMC5883L_INT_DISABLE BIT(0)
+#define QMC5883L_SOFT_RESET BIT(7)
+
+/* POR completion time max per datasheet */
+#define QMC5883L_PORT_US 350
+
+struct qmc5883l_data {
+ struct regmap *regmap;
+ /*
+ * Protect data->range/odr/osr.
+ * Protect poll and read during measurement.
+ */
+ struct mutex mutex;
+ u8 range;
+ u8 odr;
+ u8 osr;
+};
+
+enum qmc5883l_chan {
+ QMC5883L_AXIS_X,
+ QMC5883L_AXIS_Y,
+ QMC5883L_AXIS_Z
+};
+
+static const int qmc5883l_odr_avail[] = { 10, 50, 100, 200 };
+
+static const int qmc5883l_osr_avail[] = { 512, 256, 128, 64 };
+
+static const int qmc5883l_scales[][2] = {
+ [QMC5883L_RNG_2G] = { 0, 83333 },
+ [QMC5883L_RNG_8G] = { 0, 333333 },
+};
+
+static int qmc5883l_take_measurement(struct iio_dev *indio_dev, int index,
+ int *val)
+{
+ struct qmc5883l_data *data = iio_priv(indio_dev);
+ unsigned int status;
+ __le16 buf[3];
+ int ret;
+
+ guard(mutex) (&data->mutex);
+
+ /* 50ms headroom over the slowest ODR (10Hz) */
+ ret = regmap_read_poll_timeout(data->regmap,
+ QMC5883L_REG_STATUS1,
+ status, (status & QMC5883L_STATUS_DRDY),
+ 2 * USEC_PER_MSEC, 150 * USEC_PER_MSEC);
+ if (ret)
+ return ret;
+
+ ret = regmap_bulk_read(data->regmap, QMC5883L_REG_X_LSB, buf,
+ sizeof(buf));
+ if (ret)
+ return ret;
+
+ if (status & QMC5883L_STATUS_OVL)
+ return -ERANGE;
+
+ *val = (s16)le16_to_cpu(buf[index]);
+
+ return 0;
+}
+
+static int qmc5883l_read_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan,
+ int *val, int *val2, long mask)
+{
+ struct qmc5883l_data *data = iio_priv(indio_dev);
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = qmc5883l_take_measurement(indio_dev, chan->address, val);
+ if (ret)
+ return ret;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE: {
+ guard(mutex)(&data->mutex);
+
+ *val = qmc5883l_scales[data->range][0];
+ *val2 = qmc5883l_scales[data->range][1];
+
+ return IIO_VAL_INT_PLUS_NANO;
+ }
+ case IIO_CHAN_INFO_SAMP_FREQ: {
+ guard(mutex)(&data->mutex);
+
+ switch (data->odr) {
+ case QMC5883L_ODR_200HZ:
+ *val = 200;
+ break;
+ case QMC5883L_ODR_100HZ:
+ *val = 100;
+ break;
+ case QMC5883L_ODR_50HZ:
+ *val = 50;
+ break;
+ case QMC5883L_ODR_10HZ:
+ *val = 10;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return IIO_VAL_INT;
+ }
+ case IIO_CHAN_INFO_OVERSAMPLING_RATIO: {
+ guard(mutex)(&data->mutex);
+
+ switch (data->osr) {
+ case QMC5883L_OSR_64:
+ *val = 64;
+ break;
+ case QMC5883L_OSR_128:
+ *val = 128;
+ break;
+ case QMC5883L_OSR_256:
+ *val = 256;
+ break;
+ case QMC5883L_OSR_512:
+ *val = 512;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return IIO_VAL_INT;
+ }
+ default:
+ return -EINVAL;
+ }
+}
+
+static int qmc5883l_write_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan,
+ int val, int val2, long mask)
+{
+ struct qmc5883l_data *data = iio_priv(indio_dev);
+ u8 rng, osr, odr;
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_SCALE: {
+ if (val != 0)
+ return -EINVAL;
+
+ if (val2 == qmc5883l_scales[QMC5883L_RNG_2G][1])
+ rng = QMC5883L_RNG_2G;
+ else if (val2 == qmc5883l_scales[QMC5883L_RNG_8G][1])
+ rng = QMC5883L_RNG_8G;
+ else
+ return -EINVAL;
+
+ guard(mutex)(&data->mutex);
+
+ ret = regmap_update_bits(data->regmap, QMC5883L_REG_CTRL1,
+ QMC5883L_RNG_MASK,
+ FIELD_PREP(QMC5883L_RNG_MASK, rng));
+ if (ret)
+ return ret;
+
+ data->range = rng;
+
+ return 0;
+ }
+ case IIO_CHAN_INFO_SAMP_FREQ: {
+ switch (val) {
+ case 200:
+ odr = QMC5883L_ODR_200HZ;
+ break;
+ case 100:
+ odr = QMC5883L_ODR_100HZ;
+ break;
+ case 50:
+ odr = QMC5883L_ODR_50HZ;
+ break;
+ case 10:
+ odr = QMC5883L_ODR_10HZ;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ guard(mutex)(&data->mutex);
+
+ ret = regmap_update_bits(data->regmap, QMC5883L_REG_CTRL1,
+ QMC5883L_ODR_MASK,
+ FIELD_PREP(QMC5883L_ODR_MASK, odr));
+ if (ret)
+ return ret;
+
+ data->odr = odr;
+
+ return 0;
+ }
+ case IIO_CHAN_INFO_OVERSAMPLING_RATIO: {
+ switch (val) {
+ case 64:
+ osr = QMC5883L_OSR_64;
+ break;
+ case 128:
+ osr = QMC5883L_OSR_128;
+ break;
+ case 256:
+ osr = QMC5883L_OSR_256;
+ break;
+ case 512:
+ osr = QMC5883L_OSR_512;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ guard(mutex)(&data->mutex);
+
+ ret = regmap_update_bits(data->regmap, QMC5883L_REG_CTRL1,
+ QMC5883L_OSR_MASK,
+ FIELD_PREP(QMC5883L_OSR_MASK, osr));
+ if (ret)
+ return ret;
+
+ data->osr = osr;
+
+ return 0;
+ }
+ default:
+ return -EINVAL;
+ }
+}
+
+static int qmc5883l_read_avail(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ const int **vals, int *type, int *length,
+ long mask)
+{
+ switch (mask) {
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ *vals = qmc5883l_odr_avail;
+ *type = IIO_VAL_INT;
+ *length = ARRAY_SIZE(qmc5883l_odr_avail);
+ return IIO_AVAIL_LIST;
+ case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
+ *vals = qmc5883l_osr_avail;
+ *type = IIO_VAL_INT;
+ *length = ARRAY_SIZE(qmc5883l_osr_avail);
+ return IIO_AVAIL_LIST;
+ case IIO_CHAN_INFO_SCALE:
+ *vals = (const int *)qmc5883l_scales;
+ *type = IIO_VAL_INT_PLUS_NANO;
+ *length = ARRAY_SIZE(qmc5883l_scales) * 2;
+ return IIO_AVAIL_LIST;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int qmc5883l_write_raw_get_fmt(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ long mask)
+{
+ switch (mask) {
+ case IIO_CHAN_INFO_SCALE:
+ return IIO_VAL_INT_PLUS_NANO;
+ default:
+ return IIO_VAL_INT;
+ }
+}
+
+static const struct iio_info qmc5883l_info = {
+ .read_raw = qmc5883l_read_raw,
+ .write_raw = qmc5883l_write_raw,
+ .read_avail = qmc5883l_read_avail,
+ .write_raw_get_fmt = qmc5883l_write_raw_get_fmt,
+};
+
+static int qmc5883l_init(struct qmc5883l_data *data)
+{
+ struct regmap *regmap = data->regmap;
+ unsigned int reg;
+ int ret;
+
+ ret = regmap_read(regmap, QMC5883L_REG_ID, ®);
+ if (ret)
+ return ret;
+
+ /* Not failing because rev 1.0 had this register reserved */
+ if (reg != QMC5883L_CHIP_ID)
+ dev_warn(regmap_get_device(regmap),
+ "Unknown chip id: 0x%02x, continuing\n", reg);
+
+ ret = regmap_write(regmap, QMC5883L_REG_CTRL2, QMC5883L_SOFT_RESET);
+ if (ret)
+ return ret;
+
+ fsleep(QMC5883L_PORT_US);
+
+ /* DRDY pin no used in this version of the driver */
+ ret = regmap_write(regmap, QMC5883L_REG_CTRL2, QMC5883L_INT_DISABLE);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(regmap, QMC5883L_REG_SET_RESET, QMC5883L_SET_RESET_VAL);
+ if (ret)
+ return ret;
+
+ data->odr = QMC5883L_ODR_50HZ;
+ data->range = QMC5883L_RNG_2G;
+ data->osr = QMC5883L_OSR_64;
+
+ return regmap_write(regmap, QMC5883L_REG_CTRL1,
+ FIELD_PREP(QMC5883L_MODE_MASK, QMC5883L_MODE_CONT) |
+ FIELD_PREP(QMC5883L_ODR_MASK, data->odr) |
+ FIELD_PREP(QMC5883L_RNG_MASK, data->range) |
+ FIELD_PREP(QMC5883L_OSR_MASK, data->osr));
+}
+
+static void qmc5883l_power_down_action(void *priv)
+{
+ struct qmc5883l_data *data = priv;
+
+ regmap_update_bits(data->regmap, QMC5883L_REG_CTRL1,
+ QMC5883L_MODE_MASK,
+ FIELD_PREP(QMC5883L_MODE_MASK, QMC5883L_MODE_STANDBY));
+}
+
+static bool qmc5883l_volatile_reg(struct device *dev, unsigned int reg)
+{
+ return reg <= QMC5883L_REG_STATUS1;
+}
+
+static bool qmc5883l_writable_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case QMC5883L_REG_CTRL1:
+ case QMC5883L_REG_CTRL2:
+ case QMC5883L_REG_SET_RESET:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static const struct regmap_config qmc5883l_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = QMC5883L_REG_ID,
+ .cache_type = REGCACHE_MAPLE,
+ .volatile_reg = qmc5883l_volatile_reg,
+ .writeable_reg = qmc5883l_writable_reg
+};
+
+#define QMC5883L_CHANNEL(_axis) \
+ { \
+ .type = IIO_MAGN, \
+ .modified = 1, \
+ .channel2 = IIO_MOD_##_axis, \
+ .address = QMC5883L_AXIS_##_axis, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = \
+ BIT(IIO_CHAN_INFO_SCALE) | \
+ BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
+ .info_mask_shared_by_type_available = \
+ BIT(IIO_CHAN_INFO_SCALE) | \
+ BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
+ }
+
+static const struct iio_chan_spec qmc5883l_channels[] = {
+ QMC5883L_CHANNEL(X),
+ QMC5883L_CHANNEL(Y),
+ QMC5883L_CHANNEL(Z)
+};
+
+static int qmc5883l_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct qmc5883l_data *data;
+ struct iio_dev *indio_dev;
+ struct regmap *regmap;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ regmap = devm_regmap_init_i2c(client, &qmc5883l_regmap_config);
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap),
+ "regmap initialization failed\n");
+
+ ret = devm_regulator_get_enable(dev, "vdd");
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to enable VDD regulator\n");
+
+ ret = devm_regulator_get_enable(dev, "vddio");
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to enable VDDIO regulator\n");
+
+ fsleep(QMC5883L_PORT_US);
+
+ data = iio_priv(indio_dev);
+ data->regmap = regmap;
+
+ ret = devm_mutex_init(dev, &data->mutex);
+ if (ret)
+ return ret;
+
+ indio_dev->name = "qmc5883l";
+ indio_dev->info = &qmc5883l_info;
+ indio_dev->channels = qmc5883l_channels;
+ indio_dev->num_channels = ARRAY_SIZE(qmc5883l_channels);
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ ret = qmc5883l_init(data);
+ if (ret)
+ return dev_err_probe(dev, ret, "qmc5883l init failed\n");
+
+ ret = devm_add_action_or_reset(dev, qmc5883l_power_down_action, data);
+ if (ret)
+ return ret;
+
+ return devm_iio_device_register(dev, indio_dev);
+}
+
+static const struct of_device_id qmc5883l_match[] = {
+ { .compatible = "qstcorp,qmc5883l" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, qmc5883l_match);
+
+static const struct i2c_device_id qmc5883l_id[] = {
+ { .name = "qmc5883l" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, qmc5883l_id);
+
+static struct i2c_driver qmc5883l_driver = {
+ .driver = {
+ .name = "qmc5883l",
+ .of_match_table = qmc5883l_match,
+ },
+ .id_table = qmc5883l_id,
+ .probe = qmc5883l_probe
+};
+module_i2c_driver(qmc5883l_driver);
+
+MODULE_DESCRIPTION("QST QMC5883L 3-Axis Magnetic Sensor driver");
+MODULE_AUTHOR("Siratul Islam <siratul.islam@linux.dev>");
+MODULE_LICENSE("Dual BSD/GPL");
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v5] arm64: dts: qcom: glymur: add coresight nodes
From: Konrad Dybcio @ 2026-06-16 11:51 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <a8bb974f-4886-4adb-baf1-9e6c352bc6cc@oss.qualcomm.com>
On 6/12/26 1:11 AM, Jie Gan wrote:
>
>
> On 6/11/2026 5:28 PM, Konrad Dybcio wrote:
>> On 5/19/26 3:14 PM, Jie Gan wrote:
>>> Add CoreSight nodes to enable trace paths like TPDM->ETF/STM->ETF.
>>> These devices are part of the AOSS, CDSP, QDSS, PCIe5, TraceNoc and
>>> some small subsystems, such as GCC, IPCC, PMU and so on.
>>>
>>> Delete cti_wpss DT node on Mahua since this device will cause NoC issue
>>> on Mahua device.
>>
>> Another good explanation is that it simply doesn't exist there!
>>
>>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>
>>> + tpdm-cdsp-llm {
>>
>> Nodes without a unit address should be sorted alphabetically
>>
>>> + compatible = "qcom,coresight-static-tpdm";
>>> + qcom,cmb-element-bits = <32>;
>>
>> Do these other TPDMs not have the "DSB element" as the driver
>> calls it?
>
> Depends on the design of the TPDM.
>
> tpdm-cdsp-llm here only supports CMB mode.
>
> There are three types of TPDM:
> CMB only
> DSB only
> support both
OK, thank you
Konrad
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: dts: qcom: sm8250: sort out Iris power domains
From: Konrad Dybcio @ 2026-06-16 11:52 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Jonathan Marek,
Rafael J. Wysocki, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Mauro Carvalho Chehab, Stanimir Varbanov,
Abhinav Kumar, Hans Verkuil, Stefan Schmidt, Konrad Dybcio,
Bryan O'Donoghue, Dikshita Agarwal, Ulf Hansson,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm,
linux-media, Mauro Carvalho Chehab
In-Reply-To: <ijevonu6ib5daesvvzis53qh5ztufrdlqdsfmx33kiajplqwhm@muhxbznlx5k4>
On 6/12/26 9:55 AM, Dmitry Baryshkov wrote:
> On Wed, Jun 10, 2026 at 03:52:09PM +0200, Konrad Dybcio wrote:
>> On 6/10/26 3:34 PM, Dmitry Baryshkov wrote:
>>> On Wed, Jun 10, 2026 at 02:24:24PM +0200, Konrad Dybcio wrote:
>>>> On 6/4/26 6:22 PM, Dmitry Baryshkov wrote:
>>>>> On SM8250 Iris core requires two power rails to function, MX (for PLLs)
>>>>> and MMCX (for everything else). The commit fa245b3f06cd ("arm64: dts:
>>>>> qcom: sm8250: Add venus DT node") added only MX power rail, but omitted
>>>>> MMCX voltage levels.
>>>>>
>>>>> Add MMCX domain to the Iris device node.
>>>>>
>>>>> Fixes: fa245b3f06cd ("arm64: dts: qcom: sm8250: Add venus DT node")
>>>>> Reported-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> opp-720000000 {
>>>>> opp-hz = /bits/ 64 <720000000>;
>>>>> - required-opps = <&rpmhpd_opp_low_svs>;
>>>>> + required-opps = <&rpmhpd_opp_svs>,
>>>>> + <&rpmhpd_opp_low_svs>;
>>>>
>>>> So the computer tells me low_svs would be enough for PLL0 to generate 720MHz
>>>>
>>>> Is there some transient dependency that bumps this to svs?
>>>>
>>>> Your changelog mentions you altered this in v6, but I don't see any related
>>>> discussion
>>>
>>> There are two sources of information. The "clocks plan" and the "pll
>>> info". For some reason, the clock plan doesn't reflect actual PLL
>>> requirements. See the info on the corresponding PLL type.
>>
>> OK thanks, now I think I asked this already in the past..
>>
>> still, both point to LOWSVS @ 720 for sm8250
>
> Not really, PLL type points to 615. I've posted you the screenshots
> privately (sorry).
Alright then
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ 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