Re: [PATCH v2 2/2] hwmon: ltc4282: add support for the LTC4282 chip

From: "Nuno Sá" <noname.nuno@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: nuno.sa@analog.com, linux-hwmon@vger.kernel.org,
	devicetree@vger.kernel.org,  linux-doc@vger.kernel.org,
	Jean Delvare <jdelvare@suse.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	 Jonathan Corbet <corbet@lwn.net>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Andy Shevchenko <andy@kernel.org>
Subject: Re: [PATCH v2 2/2] hwmon: ltc4282: add support for the LTC4282 chip
Date: Thu, 30 Nov 2023 11:20:32 +0100	[thread overview]
Message-ID: <971eb35068639ec404669ea5320c8183ea71a7d0.camel@gmail.com> (raw)
In-Reply-To: <CACRpkdZr6TdQCLy73Yx2RdMgQifd67remdxENBKYx3UvEMm87A@mail.gmail.com>

On Wed, 2023-11-29 at 21:55 +0100, Linus Walleij wrote:
> On Wed, Nov 29, 2023 at 5:08 PM Nuno Sá <noname.nuno@gmail.com> wrote:
> 
> > Cool, I actually thought that having the direction + get/set stuff would be weird
> > given the fact that we can only PULL_LOW or HIGH_Z the pins.
> 
> There are several drivers in the kernel that implement .set_config(),
> it's existing and should be enabled if it has uses.
> 

Yeah, it might make sense to support it specially for the input case. AFAICT, if I
use the .set_config() (but from a quick look I think we will need to add support for
it in gpiolib for the high-z configuration), then I can't use the gpio_regmap stuff.
As the driver stands I don't think I could do it anyways because setting gpio2-3 and
alert requires to write 0 on the register rather than 1. But again, I'm still very
suspicious about the whole thing. The datasheet states:

"GPIO1-GPIO3 and ALERT all have comparators monitoring
the voltage on these pins with a threshold of 1.28V even when
the pins are configured as outputs."

But we can't really set the direction for gpio2-3 and the alert pins (only getting
the level and setting it as PULL_LOW or HIGH_Z. gpio1 is the only one where we can
configure it as input or open drain ouput. Bah, I'll try to see if someone internally
can shed some light on this.

> As Andy points out: when the driver reaches a certain complexity,
> such as a huge table of muxable pins (that need to be configured to
> a certain muxing from device tree), and numerous complicated
> pin config options (also needing to be set up from device tree),
> it may be worth to implement a separate pin control driver that
> act as "backend" for the GPIO driver.
> 
> I think a separate pin control driver would be overkill in this case,
> it's a PWM driver with some smallish GPIO portions AFAICT,
> but you get to decide.
> 

Agreed, the chip only supports 4 pins and it is an optional feature. The main usage
for the chip iis to act as an hot swap controller (which maps into hwmon).

- Nuno Sá