[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8b5dbbf6-bbde-4015-b0d1-12d6ec770ceb@gmail.com>
Date: Wed, 29 Oct 2025 14:30:06 +0200
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>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Bartosz Golaszewski <brgl@...ev.pl>,
Andreas Kemnade <andreas@...nade.info>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
linux-clk@...r.kernel.org, linux-gpio@...r.kernel.org,
linux-rtc@...r.kernel.org
Subject: Re: [PATCH v2 04/15] dt-bindings: mfd: ROHM BD72720
On 28/10/2025 00:42, Linus Walleij wrote:
> Hi Matti,
>
> thanks for your patch!
>
> On Mon, Oct 27, 2025 at 12:45 PM Matti Vaittinen
> <mazziesaccount@...il.com> wrote:
>
>> + rohm,clkout-open-drain:
>> + description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos".
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + minimum: 0
>> + maximum: 1
>
> I think CMOS is the same as "push-pull" ( I could be wrong, but I think I've
> seen that before) so I would probably try to use the pin config standard
> names as strings here but I'm not sure.
>
> rohm,clkout-bias-open-drain;
> rohm,clkout-bias-push-pull;
>
> Mutually exclusive.
>
> Or maybe use the pattern from rohm,pin-dvs0
> with string enumerators?
>
> rohm,clkout-bias = "open-drain";
> rohm,clkout-bias = "push-pull";
>
Hmm. I kind of agree with you. Still, the way it was done in this patch
is used by the other existing ROHM PMICs (bd71815, bd71828, bd71879). I
am kind of reluctant to support another way in the same driver - and I
am also reluctant to change the existing bindings as that sounds a bit
like asking for a nose-bleed :) (I've in the past worked with some
devices which didn't update the device-trees when kernel was updated...)
Do you think you could live with using this existing convention? :)
Yours,
-- Matti
Powered by blists - more mailing lists