Add support for MAX16150/MAX16169 #2672

mrcsosa · 2024-12-10T08:46:13Z

PR Description

Please replace this comment with a summary of your changes, and add any context
necessary to understand them. List any dependencies required for this change.
To check the checkboxes below, insert a 'x' between square brackets (without
any space), or simply check them after publishing the PR.
If you changes include a breaking change, please specify dependent PRs in the
description and try to push all related PRs simultaneously.

PR Type

Bug fix (a change that fixes an issue)
New feature (a change that adds new functionality)
Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

I have conducted a self-review of my own code changes
I have tested the changes on the relevant hardware
I have updated the documentation outside this repo accordingly (if there is the case)

nunojsa

I'm stopping the review for now. Note that you pretty much copied the driver from one subsystem to another without any integration with the input subsystem. Not what was meant.

Please do not rush into opening PRs or having things done. Really try to understand what was asked and seek help if needed 😉

nunojsa · 2024-12-12T07:23:13Z

Documentation/devicetree/bindings/input/adi,max16150.yaml

+            brcm,function = <0>;
+            brcm,pull = <0>;
+        };
+    };


This looks to be very rpi dependent... Typically not needed in bindings AFAIK. But you're definetly missing input properties. Where do you define the key code?

I think the key code is typically used to detect button presses. However, with MAX16150, it sends interrupt signals when certain amount of time the button is pressed.

nunojsa · 2024-12-12T07:23:48Z

Documentation/devicetree/bindings/input/adi,max16150.yaml

+        compatible = "adi,max16150";
+        adi,variant = "A";
+
+        gpio-pb_in = <&gpio 17 1>;


Don't think the above needs to be a gpio. It's a button that you should register with the input subsystem

nunojsa · 2024-12-12T07:24:23Z

Documentation/devicetree/bindings/input/adi,max16150.yaml

+        adi,variant = "A";
+
+        gpio-pb_in = <&gpio 17 1>;
+        gpio-out = <&gpio 18 0>;


I'm also not convinced we need the above...

nunojsa · 2024-12-12T07:24:43Z

Documentation/devicetree/bindings/input/adi,max16150.yaml

+        gpio-pb_in = <&gpio 17 1>;
+        gpio-out = <&gpio 18 0>;
+        gpio-clr = <&gpio 22 1>;
+        gpio-int = <&gpio 23 0>;


This is an interrupts property and not a gpio

nunojsa · 2024-12-12T07:26:03Z

drivers/input/misc/max16150.c

+
+	hrtimer_cancel(&data->debounce_timer);
+	hrtimer_cancel(&data->shutdown_timer);
+	return 0;


This can be done in a devm_action... Also not sure if we really need hrtimers for this

nunojsa · 2024-12-12T07:26:25Z

drivers/input/misc/max16150.c

+	if (ret) {
+		dev_err(&pdev->dev, "Failed to request IRQ for PB_IN\n");
+		return ret;
+	}


Just use an irq... No need for it to be a gpio

nunojsa · 2024-12-12T07:27:19Z

drivers/input/misc/max16150.c

+	} else {
+		dev_err(&pdev->dev, "Unknown device type: %s\n", type);
+		return -EINVAL;
+	}


use proper chip info structure for subtleties in the chips... The above does not scale at al.

nunojsa · 2024-12-12T07:28:17Z

drivers/input/misc/max16150.c

+		return -EINVAL;
+	}
+
+	ret = device_property_read_string(&pdev->dev, "adi,variant", &variant);


Not in the bindings and I dunno you need a property for this... You already have compatibles and you can different info structure per compatible.

kister-jimenez

You might want to check out existing input device drivers for reference.

kister-jimenez · 2024-12-13T14:56:12Z

drivers/input/misc/max16150.c

+
+	if (data->variant == MAX161X_A && data->out_asserted) {
+		dev_info(data->dev, "Shutdown time exceeded. Deasserting OUT.");
+		gpiod_set_value(data->gpio_clr, 0);


You should use the input subsystem like input_report_key and input_sync to report the key and the value to the input subsystem and to sync input events.

kister-jimenez · 2024-12-13T15:02:02Z

drivers/input/misc/max16150.c

+	case 'A':
+		data->variant = MAX161X_A;
+		data->debounce_time = ktime_set(0, 50 * NSEC_PER_MSEC);
+		data->shutdown_time = (data->type == MAX16150) ? ktime_set(8,
+				      0) : ktime_set(16, 0);
+		break;
+	case 'B':
+		data->variant = MAX161X_B;
+		data->debounce_time = (data->type == MAX16150) ? ktime_set(2,
+				      0) : ktime_set(50, 0);
+		data->shutdown_time = ktime_set(16, 0);
+		break;
+	case 'C':
+		data->variant = MAX161X_C;
+		data->debounce_time = ktime_set(0, 50 * NSEC_PER_MSEC);
+		data->shutdown_time = ktime_set(16, 0);
+		break;


Not sure why you need the debounce time and shutdown time.
Debounce time is for the push button input which should be connected to a push button not the processor system.

Shutdown period is how long the button is pressed before the chip deasserts (in some variant) and pull down the interrupt pin. This is also related to the button side.

kister-jimenez · 2024-12-13T15:03:32Z

drivers/input/misc/max16150.c

+	dev_info(&pdev->dev, "Detected %s variant %s\n",
+		 (data->type == MAX16150) ? "MAX16150" : "MAX16169", variant);
+
+	data->gpio_pb_in = devm_gpiod_get(&pdev->dev, "pb_in", GPIOD_IN);


pb_in is not an input to the MPU and is not connected to the MPU. This is connected to the push button.

kister-jimenez · 2024-12-13T15:05:45Z

drivers/input/misc/max16150.c

+	if (IS_ERR(data->gpio_pb_in))
+		return PTR_ERR(data->gpio_pb_in);
+
+	data->gpio_out = devm_gpiod_get(&pdev->dev, "out", GPIOD_OUT_LOW);


Out pin of the device is typically used to control a switch or to gate the power to the device. You don't need this.

kister-jimenez · 2024-12-13T15:14:18Z

drivers/input/misc/max16150.c

+	if (IS_ERR(data->gpio_clr))
+		return PTR_ERR(data->gpio_clr);
+
+	data->gpio_int = devm_gpiod_get(&pdev->dev, "int", GPIOD_IN);


Just use an irq.

kister-jimenez · 2024-12-13T15:15:38Z

drivers/input/misc/max16150.c

+enum max161x_variant {
+	MAX161X_A,
+	MAX161X_B,
+	MAX161X_C,
+};
+
+enum max161x_type {
+	MAX16150,
+	MAX16169,
+};


Why don't you just combine these? I think the variant is part of the ordering options for customers to select different timing options?

kister-jimenez · 2024-12-13T15:23:29Z

drivers/input/misc/max16150.c

+	if (gpiod_get_value(data->gpio_pb_in)) {
+		/* Button pressed */
+		hrtimer_start(&data->debounce_timer, data->debounce_time,
+			      HRTIMER_MODE_REL);
+	} else {
+		/* Button released */
+		if (data->variant == MAX161X_A && data->out_asserted) {
+			dev_info(data->dev, "Cancelling shutdown timer.");
+			hrtimer_cancel(&data->shutdown_timer);
+		}
+	}


You should use the input subsystem like input_report_key and input_sync to report the key and the value to the input subsystem and to sync input events.

I think what you want is to know the interval between the last irq if you want to distinguish the long press and the short momentary press.

kister-jimenez · 2024-12-13T15:37:23Z

drivers/input/misc/max16150.c

+	hrtimer_init(&data->shutdown_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+	data->shutdown_timer.function = max161x_shutdown_timer_cb;
+
+	ret = devm_request_irq(&pdev->dev, gpiod_to_irq(data->gpio_pb_in),


The irq pin is the int pin not the pb_in pin.

mrcsosa · 2025-01-13T02:41:02Z

Changelogs V2:

Converted few functions to use input subsystem
Removed unused gpio pins, leaving int pin (to detect 32ms and 128ms interrupts) and clr pin to reset the output for Variant A devices.
Removed variants on the driver code and dts

Add documentation for device tree bindings for MAX16150/MAX16169 Signed-off-by: Marc Paolo Sosa <[email protected]>

MAX16150/MAX16169 nanoPower Pushbutton On/Off Controller Signed-off-by: Marc Paolo Sosa <[email protected]>

Add entry for the MAX16150/MAX16169 driver. Signed-off-by: Marc Paolo Sosa <[email protected]>

kister-jimenez · 2025-01-13T07:02:18Z

drivers/input/misc/max16150.c

+#define GPIO_INT 17
+#define GPIO_CLR 27


Get this from the device tree overlay.

kister-jimenez · 2025-01-13T07:04:11Z

drivers/input/misc/max16150.c

+static irqreturn_t max16150_isr(int irq, void *dev_id)
+{
+	ktime_t now = ktime_get();
+	ktime_t duration = ktime_sub(now, last_time);
+
+	if (duration >= long_pulse)
+		gpio_set_value(GPIO_CLR, 0);
+
+	last_time = now;
+	return IRQ_HANDLED;
+}


How will the input event propagate to sysfs?
How can users define different events for the long button press and short button press?

mrcsosa requested review from nunojsa, mhennerich, dbogdan, btogorean, chegbeli, buha, amiclaus, rbolboac, danmois, CiprianRegus and machschmitt as code owners December 10, 2024 08:46

mrcsosa force-pushed the dev/max16150 branch 3 times, most recently from fc933bb to 55c3ff9 Compare December 10, 2024 12:44

nunojsa reviewed Dec 12, 2024

View reviewed changes

mrcsosa marked this pull request as draft December 12, 2024 08:06

kister-jimenez reviewed Dec 13, 2024

View reviewed changes

mrcsosa marked this pull request as ready for review December 17, 2024 00:00

mrcsosa marked this pull request as draft January 13, 2025 00:35

mrcsosa force-pushed the dev/max16150 branch 4 times, most recently from 7aebbf1 to e96094d Compare January 13, 2025 01:26

mrcsosa marked this pull request as ready for review January 13, 2025 02:49

mrcsosa added 3 commits January 13, 2025 14:45

dt-bindings: input: add adi,max16150.yaml

3a603d9

Add documentation for device tree bindings for MAX16150/MAX16169 Signed-off-by: Marc Paolo Sosa <[email protected]>

input: misc: add driver for max16150

2dc6f75

MAX16150/MAX16169 nanoPower Pushbutton On/Off Controller Signed-off-by: Marc Paolo Sosa <[email protected]>

Kconfig.adi imply MAX16150

8734318

Add entry for the MAX16150/MAX16169 driver. Signed-off-by: Marc Paolo Sosa <[email protected]>

mrcsosa marked this pull request as draft January 13, 2025 06:45

mrcsosa force-pushed the dev/max16150 branch from e96094d to 8734318 Compare January 13, 2025 06:46

mrcsosa marked this pull request as ready for review January 13, 2025 08:27

kister-jimenez reviewed Jan 13, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for MAX16150/MAX16169 #2672

Add support for MAX16150/MAX16169 #2672

mrcsosa commented Dec 10, 2024

nunojsa left a comment

nunojsa Dec 12, 2024

mrcsosa Jan 13, 2025

nunojsa Dec 12, 2024

nunojsa Dec 12, 2024

nunojsa Dec 12, 2024

nunojsa Dec 12, 2024

nunojsa Dec 12, 2024

nunojsa Dec 12, 2024

nunojsa Dec 12, 2024

kister-jimenez left a comment

kister-jimenez Dec 13, 2024

kister-jimenez Dec 13, 2024

kister-jimenez Dec 13, 2024

kister-jimenez Dec 13, 2024

kister-jimenez Dec 13, 2024

kister-jimenez Dec 13, 2024

kister-jimenez Dec 13, 2024

kister-jimenez Dec 13, 2024

mrcsosa commented Jan 13, 2025 •

edited

Loading

kister-jimenez Jan 13, 2025

kister-jimenez Jan 13, 2025

		#define GPIO_INT 17
		#define GPIO_CLR 27

Add support for MAX16150/MAX16169 #2672

Are you sure you want to change the base?

Add support for MAX16150/MAX16169 #2672

Conversation

mrcsosa commented Dec 10, 2024

PR Description

PR Type

PR Checklist

nunojsa left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kister-jimenez left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mrcsosa commented Jan 13, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mrcsosa commented Jan 13, 2025 •

edited

Loading