All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Felipe Balbi <balbi@ti.com>,
	Ulrich Hecht <ulrich.hecht@gmail.com>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>
Subject: Re: [PATCH v5] usb: renesas_usbhs: Allow an OTG PHY driver to provide VBUS
Date: Thu, 09 Jul 2015 01:03:23 +0000	[thread overview]
Message-ID: <8728955.GfUuMsjafi@avalon> (raw)
In-Reply-To: <SIXPR06MB0639B6B493881EBB77A59A01F5910@SIXPR06MB0639.apcprd06.prod.outlook.com>

Hi Phil,

On Wednesday 08 July 2015 08:08:27 Phil Edworthy wrote:
> On 08 July 2015 00:08, Laurent wrote:
> > On Tuesday 07 July 2015 12:52:43 Phil Edworthy wrote:
> > > These changes allow a PHY driver to trigger a VBUS interrupt and
> > > to provide the value of VBUS.
> > > 
> > > Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
> > 
> > This looks much better to me. I just have two comments, please see below.
> > 
> > > ---
> > > 
> > > v5:
> > >   - Avoid race when vbus_is_indirect may or may not be read
> > >   
> > >     before the phy has called vbus_session. In doing so, the
> > >     changes have also been isolated to mod_gadget.c
> > > 
> > > v4:
> > >   - Use true/false with bool vars.
> > >   - Clean up "transceiver found" message.
> > > 
> > > v3:
> > >   - Changed how indirect vbus is plumbed in.
> > >   - Removed unnecessary (void) on call to otg_set_peripheral.
> > >   - Moved code that connects to bus through transceiver so it
> > >   
> > >     is before setting gpriv->driver.
> > > 
> > > v2:
> > >   - vbus variables changed from int to bool.
> > >   - dev_info() changed to dev_err()
> > > 
> > > ---
> > > 
> > >  drivers/usb/renesas_usbhs/mod_gadget.c | 62 +++++++++++++++++++++++++++
> > >  1 file changed, 62 insertions(+)
> > > 
> > > diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c
> > > b/drivers/usb/renesas_usbhs/mod_gadget.c index dc2aa32..19a22a3 100644
> > > --- a/drivers/usb/renesas_usbhs/mod_gadget.c
> > > +++ b/drivers/usb/renesas_usbhs/mod_gadget.c

[snip]

> > > @@ -882,12 +906,28 @@ static int usbhsg_gadget_start(struct usb_gadget
> > > *gadget,
> > >  {
> > >  	struct usbhsg_gpriv *gpriv = usbhsg_gadget_to_gpriv(gadget);
> > >  	struct usbhs_priv *priv = usbhsg_gpriv_to_priv(gpriv);
> > > +	struct device *dev = usbhs_priv_to_dev(priv);
> > > +	int ret;
> > > 
> > >  	if (!driver		||
> > >  	    !driver->setup	||
> > >  	    driver->max_speed < USB_SPEED_FULL)
> > >  		return -EINVAL;
> > > 
> > > +	/* connect to bus through transceiver */
> > > +	if (!IS_ERR_OR_NULL(gpriv->transceiver)) {
> > > +		ret = otg_set_peripheral(gpriv->transceiver->otg,
> > > +					&gpriv->gadget);
> > > +		if (ret) {
> > > +			dev_err(dev, "%s: can't bind to transceiver\n",
> > > +				gpriv->gadget.name);
> > > +			return ret;
> > > +		}
> > > +
> > > +		/* get vbus using phy versions */
> > > +		usbhs_mod_phy_mode(priv);
> > 
> > Given that the presence of an external PHY is known at probe time,
> > couldn't this call be moved to the probe function ? It would then probably
> > conflict with the usbhs_mod_autonomy_mode() call from usbhs_probe(), which
> > would need to be fixed.
> 
> You could do this, but as you say it would conflict with usbhs_probe(). I
> can't see a simple way to check for the external phy connection, so I would
> prefer to keep it here.
> Is that ok?

I can live with that, but I can't help feeling that it's not the best 
architecture. Coming to think about it, why do we get the transceiver (by 
calling usb_get_phy) in the gadget code ? Isn't the transceiver shared between 
host and peripheral modes ? Shouldn't it be handled by core code then ? I 
might miss something as my knowledge of the USB subsystem isn't perfect.

If we decide to refactor the code it can be done in a follow-up patch, this 
patch has been delayed for long enough.

> > > +	}
> > > +
> > > 
> > >  	/* first hook up the driver ... */
> > >  	gpriv->driver = driver;

-- 
Regards,

Laurent Pinchart


WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Felipe Balbi <balbi@ti.com>,
	Ulrich Hecht <ulrich.hecht@gmail.com>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>
Subject: Re: [PATCH v5] usb: renesas_usbhs: Allow an OTG PHY driver to provide VBUS
Date: Thu, 09 Jul 2015 04:03:23 +0300	[thread overview]
Message-ID: <8728955.GfUuMsjafi@avalon> (raw)
In-Reply-To: <SIXPR06MB0639B6B493881EBB77A59A01F5910@SIXPR06MB0639.apcprd06.prod.outlook.com>

Hi Phil,

On Wednesday 08 July 2015 08:08:27 Phil Edworthy wrote:
> On 08 July 2015 00:08, Laurent wrote:
> > On Tuesday 07 July 2015 12:52:43 Phil Edworthy wrote:
> > > These changes allow a PHY driver to trigger a VBUS interrupt and
> > > to provide the value of VBUS.
> > > 
> > > Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
> > 
> > This looks much better to me. I just have two comments, please see below.
> > 
> > > ---
> > > 
> > > v5:
> > >   - Avoid race when vbus_is_indirect may or may not be read
> > >   
> > >     before the phy has called vbus_session. In doing so, the
> > >     changes have also been isolated to mod_gadget.c
> > > 
> > > v4:
> > >   - Use true/false with bool vars.
> > >   - Clean up "transceiver found" message.
> > > 
> > > v3:
> > >   - Changed how indirect vbus is plumbed in.
> > >   - Removed unnecessary (void) on call to otg_set_peripheral.
> > >   - Moved code that connects to bus through transceiver so it
> > >   
> > >     is before setting gpriv->driver.
> > > 
> > > v2:
> > >   - vbus variables changed from int to bool.
> > >   - dev_info() changed to dev_err()
> > > 
> > > ---
> > > 
> > >  drivers/usb/renesas_usbhs/mod_gadget.c | 62 +++++++++++++++++++++++++++
> > >  1 file changed, 62 insertions(+)
> > > 
> > > diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c
> > > b/drivers/usb/renesas_usbhs/mod_gadget.c index dc2aa32..19a22a3 100644
> > > --- a/drivers/usb/renesas_usbhs/mod_gadget.c
> > > +++ b/drivers/usb/renesas_usbhs/mod_gadget.c

[snip]

> > > @@ -882,12 +906,28 @@ static int usbhsg_gadget_start(struct usb_gadget
> > > *gadget,
> > >  {
> > >  	struct usbhsg_gpriv *gpriv = usbhsg_gadget_to_gpriv(gadget);
> > >  	struct usbhs_priv *priv = usbhsg_gpriv_to_priv(gpriv);
> > > +	struct device *dev = usbhs_priv_to_dev(priv);
> > > +	int ret;
> > > 
> > >  	if (!driver		||
> > >  	    !driver->setup	||
> > >  	    driver->max_speed < USB_SPEED_FULL)
> > >  		return -EINVAL;
> > > 
> > > +	/* connect to bus through transceiver */
> > > +	if (!IS_ERR_OR_NULL(gpriv->transceiver)) {
> > > +		ret = otg_set_peripheral(gpriv->transceiver->otg,
> > > +					&gpriv->gadget);
> > > +		if (ret) {
> > > +			dev_err(dev, "%s: can't bind to transceiver\n",
> > > +				gpriv->gadget.name);
> > > +			return ret;
> > > +		}
> > > +
> > > +		/* get vbus using phy versions */
> > > +		usbhs_mod_phy_mode(priv);
> > 
> > Given that the presence of an external PHY is known at probe time,
> > couldn't this call be moved to the probe function ? It would then probably
> > conflict with the usbhs_mod_autonomy_mode() call from usbhs_probe(), which
> > would need to be fixed.
> 
> You could do this, but as you say it would conflict with usbhs_probe(). I
> can't see a simple way to check for the external phy connection, so I would
> prefer to keep it here.
> Is that ok?

I can live with that, but I can't help feeling that it's not the best 
architecture. Coming to think about it, why do we get the transceiver (by 
calling usb_get_phy) in the gadget code ? Isn't the transceiver shared between 
host and peripheral modes ? Shouldn't it be handled by core code then ? I 
might miss something as my knowledge of the USB subsystem isn't perfect.

If we decide to refactor the code it can be done in a follow-up patch, this 
patch has been delayed for long enough.

> > > +	}
> > > +
> > > 
> > >  	/* first hook up the driver ... */
> > >  	gpriv->driver = driver;

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2015-07-09  1:03 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-02  7:36 [PATCH v2] usb: renesas_usbhs: Allow an OTG PHY driver to provide VBUS Phil Edworthy
2015-07-02  7:36 ` Phil Edworthy
2015-07-02  8:15 ` Laurent Pinchart
2015-07-02  8:15   ` Laurent Pinchart
2015-07-02  8:35   ` Phil Edworthy
2015-07-02  8:35     ` Phil Edworthy
2015-07-02 10:26   ` [PATCH v3] " Phil Edworthy
2015-07-02 10:26     ` Phil Edworthy
2015-07-06  7:27     ` Yoshihiro Shimoda
2015-07-06  7:27       ` Yoshihiro Shimoda
2015-07-07  8:59       ` Phil Edworthy
2015-07-07  8:59         ` Phil Edworthy
2015-07-06  8:20     ` Laurent Pinchart
2015-07-06  8:20       ` Laurent Pinchart
2015-07-07  9:12       ` Phil Edworthy
2015-07-07  9:12         ` Phil Edworthy
2015-07-07 11:52       ` [PATCH v5] " Phil Edworthy
2015-07-07 11:52         ` Phil Edworthy
2015-07-07 23:08         ` Laurent Pinchart
2015-07-07 23:08           ` Laurent Pinchart
2015-07-08  8:08           ` Phil Edworthy
2015-07-08  8:08             ` Phil Edworthy
2015-07-09  1:03             ` Laurent Pinchart [this message]
2015-07-09  1:03               ` Laurent Pinchart
2015-07-13 15:22               ` Phil Edworthy
2015-07-13 15:30                 ` [PATCH v6] " Phil Edworthy
2015-07-13 15:30                   ` Phil Edworthy
2015-07-13 15:50                   ` Laurent Pinchart
2015-07-13 15:50                     ` Laurent Pinchart
2015-07-13 16:15                     ` Phil Edworthy
2015-07-02 11:16 ` [PATCH v2] " Sergei Shtylyov
2015-07-02 11:16   ` Sergei Shtylyov
2015-07-02 12:01   ` Phil Edworthy
2015-07-02 12:01     ` Phil Edworthy

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=8728955.GfUuMsjafi@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=balbi@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kishon@ti.com \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=phil.edworthy@renesas.com \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=ulrich.hecht@gmail.com \
    --cc=yoshihiro.shimoda.uh@renesas.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.