Please pull u-boot-i2c master

[Heiko Schocher]

Hello Tom,

On 18.07.25 17:01, Tom Rini wrote:
> On Thu, Jul 17, 2025 at 08:10:17AM +0200, Heiko Schocher wrote:
> 
>> Hello Tom,
>>
>> The following changes since commit 53bd87651e45b32efa398dd5e433d8b93d781445:
>>
>>    block: sandbox: Add support for SYS_64BIT_LBA (2025-07-11 11:33:25 -0600)
>>
>> are available in the Git repository at:
>>
>>    https://source.denx.de/u-boot/custodians/u-boot-i2c.git i2c-for-2025.10
>>
>> for you to fetch changes up to 5e80c6757378d09950235083533e7a7c3aeae3be:
>>
>>    configs: agilex5_defconfig: Enable i3c configs for agilex5 (2025-07-16 09:33:54 +0200)
>>
>> ----------------------------------------------------------------
>> i2c updates for v2025.10
>>
>> - i2c Kconfig updates from Tom
>>    - add some driver dependencies
>>    - added missing include delay.h in iproc_i2c.c
>>
>> - i2c: muxes: Add PCA9541 i2c arbitrator driver
>>    from Padmarao Begari
>>
>> - pca954x: add pca9545 support
>>    from Frank Wunderlich
>>
>> - cmd: i2c: fix build when CFG_SYS_I2C_NOPROBES defined with DM_I2C
>>    From Holger Brunck
>>
>> - added i3c support to U-Boot and enable it for agilex5
>>    board from Dinesh Maniyam
> 
> Unfortunately the i3c support leads to this in coreboot:
> https://source.denx.de/u-boot/u-boot/-/jobs/1202949/raw
> 
> Which looks like coreboot just gets stuck in a loop? And in turn, that
> lead me to do this locally:
> commit 03e9d5f4c61cba5d8e1db81d759fefd622b3ad49
> Author: Tom Rini <trini at konsulko.com>
> Date:   Thu Jul 17 15:22:08 2025 -0600
> 
>      hack drop generic changes
>      
>      Signed-off-by: Tom Rini <trini at konsulko.com>
> 
> diff --git a/include/dm/device.h b/include/dm/device.h
> index c5cfa18d09d6..678cd83c2716 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -169,7 +169,6 @@ enum {
>    * @dma_offset: Offset between the physical address space (CPU's) and the
>    *		device's bus address space
>    * @iommu: IOMMU device associated with this device
> - * @of_node: Associated device tree node
>    */
>   struct udevice {
>   	const struct driver *driver;
> @@ -202,7 +201,6 @@ struct udevice {
>   #if CONFIG_IS_ENABLED(IOMMU)
>   	struct udevice *iommu;
>   #endif
> -	struct device_node	*of_node;
>   };
>   
>   static inline int dm_udevice_size(void)

Uff.. yep, overseen this change...

> Which leads me (a) being concerned about what our coreboot support is up
> to and (b) why i3c needs this generic change? And I don't just want to
> see CONFIG_IS_ENABLED()'ing it, why do we have to handle the device tree
> that way and is there no standard mechanism we can use?
> 

@dinesh: why do you need this?

It should be possible in the master driver to get the of pointer with


ofnode node = dev_ofnode(dev);

and if you really need it in drivers/i3c/master.c pass it to the
functions you call... ah, no, as you already save the udevice
in i3c_master_controller, you can simply use

dev_ofnode(dev)

in it!

You can simply drop of_node from generic file, and use dev_ofnode(dev)
in your driver/i3c code ... may you save the udevice in private data
or in your i3c_dev_boardinfo struct instead if really needed, so please
rework that part.

@Tom: I will drop i3c support from my pull request and send a new one

And yes, the question a) remains ...

Thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH, Managing Director: Johanna Denk, Tabea Lutz
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de