How to get a device_t
Bernd Walter
ticso at cicely12.cicely.de
Sat Aug 9 04:38:38 PDT 2003
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 (<machine/pci_cfgreg.h>,
<dev/pci/pcireg.h>)
[...]
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 <BUS_ADD_CHILD>:
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 <BUS_ADD_CHILD+0x36>
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 <kobj_lookup_method>
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 at bwct.de info at bwct.de
More information about the freebsd-hackers
mailing list