[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cac4222e-1f66-40e1-abf8-7d4661d43bbf@gmail.com>
Date: Tue, 14 Oct 2025 15:11:56 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
Lee Jones <lee@...nel.org>, Pavel Machek <pavel@...nel.org>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Sebastian Reichel <sre@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
Bartosz Golaszewski <brgl@...ev.pl>, Andreas Kemnade <andreas@...nade.info>,
linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
linux-gpio@...r.kernel.org
Subject: Re: [RFC PATCH 04/13] dt-bindings: mfd: ROHM BD72720
On 13/10/2025 15:58, Linus Walleij wrote:
> Hi Matti,
>
> thanks for your patch!
Thank You for taking the time to review of this RFC!
> On Tue, Oct 7, 2025 at 10:33 AM Matti Vaittinen
> <mazziesaccount@...il.com> wrote:
>
>> + rohm,pin-dvs0:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description:
>> + BD72720 has 4 different OTP options to determine the use of dvs0-pin.
>> + OTP0 - regulator RUN state control.
>> + OTP1 - GPI.
>> + OTP2 - GPO.
>> + OTP3 - Power sequencer output.
>> + This property specifies the use of the pin.
>> + enum:
>> + - dvs-input
>> + - gpi
>> + - gpo
>> +
>> + rohm,pin-dvs1:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description:
>> + see rohm,pin-dvs0
>> + enum:
>> + - dvs-input
>> + - gpi
>> + - gpo
>> +
>> + rohm,pin-exten0:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description: BD72720 has an OTP option to use exten0-pin for different
>> + purposes. Set this property accrdingly.
>
> accordingly?
>
>> + const: gpo
>> +
>> + rohm,pin-exten1:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description: BD72720 has an OTP option to use exten1-pin for different
>> + purposes. Set this property accrdingly.
>
> accordingly?
>
>> + const: gpo
>> +
>> + rohm,pin-fault_b:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description: BD72720 has an OTP option to use fault_b-pin for different
>> + purposes. Set this property accrdingly.
>
> accordingly?
Gah. Well spotted, thanks!
>
>> + const: gpo
>
> These are a bit idiomatic, not using the actual framework for such
> things (pin control) BUT: they are on the other hand crystal
> clear for an integrator working with this device tree, and only
> four pins so why over-engineer it. I am fine
> with them if the DT people are.
I kind of like to emphasize the fact that this is not really a pin-mux
in a traditional sense. We can't change the routing after OTP is
written. As such, it more resembles "wiring" of the signal inside the
PMIC, and this property is not a control but tells us how the signal is
wired. But yeah, let's see what others think of it.
Yours,
-- Matti
Powered by blists - more mailing lists