miibus + USB = problem

[Pyun YongHyeon]

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