Possible regression 2024.12.0 in parsing "aliases"

Possible regression 2024.12.0 in parsing "aliases"

[Alexander Shiyan]

Hello.

After updating barebox to version 2024.12.0, an error message appeared
when loading
the RK3568 board. Accordingly, the I2C1 interface does not work.
In the previous version (2024.10.0), everything worked as it should. I did not
understand what the problem is, but I suspect that aliases are now
parsed incorrectly.
The system has an alias i2c1 (this is the basic SOC i2c1 interface)
and an alias i2c10 for the GPIO expander. Perhaps the problem is somewhere here?

ERROR: rk3x-i2c fe5a0000.i2c@fe5a0000.of: probe failed: Device or resource busy

Thanks!

Re: Possible regression 2024.12.0 in parsing "aliases"

[Sascha Hauer]

Hi Alexander,

On Wed, Dec 11, 2024 at 09:14:32AM +0300, Alexander Shiyan wrote:
> Hello.
> 
> After updating barebox to version 2024.12.0, an error message appeared
> when loading
> the RK3568 board. Accordingly, the I2C1 interface does not work.
> In the previous version (2024.10.0), everything worked as it should. I did not
> understand what the problem is, but I suspect that aliases are now
> parsed incorrectly.
> The system has an alias i2c1 (this is the basic SOC i2c1 interface)
> and an alias i2c10 for the GPIO expander. Perhaps the problem is somewhere here?
> 
> ERROR: rk3x-i2c fe5a0000.i2c@fe5a0000.of: probe failed: Device or resource busy

The culprit is likely somewhere in these commits:

79357f8b96 i2c: start dynamic I2C bus numbers at 32
b474672545 i2c: get adapter.nr from device tree
5b167ad520 i2c: set adapter.nr explicitly to -1

We now use of_alias_get_id() to get the i2c adapter nr. Which adapter
number does fe5a0000.i2c@fe5a0000.of get and which i2c bus device has
already occupied that number?

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Possible regression 2024.12.0 in parsing "aliases"

[Alexander Shiyan]

Hello.

There seems to be a bug in getting the ID in i2c_add_numbered_adapter()
It uses dev.parent instead of dev, for example:
of_alias_get_id(adapter->dev.of_node, "i2c");

And with this everything works as expected.

чт, 12 дек. 2024 г. в 12:03, Sascha Hauer <s.hauer@pengutronix.de>:
>
> Hi Alexander,
>
> On Wed, Dec 11, 2024 at 09:14:32AM +0300, Alexander Shiyan wrote:
> > Hello.
> >
> > After updating barebox to version 2024.12.0, an error message appeared
> > when loading
> > the RK3568 board. Accordingly, the I2C1 interface does not work.
> > In the previous version (2024.10.0), everything worked as it should. I did not
> > understand what the problem is, but I suspect that aliases are now
> > parsed incorrectly.
> > The system has an alias i2c1 (this is the basic SOC i2c1 interface)
> > and an alias i2c10 for the GPIO expander. Perhaps the problem is somewhere here?
> >
> > ERROR: rk3x-i2c fe5a0000.i2c@fe5a0000.of: probe failed: Device or resource busy
>
> The culprit is likely somewhere in these commits:
>
> 79357f8b96 i2c: start dynamic I2C bus numbers at 32
> b474672545 i2c: get adapter.nr from device tree
> 5b167ad520 i2c: set adapter.nr explicitly to -1
>
> We now use of_alias_get_id() to get the i2c adapter nr. Which adapter
> number does fe5a0000.i2c@fe5a0000.of get and which i2c bus device has
> already occupied that number?
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Possible regression 2024.12.0 in parsing "aliases"

[Sascha Hauer]

On Thu, Dec 12, 2024 at 12:30:18PM +0300, Alexander Shiyan wrote:
> Hello.
> 
> There seems to be a bug in getting the ID in i2c_add_numbered_adapter()
> It uses dev.parent instead of dev, for example:
> of_alias_get_id(adapter->dev.of_node, "i2c");
> 
> And with this everything works as expected.

I don't understand this. In i2c-rockchip.c we have:

        i2c->adapter.dev.parent = dev;
        i2c->adapter.dev.of_node = dev->of_node;
	i2c_add_numbered_adapter(&i2c->adapter);

With that it shouldn't make a difference whether we do this:

adapter->nr = of_alias_get_id(adapter->dev.parent->of_node, "i2c");

or that:

adapter->nr = of_alias_get_id(adapter->dev->of_node, "i2c");

Should be the same device node both times.

Sascha


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Possible regression 2024.12.0 in parsing "aliases"

[Alexander Shiyan]

Hello.

Yes, there was my bug in incorrectly merging commits for the i2c subsystem.
This bug went away, but another one appeared when adding mux-adapter:

ERROR: i2c4: failed to add mux-adapter (error=-16)
ERROR: pca954x pca95460: failed to register multiplexed adapter0

чт, 12 дек. 2024 г. в 12:03, Sascha Hauer <s.hauer@pengutronix.de>:
>
> Hi Alexander,
>
> On Wed, Dec 11, 2024 at 09:14:32AM +0300, Alexander Shiyan wrote:
> > Hello.
> >
> > After updating barebox to version 2024.12.0, an error message appeared
> > when loading
> > the RK3568 board. Accordingly, the I2C1 interface does not work.
> > In the previous version (2024.10.0), everything worked as it should. I did not
> > understand what the problem is, but I suspect that aliases are now
> > parsed incorrectly.
> > The system has an alias i2c1 (this is the basic SOC i2c1 interface)
> > and an alias i2c10 for the GPIO expander. Perhaps the problem is somewhere here?
> >
> > ERROR: rk3x-i2c fe5a0000.i2c@fe5a0000.of: probe failed: Device or resource busy
>
> The culprit is likely somewhere in these commits:
>
> 79357f8b96 i2c: start dynamic I2C bus numbers at 32
> b474672545 i2c: get adapter.nr from device tree
> 5b167ad520 i2c: set adapter.nr explicitly to -1
>
> We now use of_alias_get_id() to get the i2c adapter nr. Which adapter
> number does fe5a0000.i2c@fe5a0000.of get and which i2c bus device has
> already occupied that number?
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Possible regression 2024.12.0 in parsing "aliases"

[Alexander Shiyan]

Changes to:
if (adapter->nr < 0 && adapter->dev.of_node)
adapter->nr = of_alias_get_id(adapter->dev.of_node, "i2c");

fix adding mux-adapter. Is this correct?

чт, 12 дек. 2024 г. в 14:31, Sascha Hauer <s.hauer@pengutronix.de>:
>
> On Thu, Dec 12, 2024 at 12:30:18PM +0300, Alexander Shiyan wrote:
> > Hello.
> >
> > There seems to be a bug in getting the ID in i2c_add_numbered_adapter()
> > It uses dev.parent instead of dev, for example:
> > of_alias_get_id(adapter->dev.of_node, "i2c");
> >
> > And with this everything works as expected.
>
> I don't understand this. In i2c-rockchip.c we have:
>
>         i2c->adapter.dev.parent = dev;
>         i2c->adapter.dev.of_node = dev->of_node;
>         i2c_add_numbered_adapter(&i2c->adapter);
>
> With that it shouldn't make a difference whether we do this:
>
> adapter->nr = of_alias_get_id(adapter->dev.parent->of_node, "i2c");
>
> or that:
>
> adapter->nr = of_alias_get_id(adapter->dev->of_node, "i2c");
>
> Should be the same device node both times.
>
> Sascha
>
>
> --
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |