* Re: [PATCH v11 2/7] dt-bindings: media: qcom,x1e80100-camss: Add support for combo-mode endpoints
From: Konrad Dybcio @ 2026-03-27 10:26 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, Bjorn Andersson,
Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Todor Tomov, Mauro Carvalho Chehab,
Konrad Dybcio, Bryan O'Donoghue
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-media,
Krzysztof Kozlowski, Christopher Obbard
In-Reply-To: <540c2a97-00ec-4358-855a-b238aab53860@linaro.org>
On 3/26/26 3:08 AM, Bryan O'Donoghue wrote:
> On 26/03/2026 01:51, Vladimir Zapolskiy wrote:
>> On 3/26/26 03:28, Bryan O'Donoghue wrote:
>>> Qualcomm CSI2 PHYs support a mode where two sensors may be attached to the
>>> one CSIPHY.
>>>
>>> When we have one endpoint we may have
>>> - DPHY 1, 2 or 4 data lanes + 1 clock lane
>>> - CPHY 3 wire data lane
>>>
>>> When we have two endpoints this indicates the special fixed combo-mode.
>>> - DPHY endpoint0 => 2+1 and endpoint1 => 1+1 data-lane/clock-lane combination.
>>>
>>> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>> ---
[...]
>>> + bus-type:
>>> + const: 4 # Combo is D-PHY specific
>>> +
>>
>> It's unclear why both 'bus-type' and 'phys' cell argument are needed
>> at the same time, they are equal and thus one of two is redundant.
>>
>
> bus-type lives on the CAMSS controller endpoint. It tells the V4L2 fwnode parser (v4l2_fwnode_endpoint_parse) how to interpret the endpoint properties — DPHY has data-lanes + clock-lanes, CPHY has trios.
>
> PHY phandle cell lives on the phys reference. It tells the PHY driver which electrical mode to configure
But we don't need that second part, no?
If it's strictly required that we keep the bus-type in DT, we already
store that information once and can translate MEDIA_BUS_TYPE_CSI2_DPHY
to PHY_MODE_MIPI_CSI or whatever before we power on the PHY (which we
wouldn't do without first setting up other bits of the topology anyway)
Konrad
^ permalink raw reply
* Re: [PATCH RESEND] dt-bindings: thermal: qcom-tsens: Add Eliza SoC TSENS
From: Daniel Lezcano @ 2026-03-27 10:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, Amit Kucheria, Thara Gopinath,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
linux-pm, devicetree, linux-kernel
Cc: Konrad Dybcio
In-Reply-To: <20260327100733.365573-2-krzysztof.kozlowski@oss.qualcomm.com>
On 3/27/26 11:07, Krzysztof Kozlowski wrote:
> Document the compatible for Qualcomm Eliza SoC TSENS module, fully
> compatible with TSENS v2 generation (e.g. SM8650).
>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Applied, thanks
^ permalink raw reply
* [PATCH v4 2/2] arch: arm64: boot: dts: qcom: add IMEM and PIL regions for glymur
From: Ananthu C V @ 2026-03-27 10:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, Ananthu C V
In-Reply-To: <20260327-glymur-imem-v4-0-8fe0f20ad9fd@oss.qualcomm.com>
Add an IMEM on glymur which falls back to mmio-sram and define the
PIL relocation info region as its child, for post mortem tools to
locate the loaded remoteprocs.
Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 4886e87ebd49..21ae05f0ee17 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -6457,6 +6457,22 @@ rx-pins {
};
};
+ sram@14680000 {
+ compatible = "qcom,glymur-imem", "mmio-sram";
+ reg = <0x0 0x14680000 0x0 0x1000>;
+ ranges = <0 0 0x14680000 0x1000>;
+
+ no-memory-wc;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ pil-sram@94c {
+ compatible = "qcom,pil-reloc-info";
+ reg = <0x94c 0xc8>;
+ };
+ };
+
apps_smmu: iommu@15000000 {
compatible = "qcom,glymur-smmu-500",
"qcom,smmu-500",
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: sram: document glymur as compatible
From: Ananthu C V @ 2026-03-27 10:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, Ananthu C V
In-Reply-To: <20260327-glymur-imem-v4-0-8fe0f20ad9fd@oss.qualcomm.com>
Add compatible for Qualcomm's glymur IMEM, a block of sram which
can fall back to mmio-sram.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
---
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index c451140962c8..bd62711dc630 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -34,6 +34,7 @@ properties:
- nvidia,tegra186-sysram
- nvidia,tegra194-sysram
- nvidia,tegra234-sysram
+ - qcom,glymur-imem
- qcom,kaanapali-imem
- qcom,rpm-msg-ram
- rockchip,rk3288-pmu-sram
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/2] arm64: dts: qcom: add IMEM and PIL regions for glymur
From: Ananthu C V @ 2026-03-27 10:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, Ananthu C V
This series adds dt binding and node for IMEM on glymur.
changes in v4:
- picked up acked-by for the dt-binding
- added dt node for imem on glymur
- rebased the commits
- link to v3: https://lore.kernel.org/all/20260129071435.2624252-1-ananthu.cv@oss.qualcomm.com/
changes in v3:
- moved dt-binding to sram.yaml for mmio-sram fallback
- link to v2: https://lore.kernel.org/all/20260123101501.2836551-2-ananthu.cv@oss.qualcomm.com/
changes in v2:
- alphabetically sorted the placement of glymur in the list
- link to v1: https://lore.kernel.org/all/20260122093319.2124906-1-ananthu.cv@oss.qualcomm.com/
Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
---
Ananthu C V (2):
dt-bindings: sram: document glymur as compatible
arch: arm64: boot: dts: qcom: add IMEM and PIL regions for glymur
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
arch/arm64/boot/dts/qcom/glymur.dtsi | 16 ++++++++++++++++
2 files changed, 17 insertions(+)
---
base-commit: 6b346ee225a1747218759fc4846aacf203e1eb35
change-id: 20260327-glymur-imem-bfcf2288e5f8
Best regards,
--
Ananthu C V <ananthu.cv@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v9 2/9] lib: vsprintf: export simple_strntoull() in a safe prototype
From: Andy Shevchenko @ 2026-03-27 10:21 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: Petr Mladek, rodrigo.alencar, linux-kernel, linux-iio, devicetree,
linux-doc, Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <4uijfg4efzaapu3esobez55hfwqzszwagpeb4lxej2ybmifu76@s3c57fmnsme6>
On Fri, Mar 27, 2026 at 10:11:56AM +0000, Rodrigo Alencar wrote:
> On 26/03/27 11:17AM, Andy Shevchenko wrote:
> > On Fri, Mar 27, 2026 at 09:45:17AM +0100, Petr Mladek wrote:
> > > On Fri 2026-03-20 16:27:27, Rodrigo Alencar via B4 Relay wrote:
...
> > > > +extern ssize_t __must_check simple_strntoull(const char *startp, const char **endp,
> > > > + unsigned int base, size_t max_chars,
> > > > + unsigned long long *res);
> > >
> > > Sigh, naming is hard. I personally find it a bit confusing that the
> > > name is too similar to the unsafe API.
> > >
> > > IMHO, the semantic of the new API is closer to kstrtoull().
> > > It just limits the size, so I would call it kstrntoull().
> >
> > It's not. kstrto*() quite strict about the input, this one is actually relaxed
> > variant, so I wouldn't mix these two groups.
> >
> > > Also I would use int as the return parameter, see below.
...
> > TBH, I am skeptical about this approach. My main objection is max_chars
> > parameter. If we want to limit the input strictly to the given number of
> > characters, we have to copy the string and then just use kstrto*() in a normal
> > way. The whole idea of that parameter is to be able to parse the fractional
> > part of the float number as 'iiiii.fffff', where 'i' is for integer part, and
> > 'f' for the fractional. Since we have *endp, we may simply check that.
>
> A max_chars would not be only useful for that. It can prevent out-of-bounds
> reads when the input isn't NUL-terminated (like buffers, file chunks,
> network packets, memory-mapped data, ....). Even if there is a NUL later in
> memory, a regular strtoull() function may consume characters that are outside
> the field one intends to parse.
Okay, but is it the current case or just an attempt to solve the problem that
doesn't exist (yet)?
> > In case if we want to parse only, say, 6 digits and input is longer there are
> > a few options (in my personal preferences, the first is the better):
> > - consider the input invalid
> > - parse it as is up to the maximum and then do ceil() or floor() on top of that
> > - copy only necessary amount of the (sub)string and parse that.
>
> Yes, my use case is the fixed point parsing, but I suppose we are implementing
> things here for reuse.
Yes, I'm full for reuse, but I want to have it balanced between complexity,
existing use cases and possible reuse in the future.
> Also, the default behavior of the previous fixed point
> parsing in IIO is flooring the result, which leads to the same result as
> ignoring further digits.
Correct, I also lean to implying floor() (as you can read below).
> > The problem with precision is that we need to also consider floor() or ceil()
> > and I don't think this should be burden of the library as it's individual
> > preference of each of the callers (users). At least for the starter, we will
> > see if it's only one approach is used, we may incorporate it into the library
> > code.
> >
> > The easiest way out is to just consider the input invalid if it overflows the
> > given type (s32 or s64).
> >
> > But we need to have an agreement what will be the representation of the
> > fixed-width float numbers in the kernel? Currently IIO uses
> > struct float // name is crafted for simplicity
> > {
> > int integer;
> > int fraction;
> > }
>
> Yes, but to represent things like that, an assumption is made to the precision that
> "fraction" carries.
Correct.
> > This parser wants AFAIU to have at the end of the day something like
> >
> > struct float
> > {
> > s64 integer;
> > s64 fraction;
> > }
> >
> > but also wants to have the fraction part be limited in some cases to s32
> > or so:
> >
> > struct float
> > {
> > s64 integer;
> > s32 fraction; // precision may be lost if input is longer
> > }
> >
> > Maybe we want to have kstrtof32() and kstrtof64() for these two cases?
> >
> > With that we will always consider the fraction part as 32- or 64-bit,
> > imply floor() on the fraction for the sake of simplicity and require
> > it to be NUL-terminated with possible trailing '\n'.
>
> I think this is a good idea, but calling it float or fixed point itself
> is a bit confusing as float often refers to the IEEE 754 standard and
> fixed point types is often expressed in Q-format.
Yeah... I am lack of better naming.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 5/7] arm64: dts: qcom: sm6125-xiaomi-ginkgo: Add IR transmitter
From: Sean Young @ 2026-03-27 10:20 UTC (permalink / raw)
To: Biswapriyo Nath
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Pavel Machek, Michael Turquette,
Stephen Boyd, Martin Botka, linux-arm-msm, devicetree,
linux-kernel, linux-leds, linux-clk, ~postmarketos/upstreaming,
phone-devel
In-Reply-To: <20260325-ginkgo-add-usb-ir-vib-v1-5-446c6e865ad6@gmail.com>
On Wed, Mar 25, 2026 at 06:07:28PM +0000, Biswapriyo Nath wrote:
> The IR transmitting LED is connected to SPI8 controller.
>
> Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
> ---
> .../boot/dts/qcom/sm6125-xiaomi-ginkgo-common.dtsi | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-ginkgo-common.dtsi b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-ginkgo-common.dtsi
> index f66ff5f7693..7d848117317 100644
> --- a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-ginkgo-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-ginkgo-common.dtsi
> @@ -99,6 +99,10 @@ key-volume-up {
> };
> };
>
> +&gpi_dma1 {
> + status = "okay";
> +};
> +
> &pm6125_gpios {
> vol_up_n: vol-up-n-state {
> pins = "gpio5";
> @@ -160,6 +164,10 @@ &qupv3_id_0 {
> status = "okay";
> };
>
> +&qupv3_id_1 {
> + status = "okay";
> +};
> +
> &rpm_requests {
> regulators-0 {
> compatible = "qcom,rpm-pm6125-regulators";
> @@ -332,6 +340,18 @@ &sdhc_2 {
> status = "okay";
> };
>
> +&spi8 {
> + status = "okay";
> +
> + irled@1 {
> + compatible = "ir-spi-led";
> + reg = <1>;
> +
> + duty-cycle = /bits/ 8 <30>;
> + spi-max-frequency = <1000000>;
> + };
> +};
> +
Reviewed-by: Sean Young <sean@mess.org>
Thanks,
Sean
> &tlmm {
> gpio-reserved-ranges = <0 4>, <30 4>;
> };
>
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Konrad Dybcio @ 2026-03-27 10:19 UTC (permalink / raw)
To: Neil Armstrong, Bryan O'Donoghue, Vladimir Zapolskiy,
Dmitry Baryshkov
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-phy,
linux-media, devicetree, linux-kernel
In-Reply-To: <117d9294-87ce-4060-9c8b-71190b649e64@linaro.org>
On 3/19/26 6:39 PM, Neil Armstrong wrote:
> On 3/19/26 17:56, Bryan O'Donoghue wrote:
>> On 19/03/2026 16:08, Neil Armstrong wrote:
>>> On 3/19/26 16:18, Bryan O'Donoghue wrote:
>>>> On 19/03/2026 14:56, Vladimir Zapolskiy wrote:
>>>>>> There's no reason to remove that from CAMSS - it would be an ABI break
>>>>>> in user-space anyway.
>>>>>
>>>>> If technically CAMSS CSIPHY could be excluded from the list of CAMSS media
>>>>> subdevices, then for the sake of simplification it should be done for all
>>>>> supported platforms in advance, such a change will be independent from this
>>>>> particular phy series, and vice versa, this CAMSS only driver change will
>>>>> prepare a ground for media-less CAMSS CSIPHY device drivers, hence it shall
>>>>> precede this particular CAMSS CSIPHY series.
>>>>>
>>>>> For backward compatibility with userspace a noop stub will be good enough,
>>>>> it's not an issue at all.
>>>>
>>>> The standalone PHY driver doesn't require removing the CSIPHY media
>>>> entity from CAMSS. They serve different purposes and coexist - its important to have a NOP from user-space perspective for legacy and indeed for new implementations.
>>>>
>>>> How the PHY gets represented in the kernel is of zero interest to user-sapce.
>>>>
>>>> That said, stubbing out the media entity is independent work that can happen in any order and IMO is a separate debate. Whether or not CSIPHY init sequences live inside of a monolithic CAMSS driver or live inside off a discrete csiphy driver is not related to the media graph.
>>>>
>>>> Happy to have that debate - and if indicated, carefully apply patches separately.
>>>
>>> So what does this actually solves ?
>>>
>>> Neil
>> Per-PHY voltage rails, per-PHY power domains and per-PHY OPP scaling.
>>
>> Using the PHY API instead of rolling our own, as well as separate nodes in the DT.
>>
>> We've been getting away with power-domains, opp scaling etc by sheer luck. The feedback from the list alone now addressed in this driver makes the conversion worthwhile.
>
> The PHY API doesn't solve that, having proper nodes solves that, you could add a separate csiphy node, add a port/endpoint between camss and the csiphy and attach a camss aux driver to the node, and it would have the same effect with little code change.
> And this could be done for all the CAMSS hardware elements incrementally, and if you wish the move the electrical phy part under the phy API then you just spin a PHY aux driver controlled by the csiphy media element.
>
> I understand you find it simpler to use the phys property in camss, but it has plenty of drawbacks like not be able to describe data link properties specific to the CSIPHY properties or easily describe new hardware layouts without having a fixed association table between phy-names and whatever CAMSS media elements interconnections.
>
> My question would be that if we were to completely split out the CAMSS into several separate nodes linked with port/endpoint graph, to which hardware element the phys would be associated to ? is there a fixed connection between a CSID and a CSIPHY ? is seems the CSID gen2 & gen3 can actually connect to different CSIPHY meaning a CSIPHY is a not simple electrical PHY but can be dynamically connected to different consumers.
> There's no way we can handle that with the PHY API.
Because almost all CAMSS components may be muxed around (at runtime), I
believe the endgame is to have a central place storing references to all
of them (which would end up as "the camss driver") and managing the
actual connections (turning on the respective PHYs, programming routing registers
etc.), based on incoming v4l2 requests
For older targets without that configurability, the same logic could be used,
except with predefined boundaries
Konrad
^ permalink raw reply
* Re: [PATCH 4/7] dt-bindings: leds: irled: ir-spi-led: Add new duty-cycle value
From: Sean Young @ 2026-03-27 10:18 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Biswapriyo Nath, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Pavel Machek,
Michael Turquette, Stephen Boyd, Martin Botka, linux-arm-msm,
devicetree, linux-kernel, linux-leds, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <ad7a0675-84cc-424a-b583-47c342f02fb0@kernel.org>
On Fri, Mar 27, 2026 at 10:38:17AM +0100, Krzysztof Kozlowski wrote:
> On 27/03/2026 09:41, Sean Young wrote:
> > On Fri, Mar 27, 2026 at 08:51:18AM +0100, Krzysztof Kozlowski wrote:
> >> On Wed, Mar 25, 2026 at 06:07:27PM +0000, Biswapriyo Nath wrote:
> >>> 30 duty cycle for IR transmitter is used in Xiaomi Redmi Note 8 (ginkgo).
> >>>
> >>> Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
> >>> ---
> >>> Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml b/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml
> >>> index 72cadebf6e3..0297bfbb275 100644
> >>> --- a/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml
> >>> +++ b/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml
> >>> @@ -25,7 +25,7 @@ properties:
> >>>
> >>> duty-cycle:
> >>> $ref: /schemas/types.yaml#/definitions/uint8
> >>> - enum: [50, 60, 70, 75, 80, 90]
> >>> + enum: [30, 50, 60, 70, 75, 80, 90]
> >>
> >> Hm, why is this enum, instead of 1-99, in the first place?
> >
> > Well in reality only a few different duty cycles are used by IR protocols.
> > 30% is quite common so that should part of the list.
> >
> > Having said that a range of 1-99 would be nicer. Do we set this like so:
> >
> > - minimum: 1
> > - maximum: 99
>
> I asked, because I don't know what hardware is really there. This should
> match reality, so if you say continuous range is never used, it does not
> have the be changed to 1-99.
So the transmit hardware can do an continuous range (almost). It's the
real life usage which doesn't really use many different values.
The value set here is just the default duty cycle. There is also an ioctl
LIRC_SET_SEND_DUTY_CYCLE which sets the duty cycle for transmission.
Most IR drivers just have a hardcoded default value for the duty cycle,
I think ir-spi is the only one which allows this to be set via dt.
I'd say allowing the default to be set via dt is not necessary. If this had
occurred to be during review I would've asked for it to be removed. It's
there now, so:
Reviewed-by: Sean Young <sean@mess.org>
Sean
^ permalink raw reply
* Re: [PATCH v2 2/2] pinctrl: renesas: rzt2h: Add pin configuration support
From: Lad, Prabhakar @ 2026-03-27 10:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, linux-renesas-soc, linux-gpio, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <CAMuHMdXzWFHxeyR4Z4fLUc-QhwPK1RnB5VTzQODjzoR6oDwKHg@mail.gmail.com>
Hi Geert,
Thank you for the review.
On Thu, Mar 26, 2026 at 4:34 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Thu, 19 Mar 2026 at 15:15, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Add pin configuration support for the Renesas RZ/T2H SoC. The RZ/T2H SoC
> > allows configuring several electrical characteristics through the DRCTLm
> > (I/O Buffer Function Switching) registers. These registers control bias
> > configuration, Schmitt trigger input, output slew rate, and drive
> > strength.
> >
> > Implement pinconf_ops to allow reading and updating these properties
> > through the generic pin configuration framework. The implementation
> > supports bias-disable, bias-pull-up, bias-pull-down,
> > input-schmitt-enable, slew-rate, and drive-strength-microamp.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > ---
> > v1->v2:
> > - Updated commit description
> > - Dropped 32 bit reg access for DRCTLm registers
> > - Switched using to guard for locking in rzt2h_pinctrl_drctl_rmwq
> > helper function
> > - Dropped using RENESAS_RZT2H_PIN_CONFIG_DRIVE_STRENGTH instead
> > switched to using the standard PIN_CONFIG_DRIVE_STRENGTH_UA
>
> Thanks for the update!
>
> > --- a/drivers/pinctrl/renesas/pinctrl-rzt2h.c
> > +++ b/drivers/pinctrl/renesas/pinctrl-rzt2h.c
>
> > @@ -54,6 +56,16 @@
> > #define PFC_PIN_MASK(pin) (PFC_MASK << ((pin) * 8))
> > #define PFC_FUNC_INTERRUPT 0
> >
> > +#define DRCTL_PIN_SHIFT(pin) ((pin) << 3)
>
> "* 8" sounds more logical to me.
>
Ok.
> > +#define DRCTL_DRV_PIN_MASK(pin) (GENMASK_ULL(1, 0) << DRCTL_PIN_SHIFT(pin))
> > +#define DRCTL_PUD_PIN_MASK(pin) (GENMASK_ULL(3, 2) << DRCTL_PIN_SHIFT(pin))
> > +#define DRCTL_SMT_PIN_MASK(pin) (BIT_ULL(4) << DRCTL_PIN_SHIFT(pin))
> > +#define DRCTL_SR_PIN_MASK(pin) (BIT_ULL(5) << DRCTL_PIN_SHIFT(pin))
>
> I will drop DRCTL_PIN_SHIFT(), and replace it by "((pin) * 8)" while
> applying, for consistency with e.g. PFC_PIN_MASK() above.
>
Ok, thank you for taking care of it.
Cheers,
Prabhakar
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> i.e. will queue in renesas-pinctrl for v7.1.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
^ permalink raw reply
* [PATCH] arm64: dts: qcom: eliza: Add thermal sensors
From: Krzysztof Kozlowski @ 2026-03-27 10:12 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Add TSENS thermal sensors to Qualcomm Eliza SoC among with thermal
zones. The TSENS is compatible with previous generations.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Binding was waiting for 1.5 months on the lists. Eventually I resent it
now:
https://lore.kernel.org/all/20260327100733.365573-2-krzysztof.kozlowski@oss.qualcomm.com/
so feel free to pick up the DTS with the binding, since it is not being
taken via thermal.
---
arch/arm64/boot/dts/qcom/eliza.dtsi | 561 ++++++++++++++++++++++++++++
1 file changed, 561 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
index 62fccb43a7e8..4a7a0ac40ce6 100644
--- a/arch/arm64/boot/dts/qcom/eliza.dtsi
+++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
@@ -912,6 +912,51 @@ pdc: interrupt-controller@b220000 {
interrupt-controller;
};
+ tsens0: thermal-sensor@c228000 {
+ compatible = "qcom,eliza-tsens", "qcom,tsens-v2";
+ reg = <0x0 0x0c228000 0x0 0x1000>,
+ <0x0 0x0c222000 0x0 0x1000>;
+
+ interrupts = <GIC_SPI 506 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 560 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "uplow",
+ "critical";
+
+ #qcom,sensors = <13>;
+
+ #thermal-sensor-cells = <1>;
+ };
+
+ tsens1: thermal-sensor@c229000 {
+ compatible = "qcom,eliza-tsens", "qcom,tsens-v2";
+ reg = <0x0 0x0c229000 0x0 0x1000>,
+ <0x0 0x0c223000 0x0 0x1000>;
+
+ interrupts = <GIC_SPI 507 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 561 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "uplow",
+ "critical";
+
+ #qcom,sensors = <14>;
+
+ #thermal-sensor-cells = <1>;
+ };
+
+ tsens2: thermal-sensor@c22a000 {
+ compatible = "qcom,eliza-tsens", "qcom,tsens-v2";
+ reg = <0x0 0x0c22a000 0x0 0x1000>,
+ <0x0 0x0c224000 0x0 0x1000>;
+
+ interrupts = <GIC_SPI 508 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 562 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "uplow",
+ "critical";
+
+ #qcom,sensors = <5>;
+
+ #thermal-sensor-cells = <1>;
+ };
+
spmi: arbiter@c400000 {
compatible = "qcom,eliza-spmi-pmic-arb",
"qcom,x1e80100-spmi-pmic-arb";
@@ -1313,6 +1358,522 @@ nsp_noc: interconnect@320c0000 {
};
};
+ thermal-zones {
+ aoss0-thermal {
+ thermal-sensors = <&tsens0 0>;
+
+ trips {
+ aoss-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ aoss-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ aoss1-thermal {
+ thermal-sensors = <&tsens1 0>;
+
+ trips {
+ aoss-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ aoss-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ aoss2-thermal {
+ thermal-sensors = <&tsens2 0>;
+
+ trips {
+ aoss-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ aoss-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ camera0-thermal {
+ thermal-sensors = <&tsens1 12>;
+
+ trips {
+ camera-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ camera-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ camera1-thermal {
+ thermal-sensors = <&tsens1 13>;
+
+ trips {
+ camera-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ camera-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu0-thermal {
+ thermal-sensors = <&tsens1 1>;
+
+ trips {
+ cpu-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu1-thermal {
+ thermal-sensors = <&tsens1 2>;
+
+ trips {
+ cpu-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu2-thermal {
+ thermal-sensors = <&tsens1 3>;
+
+ trips {
+ cpu-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu3-top-thermal {
+ thermal-sensors = <&tsens0 3>;
+
+ trips {
+ cpu-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu3-bottom-thermal {
+ thermal-sensors = <&tsens0 4>;
+
+ trips {
+ cpu-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu4-top-thermal {
+ thermal-sensors = <&tsens0 5>;
+
+ trips {
+ cpu-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu4-bottom-thermal {
+ thermal-sensors = <&tsens0 6>;
+
+ trips {
+ cpu-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu5-top-thermal {
+ thermal-sensors = <&tsens0 7>;
+
+ trips {
+ cpu-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu5-bottom-thermal {
+ thermal-sensors = <&tsens0 8>;
+
+ trips {
+ cpu-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu6-top-thermal {
+ thermal-sensors = <&tsens0 9>;
+
+ trips {
+ cpu-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu6-bottom-thermal {
+ thermal-sensors = <&tsens0 10>;
+
+ trips {
+ cpu-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu7-top-thermal {
+ thermal-sensors = <&tsens0 11>;
+
+ trips {
+ cpu-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu7-bottom-thermal {
+ thermal-sensors = <&tsens0 12>;
+
+ trips {
+ cpu-critical {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpuss0-thermal {
+ thermal-sensors = <&tsens0 1>;
+
+ trips {
+ cpuss-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ cpuss-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpuss1-thermal {
+ thermal-sensors = <&tsens0 2>;
+
+ trips {
+ cpuss-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ cpuss-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ ddr-thermal {
+ thermal-sensors = <&tsens1 11>;
+
+ trips {
+ ddr-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ ddr-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ gpuss0-thermal {
+ polling-delay-passive = <10>;
+
+ thermal-sensors = <&tsens1 8>;
+
+ trips {
+ gpu-alert {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+
+ gpu-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ gpu-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ gpuss1-thermal {
+ polling-delay-passive = <10>;
+
+ thermal-sensors = <&tsens1 9>;
+
+ trips {
+ gpu-alert {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+
+ gpu-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ gpu-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ modem0-thermal {
+ thermal-sensors = <&tsens2 1>;
+
+ trips {
+ modem-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ modem-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ modem1-thermal {
+ thermal-sensors = <&tsens2 2>;
+
+ trips {
+ modem-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ modem-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ modem2-thermal {
+ thermal-sensors = <&tsens2 3>;
+
+ trips {
+ modem-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ modem-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ modem3-thermal {
+ thermal-sensors = <&tsens2 4>;
+
+ trips {
+ modem-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ modem-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ nsphmx0-thermal {
+ thermal-sensors = <&tsens1 6>;
+
+ trips {
+ nsphmx-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ nsphmx-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ nsphmx1-thermal {
+ thermal-sensors = <&tsens1 7>;
+
+ trips {
+ nsphmx-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ nsphmx-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ nsphvx0-thermal {
+ thermal-sensors = <&tsens1 4>;
+
+ trips {
+ nsphvx-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ nsphvx-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ nsphvx1-thermal {
+ thermal-sensors = <&tsens1 5>;
+
+ trips {
+ nsphvx-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ nsphvx-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ video-thermal {
+ thermal-sensors = <&tsens1 10>;
+
+ trips {
+ video-hot {
+ temperature = <110000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+
+ video-critical {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+ };
+
timer {
compatible = "arm,armv8-timer";
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v9 2/9] lib: vsprintf: export simple_strntoull() in a safe prototype
From: Rodrigo Alencar @ 2026-03-27 10:11 UTC (permalink / raw)
To: Andy Shevchenko, Petr Mladek
Cc: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc,
Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <acZLHAT5qJyjKTsp@ashevche-desk.local>
On 26/03/27 11:17AM, Andy Shevchenko wrote:
> On Fri, Mar 27, 2026 at 09:45:17AM +0100, Petr Mladek wrote:
> > On Fri 2026-03-20 16:27:27, Rodrigo Alencar via B4 Relay wrote:
>
> ...
>
> > > +extern ssize_t __must_check simple_strntoull(const char *startp, const char **endp,
> > > + unsigned int base, size_t max_chars,
> > > + unsigned long long *res);
> >
> > Sigh, naming is hard. I personally find it a bit confusing that the
> > name is too similar to the unsafe API.
> >
> > IMHO, the semantic of the new API is closer to kstrtoull().
> > It just limits the size, so I would call it kstrntoull().
>
> It's not. kstrto*() quite strict about the input, this one is actually relaxed
> variant, so I wouldn't mix these two groups.
>
> > Also I would use int as the return parameter, see below.
>
> ...
>
> TBH, I am skeptical about this approach. My main objection is max_chars
> parameter. If we want to limit the input strictly to the given number of
> characters, we have to copy the string and then just use kstrto*() in a normal
> way. The whole idea of that parameter is to be able to parse the fractional
> part of the float number as 'iiiii.fffff', where 'i' is for integer part, and
> 'f' for the fractional. Since we have *endp, we may simply check that.
A max_chars would not be only useful for that. It can prevent out-of-bounds
reads when the input isn't NUL-terminated (like buffers, file chunks,
network packets, memory-mapped data, ....). Even if there is a NUL later in
memory, a regular strtoull() function may consume characters that are outside
the field one intends to parse.
> In case if we want to parse only, say, 6 digits and input is longer there are
> a few options (in my personal preferences, the first is the better):
> - consider the input invalid
> - parse it as is up to the maximum and then do ceil() or floor() on top of that
> - copy only necessary amount of the (sub)string and parse that.
Yes, my use case is the fixed point parsing, but I suppose we are implementing
things here for reuse. Also, the default behavior of the previous fixed point
parsing in IIO is flooring the result, which leads to the same result as
ignoring further digits.
> The problem with precision is that we need to also consider floor() or ceil()
> and I don't think this should be burden of the library as it's individual
> preference of each of the callers (users). At least for the starter, we will
> see if it's only one approach is used, we may incorporate it into the library
> code.
>
> The easiest way out is to just consider the input invalid if it overflows the
> given type (s32 or s64).
>
> But we need to have an agreement what will be the representation of the
> fixed-width float numbers in the kernel? Currently IIO uses
> struct float // name is crafted for simplicity
> {
> int integer;
> int fraction;
> }
Yes, but to represent things like that, an assumption is made to the precision that
"fraction" carries.
>
> This parser wants AFAIU to have at the end of the day something like
>
> struct float
> {
> s64 integer;
> s64 fraction;
> }
>
> but also wants to have the fraction part be limited in some cases to s32
> or so:
>
> struct float
> {
> s64 integer;
> s32 fraction; // precision may be lost if input is longer
> }
>
> Maybe we want to have kstrtof32() and kstrtof64() for these two cases?
>
> With that we will always consider the fraction part as 32- or 64-bit,
> imply floor() on the fraction for the sake of simplicity and require
> it to be NUL-terminated with possible trailing '\n'.
I think this is a good idea, but calling it float or fixed point itself
is a bit confusing as float often refers to the IEEE 754 standard and
fixed point types is often expressed in Q-format.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH net-next 2/5] dpll: zl3073x: use FIELD_MODIFY() for clear-and-set patterns
From: Petr Oros @ 2026-03-27 10:11 UTC (permalink / raw)
To: Ivan Vecera, netdev
Cc: Arkadiusz Kubalewski, Jiri Pirko, Michal Schmidt, Prathosh Satish,
Simon Horman, Vadim Fedorenko, linux-kernel, Conor Dooley,
Krzysztof Kozlowski, Rob Herring, devicetree, Pasi Vaananen
In-Reply-To: <20260319174826.7623-3-ivecera@redhat.com>
> Replace open-coded clear-and-set bitfield operations with
> FIELD_MODIFY().
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
> drivers/dpll/zl3073x/chan.h | 17 ++++++-----------
> drivers/dpll/zl3073x/core.c | 3 +--
> drivers/dpll/zl3073x/flash.c | 3 +--
> 3 files changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/dpll/zl3073x/chan.h b/drivers/dpll/zl3073x/chan.h
> index e0f02d3432086..481da2133202b 100644
> --- a/drivers/dpll/zl3073x/chan.h
> +++ b/drivers/dpll/zl3073x/chan.h
> @@ -66,8 +66,7 @@ static inline u8 zl3073x_chan_ref_get(const struct zl3073x_chan *chan)
> */
> static inline void zl3073x_chan_mode_set(struct zl3073x_chan *chan, u8 mode)
> {
> - chan->mode_refsel &= ~ZL_DPLL_MODE_REFSEL_MODE;
> - chan->mode_refsel |= FIELD_PREP(ZL_DPLL_MODE_REFSEL_MODE, mode);
> + FIELD_MODIFY(ZL_DPLL_MODE_REFSEL_MODE, &chan->mode_refsel, mode);
> }
>
> /**
> @@ -77,8 +76,7 @@ static inline void zl3073x_chan_mode_set(struct zl3073x_chan *chan, u8 mode)
> */
> static inline void zl3073x_chan_ref_set(struct zl3073x_chan *chan, u8 ref)
> {
> - chan->mode_refsel &= ~ZL_DPLL_MODE_REFSEL_REF;
> - chan->mode_refsel |= FIELD_PREP(ZL_DPLL_MODE_REFSEL_REF, ref);
> + FIELD_MODIFY(ZL_DPLL_MODE_REFSEL_REF, &chan->mode_refsel, ref);
> }
>
> /**
> @@ -110,13 +108,10 @@ zl3073x_chan_ref_prio_set(struct zl3073x_chan *chan, u8 ref, u8 prio)
> {
> u8 *val = &chan->ref_prio[ref / 2];
>
> - if (!(ref & 1)) {
> - *val &= ~ZL_DPLL_REF_PRIO_REF_P;
> - *val |= FIELD_PREP(ZL_DPLL_REF_PRIO_REF_P, prio);
> - } else {
> - *val &= ~ZL_DPLL_REF_PRIO_REF_N;
> - *val |= FIELD_PREP(ZL_DPLL_REF_PRIO_REF_N, prio);
> - }
> + if (!(ref & 1))
> + FIELD_MODIFY(ZL_DPLL_REF_PRIO_REF_P, val, prio);
> + else
> + FIELD_MODIFY(ZL_DPLL_REF_PRIO_REF_N, val, prio);
> }
>
> /**
> diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c
> index 6363002d48d46..7eebfc1ad1019 100644
> --- a/drivers/dpll/zl3073x/core.c
> +++ b/drivers/dpll/zl3073x/core.c
> @@ -743,8 +743,7 @@ int zl3073x_dev_phase_avg_factor_set(struct zl3073x_dev *zldev, u8 factor)
> value = (factor + 1) & 0x0f;
>
> /* Update phase measurement control register */
> - dpll_meas_ctrl &= ~ZL_DPLL_MEAS_CTRL_AVG_FACTOR;
> - dpll_meas_ctrl |= FIELD_PREP(ZL_DPLL_MEAS_CTRL_AVG_FACTOR, value);
> + FIELD_MODIFY(ZL_DPLL_MEAS_CTRL_AVG_FACTOR, &dpll_meas_ctrl, value);
> rc = zl3073x_write_u8(zldev, ZL_REG_DPLL_MEAS_CTRL, dpll_meas_ctrl);
> if (rc)
> return rc;
> diff --git a/drivers/dpll/zl3073x/flash.c b/drivers/dpll/zl3073x/flash.c
> index 83452a77e3e98..f85535c8ad246 100644
> --- a/drivers/dpll/zl3073x/flash.c
> +++ b/drivers/dpll/zl3073x/flash.c
> @@ -194,8 +194,7 @@ zl3073x_flash_cmd_wait(struct zl3073x_dev *zldev, u32 operation,
> if (rc)
> return rc;
>
> - value &= ~ZL_WRITE_FLASH_OP;
> - value |= FIELD_PREP(ZL_WRITE_FLASH_OP, operation);
> + FIELD_MODIFY(ZL_WRITE_FLASH_OP, &value, operation);
>
> rc = zl3073x_write_u8(zldev, ZL_REG_WRITE_FLASH, value);
> if (rc)
LGTM.
Reviewed-by: Petr Oros <poros@redhat.com>
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Konrad Dybcio @ 2026-03-27 10:10 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <7712fbdd-a225-49f0-aeb9-ebcbb9d5abac@oss.qualcomm.com>
On 3/27/26 11:07 AM, Konrad Dybcio wrote:
> On 3/26/26 2:04 AM, Bryan O'Donoghue wrote:
>> Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
>> PHY devices.
>>
>> The hardware can support both CPHY, DPHY and a special split-mode DPHY. We
>> capture those modes as:
>>
>> - PHY_QCOM_CSI2_MODE_DPHY
>> - PHY_QCOM_CSI2_MODE_CPHY
>> - PHY_QCOM_CSI2_MODE_SPLIT_DPHY
>
> Does the _PHY_ DT node need to be aware about this upfront?
>
> If we have some sideband signal (e.g. the sensor driver specifically
> requesting C-PHY mode), we can simply throw all this complexity into
> phy_mode + phy_configure_opts, all at runtime
Actually perhaps just phy_configure_opts, because phy_mode could be left
as "MIPI_CSI" to reduce complexity (while still carrying info about D/C
mode in the latter)
Konrad
^ permalink raw reply
* [PATCH v7 5/5] arm64: dts: qcom: hamoa-iot-evk: Add Embedded controller node
From: Anvesh Jain P @ 2026-03-27 10:08 UTC (permalink / raw)
To: Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Randy Dunlap
Cc: linux-arm-msm, devicetree, linux-kernel, platform-driver-x86,
Anvesh Jain P, Dmitry Baryshkov, Konrad Dybcio, Gaurav Kohli
In-Reply-To: <20260327-add-driver-for-ec-v7-0-7684c915e42c@oss.qualcomm.com>
From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Add embedded controller node for Hamoa IOT EVK boards which adds fan
control, temperature sensors, access to EC internal state changes and
suspend entry/exit notifications to the EC.
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Tested-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
index 460f27dcd6f6..a0d2ccf931ec 100644
--- a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
+++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
@@ -831,6 +831,16 @@ eusb6_repeater: redriver@4f {
pinctrl-0 = <&eusb6_reset_n>;
pinctrl-names = "default";
};
+
+ embedded-controller@76 {
+ compatible = "qcom,hamoa-iot-evk-ec", "qcom,hamoa-crd-ec";
+ reg = <0x76>;
+
+ interrupts-extended = <&tlmm 66 IRQ_TYPE_EDGE_FALLING>;
+
+ pinctrl-0 = <&ec_int_n_default>;
+ pinctrl-names = "default";
+ };
};
&i2c7 {
@@ -1320,6 +1330,12 @@ right_tweeter: speaker@0,1 {
};
&tlmm {
+ ec_int_n_default: ec-int-n-state {
+ pins = "gpio66";
+ function = "gpio";
+ bias-disable;
+ };
+
edp_reg_en: edp-reg-en-state {
pins = "gpio70";
function = "gpio";
--
2.34.1
^ permalink raw reply related
* [PATCH v7 4/5] arm64: dts: qcom: x1-crd: Add Embedded controller node
From: Anvesh Jain P @ 2026-03-27 10:08 UTC (permalink / raw)
To: Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Randy Dunlap
Cc: linux-arm-msm, devicetree, linux-kernel, platform-driver-x86,
Anvesh Jain P, Dmitry Baryshkov, Konrad Dybcio, Abel Vesa
In-Reply-To: <20260327-add-driver-for-ec-v7-0-7684c915e42c@oss.qualcomm.com>
From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Add embedded controller node for Hamoa/Purwa CRDs which adds fan control,
temperature sensors, access to EC internal state changes and suspend
entry/exit notifications to the EC.
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/x1-crd.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/x1-crd.dtsi b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
index 485dcd946757..1184169f49cc 100644
--- a/arch/arm64/boot/dts/qcom/x1-crd.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
@@ -1074,6 +1074,16 @@ eusb6_repeater: redriver@4f {
#phy-cells = <0>;
};
+
+ embedded-controller@76 {
+ compatible = "qcom,hamoa-crd-ec";
+ reg = <0x76>;
+
+ interrupts-extended = <&tlmm 66 IRQ_TYPE_EDGE_FALLING>;
+
+ pinctrl-0 = <&ec_int_n_default>;
+ pinctrl-names = "default";
+ };
};
&i2c7 {
@@ -1517,6 +1527,12 @@ &tlmm {
<44 4>, /* SPI (TPM) */
<238 1>; /* UFS Reset */
+ ec_int_n_default: ec-int-n-state {
+ pins = "gpio66";
+ function = "gpio";
+ bias-disable;
+ };
+
edp_reg_en: edp-reg-en-state {
pins = "gpio70";
function = "gpio";
--
2.34.1
^ permalink raw reply related
* [PATCH v7 3/5] arm64: dts: qcom: glymur-crd: Add Embedded controller node
From: Anvesh Jain P @ 2026-03-27 10:08 UTC (permalink / raw)
To: Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Randy Dunlap
Cc: linux-arm-msm, devicetree, linux-kernel, platform-driver-x86,
Anvesh Jain P, Dmitry Baryshkov, Konrad Dybcio, Abel Vesa
In-Reply-To: <20260327-add-driver-for-ec-v7-0-7684c915e42c@oss.qualcomm.com>
From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Add embedded controller node for Glymur CRDs which adds fan control,
temperature sensors, access to EC state changes through SCI events
and suspend entry/exit notifications to the EC.
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur-crd.dts | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dts b/arch/arm64/boot/dts/qcom/glymur-crd.dts
index 51ea23a49b9e..1a69b428307f 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dts
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dts
@@ -198,6 +198,22 @@ ptn3222_1: redriver@47 {
};
};
+&i2c9 {
+ clock-frequency = <400000>;
+
+ status = "okay";
+
+ embedded-controller@76 {
+ compatible = "qcom,glymur-crd-ec", "qcom,hamoa-crd-ec";
+ reg = <0x76>;
+
+ interrupts-extended = <&tlmm 66 IRQ_TYPE_EDGE_FALLING>;
+
+ pinctrl-0 = <&ec_int_n_default>;
+ pinctrl-names = "default";
+ };
+};
+
&mdss {
status = "okay";
};
@@ -263,6 +279,12 @@ &smb2370_k_e2_eusb2_repeater {
};
&tlmm {
+ ec_int_n_default: ec-int-n-state {
+ pins = "gpio66";
+ function = "gpio";
+ bias-disable;
+ };
+
edp_bl_en: edp-bl-en-state {
pins = "gpio18";
function = "gpio";
--
2.34.1
^ permalink raw reply related
* [PATCH v7 2/5] platform: arm64: Add driver for EC found on Qualcomm reference devices
From: Anvesh Jain P @ 2026-03-27 10:08 UTC (permalink / raw)
To: Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Randy Dunlap
Cc: linux-arm-msm, devicetree, linux-kernel, platform-driver-x86,
Anvesh Jain P, Maya Matuszczyk, Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260327-add-driver-for-ec-v7-0-7684c915e42c@oss.qualcomm.com>
From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Add Embedded controller driver support for Hamoa/Purwa/Glymur qualcomm
reference boards. It handles fan control, temperature sensors, access
to EC state changes and supports reporting suspend entry/exit to the
EC.
Co-developed-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
---
MAINTAINERS | 8 +
drivers/platform/arm64/Kconfig | 12 +
drivers/platform/arm64/Makefile | 1 +
drivers/platform/arm64/qcom-hamoa-ec.c | 451 +++++++++++++++++++++++++++++++++
4 files changed, 472 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 30ca84404976..536dfd9adff4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21804,6 +21804,14 @@ F: Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
F: drivers/misc/fastrpc.c
F: include/uapi/misc/fastrpc.h
+QUALCOMM HAMOA EMBEDDED CONTROLLER DRIVER
+M: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
+M: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
+L: linux-arm-msm@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-ec.yaml
+F: drivers/platform/arm64/qcom-hamoa-ec.c
+
QUALCOMM HEXAGON ARCHITECTURE
M: Brian Cain <brian.cain@oss.qualcomm.com>
L: linux-hexagon@vger.kernel.org
diff --git a/drivers/platform/arm64/Kconfig b/drivers/platform/arm64/Kconfig
index 10f905d7d6bf..025cdf091f9e 100644
--- a/drivers/platform/arm64/Kconfig
+++ b/drivers/platform/arm64/Kconfig
@@ -90,4 +90,16 @@ config EC_LENOVO_THINKPAD_T14S
Say M or Y here to include this support.
+config EC_QCOM_HAMOA
+ tristate "Embedded Controller driver for Qualcomm Hamoa/Glymur reference devices"
+ depends on ARCH_QCOM || COMPILE_TEST
+ depends on I2C
+ help
+ Say M or Y here to enable the Embedded Controller driver for Qualcomm
+ Snapdragon-based Hamoa/Glymur reference devices. The driver handles fan
+ control, temperature sensors, access to EC state changes and supports
+ reporting suspend entry/exit to the EC.
+
+ This driver currently supports Hamoa/Purwa/Glymur reference devices.
+
endif # ARM64_PLATFORM_DEVICES
diff --git a/drivers/platform/arm64/Makefile b/drivers/platform/arm64/Makefile
index 60c131cff6a1..7681be4a46e9 100644
--- a/drivers/platform/arm64/Makefile
+++ b/drivers/platform/arm64/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_EC_ACER_ASPIRE1) += acer-aspire1-ec.o
obj-$(CONFIG_EC_HUAWEI_GAOKUN) += huawei-gaokun-ec.o
obj-$(CONFIG_EC_LENOVO_YOGA_C630) += lenovo-yoga-c630.o
obj-$(CONFIG_EC_LENOVO_THINKPAD_T14S) += lenovo-thinkpad-t14s.o
+obj-$(CONFIG_EC_QCOM_HAMOA) += qcom-hamoa-ec.o
diff --git a/drivers/platform/arm64/qcom-hamoa-ec.c b/drivers/platform/arm64/qcom-hamoa-ec.c
new file mode 100644
index 000000000000..0f883130ac9a
--- /dev/null
+++ b/drivers/platform/arm64/qcom-hamoa-ec.c
@@ -0,0 +1,451 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2024 Maya Matuszczyk <maccraft123mc@gmail.com>
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/pm.h>
+#include <linux/slab.h>
+#include <linux/thermal.h>
+
+#define EC_SCI_EVT_READ_CMD 0x05
+#define EC_FW_VERSION_CMD 0x0e
+#define EC_MODERN_STANDBY_CMD 0x23
+#define EC_FAN_DBG_CONTROL_CMD 0x30
+#define EC_SCI_EVT_CONTROL_CMD 0x35
+#define EC_THERMAL_CAP_CMD 0x42
+
+#define EC_FW_VERSION_RESP_LEN 4
+#define EC_THERMAL_CAP_RESP_LEN 3
+#define EC_FAN_DEBUG_CMD_LEN 6
+#define EC_FAN_SPEED_DATA_SIZE 4
+
+#define EC_MODERN_STANDBY_ENTER 0x01
+#define EC_MODERN_STANDBY_EXIT 0x00
+
+#define EC_FAN_DEBUG_MODE_OFF 0
+#define EC_FAN_DEBUG_MODE_ON BIT(0)
+#define EC_FAN_ON BIT(1)
+#define EC_FAN_DEBUG_TYPE_PWM BIT(2)
+#define EC_MAX_FAN_CNT 2
+#define EC_FAN_NAME_SIZE 20
+#define EC_FAN_MAX_PWM 255
+
+enum qcom_ec_sci_events {
+ EC_FAN1_STATUS_CHANGE_EVT = 0x30,
+ EC_FAN2_STATUS_CHANGE_EVT,
+ EC_FAN1_SPEED_CHANGE_EVT,
+ EC_FAN2_SPEED_CHANGE_EVT,
+ EC_NEW_LUT_SET_EVT,
+ EC_FAN_PROFILE_SWITCH_EVT,
+ EC_THERMISTOR_1_THRESHOLD_CROSS_EVT,
+ EC_THERMISTOR_2_THRESHOLD_CROSS_EVT,
+ EC_THERMISTOR_3_THRESHOLD_CROSS_EVT,
+ /* Reserved: 0x39 - 0x3c/0x3f */
+ EC_RECOVERED_FROM_RESET_EVT = 0x3d,
+};
+
+struct qcom_ec_version {
+ u8 main_version;
+ u8 sub_version;
+ u8 test_version;
+};
+
+struct qcom_ec_thermal_cap {
+#define EC_THERMAL_FAN_CNT(x) (FIELD_GET(GENMASK(1, 0), (x)))
+#define EC_THERMAL_FAN_TYPE(x) (FIELD_GET(GENMASK(4, 2), (x)))
+#define EC_THERMAL_THERMISTOR_MASK(x) (FIELD_GET(GENMASK(7, 0), (x)))
+ u8 fan_cnt;
+ u8 fan_type;
+ u8 thermistor_mask;
+};
+
+struct qcom_ec_cooling_dev {
+ struct thermal_cooling_device *cdev;
+ struct device *parent_dev;
+ u8 fan_id;
+ u8 state;
+};
+
+struct qcom_ec {
+ struct qcom_ec_cooling_dev *ec_cdev;
+ struct qcom_ec_thermal_cap thermal_cap;
+ struct qcom_ec_version version;
+ struct i2c_client *client;
+};
+
+static int qcom_ec_read(struct qcom_ec *ec, u8 cmd, u8 resp_len, u8 *resp)
+{
+ int ret;
+
+ ret = i2c_smbus_read_i2c_block_data(ec->client, cmd, resp_len, resp);
+
+ if (ret < 0)
+ return ret;
+ else if (ret == 0 || ret == 0xff)
+ return -EOPNOTSUPP;
+
+ if (resp[0] >= resp_len)
+ return -EINVAL;
+
+ return 0;
+}
+
+/*
+ * EC Device Firmware Version:
+ *
+ * Read Response:
+ * ----------------------------------------------------------------------
+ * | Offset | Name | Description |
+ * ----------------------------------------------------------------------
+ * | 0x00 | Byte count | Number of bytes in response |
+ * | | | (excluding byte count) |
+ * ----------------------------------------------------------------------
+ * | 0x01 | Test-version | Test-version of EC firmware |
+ * ----------------------------------------------------------------------
+ * | 0x02 | Sub-version | Sub-version of EC firmware |
+ * ----------------------------------------------------------------------
+ * | 0x03 | Main-version | Main-version of EC firmware |
+ * ----------------------------------------------------------------------
+ *
+ */
+static int qcom_ec_read_fw_version(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct qcom_ec *ec = i2c_get_clientdata(client);
+ struct qcom_ec_version *version = &ec->version;
+ u8 resp[EC_FW_VERSION_RESP_LEN];
+ int ret;
+
+ ret = qcom_ec_read(ec, EC_FW_VERSION_CMD, EC_FW_VERSION_RESP_LEN, resp);
+ if (ret < 0)
+ return ret;
+
+ version->main_version = resp[3];
+ version->sub_version = resp[2];
+ version->test_version = resp[1];
+
+ dev_dbg(dev, "EC Version %d.%d.%d\n",
+ version->main_version, version->sub_version, version->test_version);
+
+ return 0;
+}
+
+/*
+ * EC Device Thermal Capabilities:
+ *
+ * Read Response:
+ * ------------------------------------------------------------------------------
+ * | Offset | Name | Description |
+ * ------------------------------------------------------------------------------
+ * | 0x00 | Byte count | Number of bytes in response |
+ * | | | (excluding byte count) |
+ * ------------------------------------------------------------------------------
+ * | 0x02 (LSB) | EC Thermal | Bit 0-1: Number of fans |
+ * | 0x3 | Capabilities | Bit 2-4: Type of fan |
+ * | | | Bit 5-6: Reserved |
+ * | | | Bit 7: Data Valid/Invalid |
+ * | | | (Valid - 1, Invalid - 0) |
+ * | | | Bit 8-15: Thermistor 0 - 7 presence |
+ * | | | (1 present, 0 absent) |
+ * ------------------------------------------------------------------------------
+ *
+ */
+static int qcom_ec_thermal_capabilities(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct qcom_ec *ec = i2c_get_clientdata(client);
+ struct qcom_ec_thermal_cap *cap = &ec->thermal_cap;
+ u8 resp[EC_THERMAL_CAP_RESP_LEN];
+ int ret;
+
+ ret = qcom_ec_read(ec, EC_THERMAL_CAP_CMD, EC_THERMAL_CAP_RESP_LEN, resp);
+ if (ret < 0)
+ return ret;
+
+ cap->fan_cnt = min(EC_MAX_FAN_CNT, EC_THERMAL_FAN_CNT(resp[1]));
+ cap->fan_type = EC_THERMAL_FAN_TYPE(resp[1]);
+ cap->thermistor_mask = EC_THERMAL_THERMISTOR_MASK(resp[2]);
+
+ dev_dbg(dev, "Fan count: %d Fan Type: %d Thermistor Mask: %x\n",
+ cap->fan_cnt, cap->fan_type, cap->thermistor_mask);
+
+ return 0;
+}
+
+static irqreturn_t qcom_ec_irq(int irq, void *data)
+{
+ struct qcom_ec *ec = data;
+ struct device *dev = &ec->client->dev;
+ int val;
+
+ val = i2c_smbus_read_byte_data(ec->client, EC_SCI_EVT_READ_CMD);
+ if (val < 0) {
+ dev_err_ratelimited(dev, "Failed to read EC SCI Event: %d\n", val);
+ return IRQ_HANDLED;
+ }
+
+ switch (val) {
+ case EC_FAN1_STATUS_CHANGE_EVT:
+ dev_dbg_ratelimited(dev, "Fan1 status changed\n");
+ break;
+ case EC_FAN2_STATUS_CHANGE_EVT:
+ dev_dbg_ratelimited(dev, "Fan2 status changed\n");
+ break;
+ case EC_FAN1_SPEED_CHANGE_EVT:
+ dev_dbg_ratelimited(dev, "Fan1 speed crossed low/high trip point\n");
+ break;
+ case EC_FAN2_SPEED_CHANGE_EVT:
+ dev_dbg_ratelimited(dev, "Fan2 speed crossed low/high trip point\n");
+ break;
+ case EC_NEW_LUT_SET_EVT:
+ dev_dbg_ratelimited(dev, "New LUT set\n");
+ break;
+ case EC_FAN_PROFILE_SWITCH_EVT:
+ dev_dbg_ratelimited(dev, "FAN Profile switched\n");
+ break;
+ case EC_THERMISTOR_1_THRESHOLD_CROSS_EVT:
+ dev_dbg_ratelimited(dev, "Thermistor 1 threshold crossed\n");
+ break;
+ case EC_THERMISTOR_2_THRESHOLD_CROSS_EVT:
+ dev_dbg_ratelimited(dev, "Thermistor 2 threshold crossed\n");
+ break;
+ case EC_THERMISTOR_3_THRESHOLD_CROSS_EVT:
+ dev_dbg_ratelimited(dev, "Thermistor 3 threshold crossed\n");
+ break;
+ case EC_RECOVERED_FROM_RESET_EVT:
+ dev_dbg_ratelimited(dev, "EC recovered from reset\n");
+ break;
+ default:
+ dev_notice_ratelimited(dev, "Unknown EC event: %d\n", val);
+ break;
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int qcom_ec_sci_evt_control(struct device *dev, bool enable)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+
+ return i2c_smbus_write_byte_data(client, EC_SCI_EVT_CONTROL_CMD, !!enable);
+}
+
+static int qcom_ec_fan_get_max_state(struct thermal_cooling_device *cdev, unsigned long *state)
+{
+ *state = EC_FAN_MAX_PWM;
+
+ return 0;
+}
+
+static int qcom_ec_fan_get_cur_state(struct thermal_cooling_device *cdev, unsigned long *state)
+{
+ struct qcom_ec_cooling_dev *ec_cdev = cdev->devdata;
+
+ *state = ec_cdev->state;
+
+ return 0;
+}
+
+/*
+ * Fan Debug control command:
+ *
+ * Command Payload:
+ * --------------------------------------------------------------------------------------
+ * | Offset | Name | Description |
+ * --------------------------------------------------------------------------------------
+ * | 0x00 | Command | Fan control command |
+ * --------------------------------------------------------------------------------------
+ * | 0x01 | Fan ID | 0x1 : Fan 1 |
+ * | | | 0x2 : Fan 2 |
+ * --------------------------------------------------------------------------------------
+ * | 0x02 | Byte count = 4| Size of data to set fan speed |
+ * --------------------------------------------------------------------------------------
+ * | 0x03 | Mode | Bit 0: Debug Mode On/Off (0 - OFF, 1 - ON ) |
+ * | | | Bit 1: Fan On/Off (0 - Off, 1 - ON) |
+ * | | | Bit 2: Debug Type (0 - RPM, 1 - PWM) |
+ * --------------------------------------------------------------------------------------
+ * | 0x04 (LSB) | Speed in RPM | RPM value, if mode selected is RPM |
+ * | 0x05 | | |
+ * --------------------------------------------------------------------------------------
+ * | 0x06 | Speed in PWM | PWM value, if mode selected is PWM (0 - 255) |
+ * ______________________________________________________________________________________
+ *
+ */
+static int qcom_ec_fan_debug_mode_off(struct qcom_ec_cooling_dev *ec_cdev)
+{
+ struct device *dev = ec_cdev->parent_dev;
+ struct i2c_client *client = to_i2c_client(dev);
+ u8 request[6] = { ec_cdev->fan_id, EC_FAN_SPEED_DATA_SIZE,
+ EC_FAN_DEBUG_MODE_OFF, 0, 0, 0 };
+ int ret;
+
+ ret = i2c_smbus_write_i2c_block_data(client, EC_FAN_DBG_CONTROL_CMD,
+ sizeof(request), request);
+ if (ret) {
+ dev_err(dev, "Failed to turn off fan%d debug mode: %d\n",
+ ec_cdev->fan_id, ret);
+ }
+
+ return ret;
+}
+
+static int qcom_ec_fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
+{
+ struct qcom_ec_cooling_dev *ec_cdev = cdev->devdata;
+ struct device *dev = ec_cdev->parent_dev;
+ struct i2c_client *client = to_i2c_client(dev);
+ u8 request[6] = { ec_cdev->fan_id, EC_FAN_SPEED_DATA_SIZE,
+ EC_FAN_DEBUG_MODE_ON | EC_FAN_ON | EC_FAN_DEBUG_TYPE_PWM,
+ 0, 0, state };
+ int ret;
+
+ ret = i2c_smbus_write_i2c_block_data(client, EC_FAN_DBG_CONTROL_CMD,
+ sizeof(request), request);
+ if (ret) {
+ dev_err(dev, "Failed to set fan pwm: %d\n", ret);
+ return ret;
+ }
+
+ ec_cdev->state = state;
+
+ return 0;
+}
+
+static const struct thermal_cooling_device_ops qcom_ec_thermal_ops = {
+ .get_max_state = qcom_ec_fan_get_max_state,
+ .get_cur_state = qcom_ec_fan_get_cur_state,
+ .set_cur_state = qcom_ec_fan_set_cur_state,
+};
+
+static int qcom_ec_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+
+ return i2c_smbus_write_byte_data(client, EC_MODERN_STANDBY_CMD,
+ EC_MODERN_STANDBY_ENTER);
+}
+
+static int qcom_ec_suspend(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+
+ return i2c_smbus_write_byte_data(client, EC_MODERN_STANDBY_CMD,
+ EC_MODERN_STANDBY_EXIT);
+}
+
+static int qcom_ec_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct qcom_ec *ec;
+ unsigned int i;
+ int ret;
+
+ ec = devm_kzalloc(dev, sizeof(*ec), GFP_KERNEL);
+ if (!ec)
+ return -ENOMEM;
+
+ ec->client = client;
+
+ ret = devm_request_threaded_irq(dev, client->irq, NULL, qcom_ec_irq,
+ IRQF_ONESHOT, "qcom_ec", ec);
+ if (ret < 0)
+ return ret;
+
+ i2c_set_clientdata(client, ec);
+
+ ret = qcom_ec_read_fw_version(dev);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to read EC firmware version\n");
+
+ ret = qcom_ec_sci_evt_control(dev, true);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to enable SCI events\n");
+
+ ret = qcom_ec_thermal_capabilities(dev);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to read thermal capabilities\n");
+
+ if (ec->thermal_cap.fan_cnt == 0) {
+ dev_warn(dev, FW_BUG "Failed to get fan count, firmware update required\n");
+ return 0;
+ }
+
+ ec->ec_cdev = devm_kcalloc(dev, ec->thermal_cap.fan_cnt, sizeof(*ec->ec_cdev), GFP_KERNEL);
+ if (!ec->ec_cdev)
+ return -ENOMEM;
+
+ for (i = 0; i < ec->thermal_cap.fan_cnt; i++) {
+ struct qcom_ec_cooling_dev *ec_cdev = &ec->ec_cdev[i];
+ char name[EC_FAN_NAME_SIZE];
+
+ scnprintf(name, sizeof(name), "qcom_ec_fan_%u", i);
+ ec_cdev->fan_id = i + 1;
+ ec_cdev->parent_dev = dev;
+
+ ec_cdev->cdev = devm_thermal_of_cooling_device_register(dev, NULL, name, ec_cdev,
+ &qcom_ec_thermal_ops);
+ if (IS_ERR(ec_cdev->cdev)) {
+ return dev_err_probe(dev, PTR_ERR(ec_cdev->cdev),
+ "Failed to register fan%d cooling device\n", i);
+ }
+ }
+
+ return 0;
+}
+
+static void qcom_ec_remove(struct i2c_client *client)
+{
+ struct qcom_ec *ec = i2c_get_clientdata(client);
+ struct device *dev = &client->dev;
+ int ret;
+
+ ret = qcom_ec_sci_evt_control(dev, false);
+ if (ret < 0)
+ dev_err(dev, "Failed to disable SCI events: %d\n", ret);
+
+ for (int i = 0; i < ec->thermal_cap.fan_cnt; i++) {
+ struct qcom_ec_cooling_dev *ec_cdev = &ec->ec_cdev[i];
+
+ qcom_ec_fan_debug_mode_off(ec_cdev);
+ }
+}
+
+static const struct of_device_id qcom_ec_of_match[] = {
+ { .compatible = "qcom,hamoa-crd-ec" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, qcom_ec_of_match);
+
+static const struct i2c_device_id qcom_ec_i2c_id_table[] = {
+ { "qcom-hamoa-ec", },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, qcom_ec_i2c_id_table);
+
+static DEFINE_SIMPLE_DEV_PM_OPS(qcom_ec_pm_ops,
+ qcom_ec_suspend,
+ qcom_ec_resume);
+
+static struct i2c_driver qcom_ec_i2c_driver = {
+ .driver = {
+ .name = "qcom-hamoa-ec",
+ .of_match_table = qcom_ec_of_match,
+ .pm = &qcom_ec_pm_ops
+ },
+ .probe = qcom_ec_probe,
+ .remove = qcom_ec_remove,
+ .id_table = qcom_ec_i2c_id_table,
+};
+module_i2c_driver(qcom_ec_i2c_driver);
+
+MODULE_DESCRIPTION("QCOM Hamoa Embedded Controller");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v7 1/5] dt-bindings: embedded-controller: Add Qualcomm reference device EC description
From: Anvesh Jain P @ 2026-03-27 10:08 UTC (permalink / raw)
To: Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Randy Dunlap
Cc: linux-arm-msm, devicetree, linux-kernel, platform-driver-x86,
Anvesh Jain P, Maya Matuszczyk, Krzysztof Kozlowski
In-Reply-To: <20260327-add-driver-for-ec-v7-0-7684c915e42c@oss.qualcomm.com>
From: Maya Matuszczyk <maccraft123mc@gmail.com>
Add description for the EC firmware running on Hamoa/Purwa and Glymur
reference devices.
Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Co-developed-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
---
.../embedded-controller/qcom,hamoa-crd-ec.yaml | 56 ++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
new file mode 100644
index 000000000000..ac5a08f8f76d
--- /dev/null
+++ b/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/embedded-controller/qcom,hamoa-crd-ec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Hamoa Embedded Controller
+
+maintainers:
+ - Sibi Sankar <sibi.sankar@oss.qualcomm.com>
+ - Anvesh Jain P <anvesh.p@oss.qualcomm.com>
+
+description:
+ Qualcomm Snapdragon based Hamoa/Purwa and Glymur reference devices have an
+ EC running on different MCU chips. The EC handles things like fan control,
+ temperature sensors, access to EC internal state changes.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,glymur-crd-ec
+ - qcom,hamoa-iot-evk-ec
+ - const: qcom,hamoa-crd-ec
+ - enum:
+ - qcom,hamoa-crd-ec
+
+ reg:
+ const: 0x76
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ embedded-controller@76 {
+ compatible = "qcom,hamoa-crd-ec";
+ reg = <0x76>;
+
+ interrupts-extended = <&tlmm 66 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+...
--
2.34.1
^ permalink raw reply related
* [PATCH v7 0/5] Add driver for EC found on Qualcomm reference devices
From: Anvesh Jain P @ 2026-03-27 10:08 UTC (permalink / raw)
To: Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Randy Dunlap
Cc: linux-arm-msm, devicetree, linux-kernel, platform-driver-x86,
Anvesh Jain P, Maya Matuszczyk, Krzysztof Kozlowski,
Dmitry Baryshkov, Konrad Dybcio, Abel Vesa, Gaurav Kohli
From: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Add Embedded controller driver support for Hamoa/Purwa/Glymur Qualcomm
reference boards. It handles fan control, temperature sensors, access
to EC state changes and supports reporting suspend entry/exit to the EC.
---
Changes in v7:
- Fixed alphabetical ordering of MAINTAINERS entry.
- Link to v6: https://lore.kernel.org/r/20260325-add-driver-for-ec-v6-0-a8e888d09f0f@oss.qualcomm.com
Changes in v6:
- Add missing includes: <linux/bits.h>, <linux/device.h>
and <linux/err.h>.
- Change the thermistor_mask format specifier from %d to %x.
- Change loop counter to unsigned int.
- Replace snprintf() with scnprintf() for safer string handling.
- Use sizeof(name) instead of the EC_FAN_NAME_SIZE macro directly.
- Add missing braces.
- Link to v5: https://lore.kernel.org/r/20260317-add-driver-for-ec-v5-0-38d11f524856@oss.qualcomm.com
Changes in v5:
- Fix subject line and commit description, drop redundant
"bindings for".
- Rename binding file: qcom,hamoa-ec.yaml → qcom,hamoa-crd-ec.yaml
to match the compatible string.
- Update $id URI to match the new filename.
- Add <linux/interrupt.h> and <linux/slab.h> includes.
- Switch to devm_thermal_of_cooling_device_register, remove manual
unroll loop.
- Ratelimit all IRQ handler log messages.
- Promote unknown EC event log from dev_dbg to dev_notice.
- Remove redundant error message after devm_request_threaded_irq.
- Simplify qcom_ec_sci_evt_control, resume, and suspend using direct
returns.
- Add dev_warn + early return for zero fan count; driver stays loaded
for PM notifications.
- Fix thermistor presence bitmask documentation: 1 = present, 0 = absent.
- Fix snprintf format specifier to %u to suppress -Wformat-truncation.
- Remove unused cdev variable from qcom_ec_probe.
- Fix typo: "exluding" → "excluding" in register map comments.
- Fix capitalization: "ec" → "EC" in error messages.
- Link to v4: https://lore.kernel.org/r/20260313-v04-add-driver-for-ec-v4-0-ca9d0efd62aa@oss.qualcomm.com
Changes in v4:
- Fix fan count calculation to use min() instead of max() to correctly
cap fan_cnt at EC_MAX_FAN_CNT.
- Remove unnecessary mutex lock/unlock.
- Disable fan debug mode on ec module removal.
- Fix issue reported by kernel test robot.
- Consolidate hamoa-iot-evk specific changes into hamoa-iot-evk.dts.
- Add board-specific compatible strings as per review comments.
- Link to v3: https://lore.kernel.org/all/20260308233646.2318676-1-sibi.sankar@oss.qualcomm.com/
Changes in v3:
- Revamp the bindings and driver to support generic ec specification
that works across Qualcomm Hamoa/Purwa and Glymur reference devices.
- Add ec nodes to Hamoa/Purwa CRDs and IOT-EVKs.
- Add ec node to Glymur CRDs.
- Link to v2: https://lore.kernel.org/lkml/20241219200821.8328-1-maccraft123mc@gmail.com/
- Link to v1: https://lore.kernel.org/lkml/20240927185345.3680-1-maccraft123mc@gmail.com/
---
Maya Matuszczyk (1):
dt-bindings: embedded-controller: Add Qualcomm reference device EC description
Sibi Sankar (4):
platform: arm64: Add driver for EC found on Qualcomm reference devices
arm64: dts: qcom: glymur-crd: Add Embedded controller node
arm64: dts: qcom: x1-crd: Add Embedded controller node
arm64: dts: qcom: hamoa-iot-evk: Add Embedded controller node
.../embedded-controller/qcom,hamoa-crd-ec.yaml | 56 +++
MAINTAINERS | 8 +
arch/arm64/boot/dts/qcom/glymur-crd.dts | 22 +
arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 16 +
arch/arm64/boot/dts/qcom/x1-crd.dtsi | 16 +
drivers/platform/arm64/Kconfig | 12 +
drivers/platform/arm64/Makefile | 1 +
drivers/platform/arm64/qcom-hamoa-ec.c | 451 +++++++++++++++++++++
8 files changed, 582 insertions(+)
---
base-commit: 85964cdcad0fac9a0eb7b87a0f9d88cc074b854c
change-id: 20260309-add-driver-for-ec-3fa478f264d9
Best regards,
--
Anvesh Jain P <anvesh.p@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Konrad Dybcio @ 2026-03-27 10:07 UTC (permalink / raw)
To: Hangxiang Ma, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <bc6abd24-d56a-4fc0-89e9-8986e8d8b3b7@oss.qualcomm.com>
On 3/27/26 3:23 AM, Hangxiang Ma wrote:
> On 3/26/2026 9:04 AM, Bryan O'Donoghue wrote:
>> +#include <linux/delay.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/time64.h>
>> +
>> +#include "phy-qcom-mipi-csi2.h"
>> +
>> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(offset, n) ((offset) + 0x4 * (n))
>> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL0_PHY_SW_RESET BIT(0)
>> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE BIT(7)
>> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_COMMON_PWRDN_B BIT(0)
>> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_ID BIT(1)
>> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL10_IRQ_CLEAR_CMD BIT(0)
>> +#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, n) ((offset) + 0xb0 + 0x4 * (n))
>>
> Hi Bryan, one minor observation on the following macro:
>
> CSIPHY_3PH_CMN_CSI_COMMON_STATUSn
>
> The 0xb0 offset implicitly assumes a fixed distance between the
> common_ctrl and common_status register blocks. This holds for the PHYs
> covered by this series, but on some other platforms (e.g. Kaanapali,
> Pakala) the offset differs.
>
> That said, I think keeping this fixed value is reasonable for the scope
> of the current PHY series, and it does help keep the macro set simple.
> It might just be worth documenting this assumption (e.g. via a comment
> or in the commit message).
>
> Alternatively, if future PHY variants need to support different layouts,
> this could be made more extensible by moving the status base offset into
> the per-PHY data (similar to other register layout parameters). But I
> don’t think that needs to block the current series.
If the register contents are generally similar but the bit positions
and/or reg offsets differ, regmap_fields may be useful
Konrad
^ permalink raw reply
* [PATCH RESEND] dt-bindings: thermal: qcom-tsens: Add Eliza SoC TSENS
From: Krzysztof Kozlowski @ 2026-03-27 10:07 UTC (permalink / raw)
To: Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-pm, devicetree, linux-kernel
Cc: Krzysztof Kozlowski, Konrad Dybcio
Document the compatible for Qualcomm Eliza SoC TSENS module, fully
compatible with TSENS v2 generation (e.g. SM8650).
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
index 928243cd2883..7d34ba00e684 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
@@ -54,6 +54,7 @@ properties:
- description: v2 of TSENS
items:
- enum:
+ - qcom,eliza-tsens
- qcom,glymur-tsens
- qcom,kaanapali-tsens
- qcom,milos-tsens
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Konrad Dybcio @ 2026-03-27 10:07 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <20260326-x1e-csi2-phy-v5-1-0c0fc7f5c01b@linaro.org>
On 3/26/26 2:04 AM, Bryan O'Donoghue wrote:
> Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
> PHY devices.
>
> The hardware can support both CPHY, DPHY and a special split-mode DPHY. We
> capture those modes as:
>
> - PHY_QCOM_CSI2_MODE_DPHY
> - PHY_QCOM_CSI2_MODE_CPHY
> - PHY_QCOM_CSI2_MODE_SPLIT_DPHY
Does the _PHY_ DT node need to be aware about this upfront?
If we have some sideband signal (e.g. the sensor driver specifically
requesting C-PHY mode), we can simply throw all this complexity into
phy_mode + phy_configure_opts, all at runtime
Further, the combo/split mode may possibly be selected through
aggregation of requests.
The question remains whether the sensor should have a direct connection to
the PHY itself (i.e. phys = <&csiphyN> or of_graph straight into the PHY)
or whether it's going to be translated by the camss node (which would be
the one holding a PHY reference) - there's probably surface for adding such
negotiation logic in both places
Note this is a question and I'm not aware of all the possible combinations
Konrad
^ permalink raw reply
* Re: [PATCH net-next 1/5] dpll: zl3073x: clean up esync get/set and use zl3073x_out_is_ndiv()
From: Petr Oros @ 2026-03-27 10:03 UTC (permalink / raw)
To: Ivan Vecera, netdev
Cc: Arkadiusz Kubalewski, Jiri Pirko, Michal Schmidt, Prathosh Satish,
Simon Horman, Vadim Fedorenko, linux-kernel, Conor Dooley,
Krzysztof Kozlowski, Rob Herring, devicetree, Pasi Vaananen
In-Reply-To: <20260319174826.7623-2-ivecera@redhat.com>
> Return -EOPNOTSUPP early in esync_get callbacks when esync is not
> supported instead of conditionally populating the range at the end.
> This simplifies the control flow by removing the finish label/goto
> in the output variant and the conditional range assignment in both
> input and output variants.
>
> Replace open-coded N-div signal format switch statements with
> zl3073x_out_is_ndiv() helper in esync_get, esync_set and
> frequency_set callbacks.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
> drivers/dpll/zl3073x/dpll.c | 64 ++++++++++++-------------------------
> 1 file changed, 20 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
> index a29f606318f6d..79ef62d69a32d 100644
> --- a/drivers/dpll/zl3073x/dpll.c
> +++ b/drivers/dpll/zl3073x/dpll.c
> @@ -131,6 +131,12 @@ zl3073x_dpll_input_pin_esync_get(const struct dpll_pin *dpll_pin,
> ref_id = zl3073x_input_pin_ref_get(pin->id);
> ref = zl3073x_ref_state_get(zldev, ref_id);
>
> + if (!pin->esync_control || zl3073x_ref_freq_get(ref) == 1)
> + return -EOPNOTSUPP;
> +
> + esync->range = esync_freq_ranges;
> + esync->range_num = ARRAY_SIZE(esync_freq_ranges);
> +
> switch (FIELD_GET(ZL_REF_SYNC_CTRL_MODE, ref->sync_ctrl)) {
> case ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75:
> esync->freq = ref->esync_n_div == ZL_REF_ESYNC_DIV_1HZ ? 1 : 0;
> @@ -142,17 +148,6 @@ zl3073x_dpll_input_pin_esync_get(const struct dpll_pin *dpll_pin,
> break;
> }
>
> - /* If the pin supports esync control expose its range but only
> - * if the current reference frequency is > 1 Hz.
> - */
> - if (pin->esync_control && zl3073x_ref_freq_get(ref) > 1) {
> - esync->range = esync_freq_ranges;
> - esync->range_num = ARRAY_SIZE(esync_freq_ranges);
> - } else {
> - esync->range = NULL;
> - esync->range_num = 0;
> - }
> -
> return 0;
> }
>
> @@ -582,8 +577,8 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
> struct zl3073x_dpll_pin *pin = pin_priv;
> const struct zl3073x_synth *synth;
> const struct zl3073x_out *out;
> + u32 synth_freq, out_freq;
> u8 clock_type, out_id;
> - u32 synth_freq;
>
> out_id = zl3073x_output_pin_out_get(pin->id);
> out = zl3073x_out_state_get(zldev, out_id);
> @@ -592,17 +587,19 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
> * for N-division is also used for the esync divider so both cannot
> * be used.
> */
> - switch (zl3073x_out_signal_format_get(out)) {
> - case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV:
> - case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV_INV:
> + if (zl3073x_out_is_ndiv(out))
> return -EOPNOTSUPP;
> - default:
> - break;
> - }
>
> /* Get attached synth frequency */
> synth = zl3073x_synth_state_get(zldev, zl3073x_out_synth_get(out));
> synth_freq = zl3073x_synth_freq_get(synth);
> + out_freq = synth_freq / out->div;
> +
> + if (!pin->esync_control || out_freq == 1)
> + return -EOPNOTSUPP;
> +
> + esync->range = esync_freq_ranges;
> + esync->range_num = ARRAY_SIZE(esync_freq_ranges);
>
> clock_type = FIELD_GET(ZL_OUTPUT_MODE_CLOCK_TYPE, out->mode);
> if (clock_type != ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC) {
> @@ -610,11 +607,11 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
> esync->freq = 0;
> esync->pulse = 0;
>
> - goto finish;
> + return 0;
> }
>
> /* Compute esync frequency */
> - esync->freq = synth_freq / out->div / out->esync_n_period;
> + esync->freq = out_freq / out->esync_n_period;
>
> /* By comparing the esync_pulse_width to the half of the pulse width
> * the esync pulse percentage can be determined.
> @@ -623,18 +620,6 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
> */
> esync->pulse = (50 * out->esync_n_width) / out->div;
>
> -finish:
> - /* Set supported esync ranges if the pin supports esync control and
> - * if the output frequency is > 1 Hz.
> - */
> - if (pin->esync_control && (synth_freq / out->div) > 1) {
> - esync->range = esync_freq_ranges;
> - esync->range_num = ARRAY_SIZE(esync_freq_ranges);
> - } else {
> - esync->range = NULL;
> - esync->range_num = 0;
> - }
> -
> return 0;
> }
>
> @@ -660,13 +645,8 @@ zl3073x_dpll_output_pin_esync_set(const struct dpll_pin *dpll_pin,
> * for N-division is also used for the esync divider so both cannot
> * be used.
> */
> - switch (zl3073x_out_signal_format_get(&out)) {
> - case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV:
> - case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV_INV:
> + if (zl3073x_out_is_ndiv(&out))
> return -EOPNOTSUPP;
> - default:
> - break;
> - }
>
> /* Select clock type */
> if (freq)
> @@ -728,9 +708,9 @@ zl3073x_dpll_output_pin_frequency_set(const struct dpll_pin *dpll_pin,
> struct zl3073x_dev *zldev = zldpll->dev;
> struct zl3073x_dpll_pin *pin = pin_priv;
> const struct zl3073x_synth *synth;
> - u8 out_id, signal_format;
> u32 new_div, synth_freq;
> struct zl3073x_out out;
> + u8 out_id;
>
> out_id = zl3073x_output_pin_out_get(pin->id);
> out = *zl3073x_out_state_get(zldev, out_id);
> @@ -740,12 +720,8 @@ zl3073x_dpll_output_pin_frequency_set(const struct dpll_pin *dpll_pin,
> synth_freq = zl3073x_synth_freq_get(synth);
> new_div = synth_freq / (u32)frequency;
>
> - /* Get used signal format for the given output */
> - signal_format = zl3073x_out_signal_format_get(&out);
> -
> /* Check signal format */
> - if (signal_format != ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV &&
> - signal_format != ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV_INV) {
> + if (!zl3073x_out_is_ndiv(&out)) {
> /* For non N-divided signal formats the frequency is computed
> * as division of synth frequency and output divisor.
> */
LGTM,
Reviewed-by: Petr Oros <poros@redhat.com>
^ permalink raw reply
* Re: [PATCH 2/7] arm64: dts: qcom: sm6125: Enable USB-C port handling
From: Konrad Dybcio @ 2026-03-27 9:55 UTC (permalink / raw)
To: Biswapriyo Nath
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Pavel Machek, Sean Young,
Michael Turquette, Stephen Boyd, Martin Botka, linux-arm-msm,
devicetree, linux-kernel, linux-leds, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260326182821.8332-1-nathbappai@gmail.com>
On 3/26/26 7:28 PM, Biswapriyo Nath wrote:
> On Thu, 26 Mar 2026 10:41:03 +0100 Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
>
>> On 3/25/26 7:07 PM, Biswapriyo Nath wrote:
>>> Plug in USB-C related bits and pieces to enable USB role switching.
>>> Also, remove dr_mode to enable OTG capability.
>>>
>>> Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
>>> ---
>>
>> I'm not sure what this is going to do for other 6125 devices
>> that don't have the Type-C infra wired up.. Does just applying
>> this commit alone keep peripheral mode working on your phone?
>>
>> Konrad
>>
>
> Yes, I have verified that USB peripheral mode is working with this
> patch only by using USB network[1].
Thanks
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