[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2024100406-spyglass-roulette-761d@gregkh>
Date: Fri, 4 Oct 2024 15:37:21 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Radhey Shyam Pandey <radhey.shyam.pandey@....com>
Cc: mka@...omium.org, paul.walmsley@...ive.com, palmer@...belt.com,
aou@...s.berkeley.edu, wentong.wu@...el.com,
sakari.ailus@...ux.intel.com, javier.carrasco@...fvision.net,
matthias@...hlcke.net, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
git@....com
Subject: Re: [PATCH v2] usb: misc: onboard_usb_dev: introduce new config
symbol for usb5744 SMBus support
On Fri, Oct 04, 2024 at 03:36:11PM +0200, Greg KH wrote:
> On Sat, Sep 28, 2024 at 06:56:32PM +0530, Radhey Shyam Pandey wrote:
> > Introduce new kernel config symbol for Microchip usb5744 SMBus programming
> > support. Since usb5744 i2c initialization routine uses i2c SMBus APIs these
> > APIs should only be invoked when kernel has I2C support. This new kernel
> > config describes the dependency on I2C kernel support and fix the below
> > build issues when USB_ONBOARD_DEV=y and CONFIG_I2C=m.
> >
> > riscv64-linux-ld: drivers/usb/misc/onboard_usb_dev.o:
> > undefined reference to `i2c_find_device_by_fwnode'
> > drivers/usb/misc/onboard_usb_dev.c:408:(.text+0xb24): undefined
> > reference to `i2c_smbus_write_block_data'
> > <snip>
> >
> > Parsing of the i2c-bus bus handle is not put under usb5744 kernel config
> > check as the intention is to report an error when DT is configured for
> > usb5744 SMBus support and kernel has USB_ONBOARD_DEV_USB5744 disabled.
> >
> > Fixes: 6782311d04df ("usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus programming support")
> > Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@....com>
> > Suggested-by: Matthias Kaehlcke <matthias@...hlcke.net>
> > Reported-by: kernel test robot <lkp@...el.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202409140539.3Axwv38m-lkp@intel.com/
> > Acked-by: Matthias Kaehlcke <matthias@...hlcke.net>
> > ---
> > Changes for v2:
> > - As suggested by Greg drop default 'y' and instead describe the
> > constraints in the kconfig description.
> > ---
> > drivers/usb/misc/Kconfig | 12 ++++++++++++
> > drivers/usb/misc/onboard_usb_dev.c | 6 ++++--
> > 2 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
> > index 50b86d531701..6497c4e81e95 100644
> > --- a/drivers/usb/misc/Kconfig
> > +++ b/drivers/usb/misc/Kconfig
> > @@ -331,3 +331,15 @@ config USB_ONBOARD_DEV
> > this config will enable the driver and it will automatically
> > match the state of the USB subsystem. If this driver is a
> > module it will be called onboard_usb_dev.
> > +
> > +config USB_ONBOARD_DEV_USB5744
> > + bool "Onboard USB Microchip usb5744 hub with SMBus support"
> > + depends on (USB_ONBOARD_DEV && I2C=y) || (USB_ONBOARD_DEV=m && I2C=m)
> > + help
> > + Say Y here if you want to support onboard USB Microchip usb5744
> > + hub that requires SMBus initialization.
> > +
> > + This options enables usb5744 i2c default initialization sequence
> > + during hub start-up configuration stage. It is must to enable this
> > + option on AMD Kria KR260 Robotics Starter Kit as this hub is
> > + connected to USB-SD converter which mounts the root filesystem.
>
> With this applied I get the following build warning:
>
>
> WARNING: unmet direct dependencies detected for MODVERSIONS
> Depends on [n]: MODULES [=y] && !COMPILE_TEST [=y]
> Selected by [y]:
> - RANDSTRUCT_FULL [=y] && (CC_HAS_RANDSTRUCT [=n] || GCC_PLUGINS [=y]) && MODULES [=y]
>
> WARNING: unmet direct dependencies detected for MODVERSIONS
> Depends on [n]: MODULES [=y] && !COMPILE_TEST [=y]
> Selected by [y]:
> - RANDSTRUCT_FULL [=y] && (CC_HAS_RANDSTRUCT [=n] || GCC_PLUGINS [=y]) && MODULES [=y]
>
> WARNING: unmet direct dependencies detected for MODVERSIONS
> Depends on [n]: MODULES [=y] && !COMPILE_TEST [=y]
> Selected by [y]:
> - RANDSTRUCT_FULL [=y] && (CC_HAS_RANDSTRUCT [=n] || GCC_PLUGINS [=y]) && MODULES [=y]
>
>
> Which is odd.
>
> It's one extra "unmet direct ..." message than normal for now, so
> something in this commit is not working properly.
>
> Can you fix this up and send a new version?
Nevermind, it's not this patch's fault, I'll go take this now, sorry for
the noise...
greg k-h
Powered by blists - more mailing lists