Re: FYI: device_suspend(...) in kernel_power_off().

2005-08-10 Thread Pavel Machek
Hi! > >> > Code is not ready now => it can never be fixed? Thats quite a strange > >> > conclusion to make. > >> > >> It seems there is an fundamental incompatibility with ACPI power off. > >> As best as I can tell the normal case of device_suspend(PMSG_SUSPEND) > >> works reasonably well in 2.6.

Re: FYI: device_suspend(...) in kernel_power_off().

2005-08-09 Thread Nigel Cunningham
Hi. On Wed, 2005-08-10 at 03:25, Eric W. Biederman wrote: > Pavel Machek <[EMAIL PROTECTED]> writes: > > > Hi! > > > >> >> There as been a fair amount of consensus that calling > >> >> device_suspend(...) in the reboot path was inappropriate now, because > >> >> the device suspend code was too im

Re: FYI: device_suspend(...) in kernel_power_off().

2005-08-09 Thread Eric W. Biederman
Pavel Machek <[EMAIL PROTECTED]> writes: > Hi! > >> >> There as been a fair amount of consensus that calling >> >> device_suspend(...) in the reboot path was inappropriate now, because >> >> the device suspend code was too immature. With this latest >> >> piece of evidence it seems to me that in

Re: FYI: device_suspend(...) in kernel_power_off().

2005-08-07 Thread Pavel Machek
Hi! > >> There as been a fair amount of consensus that calling > >> device_suspend(...) in the reboot path was inappropriate now, because > >> the device suspend code was too immature. With this latest > >> piece of evidence it seems to me that introducing device_suspend(...) > >> in kernel_powe

Re: FYI: device_suspend(...) in kernel_power_off().

2005-08-07 Thread Eric W. Biederman
Pavel Machek <[EMAIL PROTECTED]> writes: > Hi! > >> There as been a fair amount of consensus that calling >> device_suspend(...) in the reboot path was inappropriate now, because >> the device suspend code was too immature. With this latest >> piece of evidence it seems to me that introducing de

Re: FYI: device_suspend(...) in kernel_power_off().

2005-08-07 Thread Pavel Machek
Hi! > There as been a fair amount of consensus that calling > device_suspend(...) in the reboot path was inappropriate now, because > the device suspend code was too immature. With this latest > piece of evidence it seems to me that introducing device_suspend(...) > in kernel_power_off, kernel_h