linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Garrett <matthew.garrett@nebula.com>
To: "rui.zhang@intel.com" <rui.zhang@intel.com>
Cc: "dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"rafael.j.wysocki@intel.com" <rafael.j.wysocki@intel.com>
Subject: Re: [RFC PATCH 0/8] ACPI: change the way of enumerating PNPACPI/Platform devices
Date: Wed, 26 Feb 2014 16:47:48 +0000	[thread overview]
Message-ID: <1393433267.14900.3.camel@x230> (raw)
In-Reply-To: <1393405874-3266-1-git-send-email-rui.zhang@intel.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1198 bytes --]

On Wed, 2014-02-26 at 17:11 +0800, Zhang Rui wrote:

> 1. without the patch, the acpi_platform scan handler white list is
>    continuously growing.
> 2. with the patch set, the PNPACPI scan handler white list will become
>    smaller and smaller by
>    a) remove the ids from the PNPACPI white list, for the devices
>       that are never enumerated via ACPI
>    b) remove the ids from the PNPACPI whilte list and convert the drivers to
>       platform bus drivers, for the devices that are not PNP devices in nature.
>    which will be done later.

I agree that this is the right direction to go in. The number of acpipnp
devices that are also pnpbios or (even worse) isapnp is (a) unlikely to
increase, and (b) *very* small, and pretty much limited to superio and a
small number of sound cards on old laptops. We may come up with a better
solution for them later, but right now shifting away from requiring that
every new ACPI device driver also bump a whitelist is an improvement.

-- 
Matthew Garrett <matthew.garrett@nebula.com>
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

  parent reply	other threads:[~2014-02-26 16:47 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26  9:11 [RFC PATCH 0/8] ACPI: change the way of enumerating PNPACPI/Platform devices Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 1/8] ACPI: introduce .match() callback for ACPI scan handler Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 2/8] PNPACPI: use whilte list for pnpacpi device enumeration Zhang Rui
2014-03-07  1:44   ` Rafael J. Wysocki
2014-03-09  5:29     ` Zhang Rui
2014-03-09 17:49       ` Rafael J. Wysocki
2014-03-10  2:24         ` Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 3/8] PNPACPI: remove ids that does not comply with the ACPI PNP id rule Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 4/8] PNPACPI: remove unsupported serial PNP ids from PNPACPI id list Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 5/8] PNPACPI: check and enumerate CMOS RTC devices explicitly Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 6/8] ACPI: use platform bus as the default bus for _HID enumeration Zhang Rui
2014-03-02 23:51   ` Rafael J. Wysocki
2014-03-03 14:11     ` Zhang Rui
2014-03-03 23:23       ` Rafael J. Wysocki
2014-03-04  0:27         ` Zhang, Rui
2014-03-04  0:35           ` Rafael J. Wysocki
2014-03-07  1:46             ` Rafael J. Wysocki
2014-03-09  5:33               ` Zhang Rui
2014-03-09 17:50                 ` Rafael J. Wysocki
2014-03-09 15:50   ` Zhang Rui
2014-03-09 18:04     ` Rafael J. Wysocki
2014-03-10  2:44       ` Zhang Rui
2014-03-10  2:45       ` Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 7/8] Revert "ACPI / PNP: skip ACPI device nodes associated with physical nodes already" Zhang Rui
2014-02-26  9:11 ` [RFC PATCH 8/8] PNPACPI: create both PNP and Platform device nodes for PNP0C01/PNP0C02 Zhang Rui
2014-03-03 14:17   ` Zhang Rui
2014-03-03 16:17     ` Bjorn Helgaas
2014-02-26 16:47 ` Matthew Garrett [this message]
2014-03-03 13:50   ` [RFC PATCH 0/8] ACPI: change the way of enumerating PNPACPI/Platform devices Zhang Rui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1393433267.14900.3.camel@x230 \
    --to=matthew.garrett@nebula.com \
    --cc=bhelgaas@google.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rui.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).