All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
To: "Zheng, Lv" <lv.zheng@intel.com>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
	"mika.westerberg@linux.intel.com"
	<mika.westerberg@linux.intel.com>,
	"Moore, Robert" <robert.moore@intel.com>,
	"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>
Cc: "lenb@kernel.org" <lenb@kernel.org>,
	"hdegoede@redhat.com" <hdegoede@redhat.com>,
	"tj@kernel.org" <tj@kernel.org>,
	"mjg59@srcf.ucam.org" <mjg59@srcf.ucam.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"al.stone@linaro.org" <al.stone@linaro.org>,
	"graeme.gregory@linaro.org" <graeme.gregory@linaro.org>,
	"leo.duran@amd.com" <leo.duran@amd.com>,
	"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>
Subject: Re: [V8 PATCH 1/3] ACPICA: Add ACPI _CLS processing
Date: Fri, 24 Apr 2015 16:08:31 -0500	[thread overview]
Message-ID: <553AB0CF.1010904@amd.com> (raw)
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E8802704682@SHSMSX101.ccr.corp.intel.com>

On 4/16/15 20:45, Zheng, Lv wrote:
> Before back porting this to ACPICA, let me ask one simple question.
> According to the spec, the _CLS is optional and PCI specific.
> So why should we implement it in ACPICA core not OSPM specific modules?
> If this need to be implemented in ACPICA, then what about the following device identification objects?
> _DDN, _HRV, _MLS, _PLD, _STR, _SUN
>
> Thanks and best regards
> -Lv

Hi,

Sorry for late reply. As for the justification for introducing the _CLS 
support in the ACPICA, this is mainly because ACPI does not currently 
define _CID for certain device classes, which used to mostly be PCI 
devices. Instead, ACPI spec mentioned that _CLS can be used for loading 
generic drivers on hardware that is compatible with PCI-defined device 
classes, but that is not implemented on the PCI bus (and is therefore 
enumerated by ACPI.)

The code introduced for supporting _CLS is also similar in the way 
ACPICA is currently parsing the _CID or _SUB (which are also optional), 
and using it for the same purpose of identifying devices for loading 
drivers.

Also, since this method for identifying devices is OS-independent, I 
believe this should not be done in the OSPM specific modules.

Thanks,

Suravee

  parent reply	other threads:[~2015-04-24 21:08 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-30 21:56 [V8 PATCH 0/3] Introduce ACPI support for ahci_platform driver Suravee Suthikulpanit
2015-03-30 21:56 ` Suravee Suthikulpanit
2015-03-30 21:56 ` [V8 PATCH 1/3] ACPICA: Add ACPI _CLS processing Suravee Suthikulpanit
2015-03-30 21:56   ` Suravee Suthikulpanit
2015-04-13 13:54   ` Rafael J. Wysocki
2015-04-17  1:45   ` Zheng, Lv
2015-04-17  3:48     ` Moore, Robert
2015-04-24 21:08     ` Suravee Suthikulpanit [this message]
2015-04-25  2:28       ` Rafael J. Wysocki
2015-04-26 22:45         ` Suthikulpanit, Suravee
2015-04-26 22:45           ` Suthikulpanit, Suravee
2015-04-27 20:38           ` Rafael J. Wysocki
2015-04-27 20:38             ` Rafael J. Wysocki
2015-04-27 22:18             ` Suravee Suthikulpanit
2015-03-30 21:56 ` [V8 PATCH 2/3] ACPI / scan: Add support for ACPI _CLS device matching Suravee Suthikulpanit
2015-03-30 21:56   ` Suravee Suthikulpanit
2015-03-30 21:56 ` [V8 PATCH 3/3] ata: ahci_platform: Add ACPI _CLS matching Suravee Suthikulpanit
2015-03-30 21:56   ` Suravee Suthikulpanit
2015-04-06 15:45 ` [V8 PATCH 0/3] Introduce ACPI support for ahci_platform driver Suravee Suthikulanit
2015-04-06 15:45   ` Suravee Suthikulanit
2015-04-23 16:32   ` Suthikulpanit, Suravee
2015-04-23 17:02     ` Rafael J. Wysocki
2015-04-24 20:46       ` Suravee Suthikulpanit

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=553AB0CF.1010904@amd.com \
    --to=suravee.suthikulpanit@amd.com \
    --cc=al.stone@linaro.org \
    --cc=graeme.gregory@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hanjun.guo@linaro.org \
    --cc=hdegoede@redhat.com \
    --cc=lenb@kernel.org \
    --cc=leo.duran@amd.com \
    --cc=linaro-acpi@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lv.zheng@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=rjw@rjwysocki.net \
    --cc=robert.moore@intel.com \
    --cc=tj@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.