public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Pandey, Radhey Shyam" <radhey.shyam.pandey@amd.com>
Cc: "mka@chromium.org" <mka@chromium.org>,
	"sakari.ailus@linux.intel.com" <sakari.ailus@linux.intel.com>,
	"wentong.wu@intel.com" <wentong.wu@intel.com>,
	"javier.carrasco@wolfvision.net" <javier.carrasco@wolfvision.net>,
	"stefan.eichenberger@toradex.com"
	<stefan.eichenberger@toradex.com>,
	"francesco.dolcini@toradex.com" <francesco.dolcini@toradex.com>,
	"jbrunet@baylibre.com" <jbrunet@baylibre.com>,
	"macpaul.lin@mediatek.com" <macpaul.lin@mediatek.com>,
	"frieder.schrempf@kontron.de" <frieder.schrempf@kontron.de>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"git (AMD-Xilinx)" <git@amd.com>
Subject: Re: [PATCH v4 2/2] usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus programming support
Date: Tue, 3 Sep 2024 09:58:49 +0200	[thread overview]
Message-ID: <2024090324-phonics-angler-64c2@gregkh> (raw)
In-Reply-To: <MN0PR12MB5953AD101E185462A6CC61BBB7932@MN0PR12MB5953.namprd12.prod.outlook.com>

On Tue, Sep 03, 2024 at 07:19:09AM +0000, Pandey, Radhey Shyam wrote:
> > -----Original Message-----
> > From: Greg KH <gregkh@linuxfoundation.org>
> > Sent: Tuesday, September 3, 2024 12:10 PM
> > To: Pandey, Radhey Shyam <radhey.shyam.pandey@amd.com>
> > Cc: mka@chromium.org; sakari.ailus@linux.intel.com;
> > wentong.wu@intel.com; javier.carrasco@wolfvision.net;
> > stefan.eichenberger@toradex.com; francesco.dolcini@toradex.com;
> > jbrunet@baylibre.com; macpaul.lin@mediatek.com;
> > frieder.schrempf@kontron.de; linux-usb@vger.kernel.org; linux-
> > kernel@vger.kernel.org; git (AMD-Xilinx) <git@amd.com>
> > Subject: Re: [PATCH v4 2/2] usb: misc: onboard_usb_dev: add Microchip
> > usb5744 SMBus programming support
> > 
> > On Sun, Sep 01, 2024 at 05:38:39PM +0530, Radhey Shyam Pandey wrote:
> > > usb5744 supports SMBus Configuration and it may be configured via the
> > > SMBus slave interface during the hub start-up configuration stage.
> > >
> > > To program it driver uses i2c-bus phandle (added in commit '02be19e914b8
> > > dt-bindings: usb: Add support for Microchip usb5744 hub controller') to
> > > get i2c client device and then based on usb5744 compatible check calls
> > > usb5744 i2c default initialization sequence.
> > >
> > > Apart from the USB command attach, prevent the hub from suspend.
> > > when the USB Attach with SMBus (0xAA56) command is issued to the hub,
> > > the hub is getting enumerated and then it puts in a suspend mode.
> > > This causes the hub to NAK any SMBus access made by the SMBus Master
> > > during this period and not able to see the hub's slave address while
> > > running the "i2c probe" command.
> > >
> > > Prevent the MCU from putting the HUB in suspend mode through register
> > > write. The BYPASS_UDC_SUSPEND bit (Bit 3) of the RuntimeFlags2
> > > register at address 0x411D controls this aspect of the hub. The
> > > BYPASS_UDC_SUSPEND bit in register 0x411Dh must be set to ensure that
> > the
> > > MCU is always enabled and ready to respond to SMBus runtime
> > commands.
> > > This register needs to be written before the USB attach command is issued.
> > >
> > > The byte sequence is as follows:
> > > Slave addr: 0x2d           00 00 05 00 01 41 1D 08
> > > Slave addr: 0x2d           99 37 00
> > > Slave addr: 0x2d           AA 56 00
> > >
> > > Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> > > ---
> > > Changes for v4:
> > > - Fix error: implicit declaration of function 'i2c_smbus_*' APIs by
> > >   introducing a dependency on I2C_CONFIG. This error is reported
> > >   by kernel test on v3 series and usb:usb-testing 20/25 branch.
> > >   https://lore.kernel.org/all/2024082503-uncoated-chaperone-
> > 7f70@gregkh
> > >
> > > Changes for v3:
> > > - Add comment for UDC suspend sequence.
> > > - Drop USB5744_CREG_MEM_NBYTES and USB5744_CREG_NBYTES and
> > replace
> > >   it with literal + comment.
> > > - Move microchip defines to source file.
> > >
> > > Changes for v2:
> > > - Move power on reset delay to separate patch.
> > > - Switch to compatible based check for calling usb5755
> > >   onboard_dev_5744_i2c_init(). This is done to make
> > >   onboard_dev_5744_i2c_init() as static.
> > > - Fix subsystem "usb: misc: onboard_usb_dev:..."
> > > - Use #define for different register bits instead of magic values.
> > > - Use err_power_off label name.
> > > - Modified commit description to be in sync with v2 changes.
> > > ---
> > >  drivers/usb/misc/Kconfig           |  2 +-
> > >  drivers/usb/misc/onboard_usb_dev.c | 73
> > ++++++++++++++++++++++++++++++
> > >  2 files changed, 74 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
> > > index 50b86d531701..cb5e47d439ab 100644
> > > --- a/drivers/usb/misc/Kconfig
> > > +++ b/drivers/usb/misc/Kconfig
> > > @@ -318,7 +318,7 @@ config BRCM_USB_PINMAP
> > >
> > >  config USB_ONBOARD_DEV
> > >  	tristate "Onboard USB device support"
> > > -	depends on OF
> > > +	depends on OF && I2C
> > 
> > This feels wrong.
> > 
> > While a single device that this driver supports might need i2c, not all
> > of the devices do, so you have the potential to drag in a bunch of code
> > here for devices that do not have/need i2c at all, right?
> > 
> > Any way to "split this out" into a smaller chunk?  Or better yet, just
> > detect at runtime if you need/want to call those i2c functions (and they
> > should have no-ops for when i2c is not enabled, right?)
> 
> In onboard driver I am calling onboard_dev_5744_i2c_init() by
> detecting at runtime if "i2c-bus" phandle is present. But the 
> problem is i2c_smbus_* APIs are declared and defined only for 
> #if IS_ENABLED(CONFIG_I2C).
> 
> Do you think we should implement no-ops for I2C smbus APIs
> (in linux/i2c.h)? OR a simpler alternative would be to
> add #if IS_ENABLED(CONFIG_I2C) check in the onboard_*_i2c_init()
> and return error code if CONFIG_I2C is not defined ? 
> Did a grep on #if IS_ENABLED(CONFIG_I2C) and find couple of 
> drivers using this approach.

Yes, try doing this with simpler way first and see what that looks like.

thanks,

greg k-h

  reply	other threads:[~2024-09-03  7:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-01 12:08 [PATCH v4 0/2] usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus support Radhey Shyam Pandey
2024-09-01 12:08 ` [PATCH v4 1/2] usb: misc: onboard_dev: extend platform data to add power on delay field Radhey Shyam Pandey
2024-09-01 12:08 ` [PATCH v4 2/2] usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus programming support Radhey Shyam Pandey
2024-09-03  6:40   ` Greg KH
2024-09-03  7:19     ` Pandey, Radhey Shyam
2024-09-03  7:58       ` Greg KH [this message]
2024-09-18 17:07       ` Matthias Kaehlcke
2024-09-18 19:22         ` Pandey, Radhey Shyam
2024-09-19 10:12           ` Matthias Kaehlcke
2024-09-18 17:39   ` Matthias Kaehlcke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2024090324-phonics-angler-64c2@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=francesco.dolcini@toradex.com \
    --cc=frieder.schrempf@kontron.de \
    --cc=git@amd.com \
    --cc=javier.carrasco@wolfvision.net \
    --cc=jbrunet@baylibre.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=macpaul.lin@mediatek.com \
    --cc=mka@chromium.org \
    --cc=radhey.shyam.pandey@amd.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=stefan.eichenberger@toradex.com \
    --cc=wentong.wu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox