1. Patchew
  2. linux
  3. [PATCH v2 0/3] i2c: spacemit: add reset support
  4. View patch

[PATCH v2 2/3] i2c: k1: add reset support

Encrow Thorne posted 3 patches 1 month, 3 weeks ago
There is a newer version of this series
[PATCH v2 2/3] i2c: k1: add reset support
Posted by Encrow Thorne 1 month, 3 weeks ago 
The K1 I2C controller provides a reset line that needs to be deasserted
before the controller can be accessed.

Add reset support to the driver to ensure the controller starts in the
required state.

Signed-off-by: Encrow Thorne <jyc0019@gmail.com>
---
 drivers/i2c/busses/i2c-k1.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/i2c/busses/i2c-k1.c b/drivers/i2c/busses/i2c-k1.c
index d42c03ef5db5..23661c7ddb67 100644
--- a/drivers/i2c/busses/i2c-k1.c
+++ b/drivers/i2c/busses/i2c-k1.c
@@ -10,6 +10,7 @@
  #include <linux/module.h>
  #include <linux/of_address.h>
  #include <linux/platform_device.h>
+ #include <linux/reset.h>
 
 /* spacemit i2c registers */
 #define SPACEMIT_ICR		 0x0		/* Control register */
@@ -534,6 +535,7 @@ static int spacemit_i2c_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct device_node *of_node = pdev->dev.of_node;
 	struct spacemit_i2c_dev *i2c;
+	struct reset_control *rst;
 	int ret;
 
 	i2c = devm_kzalloc(dev, sizeof(*i2c), GFP_KERNEL);
@@ -578,6 +580,11 @@ static int spacemit_i2c_probe(struct platform_device *pdev)
 	if (IS_ERR(clk))
 		return dev_err_probe(dev, PTR_ERR(clk), "failed to enable bus clock");
 
+	rst = devm_reset_control_get_optional_exclusive_deasserted(dev, NULL);
+	if (IS_ERR(rst))
+		return dev_err_probe(dev, PTR_ERR(rst),
+				     "failed to acquire deasserted reset\n");
+
 	spacemit_i2c_reset(i2c);
 
 	i2c_set_adapdata(&i2c->adapt, i2c);

-- 
2.25.1
Re: [PATCH v2 2/3] i2c: k1: add reset support
Posted by Troy Mitchell 1 month, 2 weeks ago 
On Fri, Dec 19, 2025 at 03:42:21PM +0800, Encrow Thorne wrote:
> The K1 I2C controller provides a reset line that needs to be deasserted
> before the controller can be accessed.
> 
> Add reset support to the driver to ensure the controller starts in the
> required state.
> 
> Signed-off-by: Encrow Thorne <jyc0019@gmail.com>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Re: [PATCH v2 2/3] i2c: k1: add reset support
Posted by Andi Shyti 1 month, 2 weeks ago 
Hi Encrow,

...

> +	rst = devm_reset_control_get_optional_exclusive_deasserted(dev, NULL);
> +	if (IS_ERR(rst))
> +		return dev_err_probe(dev, PTR_ERR(rst),
> +				     "failed to acquire deasserted reset\n");

If this is optional, why are we returning with error?

Thanks,
Andi
Re: [PATCH v2 2/3] i2c: k1: add reset support
Posted by Guodong Xu 1 month, 2 weeks ago 
Hi, Andi

On Fri, Dec 26, 2025 at 5:01 AM Andi Shyti <andi.shyti@kernel.org> wrote:
>
> Hi Encrow,
>
> ...
>
> > +     rst = devm_reset_control_get_optional_exclusive_deasserted(dev, NULL);
> > +     if (IS_ERR(rst))
> > +             return dev_err_probe(dev, PTR_ERR(rst),
> > +                                  "failed to acquire deasserted reset\n");
>
> If this is optional, why are we returning with error?
>

According to include/linux/reset.h, if the requested reset is not
specified in the device tree, this function returns NULL instead of
an error. Therefore, IS_ERR(rst) will only be true for actual
errors (e.g probe deferral).

BR,
Guodong

> Thanks,
> Andi
Re: [PATCH v2 2/3] i2c: k1: add reset support
Posted by Andi Shyti 1 month, 1 week ago 
Hi Guodong,

On Fri, Dec 26, 2025 at 07:38:22AM +0800, Guodong Xu wrote:
> On Fri, Dec 26, 2025 at 5:01 AM Andi Shyti <andi.shyti@kernel.org> wrote:
> > > +     rst = devm_reset_control_get_optional_exclusive_deasserted(dev, NULL);
> > > +     if (IS_ERR(rst))
> > > +             return dev_err_probe(dev, PTR_ERR(rst),
> > > +                                  "failed to acquire deasserted reset\n");
> >
> > If this is optional, why are we returning with error?
> >
> 
> According to include/linux/reset.h, if the requested reset is not
> specified in the device tree, this function returns NULL instead of
> an error. Therefore, IS_ERR(rst) will only be true for actual
> errors (e.g probe deferral).

And this is quite obvious, but you haven't answered my qestion.

Why do we care of internal failures in reset? If reset fails on
an optional reset control function why should we kill our driver?
Just ignore the error and move forward as we have done until now.

If the kernel is suffering from internal failures (say ENOMEM),
it will fail anyway or, with some luck, recover.

Andi
Re: [PATCH v2 2/3] i2c: k1: add reset support
Posted by Guodong Xu 1 month, 1 week ago 
Hi, Andi

On Sun, Dec 28, 2025 at 3:26 AM Andi Shyti <andi.shyti@kernel.org> wrote:
>
> Hi Guodong,
>
> On Fri, Dec 26, 2025 at 07:38:22AM +0800, Guodong Xu wrote:
> > On Fri, Dec 26, 2025 at 5:01 AM Andi Shyti <andi.shyti@kernel.org> wrote:
> > > > +     rst = devm_reset_control_get_optional_exclusive_deasserted(dev, NULL);
> > > > +     if (IS_ERR(rst))
> > > > +             return dev_err_probe(dev, PTR_ERR(rst),
> > > > +                                  "failed to acquire deasserted reset\n");
> > >
> > > If this is optional, why are we returning with error?
> > >
> >
> > According to include/linux/reset.h, if the requested reset is not
> > specified in the device tree, this function returns NULL instead of
> > an error. Therefore, IS_ERR(rst) will only be true for actual
> > errors (e.g probe deferral).
>
> And this is quite obvious, but you haven't answered my qestion.
>
> Why do we care of internal failures in reset? If reset fails on
> an optional reset control function why should we kill our driver?

Thanks for the clarification. I see your point now.

My reasoning is that if the resets property is explicitly listed in the
Device Tree, the driver must respect it. If the property is present but
we encounter an error (like -EPROBE_DEFER), ignoring that failure could
put the hardware in an undefined or dirty state.

> Just ignore the error and move forward as we have done until now.

I want to double-check what you mean.

I checked other drivers in drivers/i2c/busses (e.g. i2c-riic.c, i2c-mv64xxx.c,
i2c-designware-platdrv.c), and they seem to follow this pattern of returning
errors even for optional resets.

BR,
Guodong

>
> If the kernel is suffering from internal failures (say ENOMEM),
> it will fail anyway or, with some luck, recover.
>
> Andi
Re: [PATCH v2 2/3] i2c: k1: add reset support
Posted by Troy Mitchell 1 month, 1 week ago 
On Sun, Dec 28, 2025 at 08:42:47AM +0800, Guodong Xu wrote:
> Hi, Andi
> 
> On Sun, Dec 28, 2025 at 3:26 AM Andi Shyti <andi.shyti@kernel.org> wrote:
> >
> > Hi Guodong,
> >
> > On Fri, Dec 26, 2025 at 07:38:22AM +0800, Guodong Xu wrote:
> > > On Fri, Dec 26, 2025 at 5:01 AM Andi Shyti <andi.shyti@kernel.org> wrote:
> > > > > +     rst = devm_reset_control_get_optional_exclusive_deasserted(dev, NULL);
> > > > > +     if (IS_ERR(rst))
> > > > > +             return dev_err_probe(dev, PTR_ERR(rst),
> > > > > +                                  "failed to acquire deasserted reset\n");
> > > >
> > > > If this is optional, why are we returning with error?
> > > >
> > >
> > > According to include/linux/reset.h, if the requested reset is not
> > > specified in the device tree, this function returns NULL instead of
> > > an error. Therefore, IS_ERR(rst) will only be true for actual
> > > errors (e.g probe deferral).
> >
> > And this is quite obvious, but you haven't answered my qestion.
> >
> > Why do we care of internal failures in reset? If reset fails on
> > an optional reset control function why should we kill our driver?
> 
> Thanks for the clarification. I see your point now.
> 
> My reasoning is that if the resets property is explicitly listed in the
> Device Tree, the driver must respect it.
It's not required.

>
> If the property is present but
> we encounter an error (like -EPROBE_DEFER), ignoring that failure could
> put the hardware in an undefined or dirty state.
Then why it's optional?

The real reason:
"Optional" here means the reset line is allowed to be absent from the
Device Tree. It does not mean we can ignore the failure when it is
defined in the DT but fails to be acquired.

If devm_reset_control_get_optional_* returns an error (e.g.,
-EPROBE_DEFER), it indicates the hardware description expects a reset
control, but the system is not yet ready to provide it. Ignoring this
error would break the probe deferral mechanism and potentially cause the
driver to access hardware in an invalid state.

                          - Troy
Re: [PATCH v2 2/3] i2c: k1: add reset support
Posted by Troy Mitchell 1 month, 1 week ago 
On Tue, Dec 30, 2025 at 10:11:16PM +0800, Troy Mitchell wrote:
> On Sun, Dec 28, 2025 at 08:42:47AM +0800, Guodong Xu wrote:
> > Hi, Andi
> > 
> > On Sun, Dec 28, 2025 at 3:26 AM Andi Shyti <andi.shyti@kernel.org> wrote:
> > >
> > > Hi Guodong,
> > >
> > > On Fri, Dec 26, 2025 at 07:38:22AM +0800, Guodong Xu wrote:
> > > > On Fri, Dec 26, 2025 at 5:01 AM Andi Shyti <andi.shyti@kernel.org> wrote:
> > > > > > +     rst = devm_reset_control_get_optional_exclusive_deasserted(dev, NULL);
> > > > > > +     if (IS_ERR(rst))
> > > > > > +             return dev_err_probe(dev, PTR_ERR(rst),
> > > > > > +                                  "failed to acquire deasserted reset\n");
> > > > >
> > > > > If this is optional, why are we returning with error?
> > > > >
> > > >
> > > > According to include/linux/reset.h, if the requested reset is not
> > > > specified in the device tree, this function returns NULL instead of
> > > > an error. Therefore, IS_ERR(rst) will only be true for actual
> > > > errors (e.g probe deferral).
> > >
> > > And this is quite obvious, but you haven't answered my qestion.
> > >
> > > Why do we care of internal failures in reset? If reset fails on
> > > an optional reset control function why should we kill our driver?
> > 
> > Thanks for the clarification. I see your point now.
> > 
> > My reasoning is that if the resets property is explicitly listed in the
> > Device Tree, the driver must respect it.
Sorry, I misread your comment. I thought you were referring to the
bindings. In that case, we are on the same page.

                                    - Troy
> It's not required.
> 
> >
> > If the property is present but
> > we encounter an error (like -EPROBE_DEFER), ignoring that failure could
> > put the hardware in an undefined or dirty state.
> Then why it's optional?
> 
> The real reason:
> "Optional" here means the reset line is allowed to be absent from the
> Device Tree. It does not mean we can ignore the failure when it is
> defined in the DT but fails to be acquired.
> 
> If devm_reset_control_get_optional_* returns an error (e.g.,
> -EPROBE_DEFER), it indicates the hardware description expects a reset
> control, but the system is not yet ready to provide it. Ignoring this
> error would break the probe deferral mechanism and potentially cause the
> driver to access hardware in an invalid state.
> 
>                           - Troy

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.