All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bin Liu <b-liu@ti.com>
To: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	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 08:44:18 -0500	[thread overview]
Message-ID: <20190322134418.GF25852@uda0271908> (raw)

On Fri, Mar 22, 2019 at 02:34:41PM +0100, Paul Kocialkowski wrote:
> Le vendredi 22 mars 2019 à 08:28 -0500, Bin Liu a écrit :
> > Again, think about an embedded product, if dr_mode is 'otg' which
> > indicates the peripheral mode will be used at some point, 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.
> 
> Why should we think of an embedded product where the end user doesn't
> have access to the console? Unless I'm mistaken, the Linux kernel
> doesn't target commercial products where users are powerless in
> particular, and leaves out all other use cases (which may or may not be
> commercial).

Okay, this will lead to an endless argument as well, so I will only
explain why I mentioned embedded - AFAIK musb is only used in embedded
processors. then we can stop arguing on this point...

> I don't think this assumption makes any sense in Linux as a project (or
> that it's sane in any context of software development for that matter,
> but that's beside the point).
> 
> > > 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.
> > 
> > > 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.
> 
> I disagree: dr_mode describes the hardware capabilities, not what the
> software does with it.

I have different understanding, dr_mode describles the use case, not the
hardware capabilities. And software operates the hardware accordingly
based on dr_mode.

Regards,
-Bin.

WARNING: multiple messages have this Message-ID (diff)
From: Bin Liu <b-liu@ti.com>
To: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	<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 08:44:18 -0500	[thread overview]
Message-ID: <20190322134418.GF25852@uda0271908> (raw)
In-Reply-To: <bf2e01b54009e074140aedd0159503f14fdeb450.camel@bootlin.com>

On Fri, Mar 22, 2019 at 02:34:41PM +0100, Paul Kocialkowski wrote:
> Le vendredi 22 mars 2019 à 08:28 -0500, Bin Liu a écrit :
> > Again, think about an embedded product, if dr_mode is 'otg' which
> > indicates the peripheral mode will be used at some point, 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.
> 
> Why should we think of an embedded product where the end user doesn't
> have access to the console? Unless I'm mistaken, the Linux kernel
> doesn't target commercial products where users are powerless in
> particular, and leaves out all other use cases (which may or may not be
> commercial).

Okay, this will lead to an endless argument as well, so I will only
explain why I mentioned embedded - AFAIK musb is only used in embedded
processors. then we can stop arguing on this point...

> I don't think this assumption makes any sense in Linux as a project (or
> that it's sane in any context of software development for that matter,
> but that's beside the point).
> 
> > > 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.
> > 
> > > 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.
> 
> I disagree: dr_mode describes the hardware capabilities, not what the
> software does with it.

I have different understanding, dr_mode describles the use case, not the
hardware capabilities. And software operates the hardware accordingly
based on dr_mode.

Regards,
-Bin.

             reply	other threads:[~2019-03-22 13:44 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22 13:44 Bin Liu [this message]
2019-03-22 13:44 ` [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 14:04 Bin Liu
2019-03-22 14:04 ` [PATCH] " Bin Liu
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: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=20190322134418.GF25852@uda0271908 \
    --to=b-liu@ti.com \
    --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.