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>