From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 9 04:38:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0B5C37B401; Sat, 9 Aug 2003 04:38:37 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80E8F43F75; Sat, 9 Aug 2003 04:38:35 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h79BcCaK054651 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 9 Aug 2003 13:38:14 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h79Bc9A4051373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2003 13:38:10 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h79Bc9NS054195; Sat, 9 Aug 2003 13:38:09 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h79Bc5ca054194; Sat, 9 Aug 2003 13:38:05 +0200 (CEST) Date: Sat, 9 Aug 2003 13:38:05 +0200 From: Bernd Walter To: John Baldwin Message-ID: <20030809113804.GI46866@cicely12.cicely.de> References: <20030808195511.GD46866@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: ticso@cicely12.cicely.de cc: Poul-Henning Kamp cc: freebsd-hackers@FreeBSD.org cc: ticso@cicely.de Subject: Re: How to get a device_t X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2003 11:38:38 -0000 On Fri, Aug 08, 2003 at 04:32:43PM -0400, John Baldwin wrote: > > On 08-Aug-2003 Bernd Walter wrote: > > On Fri, Aug 08, 2003 at 03:48:22PM -0400, John Baldwin wrote: > >> > >> On 08-Aug-2003 Bernd Walter wrote: > >> > On Fri, Aug 08, 2003 at 02:27:30PM -0400, John Baldwin wrote: > >> >> Well, that would be a major pain on current since nexus is already > >> >> finished attaching many of its drivers by the time it gets to here. > >> >> Also, if you use ACPI and if ACPI exists, then this function _won't_ > >> >> _ever_ _be_ _called_. If you use a hostb PCI driver, then it will > >> >> work both for ACPI and legacy. > >> > > >> > I agree with this point and if I understood correct this is what > >> > John Birrel already had done. > >> > >> No, he is still working in the nexus/pcib driver's identify routine, > >> not in a separate 'hostb' PCI driver. > >> > >> > However - I would still like to know why > >> > device_add_child(nexus, "elanbb", -1); > >> > results in an elanbb instance numer 1 connected to pci0. > >> > And why I don't get any iicbb childs. > >> > >> I would have to see your code changes in order to try to tell you that. > > > > http://www.cosmo-project.de/~bernd/elanbb.diff > > First off, the iicbb driver does not know have an elanbb attachment. > You need a set of driver methods and corresponding > > DRIVER_MODULE(iicbb, elanbb, ...) > > For the iicbb child of elanbb to get a driver that probes it and attaches > to it. > > Hmm, what you want to do is not hijack the legacy/pcib identify > routine I think, but add an identify routine to your elanbb driver > and have elanbb live off the nexus (so DRIVER_MODULE(elan, nexus)) > and have its identify routine use pci_cfgreg() to get the devid for > device 0 and if it is the right one call init_AMD_Elan_sc520() and > add it's probe routine. Or rather. I've fixed all this and you can > get the changes (whcih should fix bogus elanbb0 and make iicbb0 show > up) at http://www.freebsd.org/~jhb/patches/elan.patch It includes > your patch above but fixes a few things. One other bug I fixed is > that since yout elan was hung off of pci and had an empty probe > routine, any unclaimed PCI device got "claimed" by your elanbb driver, > hence your bogus elanbb0. Note that the version of elanbb in > elan.patch uses a private identify routine that calls > init_AMD_Elan_sc250(), so it will work both with and without ACPI. > However, the warning printf about CPU_ELAN won't show up with ACPI. > I left the printf in pci_bus.c for now. A better place to put it would > be in the hostb driver itself. Well, I went ahead and did that too, > so now the warning will show up both for ACPI and non-ACPI systems. After adding you patch and some includes (, ) [...] pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=30001022) pcibios: BIOS version 2.00 Doing h0h0magic for AMD Elan sc520 sysctl machdep.i8254_freq=1189161 returns 0 Timecounter "ELAN" frequency 8333333 Hz Fatal trap 12: page fault while in kernel mode fault virtual address = 0x78363029 fault code = supervisor read, page not present instruction pointer = 0x8:0xc029d05b stack pointer = 0x10:0xc03cdcc4 frame pointer = 0x10:0xc03cdcd4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 Stopped at BUS_ADD_CHILD+0x2b: pushl 0x4(%eax) db> trace BUS_ADD_CHILD(c0307fb8,0,c02c9f2f,ffffffff) at BUS_ADD_CHILD+0x2b elanbb_identify(c0307fb8,c05ad800,c05a72b0,c05ad800,c03cdd1c) at elanbb_identify+0x3b DEVICE_IDENTIFY(c0307fb8,c05ad800) at DEVICE_IDENTIFY+0x3e bus_generic_probe(c05ad800,c0db7098,c03cdd40,c01b24da,c05ad800) at bus_generic_probe+0x28 nexus_attach(c05ad800,c05ad800,c05adb80,c03cdd5c,c01b0f01) at nexus_attach+0xd DEVICE_ATTACH(c05ad800,1,c05ad800,c0305efc,3d2000) at DEVICE_ATTACH+0x3a device_probe_and_attach(c05ad800) at device_probe_and_attach+0x81 root_bus_configure(c05adb80,c02e4cb8,0,4) at root_bus_configure+0x16 configure(0,3cac00,3ca000,0,c0123825) at configure+0x22 mi_startup() at mi_startup+0xb2 begin() at begin+0x2c db> c029d030 : typedef device_t bus_add_child_t(device_t _dev, int _order, const char *_name, int _unit); static __inline device_t BUS_ADD_CHILD(device_t _dev, int _order, const char *_name, int _unit) { c029d030: 55 push %ebp c029d031: 89 e5 mov %esp,%ebp c029d033: 56 push %esi c029d034: 53 push %ebx c029d035: 8b 75 08 mov 0x8(%ebp),%esi kobjop_t _m; KOBJOPLOOKUP(((kobj_t)_dev)->ops,bus_add_child); c029d038: b8 00 00 00 00 mov $0x0,%eax c029d03d: a0 14 c3 2e c0 mov 0xc02ec314,%al c029d042: 8b 16 mov (%esi),%edx c029d044: 8d 1c c2 lea (%edx,%eax,8),%ebx c029d047: 81 3b 14 c3 2e c0 cmpl $0xc02ec314,(%ebx) c029d04d: 74 17 je c029d066 c029d04f: 68 14 c3 2e c0 push $0xc02ec314 c029d054: 53 push %ebx c029d055: 8b 82 00 08 00 00 mov 0x800(%edx),%eax c029d05b: ff 70 04 pushl 0x4(%eax) c029d05e: e8 7d 77 f1 ff call c01b47e0 c029d063: 83 c4 0c add $0xc,%esp return ((bus_add_child_t *) _m)(_dev, _order, _name, _unit); c029d066: ff 75 14 pushl 0x14(%ebp) c029d069: ff 75 10 pushl 0x10(%ebp) c029d06c: ff 75 0c pushl 0xc(%ebp) c029d06f: 56 push %esi c029d070: ff 53 04 call *0x4(%ebx) } c029d073: 8d 65 f8 lea 0xfffffff8(%ebp),%esp c029d076: 5b pop %ebx c029d077: 5e pop %esi c029d078: 5d pop %ebp c029d079: c3 ret -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de