From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by ozlabs.org (Postfix) with ESMTP id EC46267A04 for ; Thu, 2 Jun 2005 08:43:03 +1000 (EST) In-Reply-To: <429E2653.6010101@osdl.org> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <20050531105939.7486e071@dxpl.pdx.osdl.net> <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> <429E2653.6010101@osdl.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: From: Andy Fleming Date: Wed, 1 Jun 2005 17:42:56 -0500 To: Stephen Hemminger Cc: Netdev , Embedded PPC Linux list Subject: Re: RFC: PHY Abstraction Layer II List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Jun 1, 2005, at 16:19, Stephen Hemminger wrote: > Andy Fleming wrote: >> >> But not this one. The phy_read and phy_write functions are >> reading from and writing to a bus. It is a reasonable >> implementation to have the operation block in the bus driver, and >> be awoken when an interrupt signals the operation is done. All >> of the phydev spinlocks have been arranged so as to prevent the >> lock being taken during interrupt time. >> >> Unless I've misunderstood spinlocks (it wouldn't be the first >> time), as long as the lock is never taken in interrupt time, it >> should be ok to hold the lock, and wait for an interrupt before >> clearing the lock. >> > > > The problem is that sleeping is defined in the linux kernel as > meaning waiting on a mutual exclusion > primitive (like semaphore) that puts the current thread to sleep. > It is not legal to sleep with a spinlock held. > In the phy_read code you do: > spin_lock_bh(&bus->mdio_lock); > retval = bus->read(bus, phydev->addr, regnum); > spin_unlock_bh(&bus->mdio_lock); > > If the bus->read function were to do something like start a request > and wait on a semaphore, then > you would be sleeping with a spin lock held. So bus->read can not > sleep! (as sleep is defined in the > linux kernel). Hmm... I understand this reasoning, but I still need a way for a bus read to wait for an interrupt before returning. I suppose I can just have the code spin while it waits, but that seems wrong, somehow. I'm open to any suggestions.