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
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
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 accordance with
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 demolishes
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
> > >
> 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
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
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
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
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
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 is not the
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 proper
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 good
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
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
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
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 graphics adapter for
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
* 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
* 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
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
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,
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
(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
* 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
* 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 do
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 adding the CPUs
(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
date
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/class/rtc/rtc0
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 12 02:30
* 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, right?
(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 $(( $(cat since_epoch)
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 enough to fake
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
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 mean
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.
I still
* 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 using
* 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 be
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 want
46 matches
Mail list logo
