lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 1 Nov 2012 09:19:59 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Len Brown <lenb@...nel.org>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Lv Zheng <lv.zheng@...el.com>,
	Huang Ying <ying.huang@...el.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86 list <x86@...nel.org>,
	Tony Luck <tony.luck@...el.com>
Subject: Re: [PATCH 5/5] ACPI: Add support for platform bus type

On Thu, Nov 1, 2012 at 7:35 AM, Rafael J. Wysocki <rjw@...k.pl> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ