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

[David Brownell <david-b@pacbell.net>]

> > >+/* Suspend/resume in "struct device_driver" don't really need that
> > >+ * strange third parameter, so we just make it a constant and expect
> > >+ * SPI drivers to ignore it just like most platform drivers do.
> > >+ *
> >
> > So you just ignored my letter on that subject :(
> > The fact that you don't need it doesn't mean that other people won't.
> > The fact that there's no clean way to suspend USB doesn't mean that 
> > there shouldn't be one for SPI.
>
> The third parameter is obsolete and should only be used to select _one_
> of the tree suspend calls you will get.

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.

USB can suspend just fine, thank you, though starting with 2.6.12 some
bugs seem to have crept in; fixes are in the 2.6.15 prepatchces.


> Any additional suspend calls should _not_ create extra usage of this
> parameter.  It's a left over from Pat's first driver model incarnation
> which is specific to the platform device drivers.  (Mainly it exists
> because no one can be bothered to clean it up.)

Most folk who've considered the question would like to see it go away.
Except ... making sure every driver in a few dozen architectures still
builds after removing that parameter is more than the usual amount of
janitorial work!

Progress could start by updating Documentation/driver-model/driver.txt to
say "don't test that parameter", reducing future confusion on this point.

- Dave

-
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/