Hi All,

On Mon, 12 May 2025 at 13:51, Anand Moon via groups.io
<linux.amoon=gmail....@groups.io> wrote:
>
> Hi Quentin,
>
> On Mon, 12 May 2025 at 12:36, Quentin Schulz <quentin.sch...@cherry.de> wrote:
> >
> > Hi Anand,
> >
> > On 5/9/25 7:45 PM, Anand Moon wrote:
> > > Hi Quentin,
> > >
> > > On Fri, 9 May 2025 at 17:21, Quentin Schulz <quentin.sch...@cherry.de> 
> > > wrote:
> > >>
> > >> Hi Neil, Anand,
> > >>
> > >> On 5/9/25 9:57 AM, Neil Armstrong wrote:
> > >>> On 09/05/2025 09:02, Anand Moon wrote:
> > >>>> Add conditional compilation for the usb5744_i2c_init() function based
> > >>>> on the CONFIG_DM_I2C configuration, to avoid compilation failure.
> > >>>>
> > >>>>     CC      net/net-common.o
> > >>>>     AR      net/built-in.o
> > >>>>     LDS     u-boot.lds
> > >>>>     LD      u-boot
> > >>>> aarch64-linux-gnu-ld.bfd: common/usb_onboard_hub.o: in function
> > >>>> `usb5744_i2c_init':
> > >>>> /home/amoon/mainline/u-boot/amlogic/u-boot-maineline/common/
> > >>>> usb_onboard_hub.c:74:(.text.usb5744_i2c_init+0xfc): undefined
> > >>>> reference to `i2c_get_chip'
> > >>>> aarch64-linux-gnu-ld.bfd: /home/amoon/mainline/u-boot/amlogic/u-boot-
> > >>>> maineline/common/usb_onboard_hub.c:89:(.text.usb5744_i2c_init+0x1a0):
> > >>>> undefined reference to `dm_i2c_write'
> > >>>> aarch64-linux-gnu-ld.bfd: /home/amoon/mainline/u-boot/amlogic/u-boot-
> > >>>> maineline/common/usb_onboard_hub.c:96:(.text.usb5744_i2c_init+0x1c8):
> > >>>> undefined reference to `dm_i2c_write'
> > >>>> aarch64-linux-gnu-ld.bfd: /home/amoon/mainline/u-boot/amlogic/u-boot-
> > >>>> maineline/common/usb_onboard_hub.c:104:(.text.usb5744_i2c_init+0x1f0):
> > >>>> undefined reference to `dm_i2c_write'
> > >>>> Segmentation fault (core dumped)
> > >>>> make: *** [Makefile:1824: u-boot] Error 139
> > >>>> make: *** Deleting file 'u-boot'
> > >>>>
> > >>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
> > >>>> ---
> > >>>>    common/usb_onboard_hub.c | 4 ++++
> > >>>>    1 file changed, 4 insertions(+)
> > >>>>
> > >>>> diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
> > >>>> index 1242513c631..92e3f3a92c9 100644
> > >>>> --- a/common/usb_onboard_hub.c
> > >>>> +++ b/common/usb_onboard_hub.c
> > >>>> @@ -30,6 +30,7 @@ struct onboard_hub_data {
> > >>>>        int (*init)(struct udevice *dev);
> > >>>>    };
> > >>>> +#if CONFIG_IS_ENABLED(DM_I2C)
> > >>>>    static int usb5744_i2c_init(struct udevice *dev)
> > >>>>    {
> > >>>>        /*
> > >>>> @@ -109,6 +110,7 @@ static int usb5744_i2c_init(struct udevice *dev)
> > >>>>        return 0;
> > >>>>    }
> > >>>> +#endif
> > >>>>    int usb_onboard_hub_reset(struct udevice *dev)
> > >>>>    {
> > >>>> @@ -222,7 +224,9 @@ static const struct onboard_hub_data usb2514_data 
> > >>>> = {
> > >>>>    };
> > >>>>    static const struct onboard_hub_data usb5744_data = {
> > >>>> +#if CONFIG_IS_ENABLED(DM_I2C)
> > >>>>        .init = usb5744_i2c_init,
> > >>>> +#endif
> > >>>>        .power_on_delay_us = 1000,
> > >>>>        .reset_us = 5,
> > >>>>    };
> > >>>
> > >>> I think you should completely disable usb5744_data in this case
> > >>>
> > >>
> > >> I would recommend to go the same route as the Linux kernel which has a
> > >> special Kconfig option for it, c.f. USB_ONBOARD_DEV_USB5744 which adds
> > >> the necessary dependencies.
> > >>
> > > On Linux kernel, it needs to parse the device node with i2c-bus.
> > >
> >
> > Seems like it does in U-Boot too? c.f. usb5744_i2c_init() with
> > dev_read_phandle_with_args with i2c-bus?
> >
> ok.
> > >> We probably should be careful and figure out which boards are actually
> > >> using the usb5744 and add this symbol to their defconfig so they don't
> > >> regress.
> > >>
> > >  From my initial analysis configs/xilinx_zynqmp_kria_defconfig
> > > which use CONFIG_USB_ONBOARD_HUB
> > > I believe using DM_I2C to guard the code is the best approach.
> > > it should be around .init() callback to guard this to work.
> > >
> >
> > I disagree. The driver clearly supports the USB5744 and the driver is
> > compiled regardless of DM_I2C support which is required (as far as I
> > understood, maybe that's incorrect?) for being able to use USB5744? I
> > don't like hidden dependencies.
> >
> Okay, I will add a new configuration option to guard the code as done
> in the Linux kernel.
> > Also, I believe Neil's point is we shouldn't try to probe the USB5744 if
> > there is no DM_I2C support, simply excluding .init() callback will
> > probably just render this "support" of USB5744 non-functional?
> >
> Let me debug this more, I will update the next version.
> I need to check if this binds correctly to the USB hub reset.

I am trying to get the usb_onboard_hub to bind.
but this driver is not getting probed in the first place,
I am missing some configuration to get this working.

Hit any key to stop autoboot:  0
=> usb start
starting USB...
Register 3000140 NbrPorts 3
Starting the controller
USB XHCI 1.10
Bus usb@ff500000: 4 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
=> dm tree
...
mmc           1  [ + ]   meson_gx_mmc          |   |-- mmc@ffe07000
 blk           1  [   ]   mmc_blk               |   |   |-- m...@ffe07000.blk
 bootdev       2  [   ]   mmc_bootdev           |   |   `-- mmc@ffe07000.bootdev
 simple_bus   11  [ + ]   dwc3-meson-g12a       |   `-- usb@ffe09000
 usb_gadget    0  [   ]   dwc2-udc-otg          |       |-- usb@ff400000
 usb           0  [ + ]   xhci-dwc3             |       `-- usb@ff500000
 usb_hub       0  [ + ]   usb_hub               |           `-- usb_hub
 usb_hub       1  [ + ]   usb_hub               |               |-- usb_hub
 usb_hub       2  [ + ]   usb_hub               |               `-- usb_hub
 usb_mass_s    0  [ + ]   usb_mass_storage      |
`-- usb_mass_storage
 blk           2  [ + ]   usb_storage_blk       |
 |-- usb_mass_storage.lun0
 partition     0  [ + ]   blk_partition         |
 |   `-- usb_mass_storage.lun0:1
 bootdev       3  [   ]   usb_bootdev           |
 `-- usb_mass_storage.lun0.bootdev
 clk           2  [ + ]   fixed_clock           |-- xtal-clk

Thanks
-Anand

Reply via email to