* Re: [PATCH] arm64: dts: qcom: eliza: Add thermal sensors
From: Krzysztof Kozlowski @ 2026-03-27 10:38 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260327101225.382493-2-krzysztof.kozlowski@oss.qualcomm.com>
On 27/03/2026 11:12, Krzysztof Kozlowski wrote:
> 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/
Binding was applied just now, so this DTS patch is unblocked.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next 5/5] dpll: zl3073x: add ref-sync pair support
From: Petr Oros @ 2026-03-27 10:34 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-6-ivecera@redhat.com>
> Add support for ref-sync pair registration using the 'ref-sync-sources'
> phandle property from device tree. A ref-sync pair consists of a clock
> reference and a low-frequency sync signal where the DPLL locks to the
> clock reference but phase-aligns to the sync reference.
>
> The implementation:
> - Stores fwnode handle in zl3073x_dpll_pin during pin registration
> - Adds ref_sync_get/set callbacks to read and write the sync control
> mode and pair registers
> - Validates ref-sync frequency constraints: sync signal must be 8 kHz
> or less, clock reference must be 1 kHz or more and higher than sync
> - Excludes sync source from automatic reference selection by setting
> its priority to NONE on connect; on disconnect the priority is left
> as NONE and the user must explicitly make the pin selectable again
> - Iterates ref-sync-sources phandles to register declared pairings
> via dpll_pin_ref_sync_pair_add()
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
> drivers/dpll/zl3073x/dpll.c | 207 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 206 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
> index 276f0a92db0b1..8010e2635f641 100644
> --- a/drivers/dpll/zl3073x/dpll.c
> +++ b/drivers/dpll/zl3073x/dpll.c
> @@ -13,6 +13,7 @@
> #include <linux/module.h>
> #include <linux/netlink.h>
> #include <linux/platform_device.h>
> +#include <linux/property.h>
> #include <linux/slab.h>
> #include <linux/sprintf.h>
>
> @@ -30,6 +31,7 @@
> * @dpll: DPLL the pin is registered to
> * @dpll_pin: pointer to registered dpll_pin
> * @tracker: tracking object for the acquired reference
> + * @fwnode: firmware node handle
> * @label: package label
> * @dir: pin direction
> * @id: pin id
> @@ -45,6 +47,7 @@ struct zl3073x_dpll_pin {
> struct zl3073x_dpll *dpll;
> struct dpll_pin *dpll_pin;
> dpll_tracker tracker;
> + struct fwnode_handle *fwnode;
> char label[8];
> enum dpll_pin_direction dir;
> u8 id;
> @@ -184,6 +187,109 @@ zl3073x_dpll_input_pin_esync_set(const struct dpll_pin *dpll_pin,
> return zl3073x_ref_state_set(zldev, ref_id, &ref);
> }
>
> +static int
> +zl3073x_dpll_input_pin_ref_sync_get(const struct dpll_pin *dpll_pin,
> + void *pin_priv,
> + const struct dpll_pin *ref_sync_pin,
> + void *ref_sync_pin_priv,
> + enum dpll_pin_state *state,
> + struct netlink_ext_ack *extack)
> +{
> + struct zl3073x_dpll_pin *sync_pin = ref_sync_pin_priv;
> + struct zl3073x_dpll_pin *pin = pin_priv;
> + struct zl3073x_dpll *zldpll = pin->dpll;
> + struct zl3073x_dev *zldev = zldpll->dev;
> + const struct zl3073x_ref *ref;
> + u8 ref_id, mode, pair;
> +
> + ref_id = zl3073x_input_pin_ref_get(pin->id);
> + ref = zl3073x_ref_state_get(zldev, ref_id);
> + mode = zl3073x_ref_sync_mode_get(ref);
> + pair = zl3073x_ref_sync_pair_get(ref);
> +
> + if (mode == ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR &&
> + pair == zl3073x_input_pin_ref_get(sync_pin->id))
> + *state = DPLL_PIN_STATE_CONNECTED;
> + else
> + *state = DPLL_PIN_STATE_DISCONNECTED;
> +
> + return 0;
> +}
> +
> +static int
> +zl3073x_dpll_input_pin_ref_sync_set(const struct dpll_pin *dpll_pin,
> + void *pin_priv,
> + const struct dpll_pin *ref_sync_pin,
> + void *ref_sync_pin_priv,
> + const enum dpll_pin_state state,
> + struct netlink_ext_ack *extack)
> +{
> + struct zl3073x_dpll_pin *sync_pin = ref_sync_pin_priv;
> + struct zl3073x_dpll_pin *pin = pin_priv;
> + struct zl3073x_dpll *zldpll = pin->dpll;
> + struct zl3073x_dev *zldev = zldpll->dev;
> + u8 mode, ref_id, sync_ref_id;
> + struct zl3073x_chan chan;
> + struct zl3073x_ref ref;
> + int rc;
> +
> + ref_id = zl3073x_input_pin_ref_get(pin->id);
> + sync_ref_id = zl3073x_input_pin_ref_get(sync_pin->id);
> + ref = *zl3073x_ref_state_get(zldev, ref_id);
> +
> + if (state == DPLL_PIN_STATE_CONNECTED) {
> + const struct zl3073x_ref *sync_ref;
> + u32 ref_freq, sync_freq;
> +
> + sync_ref = zl3073x_ref_state_get(zldev, sync_ref_id);
> + ref_freq = zl3073x_ref_freq_get(&ref);
> + sync_freq = zl3073x_ref_freq_get(sync_ref);
> +
> + /* Sync signal must be 8 kHz or less and clock reference
> + * must be 1 kHz or more and higher than the sync signal.
> + */
> + if (sync_freq > 8000) {
> + NL_SET_ERR_MSG(extack,
> + "sync frequency must be 8 kHz or less");
> + return -EINVAL;
> + }
> + if (ref_freq < 1000) {
> + NL_SET_ERR_MSG(extack,
> + "clock frequency must be 1 kHz or more");
> + return -EINVAL;
> + }
> + if (ref_freq <= sync_freq) {
> + NL_SET_ERR_MSG(extack,
> + "clock frequency must be higher than sync frequency");
> + return -EINVAL;
> + }
> +
> + zl3073x_ref_sync_pair_set(&ref, sync_ref_id);
> + mode = ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR;
> + } else {
> + mode = ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR_OFF;
> + }
> +
> + zl3073x_ref_sync_mode_set(&ref, mode);
> +
> + rc = zl3073x_ref_state_set(zldev, ref_id, &ref);
> + if (rc)
> + return rc;
> +
> + /* Exclude sync source from automatic reference selection by setting
> + * its priority to NONE. On disconnect the priority is left as NONE
> + * and the user must explicitly make the pin selectable again.
> + */
> + if (state == DPLL_PIN_STATE_CONNECTED) {
> + chan = *zl3073x_chan_state_get(zldev, zldpll->id);
> + zl3073x_chan_ref_prio_set(&chan, sync_ref_id,
> + ZL_DPLL_REF_PRIO_NONE);
> + return zl3073x_chan_state_set(zldev, zldpll->id, &chan);
> + }
> +
> + return 0;
> +}
> +
> static int
> zl3073x_dpll_input_pin_ffo_get(const struct dpll_pin *dpll_pin, void *pin_priv,
> const struct dpll_device *dpll, void *dpll_priv,
> @@ -1100,6 +1206,8 @@ static const struct dpll_pin_ops zl3073x_dpll_input_pin_ops = {
> .phase_adjust_set = zl3073x_dpll_input_pin_phase_adjust_set,
> .prio_get = zl3073x_dpll_input_pin_prio_get,
> .prio_set = zl3073x_dpll_input_pin_prio_set,
> + .ref_sync_get = zl3073x_dpll_input_pin_ref_sync_get,
> + .ref_sync_set = zl3073x_dpll_input_pin_ref_sync_set,
> .state_on_dpll_get = zl3073x_dpll_input_pin_state_on_dpll_get,
> .state_on_dpll_set = zl3073x_dpll_input_pin_state_on_dpll_set,
> };
> @@ -1190,8 +1298,11 @@ zl3073x_dpll_pin_register(struct zl3073x_dpll_pin *pin, u32 index)
> if (IS_ERR(props))
> return PTR_ERR(props);
>
> - /* Save package label, esync capability and phase adjust granularity */
> + /* Save package label, fwnode, esync capability and phase adjust
> + * granularity.
> + */
> strscpy(pin->label, props->package_label);
> + pin->fwnode = fwnode_handle_get(props->fwnode);
> pin->esync_control = props->esync_control;
> pin->phase_gran = props->dpll_props.phase_gran;
>
> @@ -1236,6 +1347,8 @@ zl3073x_dpll_pin_register(struct zl3073x_dpll_pin *pin, u32 index)
> dpll_pin_put(pin->dpll_pin, &pin->tracker);
> pin->dpll_pin = NULL;
> err_pin_get:
> + fwnode_handle_put(pin->fwnode);
> + pin->fwnode = NULL;
> zl3073x_pin_props_put(props);
>
> return rc;
> @@ -1265,6 +1378,9 @@ zl3073x_dpll_pin_unregister(struct zl3073x_dpll_pin *pin)
>
> dpll_pin_put(pin->dpll_pin, &pin->tracker);
> pin->dpll_pin = NULL;
> +
> + fwnode_handle_put(pin->fwnode);
> + pin->fwnode = NULL;
> }
>
> /**
> @@ -1735,6 +1851,88 @@ zl3073x_dpll_free(struct zl3073x_dpll *zldpll)
> kfree(zldpll);
> }
>
> +/**
> + * zl3073x_dpll_ref_sync_pair_register - register ref_sync pairs for a pin
> + * @pin: pointer to zl3073x_dpll_pin structure
> + *
> + * Iterates 'ref-sync-sources' phandles in the pin's firmware node and
> + * registers each declared pairing.
> + *
> + * Return: 0 on success, <0 on error
> + */
> +static int
> +zl3073x_dpll_ref_sync_pair_register(struct zl3073x_dpll_pin *pin)
> +{
> + struct zl3073x_dev *zldev = pin->dpll->dev;
> + struct fwnode_handle *fwnode;
> + struct dpll_pin *sync_pin;
> + dpll_tracker tracker;
> + int n, rc;
> +
> + for (n = 0; ; n++) {
> + /* Get n'th ref-sync source */
> + fwnode = fwnode_find_reference(pin->fwnode, "ref-sync-sources",
> + n);
> + if (IS_ERR(fwnode)) {
> + rc = PTR_ERR(fwnode);
> + break;
> + }
> +
> + /* Find associated dpll pin */
> + sync_pin = fwnode_dpll_pin_find(fwnode, &tracker);
> + fwnode_handle_put(fwnode);
> + if (!sync_pin) {
> + dev_warn(zldev->dev, "%s: ref-sync source %d not found",
> + pin->label, n);
> + continue;
> + }
> +
> + /* Register new ref-sync pair */
> + rc = dpll_pin_ref_sync_pair_add(pin->dpll_pin, sync_pin);
> + dpll_pin_put(sync_pin, &tracker);
> +
> + /* -EBUSY means pairing already exists from another DPLL's
> + * registration.
> + */
> + if (rc && rc != -EBUSY) {
> + dev_err(zldev->dev,
> + "%s: failed to add ref-sync source %d: %pe",
> + pin->label, n, ERR_PTR(rc));
> + break;
> + }
> + }
> +
> + return rc != -ENOENT ? rc : 0;
> +}
> +
> +/**
> + * zl3073x_dpll_ref_sync_pairs_register - register ref_sync pairs for a DPLL
> + * @zldpll: pointer to zl3073x_dpll structure
> + *
> + * Iterates all registered input pins of the given DPLL and establishes
> + * ref_sync pairings declared by 'ref-sync-sources' phandles in the
> + * device tree.
> + *
> + * Return: 0 on success, <0 on error
> + */
> +static int
> +zl3073x_dpll_ref_sync_pairs_register(struct zl3073x_dpll *zldpll)
> +{
> + struct zl3073x_dpll_pin *pin;
> + int rc;
> +
> + list_for_each_entry(pin, &zldpll->pins, list) {
> + if (!zl3073x_dpll_is_input_pin(pin) || !pin->fwnode)
> + continue;
> +
> + rc = zl3073x_dpll_ref_sync_pair_register(pin);
> + if (rc)
> + return rc;
> + }
> +
> + return 0;
> +}
> +
> /**
> * zl3073x_dpll_register - register DPLL device and all its pins
> * @zldpll: pointer to zl3073x_dpll structure
> @@ -1758,6 +1956,13 @@ zl3073x_dpll_register(struct zl3073x_dpll *zldpll)
> return rc;
> }
>
> + rc = zl3073x_dpll_ref_sync_pairs_register(zldpll);
> + if (rc) {
> + zl3073x_dpll_pins_unregister(zldpll);
> + zl3073x_dpll_device_unregister(zldpll);
> + return rc;
> + }
> +
> return 0;
> }
>
LGTM.
Reviewed-by: Petr Oros <poros@redhat.com>
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: power: reset: qcom-pon: Add new compatible PMM8654AU
From: Krzysztof Kozlowski @ 2026-03-27 10:32 UTC (permalink / raw)
To: Rakesh Kota, Rob Herring
Cc: Sebastian Reichel, Krzysztof Kozlowski, Conor Dooley, Vinod Koul,
Bjorn Andersson, Konrad Dybcio, linux-pm, devicetree,
linux-kernel, linux-arm-msm, Dmitry Baryshkov
In-Reply-To: <20260327095341.5radsv6dsbwptnfs@hu-kotarake-hyd.qualcomm.com>
On 27/03/2026 10:53, Rakesh Kota wrote:
> On Mon, Mar 23, 2026 at 01:18:20PM -0500, Rob Herring wrote:
>> On Mon, Mar 23, 2026 at 04:15:15PM +0530, Rakesh Kota wrote:
>>> PMM8654AU is a different PMIC from PMM8650AU, even though both share
>>> the same PMIC subtype. Add PON compatible string for PMM8654AU PMIC
>>> variant.
>>>
>>> The PMM8654AU PON block is compatible with the PMK8350 PON
>>> implementation, but PMM8654AU also implements additional PON registers
>>> beyond the baseline. Use the PMM8654AU naming to match the compatible
>>> string already present in the upstream pinctrl-spmi-gpio driver, keeping
>>> device tree and kernel driver naming consistent.
>>>
>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
>>> ---
>>> Changes in v4:
>>> - Remove the contain for PMK8350 and new if:then for PMM8654AU as
>>> suggested by Krzysztof Kozlowski
>>>
>>> Changes in v3:
>>> - Update the commit message.
>>>
>>> Changes in v2:
>>> - Introduces PMM8654AU compatible strings as suggested by Konrad Dybcio.
>>> ---
>>> .../devicetree/bindings/power/reset/qcom,pon.yaml | 32 +++++++++++++++++-----
>>> 1 file changed, 25 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
>>> index 979a377cb4ffd577bfa51b9a3cd089acc202de0c..2a5d9182b8d5c1a286716ab175c7bb5e39b334e0 100644
>>> --- a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
>>> +++ b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
>>> @@ -17,12 +17,16 @@ description: |
>>>
>>> properties:
>>> compatible:
>>> - enum:
>>> - - qcom,pm8916-pon
>>> - - qcom,pm8941-pon
>>> - - qcom,pms405-pon
>>> - - qcom,pm8998-pon
>>> - - qcom,pmk8350-pon
>>> + oneOf:
>>> + - enum:
>>> + - qcom,pm8916-pon
>>> + - qcom,pm8941-pon
>>> + - qcom,pms405-pon
>>> + - qcom,pm8998-pon
>>> + - qcom,pmk8350-pon
>>> + - items:
>>> + - const: qcom,pmm8654au-pon
>>> + - const: qcom,pmk8350-pon
>>>
>>> reg:
>>> description: |
>>> @@ -100,7 +104,6 @@ allOf:
>>> - if:
>>> properties:
>>> compatible:
>>> - contains:
>>> const: qcom,pmk8350-pon
>>> then:
>>> properties:
>>> @@ -113,6 +116,21 @@ allOf:
>>> - const: hlos
>>> - const: pbs
>>>
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + const: qcom,pmm8654au-pon
>>> + then:
>>> + properties:
>>> + reg:
>>> + minItems: 1
>>> + maxItems: 2
>>> + reg-names:
>>> + minItems: 1
>>> + items:
>>> + - const: hlos
>>> + - const: pbs
>>
>> I don't understand this. The existing if/then schema did the exact same
>> thing until you removed 'contains'. Now we just have the same schema
>> duplicated.
>>
>> What does need changing now that I've looked at it is dropping 'reg'
>> in this schema as it just repeats what the top-level schema has.
>>
>
> we have got suggestion to add a new if:then block for the new compatible from Krzysztof Kozlowski.
>
But I did not suggest to add the contents in new if:then: block. I
certainly did not suggest to not check this patch before submitting, either.
We had long discussion where I asked you how many address spaces you
have there?
Answer above.
And then answer why the patch says the device has one address space or
two address spaces. You engaged me, Konrad and now Rob in reviewing this
triviality. This is on the verge of wasting of our time.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next 4/5] dt-bindings: dpll: add ref-sync-sources property
From: Petr Oros @ 2026-03-27 10:27 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-5-ivecera@redhat.com>
> Add ref-sync-sources phandle-array property to the dpll-pin schema
> allowing board designers to declare which input pins can serve as
> sync sources in a Reference-Sync pair. A Ref-Sync pair consists of
> a clock reference and a low-frequency sync signal where the DPLL locks
> to the clock but phase-aligns to the sync reference.
>
> Update both examples in the Microchip ZL3073x binding to demonstrate
> the new property with a 1 PPS sync source paired to a clock source.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
> .../devicetree/bindings/dpll/dpll-pin.yaml | 11 +++++++
> .../bindings/dpll/microchip,zl30731.yaml | 30 ++++++++++++++-----
> 2 files changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
> index 51db93b77306f..7084f102e274c 100644
> --- a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
> +++ b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
> @@ -36,6 +36,17 @@ properties:
> description: String exposed as the pin board label
> $ref: /schemas/types.yaml#/definitions/string
>
> + ref-sync-sources:
> + description: |
> + List of phandles to input pins that can serve as the sync source
> + in a Reference-Sync pair with this pin acting as the clock source.
> + A Ref-Sync pair consists of a clock reference and a low-frequency
> + sync signal. The DPLL locks to the clock reference but
> + phase-aligns to the sync reference.
> + Only valid for input pins. Each referenced pin must be a
> + different input pin on the same device.
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> supported-frequencies-hz:
> description: List of supported frequencies for this pin, expressed in Hz.
>
> diff --git a/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml b/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
> index 17747f754b845..fa5a8f8e390cd 100644
> --- a/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
> +++ b/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
> @@ -52,11 +52,19 @@ examples:
> #address-cells = <1>;
> #size-cells = <0>;
>
> - pin@0 { /* REF0P */
> + sync0: pin@0 { /* REF0P - 1 PPS sync source */
> reg = <0>;
> connection-type = "ext";
> - label = "Input 0";
> - supported-frequencies-hz = /bits/ 64 <1 1000>;
> + label = "SMA1";
> + supported-frequencies-hz = /bits/ 64 <1>;
> + };
> +
> + pin@1 { /* REF0N - clock source, can pair with sync0 */
> + reg = <1>;
> + connection-type = "ext";
> + label = "SMA2";
> + supported-frequencies-hz = /bits/ 64 <10000 10000000>;
> + ref-sync-sources = <&sync0>;
> };
> };
>
> @@ -90,11 +98,19 @@ examples:
> #address-cells = <1>;
> #size-cells = <0>;
>
> - pin@0 { /* REF0P */
> + sync1: pin@0 { /* REF0P - 1 PPS sync source */
> reg = <0>;
> - connection-type = "ext";
> - label = "Input 0";
> - supported-frequencies-hz = /bits/ 64 <1 1000>;
> + connection-type = "gnss";
> + label = "GNSS_1PPS_IN";
> + supported-frequencies-hz = /bits/ 64 <1>;
> + };
> +
> + pin@1 { /* REF0N - clock source */
> + reg = <1>;
> + connection-type = "gnss";
> + label = "GNSS_10M_IN";
> + supported-frequencies-hz = /bits/ 64 <10000000>;
> + ref-sync-sources = <&sync1>;
> };
> };
>
LGTM.
Reviewed-by: Petr Oros <poros@redhat.com>
^ permalink raw reply
* Re: [PATCH net-next 3/5] dpll: zl3073x: add ref sync and output clock type helpers
From: Petr Oros @ 2026-03-27 10:26 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-4-ivecera@redhat.com>
> Add ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR and ZL_REF_SYNC_CTRL_PAIR
> register definitions.
>
> Add inline helpers to get and set the sync control mode and sync pair
> fields of the reference sync control register:
>
> zl3073x_ref_sync_mode_get/set() - ZL_REF_SYNC_CTRL_MODE field
> zl3073x_ref_sync_pair_get/set() - ZL_REF_SYNC_CTRL_PAIR field
>
> Add inline helpers to get and set the clock type field of the output
> mode register:
>
> zl3073x_out_clock_type_get/set() - ZL_OUTPUT_MODE_CLOCK_TYPE field
>
> Convert existing esync callbacks to use the new helpers.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
> drivers/dpll/zl3073x/dpll.c | 24 ++++++++-----------
> drivers/dpll/zl3073x/out.h | 22 ++++++++++++++++++
> drivers/dpll/zl3073x/ref.h | 46 +++++++++++++++++++++++++++++++++++++
> drivers/dpll/zl3073x/regs.h | 2 ++
> 4 files changed, 80 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
> index 79ef62d69a32d..276f0a92db0b1 100644
> --- a/drivers/dpll/zl3073x/dpll.c
> +++ b/drivers/dpll/zl3073x/dpll.c
> @@ -137,7 +137,7 @@ zl3073x_dpll_input_pin_esync_get(const struct dpll_pin *dpll_pin,
> esync->range = esync_freq_ranges;
> esync->range_num = ARRAY_SIZE(esync_freq_ranges);
>
> - switch (FIELD_GET(ZL_REF_SYNC_CTRL_MODE, ref->sync_ctrl)) {
> + switch (zl3073x_ref_sync_mode_get(ref)) {
> case ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75:
> esync->freq = ref->esync_n_div == ZL_REF_ESYNC_DIV_1HZ ? 1 : 0;
> esync->pulse = 25;
> @@ -173,8 +173,7 @@ zl3073x_dpll_input_pin_esync_set(const struct dpll_pin *dpll_pin,
> else
> sync_mode = ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75;
>
> - ref.sync_ctrl &= ~ZL_REF_SYNC_CTRL_MODE;
> - ref.sync_ctrl |= FIELD_PREP(ZL_REF_SYNC_CTRL_MODE, sync_mode);
> + zl3073x_ref_sync_mode_set(&ref, sync_mode);
>
> if (freq) {
> /* 1 Hz is only supported frequency now */
> @@ -578,7 +577,7 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
> const struct zl3073x_synth *synth;
> const struct zl3073x_out *out;
> u32 synth_freq, out_freq;
> - u8 clock_type, out_id;
> + u8 out_id;
>
> out_id = zl3073x_output_pin_out_get(pin->id);
> out = zl3073x_out_state_get(zldev, out_id);
> @@ -601,8 +600,7 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
> 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) {
> + if (zl3073x_out_clock_type_get(out) != ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC) {
> /* No need to read esync data if it is not enabled */
> esync->freq = 0;
> esync->pulse = 0;
> @@ -635,8 +633,8 @@ zl3073x_dpll_output_pin_esync_set(const struct dpll_pin *dpll_pin,
> struct zl3073x_dpll_pin *pin = pin_priv;
> const struct zl3073x_synth *synth;
> struct zl3073x_out out;
> - u8 clock_type, out_id;
> u32 synth_freq;
> + u8 out_id;
>
> out_id = zl3073x_output_pin_out_get(pin->id);
> out = *zl3073x_out_state_get(zldev, out_id);
> @@ -648,15 +646,13 @@ zl3073x_dpll_output_pin_esync_set(const struct dpll_pin *dpll_pin,
> if (zl3073x_out_is_ndiv(&out))
> return -EOPNOTSUPP;
>
> - /* Select clock type */
> + /* Update clock type in output mode */
> if (freq)
> - clock_type = ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC;
> + zl3073x_out_clock_type_set(&out,
> + ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC);
> else
> - clock_type = ZL_OUTPUT_MODE_CLOCK_TYPE_NORMAL;
> -
> - /* Update clock type in output mode */
> - out.mode &= ~ZL_OUTPUT_MODE_CLOCK_TYPE;
> - out.mode |= FIELD_PREP(ZL_OUTPUT_MODE_CLOCK_TYPE, clock_type);
> + zl3073x_out_clock_type_set(&out,
> + ZL_OUTPUT_MODE_CLOCK_TYPE_NORMAL);
>
> /* If esync is being disabled just write mailbox and finish */
> if (!freq)
> diff --git a/drivers/dpll/zl3073x/out.h b/drivers/dpll/zl3073x/out.h
> index edf40432bba5f..660889c57bffa 100644
> --- a/drivers/dpll/zl3073x/out.h
> +++ b/drivers/dpll/zl3073x/out.h
> @@ -42,6 +42,28 @@ const struct zl3073x_out *zl3073x_out_state_get(struct zl3073x_dev *zldev,
> int zl3073x_out_state_set(struct zl3073x_dev *zldev, u8 index,
> const struct zl3073x_out *out);
>
> +/**
> + * zl3073x_out_clock_type_get - get output clock type
> + * @out: pointer to out state
> + *
> + * Return: clock type of given output (ZL_OUTPUT_MODE_CLOCK_TYPE_*)
> + */
> +static inline u8 zl3073x_out_clock_type_get(const struct zl3073x_out *out)
> +{
> + return FIELD_GET(ZL_OUTPUT_MODE_CLOCK_TYPE, out->mode);
> +}
> +
> +/**
> + * zl3073x_out_clock_type_set - set output clock type
> + * @out: pointer to out state
> + * @type: clock type (ZL_OUTPUT_MODE_CLOCK_TYPE_*)
> + */
> +static inline void
> +zl3073x_out_clock_type_set(struct zl3073x_out *out, u8 type)
> +{
> + FIELD_MODIFY(ZL_OUTPUT_MODE_CLOCK_TYPE, &out->mode, type);
> +}
> +
> /**
> * zl3073x_out_signal_format_get - get output signal format
> * @out: pointer to out state
> diff --git a/drivers/dpll/zl3073x/ref.h b/drivers/dpll/zl3073x/ref.h
> index 06d8d4d97ea26..09fab97a71d7e 100644
> --- a/drivers/dpll/zl3073x/ref.h
> +++ b/drivers/dpll/zl3073x/ref.h
> @@ -106,6 +106,52 @@ zl3073x_ref_freq_set(struct zl3073x_ref *ref, u32 freq)
> return 0;
> }
>
> +/**
> + * zl3073x_ref_sync_mode_get - get sync control mode
> + * @ref: pointer to ref state
> + *
> + * Return: sync control mode (ZL_REF_SYNC_CTRL_MODE_*)
> + */
> +static inline u8
> +zl3073x_ref_sync_mode_get(const struct zl3073x_ref *ref)
> +{
> + return FIELD_GET(ZL_REF_SYNC_CTRL_MODE, ref->sync_ctrl);
> +}
> +
> +/**
> + * zl3073x_ref_sync_mode_set - set sync control mode
> + * @ref: pointer to ref state
> + * @mode: sync control mode (ZL_REF_SYNC_CTRL_MODE_*)
> + */
> +static inline void
> +zl3073x_ref_sync_mode_set(struct zl3073x_ref *ref, u8 mode)
> +{
> + FIELD_MODIFY(ZL_REF_SYNC_CTRL_MODE, &ref->sync_ctrl, mode);
> +}
> +
> +/**
> + * zl3073x_ref_sync_pair_get - get sync pair reference index
> + * @ref: pointer to ref state
> + *
> + * Return: paired reference index
> + */
> +static inline u8
> +zl3073x_ref_sync_pair_get(const struct zl3073x_ref *ref)
> +{
> + return FIELD_GET(ZL_REF_SYNC_CTRL_PAIR, ref->sync_ctrl);
> +}
> +
> +/**
> + * zl3073x_ref_sync_pair_set - set sync pair reference index
> + * @ref: pointer to ref state
> + * @pair: paired reference index
> + */
> +static inline void
> +zl3073x_ref_sync_pair_set(struct zl3073x_ref *ref, u8 pair)
> +{
> + FIELD_MODIFY(ZL_REF_SYNC_CTRL_PAIR, &ref->sync_ctrl, pair);
> +}
> +
> /**
> * zl3073x_ref_is_diff - check if the given input reference is differential
> * @ref: pointer to ref state
> diff --git a/drivers/dpll/zl3073x/regs.h b/drivers/dpll/zl3073x/regs.h
> index 5ae50cb761a97..d425dc67250fe 100644
> --- a/drivers/dpll/zl3073x/regs.h
> +++ b/drivers/dpll/zl3073x/regs.h
> @@ -213,7 +213,9 @@
> #define ZL_REG_REF_SYNC_CTRL ZL_REG(10, 0x2e, 1)
> #define ZL_REF_SYNC_CTRL_MODE GENMASK(2, 0)
> #define ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR_OFF 0
> +#define ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR 1
> #define ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75 2
> +#define ZL_REF_SYNC_CTRL_PAIR GENMASK(7, 4)
>
> #define ZL_REG_REF_ESYNC_DIV ZL_REG(10, 0x30, 4)
> #define ZL_REF_ESYNC_DIV_1HZ 0
LGTM.
Reviewed-by: Petr Oros <poros@redhat.com>
^ permalink raw reply
* 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
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