Re: [PATCH/RFC 1/2] simple SPI framework

[Russell King]

On Thu, Oct 06, 2005 at 07:23:48PM +0100, Mark Underwood wrote:
> --- David Brownell <david-b@xxxxxxxxxxx> wrote:
> > Vitaly ... comments from Russell and Pavel both addresses your comments
> > about that obsolete parameter.  What letter?  The one I remember was
> > one responding to Mark Underwood (?) where you complained about issuing
> > three calls for one suspend event.  You can't have it both ways!!
> > Either that parameter should be used in the documented way (call the
> > suspend method three times, one right after another) or it should be used
> > more sanely (parameter is constant.
> 
> Yes, that was in reply to my SPI subsystem patch set (in which Vitaly
> didn't like the fact that I call suspend/resume 3 times) and then in
> the same thread (in answer to David's response of dropping this as he
> didn't think anyone would mind this) Vitaly said that you can't do this.

Vitaly has a problem then.  We must _not_ call suspend three times
just because it has different "levels" - SUSPEND_DISABLE,
SUSPEND_SAVE_STATE and SUSPEND_POWER_DOWN.

As I've said earlier in the thread, the only reason these exist is
because no one has gone to the effort of cleaning up the crap left
behind from PM version 1 for the platform devices.

When PM v2 happened, I just hacked the platform device drivers to
work with this new model.  So please consider the three argument
suspend callback a legacy feature and if you're going to use it,
call it exactly once.

And please document that this is the case for your bus type, and
that the "level" argument is meaningless.  Better still, please
do not use the device_driver suspend/resume pointers at all.  Same
argument applies - only platform devices use them, and these should
eventually be killed off.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/