From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 76773305662 for ; Mon, 3 Aug 2026 05:49:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785736145; cv=none; b=bF0/Nf/iQPZ8XfVq0+RAVVBZVpYEpg6CU7FmfQ5N/+ziQXFbu6zr134vKCo6iVPH7BMRSXL4gUF/lZGFbNsoBKJiRadLUDeNx/FHUp+44UGG9RGY3ufCDnui7NkORxJb+Rb0VClyMiIptUusuwTH6N8N+aKd+pdzAf2UyWV+nqU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785736145; c=relaxed/simple; bh=x1Z4nUqvVtCWJiVWeGWzCEKbiZv0wMWpiYwZdmMU34k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=D5LTtrGILSgjCUHsmfAc84GnmZan4+4sb1HjLaB+CPOtPw9cMspEXtp2Yt2jGOLcTvO0zyl6JFJe792YqDUJEtyNtOvcmJQjQIIcrGdO4MsTy+jz/pjasB6eZXCDpxxsQ2JJ75FOsGmj1wlrHvsvMHhoXIqlGmShI91kk5FS5sg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=qcNL7HwG; arc=none smtp.client-ip=209.85.167.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qcNL7HwG" Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-5b2aa3be376so2214819e87.0 for ; Sun, 02 Aug 2026 22:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785736141; x=1786340941; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+Z8jXZAUhcjKTtPoIZ4/epKb5xdLnKYJzAnB3Lfizgk=; b=qcNL7HwG00+Ui84qD0786CouAT5q6Fwv392Lrn0nX8l4oULWsE1nbACCco/+cq3qnG Xm8t5vkQ9sl+ejHH7GQrZKy6HqAJwm/1AIA3hlgm0PbNBXdOss6HqMX1yCycRPPwI9kB uXxI5A0jcIJmm6Sj8AdsWe7JXT60dEen+yZN2DAfnmhufcDmu9Cr+S3d/QWUp0e1BsgA /CEDB55XQbpCI2lNU7+tb2PNon8RTqS9CtVyEVrKJLaujMBWl+BYZbMBO+0gs61wScdA Z4bQXrBz6SAeLz2T4eZ7Wuw3Hnsl1DQY6qItdbqwMyEnoqbnUCRAAyujN+nPI237XWkw mmbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785736141; x=1786340941; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=+Z8jXZAUhcjKTtPoIZ4/epKb5xdLnKYJzAnB3Lfizgk=; b=SOW5tlacY3bIsVxIRSZCK3/+YcfEHf4gbN57Xax0VQt52144os7unjazyIO8AgFH46 9ZZganlEhF2Ltvl77Cf9fFBDvyGzDwmKOYd9a0s8ovF1td0Q4SBQC3Le37J/wp8lVVXL GyAQcYVso7bNRTRdYe25IZFGBvYnbdEIHhvEDuh1M5OKHAhLVv8lepibV6wxjC+Oh++6 KzLp1XFwfrxjrnQICogXA/2JCEDTMYjht4fJ+XjAsj5VuF3ium8Vb6RT7aBDlomvr5+R G2+T2olMtUNqhS7ouafN6V6raUTYuWzOsQ+AyJ1GPaStsBtIH4S10VxLAAj2yd6KQZ5r +rcQ== X-Forwarded-Encrypted: i=1; AHgh+RrEIj9Ac8fJycqdGJ6ZmeElyK8/Vqqn8+Jagf1SKLfyIIUQSRlKf1nG3jMKOlqF3xG2LOFpWMzk5tTcaUI=@vger.kernel.org X-Gm-Message-State: AOJu0Yypn9DgcBBNGWNbeAmWecaS81hJ2Sfl2hvsZSFrdn9BsO1QOWzp upQv6A2b/jaoiB627N1mJIzMDTS6ZlMYt7L+FhImCuVHl9DLUd8DgTR3 X-Gm-Gg: AR+sD13RDLSUUIak/patzx/BSdN/JwGXR1zhoJDfjX/orwivyiy/qob5Cpx+B53dCMJ R7djVUCbZypf8jpJDxGiCnWwxOHVqq6aCJKHLtTPDwsKusJZ1NQJgO3M2pzNAOqp6CV9bPcQytT 0YnM9MacLNFrCk5noUsRjCpVAoIesImxhjGNnuN1Xg8myuCSxNqnB6B2XIoPk2AP3P7Fjh1Q/F9 ALv4XOQiMOePuYYrzIohhg0c0rXgXCT8K0CjR6Ck7obX5WN+yDZ2eSIx1tIUAktEO6PIZSndDOi oB1BkspzbNkBl3uPD2UfG2mWqU0LitaunZDEF7Fs/KN1ZwDbLGM+fNuBpjyYJLj6Xe5JjFe9Grz digrzFkNQj2UJ5OkLMaSz1Tfbpck2xxhmed6l4J9V+7DKYkRU0Frs1Kk1upQuBIwpVl4wuxjzfd 5DVKujt6vin0qcv3qsopX8JQcTm65rlbar8olckZ38vphq6RFuJR/VrV854w7rJoioBQtHzSCfb MZq/Kn7E/Fw8ukAxcI4APHYajghlcNewFM2Qv2ik/mvbkzi/YICfLuCLg== X-Received: by 2002:ac2:41c3:0:b0:5ae:b130:1e1 with SMTP id 2adb3069b0e04-5b2e4f3b5c0mr1164615e87.28.1785736141209; Sun, 02 Aug 2026 22:49:01 -0700 (PDT) Received: from ?IPV6:2a10:a5c0:800d:dd00:8fdf:935a:2c85:d703? ([2a10:a5c0:800d:dd00:8fdf:935a:2c85:d703]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5b2e23cb4e6sm1832235e87.22.2026.08.02.22.48.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Aug 2026 22:49:00 -0700 (PDT) Message-ID: Date: Mon, 3 Aug 2026 08:48:59 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/8] dt-bindings: mfd: ROHM BD73800 PMIC To: Linus Walleij Cc: Matti Vaittinen , Matti Vaittinen , Lee Jones , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Liam Girdwood , Mark Brown , Michael Turquette , Stephen Boyd , Brian Masney , Bartosz Golaszewski , Alexandre Belloni , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, linux-gpio@vger.kernel.org, linux-rtc@vger.kernel.org References: <3e700a3fa7872a96257ff25a77670ec05cfd239c.1782909323.git.mazziesaccount@gmail.com> Content-Language: en-US, en-AU, en-GB, en-BW From: Matti Vaittinen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi dee Ho Linus, The way too short summer holiday is now gone, so I am back at this :) Thanks again for the comments, I am trying to improve for v2 ;) On 03/07/2026 23:46, Linus Walleij wrote: > On Wed, Jul 1, 2026 at 2:41 PM Matti Vaittinen > wrote: > >> + # The GPIO1, CLKOUT (GPIO2), FAULT_B and EXTEN_OUT pins can be >> + # configured to interrupt pins by OTP. > > Maybe move this helpful comment into the top description: instead? > It's kind of generic helpful info. > >> +# The GPIO1, CLKOUT, FAULT_B and EXTEN_OUT pins may be configured for a >> +# specific purpose (like ADC input, 32.768 clk output, fault indicator or >> +# delivering power sequence to a companion PMIC when multiple PMICs are >> +# used) - but also to be either a GPO or GPI. (When used as a GPI the pin >> +# can also be used as an IRQ source). The pin purpose is determined by >> +# OTP (One Time Programmable memory), typically during device manufacturing. >> +# The OTP can't be read at runtime so device-tree should describe the pins. >> + rohm,pin-gpio1: >> + $ref: /schemas/types.yaml#/definitions/string >> + description: >> + Indicate if the GPIO1 pin has been set to GPI or GPO at manufacturing. >> + enum: [gpi, gpo] >> + >> + rohm,pin-clkout: >> + $ref: /schemas/types.yaml#/definitions/string >> + description: >> + Indicate if the CLKOUT pin has been set to GPI or GPO at manufacturing. >> + enum: [gpi, gpo] >> + >> + rohm,pin-fault-b: >> + $ref: /schemas/types.yaml#/definitions/string >> + description: >> + Indicate if the FAULT_B pin has been set to GPI or GPO at manufacturing. >> + enum: [gpi, gpo] >> + >> + rohm,pin-exten: >> + $ref: /schemas/types.yaml#/definitions/string >> + description: >> + Indicate if the EXTEN_OUT pin has been set to GPI or GPO at >> + manufacturing. >> + enum: [gpi, gpo] > > Can we explain what "GPI" and "GPO" means in this context? > > I read it as "general purpose input" and "general purpose output", but... > you just describe the exact purpose? So what is "general purpose" > about them in that case? These property names (pin-gpio1, pin-clkout, pin-fault-b, pin-exten) do not define the purpose of the pin, but they match the pin name in the data-sheet. The idea is indeed to be able to say "the fault-b -pin is not a fault signal, but a general purpose input" - if the IC we are describing here has OTP configuration enabling this. I am re-using the approach from the BD72720 here. I think I will add a common binding file with these, which can then be referred by multiple rohm ICs (in same fashion I added the Documentation/devicetree/bindings/regulator/rohm,pmic-states.yaml for commonly used ROHM regulator properties). I'll see if it looks Ok (to me), and send it in v2 :) > I would re-use "input-enable" and "output-enable" from: > Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml > (I mean don't $rf that, just use these strings). > > I suppose: > enum: [input-enable, output-enable] > >> + 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 > > Here I would also reuse the generic pinconf properties, > something like; > > rohm,clkout-drive-type: > enum: [drive-push-pull, drive-open-drain] As I mentioned in my very hasty original reply, this is also an existing binding used in quite a few PMIC device-trees. Changing it now sounds like asking for problems, for (in my opinion) little benefit. Yet, since it is used by a few PMICs, I could perhaps put it in a common rohm binding file as well. Then it would be more obvious it is an existing property if new models re-use this. > (Push-pull is what is colloquially referred to as "cmos".) I will at least add a.k.a "push-pull" to the description :) > >> + rohm,pin-gpio1 = "gpo"; >> + rohm,pin-exten = "gpi"; > > If you instead use nodes with properties you can do this: > > rohm,pin-clkout { > output-enable; > drive-push-pull; > }; > > This collects the clkout config in one place and make > it obvious what is going on. But I don't know what the DT > maintainers think about this idea. I believe you mean I could translate: rohm,pin-clkout = "gpo"; rohm,clkout-open-drain = <0>; to rohm,pin-clkout { output-enable; drive-push-pull; }; right? I am actually not sure if this would work. The data-sheet made me to assume it might not. There is separate "OUT32K" register, which controls the clock gate. This, as far as I understand, is not usable when the OTP variant sets the CLKOUT -pin to GPO. The mode (open-drain / cmos) configuration resides in this clock gate register. [Just to complete picture, when OTP is set to GPO, the pin output is controlled by GPIO_OUT register instead. When OTP has set the pin to clk output (or to GPI), then the GPIO_OUT register writes have no impact.] Thus, in case of the BD73800, the: rohm,pin-clkout = "gpo"; rohm,clkout-open-drain = <0>; might actually be contradicting. ... Now, I will make a side-note... The data-sheet front page says: > 4 GPIOs > - OTP Option for GPIOs instead of I/F signals: > EXTEN_OUT, FAULT_B, CLKOUT, GPIO1 > - GPO Supports Open Drain and CMOS Output I, however, see no register control for the GPO output types. I _assume_ the output type (when pins are used for GPO) depends on OTP again. I will see if I can clarify this. Yours, -- Matti -- Matti Vaittinen Linux kernel developer at ROHM Semiconductors Oulu Finland ~~ When things go utterly wrong vim users can always type :help! ~~