From: Oliver Neukum <oliver@neukum.org>
To: "Li, Shaohua" <shaohua.li@intel.com>
Cc: "Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
"Patrick Mochel" <mochel@digitalimplant.org>,
"Zhu, Yi" <yi.zhu@intel.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: suspend/resume support for driver requires an external firmware
Date: Fri, 24 Sep 2004 14:42:03 +0200 [thread overview]
Message-ID: <200409241442.03078.oliver@neukum.org> (raw)
In-Reply-To: <16A54BF5D6E14E4D916CE26C9AD3057534510B@pdsmsx402.ccr.corp.intel.com>
Am Freitag, 24. September 2004 13:52 schrieb Li, Shaohua:
> I somewhat think choice 2 is better. The pre-load can be invoked in any
> order instead of in the device tree hierarchy order. And currently only
> few devices need it, is it worth adding it in the device core?
If order doesn't matter, the device tree order is as good as any
other order.
> In addition, the notifiers have better flexibility. We can easily add
> more notifier types if needed, such as adding a callback between the
> sysdev resume and regular devices resume. To tell the truth, we actually
> have the case. An ACPI link device must resume before regular devices
> but must be with IRQ enabled. I'm considering add a call back between
> sysdev and regular devices resume for the issue. I guess the MTRR driver
> in SMP has the same requirement. Anyway, notifier solution sounds like
> easier to extend, but we can't extend device core casually.
If you add this stuff to anything but the device core, you have to teach
the drivers about the various notifier chains. Why would adding methods
to the device core be harder than adding notifier chains? If drivers do
not need the method they don't need to implement it. If they do need
it, using a notifier chain isn't easier.
Regards
Oliver
next prev parent reply other threads:[~2004-09-24 12:42 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-24 11:52 Li, Shaohua
2004-09-24 12:42 ` Oliver Neukum [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-09-28 6:16 Zhu, Yi
2004-09-28 6:07 Zhu, Yi
2004-09-28 6:11 ` Patrick Mochel
2004-09-28 5:31 Zhu, Yi
2004-09-28 5:34 ` Patrick Mochel
2004-09-28 2:28 Zhu, Yi
2004-09-28 4:55 ` Patrick Mochel
2004-09-28 2:28 Zhu, Yi
2004-09-28 2:27 Zhu, Yi
2004-09-28 4:52 ` Patrick Mochel
2004-09-27 6:23 Li, Shaohua
2004-09-27 7:51 ` Oliver Neukum
2004-09-27 3:43 Zhu, Yi
2004-09-27 3:43 Zhu, Yi
2004-09-27 7:47 ` Oliver Neukum
2004-09-27 16:50 ` Patrick Mochel
2004-09-27 17:19 ` Oliver Neukum
2004-09-27 18:19 ` Dmitry Torokhov
2004-09-27 18:37 ` Oliver Neukum
2004-09-27 22:47 ` Denis Vlasenko
2004-09-27 23:06 ` Dmitry Torokhov
2004-09-28 15:07 ` Denis Vlasenko
2004-09-24 15:03 Zhu, Yi
2004-09-24 6:16 Zhu, Yi
2004-09-24 7:33 ` Patrick Mochel
2004-09-24 8:22 ` Benjamin Herrenschmidt
2004-09-24 16:00 ` Oliver Neukum
2004-09-24 20:11 ` Marcel Holtmann
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=200409241442.03078.oliver@neukum.org \
--to=oliver@neukum.org \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--cc=shaohua.li@intel.com \
--cc=yi.zhu@intel.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 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®