From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 3 12:44:42 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B8C016A4E1 for ; Thu, 3 Aug 2006 12:44:42 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id A741643D5C for ; Thu, 3 Aug 2006 12:44:40 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== X-Cloudmark-Score: 0.000000 [] Received: from [193.217.134.95] (HELO [10.0.0.249]) by mailfe06.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 247854203; Thu, 03 Aug 2006 14:44:38 +0200 From: Hans Petter Selasky To: pyunyh@gmail.com Date: Thu, 3 Aug 2006 14:44:46 +0200 User-Agent: KMail/1.7 References: <200608021437.55500.hselasky@c2i.net> <20060803022526.GB49195@cdnetworks.co.kr> In-Reply-To: <20060803022526.GB49195@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200608031444.47566.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: miibus + USB = problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 12:44:42 -0000 On Thursday 03 August 2006 04:25, Pyun YongHyeon wrote: > On Wed, Aug 02, 2006 at 02:37:55PM +0200, Hans Petter Selasky wrote: > > Hi, > > > > I am currently in the progress of porting "if_aue.c" to my new USB API, > > and have hit a problem that needs to be solved. The problem is that the > > USB system sleeps under "miibus_xxx". Questions are: > > > > Is this allowed? > > > > What locks are held when these functions are called ? > > > > Reference: > > > > /* MII interface */ > > DEVMETHOD(miibus_readreg, aue_miibus_readreg), > > DEVMETHOD(miibus_writereg, aue_miibus_writereg), > > DEVMETHOD(miibus_statchg, aue_miibus_statchg), > > AFAIK there is no locks held when MII layer calls above methods but > it _is_ called with a driver lock from its ioctl handler. Ok. > It seems that aue(4) needs to access its register space whilst > serving above MII methods.=20 =2E.. > But I think sleeping is not a good way in the MII methods as it would > confuse MII layers. See below. > Yes, "mii_tick()" can suddenly be executed while "mii_mediachg()" is being= =20 executed. But can I assume that everytime something inside the "mii" layer is called,= it=20 goes through my driver, "if_aue". =46rom what I can see, there are only three entry points into the MII layer: mii_mediachg(mii); mii_pollstat(mii); mii_tick(mii); The idea is to call these from a separate thread, that can sleep. But then= =20 comes the next question: Can I safely "kthread_exit" from the "miibus_xxx()" functions ? I can proba= bly=20 find the answer by looking at the sourcecode, but maybe someone already=20 knows? /* MII interface */ DEVMETHOD(miibus_readreg, aue_miibus_readreg), DEVMETHOD(miibus_writereg, aue_miibus_writereg), DEVMETHOD(miibus_statchg, aue_miibus_statchg), > > > I think you can immediately return from register read/write routines > without DELAY() if you know the hardware was gone. > > > 2) pre-read all read registers regularly. How can I do this with > > "miibus"? > > Because you have a aue_tick() which is called every hz you can cache > several registers regularly. Your MII methods can copy the value > without accessing registers with proper locks. However, this may > confuse MII layers because it needs successive register accesses to > read/write media related settings and that defeats use of cached > contents of the registers. I just have to cache the result: ifmr->ifm_active =3D mii->mii_media_active; ifmr->ifm_status =3D mii->mii_media_status; Thanks for any comments. =2D-HPS