Date: Fri, 4 Aug 2006 09:09:39 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: miibus + USB = problem Message-ID: <20060804000939.GA53215@cdnetworks.co.kr> In-Reply-To: <200608031444.47566.hselasky@c2i.net> References: <200608021437.55500.hselasky@c2i.net> <20060803022526.GB49195@cdnetworks.co.kr> <200608031444.47566.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 03, 2006 at 02:44:46PM +0200, Hans Petter Selasky wrote: > 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. > > ... > > > 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 > executed. > > But can I assume that everytime something inside the "mii" layer is called, it > goes through my driver, "if_aue". > > >From 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 > comes the next question: > > Can I safely "kthread_exit" from the "miibus_xxx()" functions ? I can probably > find the answer by looking at the sourcecode, but maybe someone already > knows? > > /* MII interface */ > DEVMETHOD(miibus_readreg, aue_miibus_readreg), > DEVMETHOD(miibus_writereg, aue_miibus_writereg), > DEVMETHOD(miibus_statchg, aue_miibus_statchg), > I can't sure why you need to invoke kthread_exit(9) in aue_miibus_xxx. If you want to kill the kernel thread in aue_miibus_xxx you can simply send a termination message to kernel thread. Your kernel thread can decide when it should terminate if it recevied a termination message. Invoking mii_mediachg/mii_tick will end up with calling miibus_xxx to to read/write PHY registers from MII layer. So I think you still need to handle PHY read/write operations in aue_miibus_xxx. If the PHY operation was failed due to removal of hardware it could simply return fake value and send a message to terminate the kernel thread. -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060804000939.GA53215>