mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: Duncan Sands <duncan.sands@math.u-psud.fr>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Adrian Bunk <bunk@stusta.de>, Greg K-H <greg@kroah.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD_PROBE)
Date: Wed, 9 May 2007 10:45:41 +0200	[thread overview]
Message-ID: <20070509104541.48cc901e@gondolin.boeblingen.de.ibm.com> (raw)
In-Reply-To: <200705091014.17109.duncan.sands@math.u-psud.fr>

On Wed, 9 May 2007 10:14:16 +0200,
Duncan Sands <duncan.sands@math.u-psud.fr> wrote:

> the usbatm USB ADSL modem drivers have this functionality.  These drivers
> need to load firmware before they become useful.  The natural place to do
> this is in the probe() method, but because firmware loading can take quite
> some time (10 seconds, or even an infinite amount of time if the firmware
> is not available and the timeout has been turned off) and would block the
> USB hub thread if done from probe(), it's done in a separate kernel thread.
> Clients of usbatm, like the speedtch driver, register themselves with usbatm,
> providing a "bind" and a "heavy_init" method.  "bind" is like probe(), while
> "heavy_init" is like probe_async().  First bind is called, and if successful
> and heavy_init has been defined, then heavy_init is run in its own thread.
> If the device is unplugged, usbatm takes care of making sure that the heavy_init
> thread has stopped before calling unbind and destroying device related structures.
> 
> A bunch of other USB drivers could do with similar functionality for the
> same reason (slow probe), and there was some discussion about generalizing
> this functionality to the USB layer but I didn't find time to do anything
> about it yet.  See http://marc.info/?l=linux-usb-devel&m=116551653026075&w=2

Would a general split between probe() (check if we can handle the
device, do very basic stuff) and setup() (get the device up and
running) make sense? Drivers could stay with today's probe() function
if they want to (and still be working). setup() could be, but need not
be async. As an added benefit for huge systems, setup() might only be
called if explicitly requested (like "only do this heavy lifting
if/when we really want to use the device"). probe() could call bind()
and setup() (doing the firmware load etc.) heavy_init(). (This may be
orthogonal to the probe()/probe_async() idea.)

  reply	other threads:[~2007-05-09  8:46 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-08 13:37 Cornelia Huck
2007-05-08 14:07 ` Greg KH
2007-05-08 20:58   ` David Miller
2007-05-09  9:44     ` Greg KH
2007-05-09 17:21       ` Linus Torvalds
2007-05-08 14:11 ` Adrian Bunk
2007-05-08 14:41   ` Cornelia Huck
2007-05-08 15:27   ` Linus Torvalds
2007-05-08 16:38     ` Cornelia Huck
2007-05-08 16:47       ` david
2007-05-08 21:45         ` Stefan Richter
2007-05-08 18:30       ` Linus Torvalds
2007-05-08 19:21         ` Cornelia Huck
2007-05-08 19:31           ` Linus Torvalds
2007-05-08 20:01             ` Linus Torvalds
2007-05-08 20:26               ` david
2007-05-09  7:58                 ` Cornelia Huck
2007-05-09  8:33                   ` david
2007-05-09  9:15                     ` Cornelia Huck
2007-05-09  9:25                       ` david
2007-05-09 13:20                         ` Cornelia Huck
2007-05-09 16:18                           ` david
2007-05-09 17:07                             ` Cornelia Huck
2007-05-09 17:09                               ` david
2007-05-09 17:48                                 ` Cornelia Huck
2007-05-09 17:53                                   ` david
2007-05-09 18:36                                     ` Cornelia Huck
2007-05-09 18:52                                       ` david
2007-05-10  7:38                                         ` Cornelia Huck
2007-05-09 17:07                             ` Greg KH
2007-05-09 17:25                               ` Linus Torvalds
2007-05-09  9:30                       ` Stefan Richter
2007-05-09 22:21                 ` Phillip Susi
2007-05-09 22:37                   ` Stefan Richter
2007-05-10 14:23                     ` Phillip Susi
2007-05-10 14:55                       ` Stefan Richter
2007-05-11  7:22                         ` Cornelia Huck
2007-05-08 20:51               ` Cornelia Huck
2007-05-08 21:41               ` David Miller
2007-05-09  9:55                 ` Greg KH
2007-05-09  8:14               ` Duncan Sands
2007-05-09  8:45                 ` Cornelia Huck [this message]
2007-05-09  9:16                   ` Duncan Sands
2007-05-09 12:37                     ` Cornelia Huck
2007-05-08 20:36             ` Cornelia Huck
2007-05-09  9:53       ` Greg KH
2007-05-09 13:38         ` Cornelia Huck
2007-05-09 16:42           ` Greg KH
2007-05-09 16:50             ` david
2007-05-09 17:14               ` Cornelia Huck
2007-05-09 17:09             ` Linus Torvalds
2007-05-08 21:15     ` David Miller
2007-05-08 22:19       ` Stefan Richter
2007-05-09  9:46       ` Greg KH
2007-05-08 15:15 ` Linus Torvalds

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=20070509104541.48cc901e@gondolin.boeblingen.de.ibm.com \
    --to=cornelia.huck@de.ibm.com \
    --cc=bunk@stusta.de \
    --cc=duncan.sands@math.u-psud.fr \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --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®