public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Mark Brown <broonie@kernel.org>
Cc: Tushar Behera <tushar.behera@linaro.org>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	tobetter@gmail.com, patches@linaro.org
Subject: Re: [PATCH] usb: misc: usb3503: Force late initialization
Date: Wed, 14 Aug 2013 12:47:44 -0700	[thread overview]
Message-ID: <20130814194744.GA28373@kroah.com> (raw)
In-Reply-To: <20130814193950.GQ2401@sirena.org.uk>

On Wed, Aug 14, 2013 at 08:39:50PM +0100, Mark Brown wrote:
> > > We can't just treat it as a PHY (which is the obvious workaroud) since
> > > we do also need to use the built
> > > in PHY in the SoC.
> 
> > There has to be some type of resource that it can grab, as obviously
> > it's failing to work properly unless that resource is present.  Just
> 
> That resource is the USB bus I think (I suspect the issue is that the
> fact that power is always present confuses the USB enumeration protocol
> if the device gets brought out of reset prior to the bus being live).

Which USB bus is it?  How is this device even probed before the device
is found by the bus?

Ah crud, this is an i2c driver, not a USB driver, no wonder I'm
confused...

You are going to have to find some kind of relationship here, not just
by linker order, otherwise you are going to have problems later on.

> The normal way to grab that resource would be to make the device a
> device on the bus but currently the only way USB gets children is via
> USB enumeration.

Perhaps make this device a child of the USB controller in the DT
description?

> > messing with the init order isn't going to solve any problem if the
> > driver is built as a module, as nothing guarantees module load order.
> 
> Right, and I did discuss that with Tushar elsehwere prior to this being
> posted here.  We figured given how cheap and non-invasive the workaround
> is it was worth just doing it.

Nope, sorry, I'm not going to take it.

> > So this patch wouldn't really solve the problem, only paper over it for
> > one type of configuration (i.e. driver built into the system), right?
> 
> Yes, though realistically nobody actually does that for the relevant
> systems and if they do it's always possible to control the module load
> order if you really want to.

But you aren't telling anyone that is what is needed.  How would anyone
know that they need to control the load order?

thanks,

greg k-h

  reply	other threads:[~2013-08-14 19:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-14 10:29 [PATCH] usb: misc: usb3503: Force late initialization Tushar Behera
2013-08-14 18:22 ` Greg KH
2013-08-14 19:04   ` Mark Brown
2013-08-14 19:15     ` Greg KH
2013-08-14 19:39       ` Mark Brown
2013-08-14 19:47         ` Greg KH [this message]
2013-08-14 23:22           ` Mark Brown

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=20130814194744.GA28373@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=tobetter@gmail.com \
    --cc=tushar.behera@linaro.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