All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bin Liu <b-liu@ti.com>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Paul Kocialkowski <contact@paulk.fr>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	Chen-Yu Tsai <wens@csie.org>
Subject: usb: musb: Support gadget mode when the port is set to dual role
Date: Fri, 22 Mar 2019 09:04:04 -0500	[thread overview]
Message-ID: <20190322140404.GH25852@uda0271908> (raw)

Hi all,

On Fri, Mar 22, 2019 at 02:46:30PM +0100, Maxime Ripard wrote:
> >
> > Again, think about an embedded product,
> 
> That's all I'm thinking about.
> 
> > if dr_mode is 'otg' which indicates the peripheral mode will be used
> > at some point
> 
> No, it indicates that it *might* be used at some point, based on a
> number of external factors, including:
>   - Whether or not the user has plugged something in the connected USB
>     connector
>   - If they did so, how the ID pin has been wired (and therefore, is
>     a device or a host on the other end)
>   - And how the system designer decided to configure their kernel and
>     userspace.
> 
> > when and how to load the gadget driver if it is not loaded
> > automatically when Linux boots up? the end user doesn't have access
> > to the console.
> 
> An application could load it. And really, we start seeing SoCs in more
> and more pc-like devices, including with mUSB, so I don't think we
> should be making assumptions here.
> 
> How do you think Fedora, Ubuntu or Debian would behave here?
> 
> > > Because no other controller requires it and therefore it's not
> > > standard and violates the principle of least surprise?
> >
> > I know no other controller does this, but this doesn't mean it is not
> > standard.
> 
> I'm pretty sure that would be the definition of "standard", or of a
> norm at least.
> 
> > > And even without taking this into account, there's also the fact that
> > > while the *hardware* can do dual role, the software might decide
> > > otherwise. If I don't want to have support for any gadget (at all) in
> > > the end system, then why should I be forced to compile and load
> > > something I don't even want to use in the first place?
> >
> > then dr_mode should be set to 'host' instead, you don't have to load a
> > gadget if peripheral mode will never be used.
> 
> No. The hardware is perfectly capable of using OTG. The software has
> been configured not to.

I don't think the argument will lead to anywhere. Let's stop arguing
here, so that you can spend time to fix the driver if you want to.

Regards,
-Bin.

WARNING: multiple messages have this Message-ID (diff)
From: Bin Liu <b-liu@ti.com>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Paul Kocialkowski <contact@paulk.fr>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	<linux-kernel@vger.kernel.org>, <linux-usb@vger.kernel.org>,
	Chen-Yu Tsai <wens@csie.org>
Subject: Re: [PATCH] usb: musb: Support gadget mode when the port is set to dual role
Date: Fri, 22 Mar 2019 09:04:04 -0500	[thread overview]
Message-ID: <20190322140404.GH25852@uda0271908> (raw)
In-Reply-To: <20190322134630.c4cauwj5smxvj77y@flea>

Hi all,

On Fri, Mar 22, 2019 at 02:46:30PM +0100, Maxime Ripard wrote:
> >
> > Again, think about an embedded product,
> 
> That's all I'm thinking about.
> 
> > if dr_mode is 'otg' which indicates the peripheral mode will be used
> > at some point
> 
> No, it indicates that it *might* be used at some point, based on a
> number of external factors, including:
>   - Whether or not the user has plugged something in the connected USB
>     connector
>   - If they did so, how the ID pin has been wired (and therefore, is
>     a device or a host on the other end)
>   - And how the system designer decided to configure their kernel and
>     userspace.
> 
> > when and how to load the gadget driver if it is not loaded
> > automatically when Linux boots up? the end user doesn't have access
> > to the console.
> 
> An application could load it. And really, we start seeing SoCs in more
> and more pc-like devices, including with mUSB, so I don't think we
> should be making assumptions here.
> 
> How do you think Fedora, Ubuntu or Debian would behave here?
> 
> > > Because no other controller requires it and therefore it's not
> > > standard and violates the principle of least surprise?
> >
> > I know no other controller does this, but this doesn't mean it is not
> > standard.
> 
> I'm pretty sure that would be the definition of "standard", or of a
> norm at least.
> 
> > > And even without taking this into account, there's also the fact that
> > > while the *hardware* can do dual role, the software might decide
> > > otherwise. If I don't want to have support for any gadget (at all) in
> > > the end system, then why should I be forced to compile and load
> > > something I don't even want to use in the first place?
> >
> > then dr_mode should be set to 'host' instead, you don't have to load a
> > gadget if peripheral mode will never be used.
> 
> No. The hardware is perfectly capable of using OTG. The software has
> been configured not to.

I don't think the argument will lead to anywhere. Let's stop arguing
here, so that you can spend time to fix the driver if you want to.

Regards,
-Bin.

             reply	other threads:[~2019-03-22 14:04 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22 14:04 Bin Liu [this message]
2019-03-22 14:04 ` [PATCH] usb: musb: Support gadget mode when the port is set to dual role Bin Liu
  -- strict thread matches above, loose matches on Subject: below --
2019-03-22 13:46 Maxime Ripard
2019-03-22 13:46 ` [PATCH] " Maxime Ripard
2019-03-22 13:46 Bin Liu
2019-03-22 13:46 ` [PATCH] " Bin Liu
2019-03-22 13:44 Bin Liu
2019-03-22 13:44 ` [PATCH] " Bin Liu
2019-03-22 13:37 Paul Kocialkowski
2019-03-22 13:37 ` [PATCH] " Paul Kocialkowski
2019-03-22 13:36 Bin Liu
2019-03-22 13:36 ` [PATCH] " Bin Liu
2019-03-22 13:34 Paul Kocialkowski
2019-03-22 13:34 ` [PATCH] " Paul Kocialkowski
2019-03-22 13:28 Bin Liu
2019-03-22 13:28 ` [PATCH] " Bin Liu
2019-03-22 13:10 Paul Kocialkowski
2019-03-22 13:10 ` [PATCH] " Paul Kocialkowski
2019-03-22 13:09 Maxime Ripard
2019-03-22 13:09 ` [PATCH] " Maxime Ripard
2019-03-22 12:46 Bin Liu
2019-03-22 12:46 ` [PATCH] " Bin Liu
2019-03-21 16:41 Greg Kroah-Hartman
2019-03-21 16:41 ` [PATCH] " Greg Kroah-Hartman
2019-03-21 13:01 Maxime Ripard
2019-03-21 13:01 ` [PATCH] " Maxime Ripard
2018-05-01 16:22 Bin Liu
2018-05-01 16:22 ` [PATCH] " Bin Liu
2018-05-01 13:26 Paul Kocialkowski
2018-05-01 13:26 ` [PATCH] " Paul Kocialkowski
2018-05-01 12:25 Bin Liu
2018-05-01 12:25 ` [PATCH] " Bin Liu
2018-04-30 21:08 Paul Kocialkowski
2018-04-30 21:08 ` [PATCH] " Paul Kocialkowski
2018-04-21 14:34 Bin Liu
2019-03-21 10:02 ` [PATCH] " Bin Liu
2018-04-21 14:34 ` Bin Liu
2018-04-21 10:59 Paul Kocialkowski
2018-04-21 10:59 ` [PATCH] " Paul Kocialkowski
2018-04-21 10:51 Paul Kocialkowski
2018-04-21 10:51 ` [PATCH] " Paul Kocialkowski
2018-04-20 14:25 Bin Liu
2018-04-20 14:25 ` [PATCH] " Bin Liu
2018-04-03  9:29 Maxime Ripard
2018-04-03  9:29 ` [PATCH] " Maxime Ripard
2018-03-29 11:57 Paul Kocialkowski
2018-03-29 11:57 ` [PATCH] " Paul Kocialkowski
2018-03-29  9:23 Maxime Ripard
2018-03-29  9:23 ` [PATCH] " Maxime Ripard
2018-03-28 21:52 Paul Kocialkowski
2018-03-28 21:52 ` [PATCH] " Paul Kocialkowski

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=20190322140404.GH25852@uda0271908 \
    --to=b-liu@ti.com \
    --cc=contact@paulk.fr \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=wens@csie.org \
    /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.