Document the Top Level Mode Multiplexer on the Eliza Platform.
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
.../bindings/pinctrl/qcom,eliza-tlmm.yaml | 138 +++++++++++++++++++++
1 file changed, 138 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml
new file mode 100644
index 000000000000..d8b6591caf57
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,eliza-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. Eliza TLMM block
+
+maintainers:
+ - Abel Vesa <abel.vesa@oss.qualcomm.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm Eliza SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,eliza-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 84
+
+ gpio-line-names:
+ maxItems: 185
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-eliza-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-eliza-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-eliza-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-7][0-9]|18[0-5])$"
+ - enum: [ ufs_reset ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ gpio, aoss_cti, atest_char, atest_usb, audio_ext_mclk0,
+ audio_ref_clk, cam_mclk, cci_async_in, cci_i2c_scl,
+ cci_i2c_sda, cci_timer, coex_uart1_rx, coex_uart1_tx,
+ coex_uart2_rx, coex_uart2_tx, dbg_out_clk,
+ ddr_bist_complete, ddr_bist_fail, ddr_bist_start,
+ ddr_bist_stop, ddr_pxi0, ddr_pxi1, dp0_hot, egpio,
+ gcc_gp1, gcc_gp2, gcc_gp3, gnss_adc0, gnss_adc1,
+ hdmi_ddc_scl, hdmi_ddc_sda, hdmi_dtest0, hdmi_dtest1,
+ hdmi_hot_plug, hdmi_pixel_clk, hdmi_rcv_det, hdmi_tx_cec,
+ host2wlan_sol, i2s0_data0, i2s0_data1, i2s0_sck, i2s0_ws,
+ ibi_i3c, jitter_bist, mdp_esync0_out, mdp_esync1_out,
+ mdp_vsync, mdp_vsync0_out, mdp_vsync11_out,
+ mdp_vsync1_out, mdp_vsync2_out, mdp_vsync3_out,
+ mdp_vsync_e, nav_gpio0, nav_gpio1, nav_gpio2, nav_gpio3,
+ pcie0_clk_req_n, pcie1_clk_req_n, phase_flag,
+ pll_bist_sync, pll_clk_aux, prng_rosc0, prng_rosc1,
+ prng_rosc2, prng_rosc3, qdss_cti, qdss_gpio_traceclk,
+ qdss_gpio_tracectl, qdss_gpio_tracedata, qlink_big_enable,
+ qlink_big_request, qlink_little_enable,
+ qlink_little_request, qlink_wmss, qspi0, qspi_clk,
+ qspi_cs, qup1_se0, qup1_se1, qup1_se2, qup1_se3, qup1_se4,
+ qup1_se5, qup1_se6, qup1_se7, qup2_se0, qup2_se1,
+ qup2_se2, qup2_se3, qup2_se4, qup2_se5, qup2_se6,
+ qup2_se7, resout_gpio, sd_write_protect, sdc1, sdc2,
+ sdc2_fb_clk, tb_trig_sdc1, tb_trig_sdc2, tmess_prng0,
+ tmess_prng1, tmess_prng2, tmess_prng3, tsense_pwm1,
+ tsense_pwm2, tsense_pwm3, tsense_pwm4, uim0_clk,
+ uim0_data, uim0_present, uim0_reset, uim1_clk, uim1_data,
+ uim1_present, uim1_reset, usb0_hs, usb_phy, vfr_0, vfr_1,
+ vsense_trigger_mirnat, wcn_sw_ctrl ]
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,eliza-tlmm";
+ reg = <0x0f100000 0x300000>;
+
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ gpio-ranges = <&tlmm 0 0 186>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ qup-uart14-default-state {
+ pins = "gpio18", "gpio19";
+ function = "qup2_se5";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+...
--
2.48.1On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote: > Document the Top Level Mode Multiplexer on the Eliza Platform. > > Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> > --- > .../bindings/pinctrl/qcom,eliza-tlmm.yaml | 138 +++++++++++++++++++++ > 1 file changed, 138 insertions(+) > > diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml > new file mode 100644 > index 000000000000..d8b6591caf57 > --- /dev/null > +++ b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml > @@ -0,0 +1,138 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/pinctrl/qcom,eliza-tlmm.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm Technologies, Inc. Eliza TLMM block > + > +maintainers: > + - Abel Vesa <abel.vesa@oss.qualcomm.com> > + > +description: > + Top Level Mode Multiplexer pin controller in Qualcomm Eliza SoC. > + > +allOf: > + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# > + > +properties: > + compatible: > + const: qcom,eliza-tlmm > + > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > + gpio-reserved-ranges: > + minItems: 1 > + maxItems: 84 93 > + > + gpio-line-names: > + maxItems: 185 186, your first GPIO is 0 and last is 185. After fixing these two: Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Best regards, Krzysztof
On 26-01-28 12:38:32, Krzysztof Kozlowski wrote: > On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote: > > Document the Top Level Mode Multiplexer on the Eliza Platform. > > > > Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> > > --- > > .../bindings/pinctrl/qcom,eliza-tlmm.yaml | 138 +++++++++++++++++++++ > > 1 file changed, 138 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml > > new file mode 100644 > > index 000000000000..d8b6591caf57 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml > > @@ -0,0 +1,138 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/pinctrl/qcom,eliza-tlmm.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Qualcomm Technologies, Inc. Eliza TLMM block > > + > > +maintainers: > > + - Abel Vesa <abel.vesa@oss.qualcomm.com> > > + > > +description: > > + Top Level Mode Multiplexer pin controller in Qualcomm Eliza SoC. > > + > > +allOf: > > + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# > > + > > +properties: > > + compatible: > > + const: qcom,eliza-tlmm > > + > > + reg: > > + maxItems: 1 > > + > > + interrupts: > > + maxItems: 1 > > + > > + gpio-reserved-ranges: > > + minItems: 1 > > + maxItems: 84 > > 93 > > > + > > + gpio-line-names: > > + maxItems: 185 > > 186, your first GPIO is 0 and last is 185. Wait, are all of these wrong then? $ grep -r "gpio-line-names" Documentation/devicetree/bindings/pinctrl/qcom,sm8[3-7]50* -A 3 |grep maxItems: Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml- maxItems: 203 Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml- maxItems: 210 Documentation/devicetree/bindings/pinctrl/qcom,sm8550-tlmm.yaml- maxItems: 210 Documentation/devicetree/bindings/pinctrl/qcom,sm8650-tlmm.yaml- maxItems: 210 Documentation/devicetree/bindings/pinctrl/qcom,sm8750-tlmm.yaml- maxItems: 215 $ grep -r "UFS_RESET\"" drivers/pinctrl/qcom/pinctrl-sm8[3-7]50.c drivers/pinctrl/qcom/pinctrl-sm8350.c: PINCTRL_PIN(203, "UFS_RESET"), drivers/pinctrl/qcom/pinctrl-sm8450.c: PINCTRL_PIN(210, "UFS_RESET"), drivers/pinctrl/qcom/pinctrl-sm8550.c: PINCTRL_PIN(210, "UFS_RESET"), drivers/pinctrl/qcom/pinctrl-sm8650.c: PINCTRL_PIN(210, "UFS_RESET"), drivers/pinctrl/qcom/pinctrl-sm8750.c: PINCTRL_PIN(215, "UFS_RESET"),
On 26-01-29 12:54:49, Abel Vesa wrote: > On 26-01-28 12:38:32, Krzysztof Kozlowski wrote: > > On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote: > > > Document the Top Level Mode Multiplexer on the Eliza Platform. > > > > > > Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> > > > --- > > > .../bindings/pinctrl/qcom,eliza-tlmm.yaml | 138 +++++++++++++++++++++ > > > 1 file changed, 138 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml > > > new file mode 100644 > > > index 000000000000..d8b6591caf57 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml > > > @@ -0,0 +1,138 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/pinctrl/qcom,eliza-tlmm.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Qualcomm Technologies, Inc. Eliza TLMM block > > > + > > > +maintainers: > > > + - Abel Vesa <abel.vesa@oss.qualcomm.com> > > > + > > > +description: > > > + Top Level Mode Multiplexer pin controller in Qualcomm Eliza SoC. > > > + > > > +allOf: > > > + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# > > > + > > > +properties: > > > + compatible: > > > + const: qcom,eliza-tlmm > > > + > > > + reg: > > > + maxItems: 1 > > > + > > > + interrupts: > > > + maxItems: 1 > > > + > > > + gpio-reserved-ranges: > > > + minItems: 1 > > > + maxItems: 84 > > > > 93 > > > > > + > > > + gpio-line-names: > > > + maxItems: 185 > > > > 186, your first GPIO is 0 and last is 185. > > Wait, are all of these wrong then? > > $ grep -r "gpio-line-names" Documentation/devicetree/bindings/pinctrl/qcom,sm8[3-7]50* -A 3 |grep maxItems: > Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml- maxItems: 203 > Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml- maxItems: 210 > Documentation/devicetree/bindings/pinctrl/qcom,sm8550-tlmm.yaml- maxItems: 210 > Documentation/devicetree/bindings/pinctrl/qcom,sm8650-tlmm.yaml- maxItems: 210 > Documentation/devicetree/bindings/pinctrl/qcom,sm8750-tlmm.yaml- maxItems: 215 > $ grep -r "UFS_RESET\"" drivers/pinctrl/qcom/pinctrl-sm8[3-7]50.c > drivers/pinctrl/qcom/pinctrl-sm8350.c: PINCTRL_PIN(203, "UFS_RESET"), > drivers/pinctrl/qcom/pinctrl-sm8450.c: PINCTRL_PIN(210, "UFS_RESET"), > drivers/pinctrl/qcom/pinctrl-sm8550.c: PINCTRL_PIN(210, "UFS_RESET"), > drivers/pinctrl/qcom/pinctrl-sm8650.c: PINCTRL_PIN(210, "UFS_RESET"), > drivers/pinctrl/qcom/pinctrl-sm8750.c: PINCTRL_PIN(215, "UFS_RESET"), 185 is actually correct, because ufs_reset doesn't count.
On 26-01-28 12:38:32, Krzysztof Kozlowski wrote: > On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote: > > Document the Top Level Mode Multiplexer on the Eliza Platform. > > > > Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> > > --- > > .../bindings/pinctrl/qcom,eliza-tlmm.yaml | 138 +++++++++++++++++++++ > > 1 file changed, 138 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml > > new file mode 100644 > > index 000000000000..d8b6591caf57 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml > > @@ -0,0 +1,138 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/pinctrl/qcom,eliza-tlmm.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Qualcomm Technologies, Inc. Eliza TLMM block > > + > > +maintainers: > > + - Abel Vesa <abel.vesa@oss.qualcomm.com> > > + > > +description: > > + Top Level Mode Multiplexer pin controller in Qualcomm Eliza SoC. > > + > > +allOf: > > + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# > > + > > +properties: > > + compatible: > > + const: qcom,eliza-tlmm > > + > > + reg: > > + maxItems: 1 > > + > > + interrupts: > > + maxItems: 1 > > + > > + gpio-reserved-ranges: > > + minItems: 1 > > + maxItems: 84 > > 93 Will fix. > > > + > > + gpio-line-names: > > + maxItems: 185 > > 186, your first GPIO is 0 and last is 185. Actually it is 0 through 184. The 185 is ufs reset. > > After fixing these two: > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> > Thanks!
On 1/28/26 6:22 PM, Abel Vesa wrote: > On 26-01-28 12:38:32, Krzysztof Kozlowski wrote: >> On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote: >>> Document the Top Level Mode Multiplexer on the Eliza Platform. >>> >>> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> >>> --- [...] >>> + >>> + gpio-line-names: >>> + maxItems: 185 >> >> 186, your first GPIO is 0 and last is 185. > > Actually it is 0 through 184. The 185 is ufs reset. The UFS reset also happens to be a GPIO.. Konrad
On 26-01-29 11:34:07, Konrad Dybcio wrote: > On 1/28/26 6:22 PM, Abel Vesa wrote: > > On 26-01-28 12:38:32, Krzysztof Kozlowski wrote: > >> On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote: > >>> Document the Top Level Mode Multiplexer on the Eliza Platform. > >>> > >>> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> > >>> --- > > [...] > > >>> + > >>> + gpio-line-names: > >>> + maxItems: 185 > >> > >> 186, your first GPIO is 0 and last is 185. > > > > Actually it is 0 through 184. The 185 is ufs reset. > > The UFS reset also happens to be a GPIO.. So the gpio-line-names should include the ufs reset, but the pattern not. Will fix accordingly. Thanks.
On 1/29/26 11:41 AM, Abel Vesa wrote: > On 26-01-29 11:34:07, Konrad Dybcio wrote: >> On 1/28/26 6:22 PM, Abel Vesa wrote: >>> On 26-01-28 12:38:32, Krzysztof Kozlowski wrote: >>>> On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote: >>>>> Document the Top Level Mode Multiplexer on the Eliza Platform. >>>>> >>>>> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> >>>>> --- >> >> [...] >> >>>>> + >>>>> + gpio-line-names: >>>>> + maxItems: 185 >>>> >>>> 186, your first GPIO is 0 and last is 185. >>> >>> Actually it is 0 through 184. The 185 is ufs reset. >> >> The UFS reset also happens to be a GPIO.. > > So the gpio-line-names should include the ufs reset, > but the pattern not. Why not? Do you see a reference to ufs_reset anywhere in DT? Konrad
On 26-01-29 11:45:59, Konrad Dybcio wrote: > On 1/29/26 11:41 AM, Abel Vesa wrote: > > On 26-01-29 11:34:07, Konrad Dybcio wrote: > >> On 1/28/26 6:22 PM, Abel Vesa wrote: > >>> On 26-01-28 12:38:32, Krzysztof Kozlowski wrote: > >>>> On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote: > >>>>> Document the Top Level Mode Multiplexer on the Eliza Platform. > >>>>> > >>>>> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> > >>>>> --- > >> > >> [...] > >> > >>>>> + > >>>>> + gpio-line-names: > >>>>> + maxItems: 185 > >>>> > >>>> 186, your first GPIO is 0 and last is 185. > >>> > >>> Actually it is 0 through 184. The 185 is ufs reset. > >> > >> The UFS reset also happens to be a GPIO.. > > > > So the gpio-line-names should include the ufs reset, > > but the pattern not. > > Why not? ufs reset cannot be configured as gpio, so why would it be part of the pattern? For the same reason, it cannot be part of the gpio-line-names either. All other platforms follow this approach.
On 1/29/26 12:12 PM, Abel Vesa wrote: > On 26-01-29 11:45:59, Konrad Dybcio wrote: >> On 1/29/26 11:41 AM, Abel Vesa wrote: >>> On 26-01-29 11:34:07, Konrad Dybcio wrote: >>>> On 1/28/26 6:22 PM, Abel Vesa wrote: >>>>> On 26-01-28 12:38:32, Krzysztof Kozlowski wrote: >>>>>> On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote: >>>>>>> Document the Top Level Mode Multiplexer on the Eliza Platform. >>>>>>> >>>>>>> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> >>>>>>> --- >>>> >>>> [...] >>>> >>>>>>> + >>>>>>> + gpio-line-names: >>>>>>> + maxItems: 185 >>>>>> >>>>>> 186, your first GPIO is 0 and last is 185. >>>>> >>>>> Actually it is 0 through 184. The 185 is ufs reset. >>>> >>>> The UFS reset also happens to be a GPIO.. >>> >>> So the gpio-line-names should include the ufs reset, >>> but the pattern not. >> >> Why not? > > ufs reset cannot be configured as gpio, so why would it be part of the > pattern? It's certainly registered as a GPIO, as all users of UFSHC refer to it > For the same reason, it cannot be part of the gpio-line-names either. Since it's registered as a GPIO, why not? Konrad
On 26-01-29 13:04:23, Konrad Dybcio wrote: > On 1/29/26 12:12 PM, Abel Vesa wrote: > > On 26-01-29 11:45:59, Konrad Dybcio wrote: > >> On 1/29/26 11:41 AM, Abel Vesa wrote: > >>> On 26-01-29 11:34:07, Konrad Dybcio wrote: > >>>> On 1/28/26 6:22 PM, Abel Vesa wrote: > >>>>> On 26-01-28 12:38:32, Krzysztof Kozlowski wrote: > >>>>>> On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote: > >>>>>>> Document the Top Level Mode Multiplexer on the Eliza Platform. > >>>>>>> > >>>>>>> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> > >>>>>>> --- > >>>> > >>>> [...] > >>>> > >>>>>>> + > >>>>>>> + gpio-line-names: > >>>>>>> + maxItems: 185 > >>>>>> > >>>>>> 186, your first GPIO is 0 and last is 185. > >>>>> > >>>>> Actually it is 0 through 184. The 185 is ufs reset. > >>>> > >>>> The UFS reset also happens to be a GPIO.. > >>> > >>> So the gpio-line-names should include the ufs reset, > >>> but the pattern not. > >> > >> Why not? > > > > ufs reset cannot be configured as gpio, so why would it be part of the > > pattern? > > It's certainly registered as a GPIO, as all users of UFSHC refer to it Well, technically yes, SW-wise. But it definitely doesn't have the same configuration fields in HW. Anyway, that is not the point here. The point is the pattern has dedicated enum for ufs_reset and gpio185 is not even part of the gpio groups anyway. [1] Also, are you saying that all older platforms (sm8[3-7]50, at least) are effectively wrong since they do exactly the thing I described ? :-) > > > For the same reason, it cannot be part of the gpio-line-names either. > > Since it's registered as a GPIO, why not? If what I'm saying above is true, you can't configure gpio185, so AFAICT you won't be able to name it either. Or am I wrong ?
On 1/29/26 1:42 PM, Abel Vesa wrote:
> On 26-01-29 13:04:23, Konrad Dybcio wrote:
>> On 1/29/26 12:12 PM, Abel Vesa wrote:
>>> On 26-01-29 11:45:59, Konrad Dybcio wrote:
>>>> On 1/29/26 11:41 AM, Abel Vesa wrote:
>>>>> On 26-01-29 11:34:07, Konrad Dybcio wrote:
>>>>>> On 1/28/26 6:22 PM, Abel Vesa wrote:
>>>>>>> On 26-01-28 12:38:32, Krzysztof Kozlowski wrote:
>>>>>>>> On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote:
>>>>>>>>> Document the Top Level Mode Multiplexer on the Eliza Platform.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
>>>>>>>>> ---
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>>>> +
>>>>>>>>> + gpio-line-names:
>>>>>>>>> + maxItems: 185
>>>>>>>>
>>>>>>>> 186, your first GPIO is 0 and last is 185.
>>>>>>>
>>>>>>> Actually it is 0 through 184. The 185 is ufs reset.
>>>>>>
>>>>>> The UFS reset also happens to be a GPIO..
>>>>>
>>>>> So the gpio-line-names should include the ufs reset,
>>>>> but the pattern not.
>>>>
>>>> Why not?
>>>
>>> ufs reset cannot be configured as gpio, so why would it be part of the
>>> pattern?
>>
>> It's certainly registered as a GPIO, as all users of UFSHC refer to it
>
> Well, technically yes, SW-wise. But it definitely doesn't have the same
> configuration fields in HW. Anyway, that is not the point here.
>
> The point is the pattern has dedicated enum for ufs_reset and gpio185 is
> not even part of the gpio groups anyway. [1]
So, is the current behavior such that in case I wanted to set some
properties on the ufs pin, the description would be:
foo-state {
pins = "ufs_reset";
};
?
TBF we don't have any such ones, possibly because whatever the
bootloader had configured has always seemed to work well enough..
In that case, I agree that this pattern should not include the pin.
I'm however a little surprised to see that would be the case, since
we end up consuming this pin as a numbered GPIO via reset-gpios.
> Also, are you saying that all older platforms (sm8[3-7]50, at least) are effectively
> wrong since they do exactly the thing I described ? :-)
>
>>
>>> For the same reason, it cannot be part of the gpio-line-names either.
>>
>> Since it's registered as a GPIO, why not?
>
> If what I'm saying above is true, you can't configure gpio185, so AFAICT you
> won't be able to name it either. Or am I wrong ?
I think the truth is more nuanced:
The UFS_RESET is a GPIO in the sense of pinctrl-msm, as it has a ctl_reg
and an io_reg. It's not capable of receiving interrupts and it seems to
be output-only.
It does not have a "gpio" pinmux function (func0 is named "ufs_reset" intead),
but that's just human-facing naming, so whatever.
It can be toggled and is consumed by its number, through the gpios/xxx-pins
property.
Running cat /sys/kernel/debug/gpios on x1e80100, where ngpios and gpio-ranges
includes that pin though, I could not see it listed. I don't really know why.
That's where I'd expect to see the name given by gpio-line-names.
Now, I would also strongly expect that this pin would be only ever used for
UFS reset, making the name override unnecessary but we've all seen things..
Konrad
On 26-01-29 15:11:07, Konrad Dybcio wrote:
> On 1/29/26 1:42 PM, Abel Vesa wrote:
> > On 26-01-29 13:04:23, Konrad Dybcio wrote:
> >> On 1/29/26 12:12 PM, Abel Vesa wrote:
> >>> On 26-01-29 11:45:59, Konrad Dybcio wrote:
> >>>> On 1/29/26 11:41 AM, Abel Vesa wrote:
> >>>>> On 26-01-29 11:34:07, Konrad Dybcio wrote:
> >>>>>> On 1/28/26 6:22 PM, Abel Vesa wrote:
> >>>>>>> On 26-01-28 12:38:32, Krzysztof Kozlowski wrote:
> >>>>>>>> On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote:
> >>>>>>>>> Document the Top Level Mode Multiplexer on the Eliza Platform.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> >>>>>>>>> ---
> >>>>>>
> >>>>>> [...]
> >>>>>>
> >>>>>>>>> +
> >>>>>>>>> + gpio-line-names:
> >>>>>>>>> + maxItems: 185
> >>>>>>>>
> >>>>>>>> 186, your first GPIO is 0 and last is 185.
> >>>>>>>
> >>>>>>> Actually it is 0 through 184. The 185 is ufs reset.
> >>>>>>
> >>>>>> The UFS reset also happens to be a GPIO..
> >>>>>
> >>>>> So the gpio-line-names should include the ufs reset,
> >>>>> but the pattern not.
> >>>>
> >>>> Why not?
> >>>
> >>> ufs reset cannot be configured as gpio, so why would it be part of the
> >>> pattern?
> >>
> >> It's certainly registered as a GPIO, as all users of UFSHC refer to it
> >
> > Well, technically yes, SW-wise. But it definitely doesn't have the same
> > configuration fields in HW. Anyway, that is not the point here.
> >
> > The point is the pattern has dedicated enum for ufs_reset and gpio185 is
> > not even part of the gpio groups anyway. [1]
>
> So, is the current behavior such that in case I wanted to set some
> properties on the ufs pin, the description would be:
>
> foo-state {
> pins = "ufs_reset";
> };
>
> ?
>
> TBF we don't have any such ones, possibly because whatever the
> bootloader had configured has always seemed to work well enough..
>
> In that case, I agree that this pattern should not include the pin.
> I'm however a little surprised to see that would be the case, since
> we end up consuming this pin as a numbered GPIO via reset-gpios.
That's because the pins property uses the name (here "ufs_reset") while
the *-gpios uses the number that goes via driver specific of_xlate.
>
> > Also, are you saying that all older platforms (sm8[3-7]50, at least) are effectively
> > wrong since they do exactly the thing I described ? :-)
> >
> >>
> >>> For the same reason, it cannot be part of the gpio-line-names either.
> >>
> >> Since it's registered as a GPIO, why not?
> >
> > If what I'm saying above is true, you can't configure gpio185, so AFAICT you
> > won't be able to name it either. Or am I wrong ?
>
> I think the truth is more nuanced:
>
> The UFS_RESET is a GPIO in the sense of pinctrl-msm, as it has a ctl_reg
> and an io_reg. It's not capable of receiving interrupts and it seems to
> be output-only.
Just because we treat it as gpio in the driver, doesn't mean it is a gpio.
HW-wise, it is not a gpio. GPIOs have electrical properties (at least) that
this ufs_reset doesn't.
>
> It does not have a "gpio" pinmux function (func0 is named "ufs_reset" intead),
> but that's just human-facing naming, so whatever.
>
> It can be toggled and is consumed by its number, through the gpios/xxx-pins
> property.
Being toggle capable doesn't make it a GPIO. Again, a GPIO is more than that.
>
> Running cat /sys/kernel/debug/gpios on x1e80100, where ngpios and gpio-ranges
> includes that pin though, I could not see it listed. I don't really know why.
> That's where I'd expect to see the name given by gpio-line-names.
Yeah. I think it should've listed it. It does on Eliza and Glymur.
>
> Now, I would also strongly expect that this pin would be only ever used for
> UFS reset, making the name override unnecessary but we've all seen things..
Anyway, to conclude, pins property does allow you to use it by name beacuse
of the enum entry below.
But the gpio-line-names doesn't make any sense to allow you to override the name.
This part is can be debated, for sure.
I'll respin with these in mind and we can fix this later on, if needed, on all
platforms at once.
Thanks,
Abel
On 26-01-29 11:45:59, Konrad Dybcio wrote: > On 1/29/26 11:41 AM, Abel Vesa wrote: > > On 26-01-29 11:34:07, Konrad Dybcio wrote: > >> On 1/28/26 6:22 PM, Abel Vesa wrote: > >>> On 26-01-28 12:38:32, Krzysztof Kozlowski wrote: > >>>> On Tue, Jan 27, 2026 at 05:47:36PM +0200, Abel Vesa wrote: > >>>>> Document the Top Level Mode Multiplexer on the Eliza Platform. > >>>>> > >>>>> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> > >>>>> --- > >> > >> [...] > >> > >>>>> + > >>>>> + gpio-line-names: > >>>>> + maxItems: 185 > >>>> > >>>> 186, your first GPIO is 0 and last is 185. > >>> > >>> Actually it is 0 through 184. The 185 is ufs reset. > >> > >> The UFS reset also happens to be a GPIO.. > > > > So the gpio-line-names should include the ufs reset, > > but the pattern not. > > Why not? I was drawing the conclusion. No question mark. :) > > Do you see a reference to ufs_reset anywhere in DT? > > Konrad
On 28/01/2026 18:22, Abel Vesa wrote: >> >>> + >>> + gpio-line-names: >>> + maxItems: 185 >> >> 186, your first GPIO is 0 and last is 185. > > Actually it is 0 through 184. The 185 is ufs reset. Then the gpio pattern is not correct. > >> >> After fixing these two: >> >> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Best regards, Krzysztof
On 26-01-28 20:58:25, Krzysztof Kozlowski wrote: > On 28/01/2026 18:22, Abel Vesa wrote: > >> > >>> + > >>> + gpio-line-names: > >>> + maxItems: 185 > >> > >> 186, your first GPIO is 0 and last is 185. > > > > Actually it is 0 through 184. The 185 is ufs reset. > > Then the gpio pattern is not correct. Yep. Will fix. > > > > >> > >> After fixing these two: > >> > >> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> > Best regards, > Krzysztof
© 2016 - 2026 Red Hat, Inc.