Hi!
> > > With the USB subsystem I have followed the approach taken by the PM
> > > core, which is that tasks are frozen. But one can -- and Linus has on
> > > at least one occasion -- make a good case that tasks should be left
> > > running while only I/O is frozen. This would require the subsy
On Mon, 4 Jun 2007, Pavel Machek wrote:
> > With the USB subsystem I have followed the approach taken by the PM
> > core, which is that tasks are frozen. But one can -- and Linus has on
> > at least one occasion -- make a good case that tasks should be left
> > running while only I/O is frozen.
Hi!
> > > The theoretical answer is that it behaves the way we want. The kernel
> > > thread does selective resumes in response to device requests. If such
> > > a request comes in while the system is asleep it will awaken the
> > > system; so it's only logical that a request coming in while
Hi!
> > >> Userspace should handle the async request just fine when it comes
> > >> back
> > >> running, regardless of the time it was submitted.
> > >
> > > Okay, so the solution is to convert the drivers to use
> > > request_firmware_nowait() instead of request_firmware() in
> > > their .res
On Monday 28 May 2007 4:48 am, Michael-Luke Jones wrote:
> On 28 May 2007, at 08:43, Rafael J. Wysocki wrote:
>
> >> Seems, that's just the broken synchronous firmware loading interface
> >> with the useless timeout handling. The nowait version of the same
> >> loader
> >> doesn't time out, and
On Monday 28 May 2007 5:06 am, Kay Sievers wrote:
> Well, 10 seconds are just to short for userspace to react on some
> setups, from tiny boxes which are busy, to 512 CPU boxes enumerating
> thousands of devices, all had problems here. Any timeout for a
> firmware-request is just a broken concept,
On Tue, 29 May 2007, David Brownell wrote:
> On Monday 28 May 2007, Alan Stern wrote:
>
> > This is a matter of one's philosophy. In suspend-to-RAM, should tasks
> > be frozen or should I/O queues be frozen?
> >
> > With the USB subsystem I have followed the approach taken by the PM
> > core, w
On Sunday 27 May 2007 4:45 pm, Michael-Luke Jones wrote:
> (Slightly OT: A particularly nasty race is when an initramfs
> userspace is present, but firmware loading cannot occur because init
> has not run, so proc hasn't been mounted, so a hotplug event handler
> cannot be registered, despite
On Monday 28 May 2007, Alan Stern wrote:
> This is a matter of one's philosophy. In suspend-to-RAM, should tasks
> be frozen or should I/O queues be frozen?
>
> With the USB subsystem I have followed the approach taken by the PM
> core, which is that tasks are frozen. But one can -- and Linus h
On Mon, 28 May 2007, Pavel Machek wrote:
> > The theoretical answer is that it behaves the way we want. The kernel
> > thread does selective resumes in response to device requests. If such
> > a request comes in while the system is asleep it will awaken the
> > system; so it's only logical th
Hi!
> >In fact, I'd like drivers to use notifiers to actually
> >load the firmware into
> >memory before hibernation/suspend. Namely, if there's
> >PM_PRE_FREEZE, the
> >driver calls request_firmware() from within the
> >notifier and saves the firmware
> >in memory for future use, if need be.
Hi!
> > > I can't speak for the second example, but there's a good reason the
> > > first example works this way. It's not a matter of races; the problem
> > > is that the kernel thread's job is to selectively suspend and resume
> > > devices. We don't want it doing this while a system sleep is
On 5/28/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
On Monday, 28 May 2007 17:55, Alan Stern wrote:
> You're using the PM_PRE_FREEZE and PM_POST_THAW notifiers for both this
> and the userspace helper change. Is it your intention that drivers
> should continue to request these services but
On Mon, 28 May 2007, Matthew Garrett wrote:
> On Mon, May 28, 2007 at 12:43:36PM -0400, Alan Stern wrote:
> > On Mon, 28 May 2007, Matthew Garrett wrote:
> > > On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
> > >
> > > > I can't speak for the second example, but there's a good reason
On Monday, 28 May 2007 17:55, Alan Stern wrote:
> On Sun, 27 May 2007, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Use a hibernation and suspend notifier to disable the firmware requesting
> > mechanism before a hibernation/suspend and enable it after the op
On Mon, May 28, 2007 at 12:43:36PM -0400, Alan Stern wrote:
> On Mon, 28 May 2007, Matthew Garrett wrote:
> > On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
> >
> > > I can't speak for the second example, but there's a good reason the
> > > first example works this way. It's not a ma
On Mon, 28 May 2007, Matthew Garrett wrote:
> On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
>
> > I can't speak for the second example, but there's a good reason the
> > first example works this way. It's not a matter of races; the problem
> > is that the kernel thread's job is to
On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
> I can't speak for the second example, but there's a good reason the
> first example works this way. It's not a matter of races; the problem
> is that the kernel thread's job is to selectively suspend and resume
> devices. We don't wan
On Sun, 27 May 2007, Matthew Garrett wrote:
> > BTW, I know of two subsystems that want their kernel threads to be frozen
> > for
> > synchronization purposes. Please see these messages:
> >
> > 1)
> > https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012592.html
> > (plus follow
On Sun, 27 May 2007, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Use a hibernation and suspend notifier to disable the firmware requesting
> mechanism before a hibernation/suspend and enable it after the operation.
You're using the PM_PRE_FREEZE and PM_POST_THAW no
On 28 May 2007, at 14:00, Pavel Machek wrote:
I'm too lazy to figure out how it currently works, but
I'll just state it is not my fault
Figuring out how a userspace/kernelspace interface works should not
rely on having to read kernelspace code. Unfortunately, in the case
of hotplug / ueven
Hi!
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Use a hibernation and suspend notifier to disable the firmware requesting
> mechanism before a hibernation/suspend and enable it after the operation.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> drivers/base/firmware_class.c
Hi!
> >From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> >Use a hibernation and suspend notifier to disable the firmware
> >requesting
> >mechanism before a hibernation/suspend and enable it after the
> >operation.
> >
> >Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > drivers/bas
Hi!
> *Grumble ahead*
> Unfortunately, I don't properly understand the uevent interface, so
> some of the above may be inaccurate. This is *not* my fault as there
> is no decent documentation (and btw, telling me to write the
Translated: "I don't know what I'm talking about, but I still lik
On Mon, 2007-05-28 at 13:26 +0100, Michael-Luke Jones wrote:
> On 28 May 2007, at 12:51, Kay Sievers wrote:
>
> > Either the whole idea of userspace firmware-loading should be
> > considered
> > as a problem impossible to do right because of its unsolvable side
> > effects. Or at least releasing
On 28 May 2007, at 12:51, Kay Sievers wrote:
Either the whole idea of userspace firmware-loading should be
considered
as a problem impossible to do right because of its unsolvable side
effects. Or at least releasing loaded firmware should be the exception
for drivers which can be sure, that th
On 28 May 2007, at 13:01, Kay Sievers wrote:
In our development model, users of an interface are expected to
improve
it, because nobody else really knows what's needed. That unfortunately
didn't happen so far.
Thanks for responding :)
The fact that no-one is told to use the new right way (t
On Mon, 2007-05-28 at 11:26 +0100, Michael-Luke Jones wrote:
> On 28 May 2007, at 10:06, Kay Sievers wrote:
>
> > The underlying issue are the driver authors, that's not so easy to
> > fix. :)
>
> Sorry, I know this maybe be unintentional, but comments like this
> make me somewhat angry.
It wa
On Mon, 2007-05-28 at 12:38 +0100, Michael-Luke Jones wrote:
> On 28 May 2007, at 12:24, Kay Sievers wrote:
>
> > A driver for a bootup-critical device like this should just never
> > release the firmware after the first load. There is absolutely no
> > point
> > in doing that.
>
> Bogus argume
> This functionality should also be written into the firmware-class
> (and this fact *is* acknowledged in the sparse documentation).
Feel free to submit documentation improvements.
Pavel
--
(english) http://www.livejourna
On 28 May 2007, at 12:24, Kay Sievers wrote:
A driver for a bootup-critical device like this should just never
release the firmware after the first load. There is absolutely no
point
in doing that.
Bogus argument: is a USB-Ethernet device which needs firmware loading
boot-up critical? Not
On Mon 2007-05-28 13:24:53, Kay Sievers wrote:
> On Mon, 2007-05-28 at 13:15 +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > > > What exactly is the problem we see here? The timeout of the
> > > > > > firmware loader?
> > > > > > What goes wrong with frozen userspace, usually there is only a
> >
On Mon, 2007-05-28 at 13:15 +0200, Pavel Machek wrote:
> Hi!
>
> > > > > What exactly is the problem we see here? The timeout of the firmware
> > > > > loader?
> > > > > What goes wrong with frozen userspace, usually there is only a netlink
> > > > > message sent from the kernel, which should be
On Monday, 28 May 2007 13:15, Pavel Machek wrote:
> Hi!
>
> > > > > What exactly is the problem we see here? The timeout of the firmware
> > > > > loader?
> > > > > What goes wrong with frozen userspace, usually there is only a netlink
> > > > > message sent from the kernel, which should be recei
On Monday, 28 May 2007 10:30, Nigel Cunningham wrote:
> Hi.
>
> On Sun, 2007-05-27 at 23:45 +0200, Rafael J. Wysocki wrote:
> > On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
> > > On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki <[EMAIL PROT
Hi!
> > > > What exactly is the problem we see here? The timeout of the firmware
> > > > loader?
> > > > What goes wrong with frozen userspace, usually there is only a netlink
> > > > message sent from the kernel, which should be received and handled
> > > > just fine when userspace is running ag
Now a technical rather than emotional response...
On 28 May 2007, at 10:06, Kay Sievers wrote:
At device driver load, firmware loading must be asynchronous. This is
because device driver init can occur before userspace runs and
registers a hotplug/uevent event handler. If device use is attempte
On 28 May 2007, at 10:06, Kay Sievers wrote:
The underlying issue are the driver authors, that's not so easy to
fix. :)
Sorry, I know this maybe be unintentional, but comments like this
make me somewhat angry.
If there is no decent documentation as to how to do it the right way
(tm), how
On Mon, 2007-05-28 at 09:48 +0100, Michael-Luke Jones wrote:
> On 28 May 2007, at 08:43, Rafael J. Wysocki wrote:
>
> >> Seems, that's just the broken synchronous firmware loading interface
> >> with the useless timeout handling. The nowait version of the same
> >> loader
> >> doesn't time out,
On 28 May 2007, at 08:43, Rafael J. Wysocki wrote:
Seems, that's just the broken synchronous firmware loading interface
with the useless timeout handling. The nowait version of the same
loader
doesn't time out, and should not have that problem. The sync version
should be removed from the kern
Hi.
On Sun, 2007-05-27 at 23:45 +0200, Rafael J. Wysocki wrote:
> On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
> > On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > >
> > > Use a hibernation and suspend notifier to dis
On Monday, 28 May 2007 00:16, Kay Sievers wrote:
> On Sun, 2007-05-27 at 23:04 +0100, Matthew Garrett wrote:
> > On Sun, May 27, 2007 at 11:49:30PM +0200, Kay Sievers wrote:
> >
> > > What exactly is the problem we see here? The timeout of the firmware
> > > loader?
> > > What goes wrong with fro
On Monday, 28 May 2007 00:01, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 11:45:03PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
> > > If we remove process freezing in STR, this should just work[1] without the
> > > need to complicate things.
> >
On Sun, 2007-05-27 at 23:04 +0100, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 11:49:30PM +0200, Kay Sievers wrote:
>
> > What exactly is the problem we see here? The timeout of the firmware loader?
> > What goes wrong with frozen userspace, usually there is only a netlink
> > message sent fr
On Sun, May 27, 2007 at 11:49:30PM +0200, Kay Sievers wrote:
> What exactly is the problem we see here? The timeout of the firmware loader?
> What goes wrong with frozen userspace, usually there is only a netlink
> message sent from the kernel, which should be received and handled
> just fine when
On Sun, May 27, 2007 at 11:45:03PM +0200, Rafael J. Wysocki wrote:
> On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
> > If we remove process freezing in STR, this should just work[1] without the
> > need to complicate things.
>
> Under the (optimistic, IMO) assumption that the relevant user
On Sunday, 27 May 2007 23:49, Kay Sievers wrote:
> On 5/27/07, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > >
> > > Use a hibernation and suspend notifier to disable the firmwa
On 5/27/07, Matthew Garrett <[EMAIL PROTECTED]> wrote:
On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Use a hibernation and suspend notifier to disable the firmware requesting
> mechanism before a hibernation/suspend and enable
On Sunday, 27 May 2007 22:45, Michael-Luke Jones wrote:
> On 27 May 2007, at 21:31, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Use a hibernation and suspend notifier to disable the firmware
> > requesting
> > mechanism before a hibernation/suspend and enab
On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Use a hibernation and suspend notifier to disable the firmware requesting
> > mechanism before a hibernation/suspend and
On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Use a hibernation and suspend notifier to disable the firmware requesting
> mechanism before a hibernation/suspend and enable it after the operation.
This avoids the problem of .re
On 27 May 2007, at 21:31, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Use a hibernation and suspend notifier to disable the firmware
requesting
mechanism before a hibernation/suspend and enable it after the
operation.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTE
52 matches
Mail list logo
