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
24 matches
Mail list logo
