From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <486CF1C5.9020704@domain.hid> Date: Thu, 03 Jul 2008 17:35:33 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <486CE4C5.8050309@domain.hid> <486CEF87.6060504@domain.hid> In-Reply-To: <486CEF87.6060504@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] How can I make Xenomai share a mii bus with the kernel? Reply-To: rpm@xenomai.org List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org Gilles Chanteperdrix wrote: > Michael Galea wrote: >> I wonder if someone can suggest an approach to the following problem. >> >> We need to use xenomai to manage devices on the mii bus. The mii bus >> has PHYs managed by linux. What is the best way of providing access to >> both linux and xenomai? >> >> I know that before xenomai "loads", I can simply access the mii bus from >> linux. But after xenomai loads, is the right answer to make the linux >> function that reads the phy migrate into the xenomai domain and contend >> for the bus there? > > What protects this access to the bus, is this a mutex or a spinlock ? If > a spinlock, then simply make it an ipipe_spinlock, it will provide > mutual exclusion between all domains. > It's a spinlock_bh, but you can't tell actually, since there is a callback mechanism to perform the actual read depending on the bus implementation. Additionally, genphy_read may trigger an update from the link status and so on. I'm afraid this kind of sport may well resemble playing Russian roulette with a fully loaded gun. This said, if all executed code paths can be identified and fixed, why not (having fun). > I do not think it can be a mutex anyway, since it may certainly possible > for a driver to have a function that reads the mii status in a timer > handler to maintain the IFF_RUNNING bit state of the ethernet interface. > -- Philippe.