shared config registers and locking

[Eugene Surovegin]

On Wed, Dec 06, 2006 at 04:16:29PM +1100, Benjamin Herrenschmidt wrote:
> > On my work in porting emac over to arch/powerpc (and make it work on SMP
> > platforms since there's at least one coming, possibly too), I ended up
> > with a problem with things like the workarounds for the EMAC loss of RX
> > clock (CONFIG_IBM_EMAC_PHY_RX_CLK_FIX) that I think uncovers a more
> > generic problem about access global system wide configuration registers
> > in a race free way.
> 
> BTW, Eugene, in the specific case of this RX clock problem causing the
> transmitter to stall...
> 
> I've had this problem with sungem in the past and a few other drivers
> have to deal with it as well. The general approach seems to be a bit
> different, and if you think it can work for EMAC, I'll implement it that
> way in the driver I'm working on.
> 
> The idea is rather to try to find magic bits to force the chip clocks on
> when there is no link, simply ack the fact that when there is no link,
> nothing gets transmitted and thus ignore tx timeouts. Doing
> netif_carrier_off() (which is the right thing to do when the link is
> down anyway) should cause the net stack to ignore them.
> 
> Now, some chips (like GEM) have a problem recovering when the link
> finally comes back up and thus can have the transmitter stuck. That's
> why drivers like this will simply reset the TX side when the link is
> back up.
> 
> That should be simpler and avoid the need for the workaround, don't you
> think ?

No, it's not simpler. This just does not handle the problem this 
workaround was implemented for.

You don't understand what this workaround does. It has nothing to do 
with TX path at all. It deals with RX one and the fact that in that 
particular MAC design whole RX domain is clocked from this clock, 
meaning some parts of EMAC just simply stop working. For some modes 
(e.g. SMII) this problem will not arise as this clock is always 
present, there are other cases when it's not needed (like sane PHY).

For example, how do you handle PHY detection if you cannot talk to the 
PHY?

Ben, my suggestion, before you start "forking" and "cleaning up" this 
code, understand what it does.

-- 
Eugene