Re: [PATCH 1/2] spi/mmc_spi: SPI bus locking API, using mutex

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Wed, Feb 17, 2010 at 2:41 PM, Mike Frysinger <vapier.adi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Feb 17, 2010 at 16:07, Grant Likely wrote:
>> Also, even if I agreed with the premise that a cookie is needed for
>> deciding who can use the bus when locked, it is still a good idea to
>> use a different API when working with a locked bus.  Locking issues
>> are subtle, and driver authors *must understand what they are doing*.
>> Using a different API for talking to a locked bus is one of the things
>> that makes absolute sense to make sure that drivers know which regions
>> have the bus locked, and which do not.
>
> these sort of statements are always made yet it doesnt seem to prevent
> bugs.  of course people *should know what they're doing*, but
> *reality* is that people make mistakes and bugs get merged all the
> time.  a little proactive protection goes a long way.  i dont think
> adding a cookie would increase overhead all that much.

Heh.  Alright.  Then I think I'd like to see a follow-on patch that
adds the cookie checking so that it can be reviewed independently of
all the locking additions.

Cheers,
g.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev