Hi,
A sample patch to bind IDE devices. I'm not familar with IDE driver, so
the patch possibly is completely wrong, though it can show correct ACPI
path in my laptop. This test case just shows the framework works, please
don't apply it.
Thanks,
Shaohua
---
2.6-root/drivers/ide/ide.c | 43
+++++++++++++++++++++++++++++++++++++++++++
1 files changed, 43 insertions(+)
diff -puN drivers/ide/ide.c~ide-bind-acpi drivers/ide/ide.c
--- 2.6/drivers/ide/ide.c~ide-bind-acpi 2004-11-08 11:09:12.625009440
+0800
+++ 2.6-root/drivers/ide/ide.c 2004-11-08 11:10:04.477126720 +0800
@@ -2412,10 +2412,53 @@ EXPORT_SYMBOL(ide_fops);
EXPORT_SYMBOL(ide_lock);
+#ifdef CONFIG_ACPI
+#include <linux/acpi.h>
+int generic_ide_platform_bind(struct device *dev)
+{
+ acpi_handle parent_handle = NULL;
+ acpi_integer address;
+ int i;
+
+ /* Seems dev->parent->parent is the PCI IDE controller */
+ if (dev->parent && dev->parent->parent)
+ parent_handle = dev->parent->parent->handle;
+
+ if (!parent_handle) {
+ printk("Can't find parent handle \n");
+ return -1;
+ }
+ /* Please ref to ACPI spec for syntax of _ADR */
+ sscanf(dev->bus_id, "%d", &i);
+ address = i;
+ dev->handle = acpi_get_child(parent_handle, address);
+
+#if 1
+ {/* For debug */
+ char name[80] = {'?','\0'};
+ struct acpi_buffer buffer = {sizeof(name), name};
+
+ printk("IDE device %d:", i);
+ if (dev->handle) {
+ acpi_get_name(dev->handle, ACPI_FULL_PATHNAME,
&buffer);
+ printk("%s", name);
+ }
+ printk("\n");
+ }
+#endif
+ return 0;
+}
+#else
+int generic_ide_platform_bind(struct device *dev)
+{
+ return 0;
+}
+#endif
struct bus_type ide_bus_type = {
.name = "ide",
.suspend = generic_ide_suspend,
.resume = generic_ide_resume,
+ .platform_bind = generic_ide_platform_bind,
};
/*
_
Hi, Li-san
Thanks for your framework. It's one of patches what I really want.
My test machine has SATA controller and works with ata_piix driver with no
.suspend and .resume entry while ide.c has them.
The first thing I did is to create them and add some function calls to save
and restore the device specific PCI configuration space.
But then I had no idea how to execute ACPI's IDE specific method like _GTM,
_STM.
As I am not familiar with IDE driver too, I hope the module owner will
change ata_piix source to support .suspend, .resume, .platform_bind entries
soon.
Regards, Hiro.
[email protected] wrote on 2004/11/08 13:11:47:
> Hi,
> A sample patch to bind IDE devices. I'm not familar with IDE driver, so
> the patch possibly is completely wrong, though it can show correct ACPI
> path in my laptop. This test case just shows the framework works, please
> don't apply it.
>
> Thanks,
> Shaohua
> ---
>
> 2.6-root/drivers/ide/ide.c | 43
> +++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 43 insertions(+)
>
> diff -puN drivers/ide/ide.c~ide-bind-acpi drivers/ide/ide.c
> --- 2.6/drivers/ide/ide.c~ide-bind-acpi 2004-11-08 11:09:12.625009440
> +0800
> +++ 2.6-root/drivers/ide/ide.c 2004-11-08 11:10:04.477126720 +0800
> @@ -2412,10 +2412,53 @@ EXPORT_SYMBOL(ide_fops);
>
> EXPORT_SYMBOL(ide_lock);
>
> +#ifdef CONFIG_ACPI
> +#include <linux/acpi.h>
> +int generic_ide_platform_bind(struct device *dev)
> +{
> + acpi_handle parent_handle = NULL;
> + acpi_integer address;
> + int i;
> +
> + /* Seems dev->parent->parent is the PCI IDE controller */
> + if (dev->parent && dev->parent->parent)
> + parent_handle = dev->parent->parent->handle;
> +
> + if (!parent_handle) {
> + printk("Can't find parent handle \n");
> + return -1;
> + }
> + /* Please ref to ACPI spec for syntax of _ADR */
> + sscanf(dev->bus_id, "%d", &i);
> + address = i;
> + dev->handle = acpi_get_child(parent_handle, address);
> +
> +#if 1
> + {/* For debug */
> + char name[80] = {'?','\0'};
> + struct acpi_buffer buffer = {sizeof(name), name};
> +
> + printk("IDE device %d:", i);
> + if (dev->handle) {
> + acpi_get_name(dev->handle, ACPI_FULL_PATHNAME,
> &buffer);
> + printk("%s", name);
> + }
> + printk("\n");
> + }
> +#endif
> + return 0;
> +}
> +#else
> +int generic_ide_platform_bind(struct device *dev)
> +{
> + return 0;
> +}
> +#endif
> struct bus_type ide_bus_type = {
> .name = "ide",
> .suspend = generic_ide_suspend,
> .resume = generic_ide_resume,
> + .platform_bind = generic_ide_platform_bind,
> };
>
> /*
> _
>
On Mon, Nov 08, 2004 at 12:11:47PM +0800, Li Shaohua wrote:
> A sample patch to bind IDE devices. I'm not familar with IDE driver, so
> the patch possibly is completely wrong, though it can show correct ACPI
> path in my laptop. This test case just shows the framework works, please
> don't apply it.
> +#ifdef CONFIG_ACPI
> +#include <linux/acpi.h>
> +int generic_ide_platform_bind(struct device *dev)
> +{
> + acpi_handle parent_handle = NULL;
> + acpi_integer address;
> + int i;
> +
> + /* Seems dev->parent->parent is the PCI IDE controller */
> + if (dev->parent && dev->parent->parent)
> + parent_handle = dev->parent->parent->handle;
An IDE struct device is the gendev embedded in the ide_drive_t. Its parent
is the ide_hwif_t, and its parent is the PCI device (or maybe SBUS
or whatever). You can see this in /sys:
$ ls /sys/devices/pci0000:00/0000:00:1f.1/ide0/0.0
block detach_state power
The '0.0' is the device with an ide_bus_type. ide0 is the hwif.
0000:00:1f.1 is a pci_dev. Or in ACPI terms, ACPI/_SB/PCI0/IDEC
is ide0 and ACPI/_SB/PCI0/IDEC/PRID is 0.0
At least, I think that's the mapping. Are we ever going to do anything
with /sys/firmware/acpi/namespace/ or will it just stay around consuming
inodes and dentries for no good reason?
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
On Mon, 2004-11-08 at 10:24, Matthew Wilcox wrote:
> ... Are we ever going to do anything
> with /sys/firmware/acpi/namespace/ or will it just stay around
> consuming inodes and dentries for no good reason?
When I suggested deleting /sys/firmware/acpi, Patrick replied that his
intention was that real devices would have symbolic links into that
tree.
I think this is not the best way to go. Two simple reasons come to
mind:
The ACPI device hierarchy reflects the actual layout of the system
devices better than the current /sys/devices/ tree, linking into it from
/sys/devices doesn't fix /sys/devices. Instead we need to consult ACPI
during the actual construction of /sys/devices/.
While the layout reflects reality, the device names in
/sys/firmware/acpi are arbitrary internal BIOS names, and so there will
never be any consistency between systems such that a human or a program
could have an easy time navigating the tree structure.
The argument in favor of exposing the tree has been for things like Alex
Williamson's patch to invoke ACPI methods by reading /sysfs. But this
is a really neat solution looking for a problem. if and when such a
problem is found, the same technique can always be made available under
the real /sys/devices tree.
-Len