Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Feb 2011 09:37:53 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-hackers@freebsd.org
Cc:        Svatopluk Kraus <onwahe@gmail.com>
Subject:   Re: ichsmb - correct locking strategy?
Message-ID:  <201102220937.53075.jhb@freebsd.org>
In-Reply-To: <AANLkTinv8EkNqvQaNWpbW_q8J8kqSiJuLSb3j5S842a=@mail.gmail.com>
References:  <AANLkTinv8EkNqvQaNWpbW_q8J8kqSiJuLSb3j5S842a=@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, February 18, 2011 9:10:47 am Svatopluk Kraus wrote:
> Hi,
> 
>   I try to figure out locking strategy in FreeBSD and found 'ichsmb'
> device. There is a mutex which protects smb bus (ichsmb device). For
> example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is
> locked and a command is written to bus, then unbounded (but with
> timeout) sleep is done (mutex is unlocked during sleep). After sleep a
> word is read from bus and the mutex is unlocked.
> 
>   1. If an use of the device IS NOT serialized by layers around then
> more calls to this function (or others) can be started or even done
> before the first one is finished. The mutex don't protect sms bus.
> 
>   2. If an use of the device IS serialized by layers around then the
> mutex is useless.
> 
>   Moreover, I don't mension interrupt routine which uses the mutex and
> smb bus too.
> 
>   Am I right? Or did I miss something?

Hmm, the mutex could be useful if you have an smb controller with an interrupt 
handler (I think ichsmb or maybe intpm can support an interrupt handler) to 
prevent concurrent access to device registers.  That is the purpose of the 
mutex at least.  There is a separate locking layer in smbus itself in (see 
smbus_request_bus(), etc.).

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201102220937.53075.jhb>