Re: shared config registers and locking

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> GACK!  Many better engineers than any of us have spent countless hours
> breaking down locks.  A lock takes nearly no space at all, you're not
> proposing to lock any less often, so multiple locks take no less time,
> the only thing you stand to gain by protecting multiple data structures
> with one lock is the possibility of lock contention.  Please reconsider.

Wait wait wait.... I'm perfectly aware of lock contention issues and I'm
not proposing to have a giant lock for everything in the system.

I was proposing something very clearly aimed at configuration type
things that are generally accessed a bit at boot time and then every
time the phase of the moon changes, in which case, it's just a pain to
have to use fine grained locking and one shared lock is plenty enough.

The specific example that made me think about it was some clock control
registers on 4xx that the EMAC driver is whacking every now and then (on
link state change, no lock contention to be worried about here), though
they could be used by other drivers too (or platform code). Since those
registers are a bit different from one 4xx to the next too, and since I
now have a non-4xx platform that needs to use EMAC and has similar clock
control bits I might have to toggle there too, I'm basically ending up
with a global spinlock that I can't precisely define better than "global
clock control lock" ....

Now, what is best there ? To have 4xx expose such a lock and define
precisely what set of registers it covers and require any non-4xx
platform that uses the EMAC driver to provide a similar lock ?
 
Now, you have the right to disagree with me, I was mostly asking what
the mood was about it, I don't have any firm opinion on wether it's a
good or a bad idea just yet... so I count your vote as a "no" :-)

Another approach would be to remove the code from EMAC and have it
instead use the "feature call" thingy to call into platform code to do
the magic clock tweaking (with appropriate locking) but I don't like
much that idea as all 4xx platforms pretty much would have to duplicate
that code, and I prefer keeping some of that magic in the EMAC driver
itself. 

Now, regarding exposing a function or just a spinlock, well, you might
well be right that exposing a spinlock is better, I have no very firm
preference there neither... just a slight bias toward exporting
functions rather than variables.

Ben.