On Wed, Nov 27, 2013 at 08:00:00PM +0100, Martin Sperl wrote:

> Still I believe "compiling" the flags once in the setup code and then 
> just using them should avoid wasting some cpu cycles in this driver.

Yeah, that's fine - part of what I'm doing when I review patches is
reviewing the changelog against the code to help make sure that the
change is doing what it's supposed to (this is one way to spot
unintended side effects) so the problem was that the two didn't tie
together more than anything else.

> > That's just never going to be a sane thing to change on the fly though.
> > Changes to things that don't affect /CS are more interesting here.

> I believe we need to state the above fact explicitly that this has
> the potential for a race condition (maybe other flags as well) in case 
> no bus-lock is held and thought should be given to that during the
> design.

For the API it's basically just saying that it should take effect at the
start of the next operation (ie, any in flight operations will be fine).
There may be some setups in which changing /CS makes sense, for example
with higher level coordination going on or a design requirement that the
bus isn't shared I guess.  But documentation updates are welcome!

Attachment: signature.asc
Description: Digital signature

Reply via email to