On Saturday, 12 of January 2008, Greg KH wrote:
> On Fri, Jan 11, 2008 at 10:11:52PM -0500, Alan Stern wrote:
> > On Fri, 11 Jan 2008, Greg KH wrote:
> >
> > > On Fri, Jan 11, 2008 at 04:49:04PM -0800, Andrew Morton wrote:
> >
> > > > err, no. pm-introduce-destroy_suspended_device.patch demolish
On Saturday, 12 of January 2008, Andrew Morton wrote:
> On Fri, 11 Jan 2008 16:46:13 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > The first patch in the series introduces such a mechanism. The remaining
> > > three
> > > patches modify the MSR, x86-64 MCE and cpuid drivers in accorda
On Fri, Jan 11, 2008 at 10:11:52PM -0500, Alan Stern wrote:
> On Fri, 11 Jan 2008, Greg KH wrote:
>
> > On Fri, Jan 11, 2008 at 04:49:04PM -0800, Andrew Morton wrote:
>
> > > err, no. pm-introduce-destroy_suspended_device.patch demolishes
> > > pm-acquire-device-locks-on-suspend-rev-3.patch
> >
On Fri, 11 Jan 2008 22:11:52 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote:
> On Fri, 11 Jan 2008, Greg KH wrote:
>
> > On Fri, Jan 11, 2008 at 04:49:04PM -0800, Andrew Morton wrote:
>
> > > err, no. pm-introduce-destroy_suspended_device.patch demolishes
> > > pm-acquire-device-locks-on-susp
> The real problem is that our current email workflow patterns don't
> provide a standardized way for maintainers to tell when a new patch
> submission is meant to override or replace an earlier submission (or
> even a set of earlier submissions). Does anybody have some suggestions
> for a go
On Fri, 11 Jan 2008, Greg KH wrote:
> On Fri, Jan 11, 2008 at 04:49:04PM -0800, Andrew Morton wrote:
> > err, no. pm-introduce-destroy_suspended_device.patch demolishes
> > pm-acquire-device-locks-on-suspend-rev-3.patch
> >
> > Confused, giving up.
>
> I'm confused too, I have no idea what the
On Fri, Jan 11, 2008 at 04:49:04PM -0800, Andrew Morton wrote:
> On Fri, 11 Jan 2008 16:46:13 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > The first patch in the series introduces such a mechanism. The remaining
> > > three
> > > patches modify the MSR, x86-64 MCE and cpuid drivers i
On Fri, 11 Jan 2008 16:46:13 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > The first patch in the series introduces such a mechanism. The remaining
> > three
> > patches modify the MSR, x86-64 MCE and cpuid drivers in accordance with the
> > above approach.
>
> These patches are a preresui
On Wed, 2 Jan 2008 00:32:44 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> Some device drivers register CPU hotplug notifiers and use them to destroy
> device objects when removing the corresponding CPUs and to create these
> objects
> when adding the CPUs back.
>
> Unfortunately, this i
Hi!
> > > > That way any suspend breakage would be detectable (and bisectable)
> > > > in automated testing - if the resume does not come back after 10-20
> > > > seconds then the test failed.
> > >
> > > Yes, but please note that some systems require user space
> > > manipulations of the grap
On Wednesday 02 January 2008, Ingo Molnar wrote:
>
> then please provide a kernel config option for the new driver to take
> over 10:135 too. There's nothing worse to the adoption of new kernel
> features necessiating user-space attention. I've got several images of
> old distros that i dont wa
* David Brownell <[EMAIL PROTECTED]> wrote:
> > shouldnt we provide a Kconfig way of replacing dev 10:135 with the
> > new driver's 254:0 device? (while keeping all the current modes of
> > operation as well, of course.)
>
> The major number 254 is not statically allocated, ISTR; that should b
* David Brownell <[EMAIL PROTECTED]> wrote:
> I've been trying to make sure the x86 world could realistically switch
> to the RTC framework used by other Linux platforms, hence e.g. the
> util-unix-ng updates, but never assumed there would be no userspace
> changes. After all, userspace was u
On Wed, 02 Jan 2008 10:12:54 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> > > It'd need to have some NTP sync solution for RTC_LIB devices, but
> > > ISTR the gentime stuff still assumes an update_persistent_clock()
> > > that doesn't sleep ... and hence can't be used with I2C based RTCs.
> >
> > It'd need to have some NTP sync solution for RTC_LIB devices, but
> > ISTR the gentime stuff still assumes an update_persistent_clock()
> > that doesn't sleep ... and hence can't be used with I2C based RTCs.
>
> I still believe NTP sync stuff should be done outside of the kernel.
> given the me
On Wed, 02 Jan 2008 09:54:00 -0800
David Bro
> It'd need to have some NTP sync solution for RTC_LIB devices, but
> ISTR the gentime stuff still assumes an update_persistent_clock()
> that doesn't sleep ... and hence can't be used with I2C based RTCs.
I still believe NTP sync stuff should be done
> > > shouldnt we provide a Kconfig way of replacing dev 10:135 with the
> > > new driver's 254:0 device? (while keeping all the current modes of
> > > operation as well, of course.) It's all supposed to be 100% ioctl
> > > ABI compatible with the old driver, right?
> >
> > It's not compatible
(Alessandro Zummo Cc:-ed too -- RTC subsystem maintainer)
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > Well, we have the following test script in the userland suspend
> > package that is supposed to work right now:
> >
> > #!/bin/bash
> > date
> > cd /sys/class/rtc/rtc0
> > echo $(( $(
* Kay Sievers <[EMAIL PROTECTED]> wrote:
> > shouldnt we provide a Kconfig way of replacing dev 10:135 with the
> > new driver's 254:0 device? (while keeping all the current modes of
> > operation as well, of course.) It's all supposed to be 100% ioctl
> > ABI compatible with the old driver, r
On Jan 2, 2008 2:15 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> A stupid question. The old RTC driver is in
> drivers/char/rtc.c, and maps to:
>
> crw-r--r-- 1 root root 10, 135 Oct 25 18:02 /dev/rtc
>
> the new driver is in drivers/rtc/*, and maps to:
>
> crw-r--r-- 1 root root 254, 0 Dec
On Wednesday, 2 of January 2008, Ingo Molnar wrote:
>
> (David Brownell Cc:-ed too)
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > Well, we have the following test script in the userland suspend
> > package that is supposed to work right now:
> >
> > #!/bin/bash
> > date
> > cd /sys/
(David Brownell Cc:-ed too)
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> Well, we have the following test script in the userland suspend
> package that is supposed to work right now:
>
> #!/bin/bash
> date
> cd /sys/class/rtc/rtc0
> echo $(( $(cat since_epoch) + 20 )) > wakealarm
> s2ram
>
On Wednesday, 2 of January 2008, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > Some device drivers register CPU hotplug notifiers and use them to
> > destroy device objects when removing the corresponding CPUs and to
> > create these objects when addin
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Some device drivers register CPU hotplug notifiers and use them to
> destroy device objects when removing the corresponding CPUs and to
> create these objects when adding the CPUs back.
>
> Unfortunately, this is not the right thing to
Hi,
Some device drivers register CPU hotplug notifiers and use them to destroy
device objects when removing the corresponding CPUs and to create these objects
when adding the CPUs back.
Unfortunately, this is not the right thing to do during suspend/hibernation,
since in that cases the CPU hotplu
25 matches
Mail list logo
