All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Tal Shorer <tal.shorer@gmail.com>, Greg KH <gregkh@linuxfoundation.org>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Sasha Levin <sasha.levin@oracle.com>,
	USB list <linux-usb@vger.kernel.org>,
	"<linux-kernel@vger.kernel.org>" <linux-kernel@vger.kernel.org>,
	David Cohen <david.a.cohen@linux.intel.com>,
	Felipe Balbi <balbi@ti.com>, Lu Baolu <baolu.lu@linux.intel.com>
Subject: Re: [PATCH] usb: ulpi: don't register drivers if bus doesn't exist
Date: Mon, 25 May 2015 14:40:10 +0300	[thread overview]
Message-ID: <20150525114010.GA30679@kuha.fi.intel.com> (raw)
In-Reply-To: <CAFDyS3M1ZqrkGXGqdhTjyJp1eheJsDKLuBC-piC8jBUC=zt45Q@mail.gmail.com>

Hi,

> Why do we even need that? If you take patch that makes ulpi_init a
> subsys_initcall you won't have this problem, and no additional weird
> hacks and errors will be needed

Using subsys_initcall will work around the problem for now, but I
would not make the assumption that there will never be ulpi phy
drivers and ulpi interface drivers that don't use subsys_initcall
themselves. By checking the old phy drivers at drivers/usb/phy/, at
least so far it hasn't been uncommon for them to use subsys_initcall.

I would much prefer to have a proper fix for this issue instead of
just working around it, but we need to use subsys_initcall in any
case.

> >> > +   /* Was the bus registered successfully? */
> >> > +   if (!ulpi_bus.p)
> >> > +           return -ENODEV;
> >>
> >> Ick, no, don't go mucking around in the bus internals like this, that's
> >> not ok.  You should either "know" the bus is registered, or something is
> >> really wrong with the design here.
> > can't we use a variable which can be initialized to 1 in ulpi_init() if
> > the bus registers successfully and later check that?

Just a note. We should also be aware if the bus registration failed or
if it just hasn't been loaded yet.

If we used a variable like that, I guess it could initially have the
value -EAGAIN. If bus_register returns error, we store -ENODEV to it.
If bus_register succeeds we store 0 to it. I don't know if we can just
store the return value from bus_register to it.

In ulpi_register_driver and ulpi_register_interface we can then just
return it if it has a value other then 0.

But couldn't we add a helper function to drivers/base/bus.c that the
bus drivers can use to at least check was the bus already loaded or
not? It looks like there are a couple of bus drivers that use the
struct bus member "p" to check that.

Greg, what do you think?


Thanks,

-- 
heikki

  reply	other threads:[~2015-05-25 11:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-20 19:33 [PATCH] usb: ulpi: don't register drivers if bus doesn't exist Sasha Levin
2015-05-20 21:22 ` David Cohen
2015-05-21  6:39   ` Lu, Baolu
2015-05-21  7:21     ` Heikki Krogerus
2015-05-22 10:16       ` Heikki Krogerus
2015-05-22 10:52         ` Heikki Krogerus
2015-05-22 14:21         ` Sasha Levin
2015-05-24  7:19 ` Greg KH
2015-05-24  8:09   ` Sudip Mukherjee
2015-05-24 14:30     ` Tal Shorer
2015-05-25 11:40       ` Heikki Krogerus [this message]
2015-05-25 16:13         ` Greg KH
2015-05-25 17:00           ` Bjørn Mork
2015-05-26 17:54             ` David Cohen
2015-05-27  2:41               ` Greg KH
2015-05-27  4:35                 ` Sudip Mukherjee
2015-05-27 16:49                 ` David Cohen
2015-05-27  2:39             ` Greg KH
2015-05-27  8:39           ` Heikki Krogerus
2015-05-27  9:05             ` Sudip Mukherjee
2015-05-27 15:16             ` Alan Stern
2015-05-27 15:21               ` Greg KH
2015-05-28  5:39                 ` Sudip Mukherjee
2015-05-28  5:54                   ` Felipe Balbi
2015-05-28  6:42                     ` Sudip Mukherjee
2015-05-28  6:53                       ` Sudip Mukherjee
2015-05-28 15:57                     ` Alan Stern
2015-05-28 12:36                   ` Sasha Levin
2015-05-28 13:24                     ` Heikki Krogerus
2015-05-28 16:23                   ` Greg KH

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=20150525114010.GA30679@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=balbi@ti.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=david.a.cohen@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sasha.levin@oracle.com \
    --cc=sudipm.mukherjee@gmail.com \
    --cc=tal.shorer@gmail.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.