From: Matthew W. <wi...@de...> - 2003-06-12 11:57:07
|
Why doesn't struct acpi_device contain a struct device? I was rather hoping that with the unified device model in 2.5 that I could finally model the innards of the zx1 boxes (ie SBA has a bunch of HBAs, each of which has a PCI root bus). But it looks like acpi_device isn't part of the unified device model yet. Is there a reason for this, other than lack of time? -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk |
From: Patrick M. <mo...@os...> - 2003-06-12 15:22:13
|
> Why doesn't struct acpi_device contain a struct device? Because they are not devices, only the firmware representation of them. :) > I was rather hoping that with the unified device model in 2.5 that I > could finally model the innards of the zx1 boxes (ie SBA has a bunch of > HBAs, each of which has a PCI root bus). But it looks like acpi_device > isn't part of the unified device model yet. Is there a reason for this, > other than lack of time? struct acpi_device contains a kobject that is registered in drivers/acpi/scan.c. The hierarchy is represented in /sys/firmware/acpi/namespace. Ideally, when an ACPI namespace object is found, the bus on which the device belongs will be notified of a found device, so that it may probe, intiialize, and register the device properly. That will give it representation in /sys/devices, and ACPI could then provide a symlink between its object's directory and the device's directory. But, it hasn't happened yet. -pat |
From: Matthew W. <wi...@de...> - 2003-06-12 15:30:55
|
On Thu, Jun 12, 2003 at 08:23:41AM -0700, Patrick Mochel wrote: > > Why doesn't struct acpi_device contain a struct device? > > Because they are not devices, only the firmware representation of them. :) Umm. OK, smartypants :-P But I have some devices which _only_ have a firmware representation. For example, there's a couple of serial ports on this workstation which can't be found any other way. Then there's the SBA and LBA devices I mention below. These devices have basically nothing in common except that they only have an acpi_device to represent them. > struct acpi_device contains a kobject that is registered in > drivers/acpi/scan.c. The hierarchy is represented in > /sys/firmware/acpi/namespace. > > Ideally, when an ACPI namespace object is found, the bus on which the > device belongs will be notified of a found device, so that it may probe, > intiialize, and register the device properly. That will give it > representation in /sys/devices, and ACPI could then provide a symlink > between its object's directory and the device's directory. > > But, it hasn't happened yet. hmm. so you want a serial_object, an lba_object and an sba_object? then we can tie them together through the namespaces? I feel lost in a maze of pointers, all subtly different. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk |
From: Patrick M. <mo...@os...> - 2003-06-12 15:49:56
|
> But I have some devices which _only_ have a firmware representation. > For example, there's a couple of serial ports on this workstation which > can't be found any other way. Then there's the SBA and LBA devices I > mention below. These devices have basically nothing in common except > that they only have an acpi_device to represent them. Hm, we have a name for that - motivation :) > hmm. so you want a serial_object, an lba_object and an sba_object? > then we can tie them together through the namespaces? I feel lost in > a maze of pointers, all subtly different. Heh. Basically yes, we do want those objects. At least for serial, ACPI is used only for discovery and resource management, not for actually communicating with the device. There should also already be a serial_object of some sort, though there may not be a method for the system, or firmware driver, to tell the serial core to add the device. Something like this: acpi_device * acpidev; /* Scan ACPI devices */ if (is_serial_device(acpidev)) { struct serial_device * serdev; serdev = kmalloc(sizeof(struct serial_device),GFP_KERNEL); /* Initialize with resource information, etc */ if (!(error = serial_add_device(serdev))) { sysfs_create_link(&acpidev->kobj, &serdev->dev.kobj, "device"); sysfs_create_link(&serdev->dev.kobj, &acpidev->kobj, "ACPI"); } } should suffice, as well as add symlinks to bridge the representations. As for the other objects, you want something similar, though the format of representing the device and notifying the drivers is up to you.. -pat |