From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26254 invoked by alias); 26 Jul 2005 17:44:08 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 26239 invoked by uid 22791); 26 Jul 2005 17:44:04 -0000 Received: from carallon.force9.co.uk (HELO carallon.f9.co.uk) (80.229.37.120) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 26 Jul 2005 17:44:04 +0000 Received: from [192.168.42.8] by carallon.com (MDaemon.PRO.v8.0.2.R) with ESMTP id md50000013338.msg for ; Tue, 26 Jul 2005 18:47:12 +0100 Message-ID: <42E6771D.3060306@carallon.com> Date: Tue, 26 Jul 2005 17:44:00 -0000 From: Will Wagner User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Steve Strublic CC: ecos-discuss@ecos.sourceware.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: willw@carallon.com X-Spam-Processed: carallon.f9.co.uk, Tue, 26 Jul 2005 18:47:12 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.42.8 X-Return-Path: will_wagner@carallon.com X-MDaemon-Deliver-To: ecos-discuss@ecos.sourceware.org X-MDAV-Processed: carallon.f9.co.uk, Tue, 26 Jul 2005 18:47:12 +0100 Subject: Re: [ECOS] link loss/detection at runtime X-SW-Source: 2005-07/txt/msg00287.txt.bz2 Thanks Steve. Thats exactly where I had just got to, can't see a better way of doing it. Could you give an example of what's in your pfn_proc_link_status. I am assuming I can copy code snippets out of the dhcp code to work out how to bring the interface up and down. Cheers, Will Steve Strublic wrote: > > > > We had a similar issue at my company. We ended up hooking FEC_ETH_PHY_INT, writing an ISR/DSR > combination, and running a thread to allow calls to phy_read(). In the thread, we read the contents > of the link status register when notified by the DSR that the status has changed. This also allowed > us to have multiple notifiers execute upon link status change. > > Something like: > > phy_ok = phy_read(PHY_BMSR2, FEC_ETH_PHY, &mii_reg17); > > if (mii_reg17 & PHY_BMSR2_LINK) > link_up_status=true; > else > link_up_status=false; > > (pfn_proc_link_status)(link_up_status) ; > > There may be (probably is) an easier solution, but this one worked for us. > > HTH, > > Steve > > -------- > > "A chicken doesn't stop scratching just because the worms are scarce." - Grandma Soderquist's > Conclusion > > > > > will_wagner@carallon.com > Sent by: > ecos-discuss-owner@ecos.sou To > rceware.org ecos-discuss@ecos.sourceware.org > cc > > 07/26/2005 05:07 AM Subject > [ECOS] link loss/detection at runtime > > > > > > > > > > > Hi All, > > Are there any examples of ethernet drivers that cope with link > loss/detection after the drivers have been initialised? I am using an > MPC860 with AMD PHY. I have hunted through the source but can't find any > examples of this. > > If not can anyone point me to what needs to be done in the bsd stack to > bring an interface up/down following a change in link status. > > Thanks, > > Will > > > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss > > > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss