Re: Patch: linux-2.5.42/kernel/sys.c - warm reboot should not suspend devices

Eric W. Biederman (ebiederm@xmission.com)
14 Oct 2002 09:28:43 -0600


Eric Blade <eblade@blackmagik.dynup.net> writes:

> Here is where I realize that I've forgotten to CC: the list on all the
> traffic that I keep sending between Eric and Adam. D'oh.
>
>
> On Sun, 2002-10-13 at 20:07, Eric W. Biederman wrote:
> > >
> > > However, I'm not trying to quash what you want to discuss.
> > > I'd be interested in hearing about clarifications and perhaps
> > > extensions of the struct device_driver methods, which I think is what
> > > you're getting at, perhaps here or on linux-hotplug. It's just that,
> > > for this thread, I'm trying to focus on my patch that eliminates the
> > > software suspend on reboot (pros and cons, alternatives to it, etc.).
> >
> > The 2.5.41 variant is below. The bug is reusing the old enumeration value
> > as was previously mentioned.
> >
>
> I tried to submit a fix to this, but the only response I've gotten back
> is that it failed to apply. My original patch excluded the bit from
> device.h that added a new state to the enumeration, and when it got into
> the tree, it got into the tree using the current states that were
> available. My bad.
>
> Eric has already indicated earlier, that Adam's issue is, however, not
> with the changes to drivers/base/power.c but to the changes to the IDE
> driver.

Correct. But when people try to use power management they will see
the bug. SUSPEND_POWER_DOWN (a request for the driver to remove power
from the device) is a very different state from SUSPEND_DETACH (a
request to disassociate the driver from the device). I am not fully
convinced the two cases should be merged.

SUSPEND_POWER_DOWN as defined should actually cause the behavior Adam
was seeing. Which made it doubly interesting.

Will you submit a patch detangling this mess? I believe Adams
only problem was that it did not obviously fix his problem.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/