mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@ti.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Greg KH <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	USB list <linux-usb@vger.kernel.org>
Subject: Re: [GIT PATCH] USB patches for 3.10-rc1
Date: Tue, 30 Apr 2013 09:26:24 +0300	[thread overview]
Message-ID: <20130430062624.GB4776@arwen.pp.htv.fi> (raw)
In-Reply-To: <CA+55aFzOf3tE=Mbrrwt_aOn6GdUv26VnJ=wsmY2sYC90-aUfLQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]

Hi,

On Mon, Apr 29, 2013 at 02:31:59PM -0700, Linus Torvalds wrote:
> On Mon, Apr 29, 2013 at 2:14 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > What other things seemed odd about Greg's pull request?
> 
> The only other thing I noticed was the new CONFIG_USB_PHY quesiton,
> which is not something that I think is sensible to ask from a user,
> and the help text doesn't really help anything either.
> 
> I think the question may make sense, but the wording does not.
> 
> *EVERYBODY* wants a USB PHY. You can't have USB without a physical
> layer unless it's a purely virtual device. There's one in a EHCI
> controller too. It's like a network chip - without a PHY there's no
> point. Why ask about whether you want to support a phy or not? The
> question makes no sense.

right, the thing is that the standard host-only drivers (EHCI, OHCI,
UHCI and XHCI) still don't know about the PHY layer. They give no
SW visibility on the PHY at all so I felt that adding unused code to the
x86 binaries would worse than just asking the user if they want the PHY
layer enabled or not.

In any case, *HCI drivers need to learn about the PHY layer, at least on
their embedded forms (OMAP, Tegra, Marvel, SuperH, etc) since those will
need SW control of the PHY for e.g. PM, remote wakeup, and few other
cases.

> So I don't think the question should be "do you want a USB PHY". The
> question should be "Do you want a driver for some of the specialized
> external USB controllers" or something like that. Because as it is
> now, anybody who actually reads the question is likely to answer "y",
> I think, even if he just wants one of the *normal* USB chips that
> don't split out the PHY.

makes sense.

> Hmm? Or does PHY have some magic other meaning in USB circles? In

no, it means the same thing.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2013-04-30  6:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-29 16:23 Greg KH
2013-04-29 19:41 ` Linus Torvalds
2013-04-29 21:14   ` Alan Stern
2013-04-29 21:31     ` Linus Torvalds
2013-04-30  6:26       ` Felipe Balbi [this message]
2013-05-01 16:13     ` [PATCH] USB: remove remaining instances of USB_SUSPEND Alan Stern
2013-05-01 16:22       ` Greg KH
2013-05-01 16:24       ` Linus Torvalds
2013-05-02 13:58         ` Alan Stern

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=20130430062624.GB4776@arwen.pp.htv.fi \
    --to=balbi@ti.com \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®