+327,11 @@ struct platform_hibernation_ops {
> > > > };
> > > >
> > > > #ifdef CONFIG_HIBERNATION
> > > > +
> > > > +/* HMAC Algorithm of Hibernate Signature */
> > > > +#define SWSUSP_HMAC"hmac(sha1)"
>
On Tue, Jul 28, 2015 at 02:35:23PM +0200, Pavel Machek wrote:
> Typo in patch subject.
>
> > And for earsing footbprints, the codes in this patch remove setup
>
> And two typos here.
>
Sorry for subject and above typos, I will fix it.
Thanks.
> > data that ca
On Thu, Jul 30, 2015 at 05:30:09PM +0100, Matt Fleming wrote:
> On Thu, 2015-07-16 at 22:25 +0800, Lee, Chun-Yi wrote:
> > For forwarding swsusp key from EFI stub to boot kernel, this patch
> > allocates setup data for carrying swsusp key, size and the status
> > of efi opera
cd2a48 100644
> > > --- a/include/linux/suspend.h
> > > +++ b/include/linux/suspend.h
> > > @@ -327,6 +327,11 @@ struct platform_hibernation_ops {
> > > };
> > >
> > > #ifdef CONFIG_HIBERNATION
> > > +
> > > +/
@@ struct platform_hibernation_ops {
> > };
> >
> > #ifdef CONFIG_HIBERNATION
> > +
> > +/* HMAC Algorithm of Hibernate Signature */
> > +#define SWSUSP_HMAC "hmac(sha1)"
> > +#define SWSUSP_DIGEST_SIZE 20
>
> I'd replace SW
+327,11 @@ struct platform_hibernation_ops {
};
#ifdef CONFIG_HIBERNATION
+
+/* HMAC Algorithm of Hibernate Signature */
+#define SWSUSP_HMAChmac(sha1)
+#define SWSUSP_DIGEST_SIZE 20
I'd replace SWSUSP with HIBERNATION here, and pretty much
On Thu, Jul 30, 2015 at 05:30:09PM +0100, Matt Fleming wrote:
On Thu, 2015-07-16 at 22:25 +0800, Lee, Chun-Yi wrote:
For forwarding swsusp key from EFI stub to boot kernel, this patch
allocates setup data for carrying swsusp key, size and the status
of efi operating.
Signed-off-by: Lee
On Tue, Jul 28, 2015 at 02:35:23PM +0200, Pavel Machek wrote:
Typo in patch subject.
And for earsing footbprints, the codes in this patch remove setup
And two typos here.
Sorry for subject and above typos, I will fix it.
Thanks.
data that carried swsusp key, and clean the memory
+
+/* HMAC Algorithm of Hibernate Signature */
+#define SWSUSP_HMAC hmac(sha1)
+#define SWSUSP_DIGEST_SIZE 20
I'd replace SWSUSP with HIBERNATION here, and pretty much everywhere.
SWSUSP is shorter than HIBERNATION, and there have some codes in hibernate
SWSUSP_HMAChmac(sha1)
+#define SWSUSP_DIGEST_SIZE 20
I'd replace SWSUSP with HIBERNATION here, and pretty much everywhere.
SWSUSP is shorter than HIBERNATION, and there have some codes in hibernate
are also using swsusp. I still want to use it.
Thanks a lot!
Joey Lee
On Thu, 2015-07-16 at 22:25 +0800, Lee, Chun-Yi wrote:
> For forwarding swsusp key from EFI stub to boot kernel, this patch
> allocates setup data for carrying swsusp key, size and the status
> of efi operating.
>
> Signed-off-by: Lee, Chun-Yi
> ---
> arch/x86/boot/compres
On Thu, 2015-07-16 at 22:25 +0800, Lee, Chun-Yi wrote:
For forwarding swsusp key from EFI stub to boot kernel, this patch
allocates setup data for carrying swsusp key, size and the status
of efi operating.
Signed-off-by: Lee, Chun-Yi j...@suse.com
---
arch/x86/boot/compressed/eboot.c
Typo in patch subject.
> And for earsing footbprints, the codes in this patch remove setup
And two typos here.
> data that carried swsusp key, and clean the memory space that
And don't call it swsusp. Please fix globally.
&
WSUSP_HMAC "hmac(sha1)"
> +#define SWSUSP_DIGEST_SIZE 20
I'd replace SWSUSP with HIBERNATION here, and pretty much everywhere.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscr
Typo in patch subject.
And for earsing footbprints, the codes in this patch remove setup
And two typos here.
data that carried swsusp key, and clean the memory space that
And don't call it swsusp. Please fix globally.
+++ b
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -327,6 +327,11 @@ struct platform_hibernation_ops {
};
#ifdef CONFIG_HIBERNATION
+
+/* HMAC Algorithm of Hibernate Signature */
+#define SWSUSP_HMAC hmac(sha1)
+#define SWSUSP_DIGEST_SIZE 20
I'd replace SWSUSP
This patch provides a ioctl for triggering swsusp key re-generating
process. It's allow user call ioctl to raise the flag of key re-generating.
Kernel writes a flag to a efi runtime variable, the GUID is
S4SignKeyRegen-fe141863-c070-478e-b8a3-878a5dc9ef21, then EFI stub will
re-generates swsusp
Add handler to parse the setup data that carrying swsusp key, it
reserves swsusp key by memblock then copies key to a allocated page
in later initcall stage.
And for earsing footbprints, the codes in this patch remove setup
data that carried swsusp key, and clean the memory space that
reserved
The HMAC key should only resides in kernel memory space but not leak
to outside. To avoid including swsusp key in hibernate snapshot image,
this patch adds the checking block in the code for asking saveable
pages to make sure the key page should not marked as saveable.
Signed-off-by: Lee, Chun-Yi
For forwarding swsusp key from EFI stub to boot kernel, this patch
allocates setup data for carrying swsusp key, size and the status
of efi operating.
Signed-off-by: Lee, Chun-Yi
---
arch/x86/boot/compressed/eboot.c | 29 +
arch/x86/include/uapi/asm/bootparam.h
Using HMAC-SHA1 to be the HMAC algorithm of signing hibernate
snapshot image. The digest size of HMAC-SHA1 is 160 bits (20 bytes),
this size will be also applied to the length of HMAC key.
In addition, add HIBERNATE_VERIFICATION kernel config.
Signed-off-by: Lee, Chun-Yi
---
For forwarding swsusp key from EFI stub to boot kernel, this patch
allocates setup data for carrying swsusp key, size and the status
of efi operating.
Signed-off-by: Lee, Chun-Yi j...@suse.com
---
arch/x86/boot/compressed/eboot.c | 29 +
arch/x86/include/uapi/asm
The HMAC key should only resides in kernel memory space but not leak
to outside. To avoid including swsusp key in hibernate snapshot image,
this patch adds the checking block in the code for asking saveable
pages to make sure the key page should not marked as saveable.
Signed-off-by: Lee, Chun-Yi
This patch provides a ioctl for triggering swsusp key re-generating
process. It's allow user call ioctl to raise the flag of key re-generating.
Kernel writes a flag to a efi runtime variable, the GUID is
S4SignKeyRegen-fe141863-c070-478e-b8a3-878a5dc9ef21, then EFI stub will
re-generates swsusp
Using HMAC-SHA1 to be the HMAC algorithm of signing hibernate
snapshot image. The digest size of HMAC-SHA1 is 160 bits (20 bytes),
this size will be also applied to the length of HMAC key.
In addition, add HIBERNATE_VERIFICATION kernel config.
Signed-off-by: Lee, Chun-Yi j...@suse.com
---
Add handler to parse the setup data that carrying swsusp key, it
reserves swsusp key by memblock then copies key to a allocated page
in later initcall stage.
And for earsing footbprints, the codes in this patch remove setup
data that carried swsusp key, and clean the memory space that
reserved
On Tue 2014-05-06 13:01:56, Pali Roh?r wrote:
> System can have mmaped also character devices (e.g dri devices by X) or
> deleted
> files. Running cat on character devices is really bad idea (system can hang)
> so
> run cat only on regular files. Also mmaped files can have spaces in filenames.
>
On Tue 2014-05-06 13:01:56, Pali Roh?r wrote:
System can have mmaped also character devices (e.g dri devices by X) or
deleted
files. Running cat on character devices is really bad idea (system can hang)
so
run cat only on regular files. Also mmaped files can have spaces in filenames.
System can have mmaped also character devices (e.g dri devices by X) or deleted
files. Running cat on character devices is really bad idea (system can hang) so
run cat only on regular files. Also mmaped files can have spaces in filenames.
Signed-off-by: Pali Rohár
---
System can have mmaped also character devices (e.g dri devices by X) or deleted
files. Running cat on character devices is really bad idea (system can hang) so
run cat only on regular files. Also mmaped files can have spaces in filenames.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
Michael Tokarev wrote:
> Rafael J. Wysocki wrote:
[]
>> I guess it's a special variation of
>> http://bugzilla.kernel.org/show_bug.cgi?id=9528
>>
>> Please try to hibernate in the shutdown mode (ie. echo
>> "shutdown" into /sys/power/disk before hibernation).
[yes it works with shutdown...]
> In
Rafael J. Wysocki wrote:
> On Friday, 1 of February 2008, Michael Tokarev wrote:
[]
>> no_console_suspend it is. Tried that, the "S|" thing is still
>> here, but instead of "Suspending console(s)" it now shows
>> progress of suspending other devices. The end result is
>> the same - finally it
On Fri 2008-02-01 13:16:08, Michael Tokarev wrote:
> Pavel Machek wrote:
> > On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
> []
> >> With 2.6.24, it tries to suspend, saves pages to disk,
> >> when prints this:
> >>
> >> ..Saving pages... done.
> >> Sl
>
> It's actually "S|", not "Sl".
>
>
On Friday, 1 of February 2008, Michael Tokarev wrote:
> Pavel Machek wrote:
> > On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
> []
> >> With 2.6.24, it tries to suspend, saves pages to disk,
> >> when prints this:
> >>
> >> ..Saving pages... done.
> >> Sl
>
> It's actually "S|", not "Sl".
>
Pavel Machek wrote:
> On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
[]
>> With 2.6.24, it tries to suspend, saves pages to disk,
>> when prints this:
>>
>> ..Saving pages... done.
>> Sl
It's actually "S|", not "Sl".
>> Suspending console(s)
>> _
>>
>> At this point, nothing more happens.
Pavel Machek wrote:
On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
[]
With 2.6.24, it tries to suspend, saves pages to disk,
when prints this:
..Saving pages... done.
Sl
It's actually S|, not Sl.
Suspending console(s)
_
At this point, nothing more happens. It does not
react to
On Friday, 1 of February 2008, Michael Tokarev wrote:
Pavel Machek wrote:
On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
[]
With 2.6.24, it tries to suspend, saves pages to disk,
when prints this:
..Saving pages... done.
Sl
It's actually S|, not Sl.
Suspending console(s)
On Fri 2008-02-01 13:16:08, Michael Tokarev wrote:
Pavel Machek wrote:
On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
[]
With 2.6.24, it tries to suspend, saves pages to disk,
when prints this:
..Saving pages... done.
Sl
It's actually S|, not Sl.
Suspending console(s)
_
Rafael J. Wysocki wrote:
On Friday, 1 of February 2008, Michael Tokarev wrote:
[]
no_console_suspend it is. Tried that, the S| thing is still
here, but instead of Suspending console(s) it now shows
progress of suspending other devices. The end result is
the same - finally it stops and sits
On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
> Since I upgraded from 2.6.23 to 2.6.24, suspend to
> disk does not work anymore on this machine. I'm
> trying to debug this now, for several hours already,
> without much luck so far.
>
> The machine is based on AMD X2-64 (BE-2400) CPU and
>
Since I upgraded from 2.6.23 to 2.6.24, suspend to
disk does not work anymore on this machine. I'm
trying to debug this now, for several hours already,
without much luck so far.
The machine is based on AMD X2-64 (BE-2400) CPU and
NVidia MCP51PV (GeForce 6150/NForce 430) chipset.
Up until 2.6.23
Since I upgraded from 2.6.23 to 2.6.24, suspend to
disk does not work anymore on this machine. I'm
trying to debug this now, for several hours already,
without much luck so far.
The machine is based on AMD X2-64 (BE-2400) CPU and
NVidia MCP51PV (GeForce 6150/NForce 430) chipset.
Up until 2.6.23
On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
Since I upgraded from 2.6.23 to 2.6.24, suspend to
disk does not work anymore on this machine. I'm
trying to debug this now, for several hours already,
without much luck so far.
The machine is based on AMD X2-64 (BE-2400) CPU and
NVidia
On Saturday, 12 of January 2008, Rene Herman wrote:
> On 12-01-08 16:21, Pierre Ossman wrote:
>
> > Ah, sorry. It was a different thread. Look for a mail with the subject
> > "PNP: do not stop/start devices in suspend/resume path" in the LKML och
> > linux-pm archives.
>
> Right, and I see
On Saturday, 12 of January 2008, Rene Herman wrote:
> On 12-01-08 12:12, Pierre Ossman wrote:
>
> > On Sat, 12 Jan 2008 02:23:27 +0100
> > Rene Herman <[EMAIL PROTECTED]> wrote:
> >
> >> Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
> >> Ondrej after hibernation due
On 12-01-08 16:21, Pierre Ossman wrote:
Ah, sorry. It was a different thread. Look for a mail with the subject
"PNP: do not stop/start devices in suspend/resume path" in the LKML och
linux-pm archives.
Right, and I see that the removal of start/stop is already in -mm. That's
not going to
On Saturday 12 January 2008 16:21:50 Pierre Ossman wrote:
> On Sat, 12 Jan 2008 14:39:47 +0100
>
> Rene Herman <[EMAIL PROTECTED]> wrote:
> > On 12-01-08 12:12, Pierre Ossman wrote:
> > > I'm a bit confused here. Bjorn Helgaas wanted to remove the
> > > pnp_start/stop_dev() calls completely, and
On Sat, 12 Jan 2008 14:39:47 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 12-01-08 12:12, Pierre Ossman wrote:
>
> > I'm a bit confused here. Bjorn Helgaas wanted to remove the
> > pnp_start/stop_dev() calls completely, and you want them called all the
> > time. :)
>
> Wanted where?
On 12-01-08 12:12, Pierre Ossman wrote:
On Sat, 12 Jan 2008 02:23:27 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test
triggering in pnp_bus_resume()
On Sat, 12 Jan 2008 02:23:27 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
>
> Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
> Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test
> triggering in pnp_bus_resume() and keeping the card in a suspended
On Sat, 12 Jan 2008 02:23:27 +0100
Rene Herman [EMAIL PROTECTED] wrote:
Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test
triggering in pnp_bus_resume() and keeping the card in a suspended state.
On 12-01-08 12:12, Pierre Ossman wrote:
On Sat, 12 Jan 2008 02:23:27 +0100
Rene Herman [EMAIL PROTECTED] wrote:
Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test
triggering in pnp_bus_resume() and
On Sat, 12 Jan 2008 14:39:47 +0100
Rene Herman [EMAIL PROTECTED] wrote:
On 12-01-08 12:12, Pierre Ossman wrote:
I'm a bit confused here. Bjorn Helgaas wanted to remove the
pnp_start/stop_dev() calls completely, and you want them called all the
time. :)
Wanted where? Haven't seen a
On Saturday 12 January 2008 16:21:50 Pierre Ossman wrote:
On Sat, 12 Jan 2008 14:39:47 +0100
Rene Herman [EMAIL PROTECTED] wrote:
On 12-01-08 12:12, Pierre Ossman wrote:
I'm a bit confused here. Bjorn Helgaas wanted to remove the
pnp_start/stop_dev() calls completely, and you want them
On 12-01-08 16:21, Pierre Ossman wrote:
Ah, sorry. It was a different thread. Look for a mail with the subject
PNP: do not stop/start devices in suspend/resume path in the LKML och
linux-pm archives.
Right, and I see that the removal of start/stop is already in -mm. That's
not going to
On Saturday, 12 of January 2008, Rene Herman wrote:
On 12-01-08 16:21, Pierre Ossman wrote:
Ah, sorry. It was a different thread. Look for a mail with the subject
PNP: do not stop/start devices in suspend/resume path in the LKML och
linux-pm archives.
Right, and I see that the
On Saturday, 12 of January 2008, Rene Herman wrote:
On 12-01-08 12:12, Pierre Ossman wrote:
On Sat, 12 Jan 2008 02:23:27 +0100
Rene Herman [EMAIL PROTECTED] wrote:
Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for
Ondrej after hibernation due to the
oesn't change that suspend/resume wouldn't seem
to have any business testing the flag.
As reported by Ondrej Zary for snd-cs4236, ALSA driven ISAPnP
cards don't survive swsusp hibernation with the resume skipping
setting the resources due to testing the flag -- the sam
On Friday 11 January 2008 15:21:55 Rene Herman wrote:
> On 11-01-08 08:01, Pierre Ossman wrote:
> > On Fri, 11 Jan 2008 02:19:07 +0100
> >
> > Rene Herman <[EMAIL PROTECTED]> wrote:
> >> I see a PnP resume _consists_ of setting the resources so I can see the
> >> test implementation wise, but yes,
On 11-01-08 08:01, Pierre Ossman wrote:
On Fri, 11 Jan 2008 02:19:07 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
I see a PnP resume _consists_ of setting the resources so I can see the test
implementation wise, but yes, conceptually it seems this test shouldn't be
present. So just like the
On 11-01-08 08:01, Pierre Ossman wrote:
On Fri, 11 Jan 2008 02:19:07 +0100
Rene Herman [EMAIL PROTECTED] wrote:
I see a PnP resume _consists_ of setting the resources so I can see the test
implementation wise, but yes, conceptually it seems this test shouldn't be
present. So just like the
On Friday 11 January 2008 15:21:55 Rene Herman wrote:
On 11-01-08 08:01, Pierre Ossman wrote:
On Fri, 11 Jan 2008 02:19:07 +0100
Rene Herman [EMAIL PROTECTED] wrote:
I see a PnP resume _consists_ of setting the resources so I can see the
test implementation wise, but yes, conceptually
change that suspend/resume wouldn't seem
to have any business testing the flag.
As reported by Ondrej Zary for snd-cs4236, ALSA driven ISAPnP
cards don't survive swsusp hibernation with the resume skipping
setting the resources due to testing the flag -- the same test
On Fri, 11 Jan 2008 02:19:07 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
>
> I see a PnP resume _consists_ of setting the resources so I can see the test
> implementation wise, but yes, conceptually it seems this test shouldn't be
> present. So just like the attached then?
>
> Pierre, what
On 10-01-08 08:58, Jaroslav Kysela wrote:
On Thu, 10 Jan 2008, Rene Herman wrote:
On 09-01-08 23:43, Ondrej Zary wrote:
Jaroslav -- in your role as ISA-PnP maintainer and Bjorn, in yours as
having been foollish enough to touch PnP recently:
as hibernation (swsusp) started to work with my
On 10-01-08 08:58, Jaroslav Kysela wrote:
On Thu, 10 Jan 2008, Rene Herman wrote:
On 09-01-08 23:43, Ondrej Zary wrote:
Jaroslav -- in your role as ISA-PnP maintainer and Bjorn, in yours as
having been foollish enough to touch PnP recently:
as hibernation (swsusp) started to work with my
On Thu, 10 Jan 2008, Rene Herman wrote:
> On 09-01-08 23:43, Ondrej Zary wrote:
>
> Jaroslav -- in your role as ISA-PnP maintainer and Bjorn, in yours as
> having been foollish enough to touch PnP recently:
>
> > as hibernation (swsusp) started to work with my CPU, I
On 09-01-08 23:43, Ondrej Zary wrote:
Jaroslav -- in your role as ISA-PnP maintainer and Bjorn, in yours as having
been foollish enough to touch PnP recently:
as hibernation (swsusp) started to work with my CPU, I found that my Turtle
Beach Malibu stops working after resume from hibernation
Hello,
as hibernation (swsusp) started to work with my CPU, I found that my Turtle
Beach Malibu stops working after resume from hibernation. It's caused by fact
that the card is not enabled on the pnp layer during resume - and thus card
registers are inaccessible (reads return FFs, writes go
Hello,
as hibernation (swsusp) started to work with my CPU, I found that my Turtle
Beach Malibu stops working after resume from hibernation. It's caused by fact
that the card is not enabled on the pnp layer during resume - and thus card
registers are inaccessible (reads return FFs, writes go
On 09-01-08 23:43, Ondrej Zary wrote:
Jaroslav -- in your role as ISA-PnP maintainer and Bjorn, in yours as having
been foollish enough to touch PnP recently:
as hibernation (swsusp) started to work with my CPU, I found that my Turtle
Beach Malibu stops working after resume from hibernation
This makes the altivec code in swsusp_32.S depend on CONFIG_ALTIVEC to
avoid build failures for systems that don't have altivec. I'm not sure
whether the code will actually work for other systems, but it was merged
for just ppc32 rather than powermac a very long time ago.
Signed-off-by: Johannes
This makes the altivec code in swsusp_32.S depend on CONFIG_ALTIVEC to
avoid build failures for systems that don't have altivec. I'm not sure
whether the code will actually work for other systems, but it was merged
for just ppc32 rather than powermac a very long time ago.
Signed-off-by: Johannes
On Wednesday, 17 October 2007 05:44, Qi Yong wrote:
> On Wed, Oct 17, 2007 at 10:46:12AM +0800, Qi Yong wrote:
> > On 12/05/2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > On Fri, 11 May 2007, Rafael J. Wysocki wrote:
[--snip--]
>
> please apply.
>
> Signed-off-by: Qi Yong <[EMAIL
On Wednesday, 17 October 2007 05:44, Qi Yong wrote:
On Wed, Oct 17, 2007 at 10:46:12AM +0800, Qi Yong wrote:
On 12/05/2007, Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 11 May 2007, Rafael J. Wysocki wrote:
[--snip--]
please apply.
Signed-off-by: Qi Yong [EMAIL PROTECTED]
---
With
On Wed, Oct 17, 2007 at 10:46:12AM +0800, Qi Yong wrote:
> On 12/05/2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Fri, 11 May 2007, Rafael J. Wysocki wrote:
> > >
> > > We're working on fixing the breakage, but currently it's difficult,
> > > because
> > > none of my testboxes
On Wed, 17 Oct 2007, Qi Yong wrote:
>
> The key point is "fall back to shutdown _only_ if !ops, otherwise
> don't touch hibernation_mode". And that solves my problem.
Please, when resurrecting a five-month-old discussion, give more of the
old context.
I don't know about anybody else, but I
On 12/05/2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 11 May 2007, Rafael J. Wysocki wrote:
> >
> > We're working on fixing the breakage, but currently it's difficult, because
> > none of my testboxes has problems with the 'platform' hibernation and I
> > cannot reproduce the
On 14/05/2007, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
> On Fri, May 11, 2007 at 03:51:38PM -0700, Linus Torvalds wrote:
> >
> >
> > On Fri, 11 May 2007, Rafael J. Wysocki wrote:
> > >
> > > Just to clarify, the change in question isn't new. It was introduced by
> > > the
> > > commit
On 14/05/2007, Stefan Seyfried [EMAIL PROTECTED] wrote:
On Fri, May 11, 2007 at 03:51:38PM -0700, Linus Torvalds wrote:
On Fri, 11 May 2007, Rafael J. Wysocki wrote:
Just to clarify, the change in question isn't new. It was introduced by
the
commit
On 12/05/2007, Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 11 May 2007, Rafael J. Wysocki wrote:
We're working on fixing the breakage, but currently it's difficult, because
none of my testboxes has problems with the 'platform' hibernation and I
cannot reproduce the reported issues.
On Wed, 17 Oct 2007, Qi Yong wrote:
The key point is fall back to shutdown _only_ if !ops, otherwise
don't touch hibernation_mode. And that solves my problem.
Please, when resurrecting a five-month-old discussion, give more of the
old context.
I don't know about anybody else, but I get
On Wed, Oct 17, 2007 at 10:46:12AM +0800, Qi Yong wrote:
On 12/05/2007, Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 11 May 2007, Rafael J. Wysocki wrote:
We're working on fixing the breakage, but currently it's difficult,
because
none of my testboxes has problems with the
On Tue, 14 Aug 2007, Rafael J. Wysocki wrote:
> On Tuesday, 14 August 2007 00:12, Thomas Voegtle wrote:
> > On Mon, 13 Aug 2007, Rafael J. Wysocki wrote:
> >
> > > On Monday, 13 August 2007 23:31, Thomas Voegtle wrote:
> > > > On Mon, 13 Aug 2007, Rafael J. Wysocki wrote:
> > > >
> > > > > On
On Tue, 14 Aug 2007, Rafael J. Wysocki wrote:
On Tuesday, 14 August 2007 00:12, Thomas Voegtle wrote:
On Mon, 13 Aug 2007, Rafael J. Wysocki wrote:
On Monday, 13 August 2007 23:31, Thomas Voegtle wrote:
On Mon, 13 Aug 2007, Rafael J. Wysocki wrote:
On Sunday, 12 August 2007
On Wednesday, 15 August 2007 04:51, Kyle Moffett wrote:
> On Aug 14, 2007, at 19:24:30, Dave Jones wrote:
> > On Tue, Aug 14, 2007 at 11:22:37AM -0700, Andrew Morton wrote:
> >> On Tue, 14 Aug 2007 11:15:41 -0700 (PDT) Linus Torvalds
> >> <[EMAIL PROTECTED]> wrote:
> >>> In other words, it would
On Wednesday, 15 August 2007 04:51, Kyle Moffett wrote:
On Aug 14, 2007, at 19:24:30, Dave Jones wrote:
On Tue, Aug 14, 2007 at 11:22:37AM -0700, Andrew Morton wrote:
On Tue, 14 Aug 2007 11:15:41 -0700 (PDT) Linus Torvalds
[EMAIL PROTECTED] wrote:
In other words, it would be much better
On Aug 14, 2007, at 19:24:30, Dave Jones wrote:
On Tue, Aug 14, 2007 at 11:22:37AM -0700, Andrew Morton wrote:
On Tue, 14 Aug 2007 11:15:41 -0700 (PDT) Linus Torvalds
<[EMAIL PROTECTED]> wrote:
In other words, it would be much better to just have per-file
markers, along with some
On Tue, 2007-08-14 at 11:15 -0700, Linus Torvalds wrote:
> In other words, it would be much better to just have per-file markers,
> along with some per-subdirectory stuff or similar.
So that there would be no hot single file, I cut the
MAINTAINER file into single file segments in maintainers/*
On Tue, Aug 14, 2007 at 11:22:37AM -0700, Andrew Morton wrote:
> On Tue, 14 Aug 2007 11:15:41 -0700 (PDT)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > In other words, it would be much better to just have per-file markers,
> > along with some per-subdirectory stuff or similar.
>
>
On Tue, 2007-08-14 at 11:15 -0700, Linus Torvalds wrote:
> Quite frankly, I think the MAINTAINERS file gets a whole lot uglier this
> way.
Me too.
Chopping up the current file is simple.
How about keeping the whole thing in git?
Please look at thread:
[PATCH] [1/2many] - Find the maintainer(s)
On 08/14/2007 08:15 PM, Linus Torvalds wrote:
Quite frankly, I think the MAINTAINERS file gets a whole lot uglier this
way.
There's also a rather fundamental issue: this will likely make people
touch the MAINTAINERS file *more*, and from a maintenance standpoint, that
is exactly the wrong
On Tue, 14 Aug 2007 11:15:41 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> In other words, it would be much better to just have per-file markers,
> along with some per-subdirectory stuff or similar.
And a `make maintainers' target to pull it all together..
(perhaps we could add a
On Tue, 14 Aug 2007, Joe Perches wrote:
>
> SUSPEND TO RAM:
> P:Pavel Machek
> M:[EMAIL PROTECTED]
> P:Rafael J. Wysocki
> M:[EMAIL PROTECTED]
> L:[EMAIL PROTECTED]
> S:Maintained
> F:Documentation/power/
> F:arch/i386/kernel/acpi/
> F:arch/x86_64/kernel/acpi/
tation/power/
> F:arch/i386/kernel/acpi/
> F:arch/x86_64/kernel/acpi/
> F:arch/x86_64/kernel/suspend.c
> F:drivers/base/power/
> F: kernel/power/
> F:include/linux/suspend.h
> F:include/linux/freezer.h
> F:include/linux/pm.h
> F:include/a
nclude/linux/freezer.h
F: include/linux/pm.h
F: include/asm-*/suspend.h
HIBERNATION (aka Software Suspend, aka swsusp)
P: Pavel Machek
M: [EMAIL PROTECTED]
P: Rafael J. Wysocki
M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
S: Supported
F: Documentation/power
ux/pm.h
F: include/asm-*/suspend.h
(2) suspend
F: Documentation/power/
F: arch/i386/kernel/acpi/
F: arch/x86_64/kernel/acpi/
F: arch/x86_64/kernel/suspend.c
F: drivers/base/power/
F: kernel/power/
F: include/linux/suspend.h
F: include/linux/freezer
suspend to RAM and hibernation would be better?
> >
> > Maybe just collapse the 2 maintainers blocks into one?
No, please don't.
> > HIBERNATION (aka Software Suspend, aka swsusp) and SUSPEND TO RAM:
> > P: Pavel Machek
> > M: [EMAIL PROTECTED]
> > P: Rafael
maintainers blocks into one?
No, please don't.
HIBERNATION (aka Software Suspend, aka swsusp) and SUSPEND TO RAM:
P: Pavel Machek
M: [EMAIL PROTECTED]
P: Rafael J. Wysocki
M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
S: Supported
Then I think it should be Maintained.
No, supported
: arch/x86_64/kernel/suspend.c
F: drivers/base/power/
F: kernel/power/
F: include/linux/suspend.h
F: include/linux/freezer.h
F: include/linux/pm.h
F: include/asm-*/suspend.h
HIBERNATION (aka Software Suspend, aka swsusp) and SUSPEND TO RAM:
P:Pavel Machek
1 - 100 of 1613 matches
Mail list logo
