[ACPI] [PATCH/RFC 0/4]Bind physical devices with ACPI devices

I don't think this is a great way to do it.  There's at least two other
examples of firmware that interacts with drivers in a similar way that you
could look at -- PA-RISC's PDC and Sun/Apple/IBM OpenFirmware.  I don't
know much about OpenFirmware, and I just redid the way parisc_device
works, so I'll discourse about that for a bit.

From a driver's point of view, it's simple.  Call a function to get
a cookie (an acpi_handle for ACPI, I guess), then pass that cookie to
whatever functions necessary.  This is the code in the sym2 SCSI driver:

#ifdef CONFIG_PARISC
/*
 * Host firmware (PDC) keeps a table for altering SCSI capabilities.
 * Many newer machines export one channel of 53c896 chip as SE, 50-pin HD.
 * Also used for Multi-initiator SCSI clusters to set the SCSI Initiator ID.
 */
static int sym_read_parisc_pdc(struct sym_device *np, struct pdc_initiator *pdc)
{
        struct hardware_path hwpath;
        get_pci_node_path(np->pdev, &hwpath);
        if (!pdc_get_initiator(&hwpath, pdc))
                return 0;

        return SYM_PARISC_PDC;
}
#else
static int sym_read_parisc_pdc(struct sym_device *np, struct pdc_initiator *x)
{
        return 0;
}
#endif


Hm.. ACPI doesn't really hanve anything SCSI-related in it.  Let's look at
IDE's _GTM and _STM for examples.  

static void ide_acpi_gtm(struct hwif_s *hwif, struct acpi_timing_mode *tm)
{
	acpi_handle handle;
	acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL};
	acpi_status status;

	handle = acpi_get_gendev_handle(&hwif->gendev);
	status = acpi_evaluate_object(handle, "_GTM", NULL, &buffer);
	...
}

All we need is an acpi_get_gendev_handle that takes a struct device and
returns the acpi_handle for it.  Now, maybe that'd be best done by placing
a pointer in the struct device, but I bet it'd be just as good to walk
the namespace looking for the corresponding device.

-- 
"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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

>All we need is an acpi_get_gendev_handle that takes a struct device and

  It will fail if you just simply walk namespace to find out 
the corresponding acpi object, because there are NO
hardware id or compatible id  can be passed in.
Please check function acpi_bus_match.
  The fundamental problem here is how to use device's geographical
address( or other information ) to locate the corresponding 
acpi object in namespace.

Thanks,
Luming
 




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

It doesn't need the HID or CID.  Look at Shaohua's patches -- they don't
use HID or CID either.

-- 
"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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

I think we're saying the same thing in different words here ...

Note that an acpi_get_gendev_handle() or map_device_addr_to_acpi_handle()
function doesn't *preclude* putting a void * in struct device.  It does
let us choose whether or not to do so.

-- 
"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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

Yes, I made a mistake, please forget that point.

But another statement I made should be valid.
That is how to use geographical address to
locate corresponding acpi object.

For example,  ACPI define IDE as the following:

Device (IDE0){ /* primary controller */
	Name (_ADR, 0)
	Method (_GTM )
	...
	Device(PRIM) /* primary adapter */
		Name (_ADR, 0)
		Method(_GTM)
		...
		Device(MSTR) /* master channel */
			Name (_ADR,0)
			Method(_GTF)

  We need not only able to locate acpi object IDE0
but also we need to locate object PRIM underneath
IDE0,  and MSTR underneath PRIM. Thus, IDE driver 
can fully take advantage from ACPI, in terms of 
configuration and power management.

  Maybe we need to invent a method called
map_device_addr_to_acpi_handle to be  generic solution.

Thanks,
Luming


  



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

I would agree with you if ACPI just supports PCI bus type, but ACPI
supports many bus types. We can't get an ACPI handler if only has a
'struct device'. You might say we can get its bus type from device->bus,
but we need a 'switch-case' to get what exactly the bus type is, but
this can't apply for loadable module bus type.

Thanks,
Shaohua

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/