From owner-freebsd-mobile@FreeBSD.ORG Fri Dec 10 16:34:30 2004 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1357816A4CE for ; Fri, 10 Dec 2004 16:34:30 +0000 (GMT) Received: from smtp-sv.canvas.ne.jp (smtp-sv.canvas.ne.jp [210.172.56.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 739A743D1D for ; Fri, 10 Dec 2004 16:34:29 +0000 (GMT) (envelope-from colinp@mx3.canvas.ne.jp) Received: from canvas.ne.jp (unknown [192.168.100.61]) by smtp-2.canvas.ne.jp (Postfix) with SMTP id E6CA015EAD8 for ; Sat, 11 Dec 2004 01:34:27 +0900 (JST) Received: (qmail 14221 invoked from network); 11 Dec 2004 01:34:27 +0900 Received: from unknown (HELO mail.mx3v.canvas.ne.jp) (192.168.100.53) by vc1d with SMTP; 11 Dec 2004 01:34:27 +0900 Received: from [127.0.0.1] (unknown [202.71.91.13]) by mail.mx3v.canvas.ne.jp (Postfix) with ESMTP id 8A0B42C2B for ; Sat, 11 Dec 2004 01:34:27 +0900 (JST) Message-ID: <41B9CFDC.3040305@mx3.canvas.ne.jp> Date: Sat, 11 Dec 2004 01:33:32 +0900 From: Colin Peters User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: freebsd-mobile@freebsd.org References: <20041209120101.DF76716A4E3@hub.freebsd.org> In-Reply-To: <20041209120101.DF76716A4E3@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: corega FEtherII PCC-TXD X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 16:34:30 -0000 A few more bits of data from my continuing experiments. The extra write of 0x04 to 0x3c2 (shown below) appears to be necessary for the FEtherII PCC-TXD. Without it the card refuses to respond (the link light stays off and I get "ed1: device timeout" messages again). The other thing I have found is that ed_pccard_match is getting called and setting the flags it wants to set, but those flags are cleared before getting to ed_pccard_probe. static int ed_pccard_match(device_t dev) { ... if (pp->flags & NE2000DVF_DL10019) device_set_flags(dev, ED_FLAGS_LINKSYS); else if (pp->flags & NE2000DVF_AX88190) device_set_flags(dev, ED_FLAGS_AX88190); printf(" in ed_pccard_match flags=%08x\n", device_get_flags(dev)); return (0); Results in this in dmesg: in ed_pccard_match flags=00030000 ed1: at port 0x300-0x31f irq 9 function 0 config 7 on pccard1 But this code in probe shows the flags are no longer set at that point, which is why I had to force ed_pccard_ax88190 to be called manually. static int ed_pccard_probe(device_t dev) { int error; int flags = device_get_flags(dev); device_printf(dev, "pccard probe"); printf(" flags=%08x compare %08x.\n", flags, ED_FLAGS_AX88190); /* if (ED_FLAGS_GETTYPE(flags) == ED_FLAGS_AX88190) { */ error = ed_pccard_ax88190(dev); goto end2; /* } */ The output of dmesg shows: ed1: pccard probe flags=00000000 compare 00030000. Now I will try to figure out where these functions are called and why the flags are cleared between them. Perhaps it would be better to call match again at the beginning of probe (or use a similar approach to determine the device type at probe time)? Colin.