>
> On Friday 09 February 2007 19:27, John Keller wrote:
> > >
> > > On Wednesday 31 January 2007 20:58, Zhang Rui wrote:
> > > > On Wed, 2007-01-31 at 10:11 -0600, John Keller wrote:
> > > > > Len,
> > > > > When building kernels from your ACPI release or test trees,
> > > > > as well as the -mm tree, SN Altix boots are crashing in the
> > > > > kobject code when calling acpi_bus_register_driver().
> > > > > The crash is because kset->list has not been initialized yet.
> > > > >
> > > > > kobject_add()
> > > > > list_add_tail(&kobj->entry,&kobj->kset->list);
> > > > >
> > > > >
> > > > > Is there now a restriction on how early acpi_bus_register_driver()
> > > > > can be called? If so, at what point in time can calls be made,
> > > > > and is it still possible to register a driver early enough such
> > > > > that it will be called at device discovery time vs registration time?
> > > > >
> > > > Yes, this is caused by the recent ACPI sysfs conversion changes.
> > > > Now we make ACPI use driver model.
> > > > All the ACPI drivers should register after the ACPI bus has registered,
> > > > i.e. we can not call acpi_bus_register_driver() before acpi_scan_init()
> > > > in drivers/acpi/scan.c.
> > >
> > > John,
> > > Below is the order of the linux driver model universe.
> > > acpi_bus_register_driver is safe to call after subsys_initcall(),
> > > ie. at device_initcall() time. Do you need to be earlier than that,
> > > and if so, why?
> > >
> > > thanks,
> > > -Len
> > >
> > >
> > > #define core_initcall(fn) __define_initcall("1",fn,1)
> > > #define core_initcall_sync(fn) __define_initcall("1s",fn,1s)
> > > #define postcore_initcall(fn) __define_initcall("2",fn,2)
> > > #define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s)
> > > #define arch_initcall(fn) __define_initcall("3",fn,3)
> > > #define arch_initcall_sync(fn) __define_initcall("3s",fn,3s)
> > > #define subsys_initcall(fn) __define_initcall("4",fn,4)
> > > #define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)
> > > #define fs_initcall(fn) __define_initcall("5",fn,5)
> > > #define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)
> > > #define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)
> > > #define device_initcall(fn) __define_initcall("6",fn,6)
> > > #define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
> > > #define late_initcall(fn) __define_initcall("7",fn,7)
> > > #define late_initcall_sync(fn) __define_initcall("7s",fn,7s)
> > >
> >
> >
> > Len,
> > We're registering a driver for our IO hubs. Within the hubs are our
> > PCI root buses/bridges. Our code currently expects the hub infrastructure
> > for a particular bus to be initialized prior to bus scanning and the
> > invocation of our platform specific bus fixup code.
> >
> > We've been able to make this happen by registering our driver prior to
> > acpi_bus_scan(), so that when our hub devices are discovered, the driver
> > can execute before the acpi_pci_root_driver.
> >
> > With the latest ACPI changes it appears that this is no longer possible?
>
> Yep, that's right.
> Any chance the early hub infrastructure init can be split out to
> happen before driver registration?
Our driver's main purpose is to do the hub infrastructure init.
It does the init based on the PROM supplied info in the vendor resource
for each hub device.
I suspect we could move this code earlier, but then we'd have to manually
walk the namespace to find our hub devices and the vendor resources.
Registering as a driver, and being called with the acpi_device for each of
our hub devices works very slick today.
Or am I missing something?
John
>
> -Len
>
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
