On Thu, Nov 1, 2012 at 7:35 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
>> > @@ -1544,8 +1553,13 @@ static acpi_status acpi_bus_check_add(ac
>> > */
>> > device = NULL;
>> > acpi_bus_get_device(handle, &device);
>> > - if (ops->acpi_op_add && !device)
>> > + if (ops->acpi_op_add && !device) {
>> > acpi_add_single_object(&device, handle, type, sta, ops);
>> > + /* Is the device a known good platform device? */
>> > + if (device
>> > + && !acpi_match_device_ids(device, acpi_platform_device_ids))
>> > + acpi_create_platform_device(device);
>> > + }
>>
>> That is ugly! any reason for not using acpi_driver for them.
>
> Yes, a couple of reasons. First off, there are existing platform drivers for
> these things already and there's no reason for creating a "glue" layer between
> those drivers and struct acpi_device objects. Second, we're going to get rid
> of acpi_driver things entirely going forward (the existing ones will be replaced
> by platform drivers or included into the ACPI core).
that should be glue between acpi_device and platform_device.
how are you going to handle removing path ? aka when acpi_device get
trimed, how those platform get deleted?
>
>> there is not reason to treat those platform_device different from pci
>> root device and other pnp device.
>
> Well, I agree. :-)
>
> So those things you're talking about we'll be platform devices too in the
> future.
>
>> something like attached patch. .add of acpi_driver ops could call
>> acpi_create_platform_device.
>
> Been there, decided to do it differently this time.
>
So you are going to replace acpi_device/acpi_driver with
platform_device/platform_driver ?
Did you ever try to start to the work to see if it is doable? aka do
you have draft version to do that?
Yinghai
--
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
