Add LTC3220 driver #3005

edelweiseescala · 2025-10-28T08:30:53Z

PR Description

Add LTC3220 driver and documentation.
Datasheet: LTC3220
Tested on RPI4 using the following eval boards: DC1265A-A, DC1265A-B

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 compiled my changes, including the documentation
I have tested the changes on the relevant hardware
I have updated the documentation outside this repo accordingly
I have provided links for the relevant upstream lore

artursartamonovsadi · 2025-10-31T12:03:13Z

drivers/leds/leds-ltc3220.c

+}
+
+static ssize_t ltc3220_shutdown_store(struct device *dev,
+					struct device_attribute *devAttr,


devAttr is in camel case can you fix to match Linux Kernel style

artursartamonovsadi · 2025-10-31T12:03:46Z

drivers/leds/leds-ltc3220.c

+}
+
+static ssize_t ltc3220_force_cpo_2x_store(struct device *dev,
+						struct device_attribute *devAttr,


same as above

artursartamonovsadi · 2025-10-31T12:03:58Z

drivers/leds/leds-ltc3220.c

+}
+
+static ssize_t ltc3220_force_cpo_1p5x_store(struct device *dev,
+							struct device_attribute *devAttr,


same as above

artursartamonovsadi · 2025-10-31T12:04:10Z

drivers/leds/leds-ltc3220.c

+}
+
+static ssize_t ltc3220_quick_write_store(struct device *dev,
+					struct device_attribute *devAttr,


artursartamonovsadi · 2025-10-31T12:05:09Z

drivers/leds/leds-ltc3220.c

+}
+
+static int ltc3220_set_command(struct ltc3220_platform_data *platform_data,
+	bool is_shutdown, bool force2x, bool force1p5, bool quickWrite)


quickWrite is in camel case can you fix it according to Linux Kernel styling guide?

UtsavAgarwalADI · 2025-10-31T13:09:59Z

Could you format your commits so that there are spaces between labels? eg:

arm64:defconfig:xyz
arm64: defconfig: xyz

Additionally, could you add some more context regarding the commits?

You can see more examples here: https://lore.kernel.org/linux-arm-kernel/

UtsavAgarwalADI · 2025-10-31T13:11:39Z

drivers/leds/leds-ltc3220.c

+#define LTC3220_ULED18      0x12
+#define LTC3220_GRAD_BLINK  0x13
+
+static int ltc3220_write(struct i2c_client *client, u8 reg, u8 val)


Do we need another function call for this? I dont see any extra handling being done

Agreed. I don't see any real benefit in these wrappers. I would also see if regmap is a possibility

vasbimpikasadi

That shows great effort! It's a bit sparse on comments and I've noted some changes which I think have to be fixed before this gets approved.

vasbimpikasadi · 2025-10-31T12:59:04Z

drivers/leds/leds-ltc3220.c

+{
+	int ret;
+	struct i2c_client *client = uled->client;
+	u8 reg_val = (mode << 6) | current_level;


This could overflow. Masking can prevent that. e.g. u8 reg_val = ((mode & 0x03) << 6) | (current_level & 0x3F);

Yeah, as I said in another comment I would just consider FIELD_PREP()

vasbimpikasadi · 2025-10-31T13:00:51Z

include/linux/platform_data/leds-ltc3220.h

+
+#define NUM_LEDS 18
+
+#define MAX_CURRENT 64


Not sure about this one, but isn't it a 6-bit field? If so, it should be 0-63 so, #define MAX_CURRENT 63

vasbimpikasadi · 2025-10-31T13:07:20Z

drivers/leds/leds-ltc3220.c

+	struct ltc3220_uled_cfg *uled_cfg;
+
+	current_level = (int)brightness;
+	if (current_level > MAX_CURRENT)


You know the code way better than I do, but shouldn't that be an error? If it's fine to continue with current capped at max, at least a dev_info should be printed?

Not sure either, some subsystems (like hwmon) don't consider these stuff as hard errors and just tell you to do clamp()

I will be removing this, upon checking led subsystem already caps the value to the max if the user inputs a value exceeding the max. Thank you!

vasbimpikasadi · 2025-10-31T13:09:40Z

drivers/leds/leds-ltc3220.c

+	platform_data->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_HIGH);
+	if (IS_ERR(platform_data->reset_gpio)) {
+		dev_err(&client->dev, "Fail to set reset GPIO\n");
+		return -ENOMEM;


since IS_ERR() has returned an error, you should pass it on instead of hardcoding ENOMEM, ie PTR_ERR(platform_data->reset_gpio);

In fact, return dev_err_probe(dev, PTR_ERR(platform_data->reset_gpio), ...);

CalebEthridgeADI · 2025-10-31T14:22:08Z

include/linux/platform_data/leds-ltc3220.h

+#ifndef __LINUX_I2C_LTC3220_H
+#define __LINUX_I2C_LTC3220_H
+
+#define NUM_LEDS 18


Can you add a LTC3220 prefix before these defines like you do in leds-ltc3220.c i.e LTC3220_NUM_LEDS ?

nunojsa

First round from me. This one will need some iterations before going upstream. I'm also not that familiar with the LED subsystem so I might give it a look at some point to be more helpful.

nunojsa · 2025-10-31T14:24:02Z

Documentation/devicetree/bindings/leds/leds-ltc3220.yaml

+  compatible:
+    enum:
+      - lltc,ltc3220
+      - lltc,ltc3220-1


adi, now 😉

nunojsa · 2025-10-31T14:24:27Z

Documentation/devicetree/bindings/leds/leds-ltc3220.yaml

+    description: |
+      I2C slave address
+      0x1c for ltc3220
+      0x1d for ltc3220-1


Drop the description here. It is already obvious

nunojsa · 2025-10-31T14:24:41Z

Documentation/devicetree/bindings/leds/leds-ltc3220.yaml

+maintainers:
+  - Edelweise Escala <[email protected]>
+
+description: |


No need for | formatting

nunojsa · 2025-10-31T14:25:01Z

Documentation/devicetree/bindings/leds/leds-ltc3220.yaml

+  reset-gpios:
+    maxItems: 1
+    description: |
+      GPIO attached to the chip's reset pin


Ditto about the description

nunojsa · 2025-10-31T14:25:16Z

Documentation/devicetree/bindings/leds/leds-ltc3220.yaml

+    $ref: common.yaml#
+    properties:
+      reg:
+        description: |


nunojsa · 2025-10-31T15:24:57Z

drivers/leds/leds-ltc3220.c

+	platform_data->led_cdev.groups = ltc3220_config_groups;
+	ret = devm_led_classdev_register_ext(&client->dev,
+							&platform_data->led_cdev,
+							&init_data_config);


What is the above about? Is it like device level settings instead of individual LED settings?

It is like device level settings

nunojsa · 2025-10-31T15:27:04Z

drivers/leds/leds-ltc3220.c

+		return -ENOMEM;
+	}
+
+	ltc3220_reset(platform_data);


This is typically done in the beginning. In fact, this is bogus... Note that you're doing this after calling devm_led_classdev_register_ext() which will expose the userspace interfaces. So, effectively you can now race against userspace in a way that userspace does some configuration and then a reset happens.

nunojsa · 2025-10-31T15:27:29Z

drivers/leds/leds-ltc3220.c

+MODULE_AUTHOR("Edelweise Escala <[email protected]>");
+MODULE_DESCRIPTION("LED driver for LTC3220 controllers");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:leds-ltc3220");


Typically not used anymore

nunojsa · 2025-10-31T15:27:42Z

include/linux/platform_data/leds-ltc3220.h

@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */


Use only GPL2

nunojsa · 2025-10-31T15:29:33Z

include/linux/platform_data/leds-ltc3220.h

+	struct gpio_desc *reset_gpio;
+};
+
+#endif /* __LINUX_I2C_LTC3220_H */


Please drop the header file and move it to the source code. This is not supposed to be shared with any other source file AFAICT. Also, drop platform_data from the struct. Just name it struct ltc3220 or struct ltc3220_state. Platform data reference a very old way of doing things that is no longer used

edelweiseescala · 2025-11-04T10:48:20Z

V2 Changelog:

dt-bindings: leds: ltc3220: Document LTC3220 18 channel LED Driver
-used adi
-dropped unnecessary descriptions
-dropped | formatting
-fixed led pattern

leds: ltc3220: add driver
-Fix naming which does not follow Linux convention, also fixed naming for defines with onw LTC3220 prefix. Follow kernel style
-Remove unnecessary headers, and fixed header arrangement
-Remove unnecessary functions (ltc3220_write)
-Used FIELD_PREP()
-Use firmware agnostic properties
-Use only GPL2
-Led brightness now uses ltc3220_set_led_data
Instead of 0-63 current level it is now 0-255 where in
0-63 - normal LED mode
64-127 - blink mode
127-191 - gradation mode
191-255 - GPO
this removes the need for another custom ABI for individual led mode.

Added leds: ltc3220: Documentation for Custom ABI
-documentation for the added custom ABI

Documentation/devicetree/bindings/leds/leds-ltc3220.yaml

Documentation/ABI/testing/sysfs-class-led-driver-ltc3220

Documentation/devicetree/bindings/leds/leds-ltc3220.yaml

drivers/leds/leds-ltc3220.c

edelweiseescala · 2025-11-11T03:39:15Z

V3 Changelog:

fixed wrong files on commit

dt-bindings: leds: ltc3220: Document LTC3220 18 channel LED Driver
-fixed example format

leds: ltc3220: add driver
-used fsleep for reset
-fixed log message

leds: ltc3220: Documentation for Custom ABI
-add newline at EOF

machschmitt

Hi @edelweiseescala,

A few comments from my side.
Besides the code changes, I'd suggest to also update your SoB tag with better wording of your name.

machschmitt · 2025-11-11T17:05:21Z

Documentation/devicetree/bindings/leds/leds-ltc3220.yaml

+required:
+  - compatible
+  - reg
+  - reset-gpios


It is not common for chips to require a reset. Does the device really fail to work or not function without a hardware reset? It is often nice to do a reset before start managing a device. Though, if it can be operated without a reset, I'd drop the reset-gpios requirement.

machschmitt · 2025-11-11T17:18:19Z

Documentation/devicetree/bindings/leds/leds-ltc3220.yaml

+             reg = <0x1c>;
+             #address-cells = <1>;
+             #size-cells = <0>;
+             reset-gpios = <&gpio 17 0>;


the reset-gpio property can become clearer if the example makes use gpio dt-bindings

#include <dt-bindings/gpio/gpio.h> ... reset-gpios = <&gpio 17 GPIO_ACTIVE_LOW>;

machschmitt · 2025-11-12T12:50:59Z

Documentation/ABI/testing/sysfs-class-led-driver-ltc3220

@@ -0,0 +1,48 @@
+What:		/sys/class/leds/<led>/shutdown
+Date:		November 2025
+Contact:	Edelweise Escala <[email protected]>


Other LED ABI documentation also have a kernel version line. We're currently at 6.18-rc5 so, if this were going to be merged into the next release, I think we would add

KernelVersion: 6.18

Though, as the merge window for 6.18 has gone, you might probably use the next kernel version.

machschmitt · 2025-11-12T12:55:11Z

Documentation/ABI/testing/sysfs-class-led-driver-ltc3220

+
+What:		/sys/class/leds/<led>/force_cpo_mode
+Date:		November 2025
+Contact:	Edelweise Escala <[email protected]>


same here and in the other doc entries.

machschmitt · 2025-11-12T13:39:50Z

drivers/leds/leds-ltc3220.c

+#define LTC3220_ULED18				0x12
+#define LTC3220_GRAD_BLINK			0x13
+
+#define LTC3220_BIT0				BIT(0)


As a reviewer, I don't think this define helped much in understanding the code.
I'd either drop it and use BIT(0) in place, or separate and give more meaningful names. e.g.

#define LTC3220_GRAD_COUNT_UP BIT(0) #define LTC3220_COMMAND_QUICK_WRITE BIT(0)

machschmitt · 2025-11-12T14:33:10Z

drivers/leds/leds-ltc3220.c

+	struct led_classdev led_cdev;
+	struct device *dev;


are these led_cdev and *dev fields not used?

machschmitt · 2025-11-12T14:50:05Z

drivers/leds/leds-ltc3220.c

+	if (ret)
+		return ret;
+
+	device_for_each_child_node(&client->dev, child) {


Use device_for_each_child_node_scoped(), then no need for fwnode_handle_put().

machschmitt · 2025-11-12T14:56:45Z

drivers/leds/leds-ltc3220.c

+		if (ret != 0 || !source || source > LTC3220_NUM_LEDS) {
+			dev_err(&client->dev, "Couldn't read LED address: %d\n",
+				ret);
+			fwnode_handle_put(child);
+			return -ENOMEM;
+		}


This means that all leds are required? Are all LEDs required? If not, I'd dev_war() and continue; instead of returning error.

machschmitt · 2025-11-12T15:05:52Z

drivers/leds/leds-ltc3220.c

+			return -ENOMEM;
+		}
+
+		i = source - 1;


This looks a bit odd. I'd just use source to index uled_cfg and expect led dt node reg to be limited between 0 and 17 but see it's from 1 to 18. If the reg property will be kept limited from 1 to 18, I'd add a comment here reminding that the led node reg/index/address goes from 1 to 18.

machschmitt · 2025-11-12T15:10:02Z

drivers/leds/leds-ltc3220.c

+
+struct ltc3220_state {
+	u8 blink_cfg;
+	struct i2c_client	*client;


In most places (if not all) where we do ltc3220_state->client, we could instead do ltc3220_state->uled_cfg[index], with an index of some led that is known to have been parsed. That way we could drop the i2c client field from ltc3220_state.

Alternatively, I wonder if we could drop i2c client field from struct ltc3220_uled_cfg. Both struct ltc3220_state and struct ltc3220_uled_cfg have a client field and they point to the same device IIUC. struct led_classdev has a dev field so I'm thinking we could do

struct ltc3220_state *ltc3220_state = dev_get_drvdata(led_cdev->dev);

in ltc3220_set_led_data(), then get the i2c device from the state struct.

edelweiseescala · 2025-11-13T08:53:21Z

V4 Changelog:

fixed name on SoB

dt-bindings: leds: ltc3220: Document LTC3220 18 channel LED Driver
-removed reset on rquired
-made reset-gpio property clearer

leds: ltc3220: add driver
-use more meaningful bit name
-removed unused fields
-use device_for_each_child_node_scoped
-add some comments
-dropped i2c client on leds, used i2c leint on ltc3220_state struct

leds: ltc3220: Documentation for Custom ABI
-add kernel version

nunojsa · 2025-11-13T18:31:59Z

Documentation/ABI/testing/sysfs-class-led-driver-ltc3220

+		0 - Enables mode logic to control mode changes based on dropout signal
+		1 - Forces charge pump into 1.5x mode
+		2 - Forces charge pump into 2x mode
+		3 - Forces charge pump into 1x mode


Hmm this one seems something HW specific? Is this something that should change at runtime? If I'm right, consider a devicetree attr

nunojsa · 2025-11-13T18:33:13Z

Documentation/ABI/testing/sysfs-class-led-driver-ltc3220

+Contact:	Edelweise Escala <[email protected]>
+Description:	LTC3220 shutdown command. If you write 1 it
+		shuts down part while preserving data in registers.
+		If you write 0 device is in normal operation.


This seems like something you should implement under PM (Power management). Either runtime PM or normal suspend. Pick one :)

nunojsa · 2025-11-13T18:38:57Z

Documentation/ABI/testing/sysfs-class-led-driver-ltc3220

+		which allows parallel write on all 18 LED registers, when data is being written on
+		REG1. If you write 1 quick_write is enabled, 0 to disable.
+
+What:		/sys/class/leds/<led>/gradation_speed


I guess this one could be better named gradation_period_ms. Then you would actually pass the period in milliseconds which is a better API for the user. This is possible because we have three distinct periods which match 3 distinct ramp times.

nunojsa · 2025-11-13T18:47:31Z

Documentation/ABI/testing/sysfs-class-led-driver-ltc3220

+		2 - Ramp time of 0.48s and Period of 0.625s
+		3 - Ramp time of 0.96s and Period of 1.25s
+
+What:		/sys/class/leds/<led>/gradation_is_increasing


For this one I would suggest gradation_mode and accept the strings "ramp_up" and "ramp_down". From the IIO world you could also add an additional gradation_mode_available which would be on RO and you would give the user the available possibilities. An example for debugfs:

https://elixir.bootlin.com/linux/v6.18-rc5/source/drivers/iio/adc/ad9467.c#L998

Here you need something different likely

nunojsa · 2025-11-13T18:53:38Z

Documentation/ABI/testing/sysfs-class-led-driver-ltc3220

+		(0..3) where:
+		0 - On Time of 0.625s and Period of 1.25s
+		1 - On Time of 0.156s and Period of 1.25s
+		2 - On Time of 0.625s and Period of 2.5s


Can we somehow implement this with?

https://elixir.bootlin.com/linux/v6.18-rc5/source/include/linux/leds.h#L154

Make sure to look at other drivers and the subsystem to see what can be used.

nunojsa · 2025-11-13T19:00:46Z

drivers/leds/leds-ltc3220.c

+	ret = ltc3220_set_blink_and_gradation(ltc3220_state,
+										state,
+										ltc3220_state->grad_cfg.gradation_speed,
+										ltc3220_state->grad_cfg.is_increasing);


The above looks very bad

nunojsa · 2025-11-13T19:01:33Z

drivers/leds/leds-ltc3220.c

+	&dev_attr_gradation_is_increasing.attr,
+	&dev_attr_blink_cfg.attr,
+	NULL
+};


Be prepared to justify these attributes... I'm still not sure about it

nunojsa · 2025-11-13T19:01:51Z

drivers/leds/leds-ltc3220.c

+		ltc3220_gradation_is_increasing_store);
+
+static ssize_t ltc3220_blink_cfg_show(struct device *dev,
+								 struct device_attribute *attr, char *buf)


Take care about the above

nunojsa · 2025-11-13T19:01:59Z

drivers/leds/leds-ltc3220.c

+
+	ret = ltc3220_set_blink_and_gradation(ltc3220_state,
+										ltc3220_state->blink_cfg,
+										ltc3220_state->grad_cfg.gradation_speed,


nunojsa · 2025-11-13T19:02:54Z

drivers/leds/leds-ltc3220.c

+	ret = ltc3220_set_blink_and_gradation(ltc3220_state,
+										ltc3220_state->blink_cfg,
+										state,
+										ltc3220_state->grad_cfg.is_increasing);


Please make sure to fix things like the above (unless my github is rendering this in a very odd way)

Add dt-binding for ltc3220. LTC3220 18 Channel LED driver Signed-off-by: Edelweise Escala <[email protected]>

Add documentation for different Custom ABI added for LTC3220. Signed-off-by: Edelweise Escala <[email protected]>

Add driver for ltc3220. LTC3220 18 Channel LED Driver Signed-off-by: Edelweise Escala <[email protected]>

Add entry for LTC3220 driver Signed-off-by: Edelweise Escala <[email protected]>

edelweiseescala · 2025-11-14T10:03:42Z

V5 Changelog:

dt-bindings: leds: ltc3220: Document LTC3220 18 channel LED Driver
-added quick write and force charge pump on device tree

leds: ltc3220: add driver
-styling fixes
-used led blink
-add missing headers
-dropped reset_gpio on struct and added it on reset function instead
-added missing error handling on reset
-modified gradation increasing to accept string ramp up or ramp down
-change gradation_speed to gradation_period_ms which takes period in ms as input

leds: ltc3220: Documentation for Custom ABI
-removed quick write and force charge pump
-renamed gradation speed
-added gradation_mode_available

vasbimpikasadi

Getting really better, loads of great feedback from everyone. This is shaping up quite nicely.

vasbimpikasadi · 2025-11-14T13:58:48Z

drivers/leds/leds-ltc3220.c

+
+	ltc3220_state = devm_kzalloc(&client->dev, sizeof(*ltc3220_state), GFP_KERNEL);
+	if (!ltc3220_state)
+		return -ENODEV;


Memory allocation failure should return -ENOMEM, not -ENODEV

vasbimpikasadi · 2025-11-14T13:59:48Z

drivers/leds/leds-ltc3220.c

+							   &init_data);
+		if (ret) {
+			dev_err(&client->dev, "Fail LED class register\n");
+			return -ENOMEM;


I think ret should be propagated here to aid root causing issues should things go wrong?

vasbimpikasadi · 2025-11-14T14:02:53Z

drivers/leds/leds-ltc3220.c

+	NULL
+};
+
+static struct attribute_group device_cfg_group = {


Probably should be const? It's never modified during runtime

edelweiseescala requested review from CiprianRegus, amiclaus, btogorean, buha, chegbeli, danmois, dbogdan, machschmitt, mhennerich, nunojsa and rbolboac as code owners October 28, 2025 08:30

edelweiseescala marked this pull request as draft October 28, 2025 08:38

edelweiseescala force-pushed the main branch 4 times, most recently from 6a5debb to d57b64f Compare October 29, 2025 00:33

edelweiseescala marked this pull request as ready for review October 29, 2025 02:05

artursartamonovsadi reviewed Oct 31, 2025

View reviewed changes

UtsavAgarwalADI reviewed Oct 31, 2025

View reviewed changes

vasbimpikasadi requested changes Oct 31, 2025

View reviewed changes

CalebEthridgeADI reviewed Oct 31, 2025

View reviewed changes

nunojsa reviewed Oct 31, 2025

View reviewed changes

edelweiseescala marked this pull request as draft November 4, 2025 06:27

edelweiseescala force-pushed the main branch 2 times, most recently from d01ee06 to b251647 Compare November 4, 2025 08:46

edelweiseescala marked this pull request as ready for review November 4, 2025 10:48

edelweiseescala force-pushed the main branch from b251647 to 03831fa Compare November 4, 2025 23:41

jemfgeronimo reviewed Nov 10, 2025

View reviewed changes

edelweiseescala force-pushed the main branch from 03831fa to 139802f Compare November 11, 2025 03:32

machschmitt reviewed Nov 12, 2025

View reviewed changes

edelweiseescala force-pushed the main branch 3 times, most recently from 80d038e to 03f6cf2 Compare November 13, 2025 08:20

nunojsa reviewed Nov 13, 2025

View reviewed changes

edelweiseescala marked this pull request as draft November 14, 2025 08:26

edelweiseescala added 4 commits November 14, 2025 17:39

dt-bindings: leds: ltc3220: Document LTC3220 18 channel LED Driver

1ec620d

Add dt-binding for ltc3220. LTC3220 18 Channel LED driver Signed-off-by: Edelweise Escala <[email protected]>

leds: ltc3220: Documentation for Custom ABI

c9c8754

Add documentation for different Custom ABI added for LTC3220. Signed-off-by: Edelweise Escala <[email protected]>

leds: ltc3220: add driver

3be53f8

Add driver for ltc3220. LTC3220 18 Channel LED Driver Signed-off-by: Edelweise Escala <[email protected]>

leds: Kconfig.adi: imply ltc3220

e16e6b1

Add entry for LTC3220 driver Signed-off-by: Edelweise Escala <[email protected]>

edelweiseescala force-pushed the main branch from 03f6cf2 to e16e6b1 Compare November 14, 2025 09:40

edelweiseescala marked this pull request as ready for review November 14, 2025 10:03

vasbimpikasadi requested changes Nov 14, 2025

View reviewed changes

		@@ -0,0 +1,64 @@
		/* SPDX-License-Identifier: GPL-2.0-or-later */

Add LTC3220 driver #3005

Are you sure you want to change the base?

Add LTC3220 driver #3005

Uh oh!

Conversation

edelweiseescala commented Oct 28, 2025

PR Description

PR Type

PR Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

UtsavAgarwalADI commented Oct 31, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vasbimpikasadi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

CalebEthridgeADI Oct 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nunojsa left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

edelweiseescala commented Nov 4, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

CalebEthridgeADI Oct 31, 2025 •

edited

Loading