Hi Arnd

-----Original Message-----
From: arndbergmann at gmail.com [mailto:arndbergmann at gmail.com] On Behalf
Of Arnd Bergmann
Sent: 16 March 2017 10:13
To: Yuanzhichang
Cc: Rafael J. Wysocki; Catalin Marinas; Will Deacon; Rob Herring; Frank
Rowand; Bjorn Helgaas; Rafael Wysocki; Mark Rutland; Linux ARM; ACPI
Devel Maling List; Lorenzo Pieralisi; Benjamin Herrenschmidt; Linux
Kernel Mailing List; Linuxarm; devicetree at vger.kernel.org; linux-pci;
linux-serial at vger.kernel.org; Corey Minyard; liviu.dudau at arm.com; Zou
Rongrong; John Garry; Gabriele Paoloni; zhichang.yuan02 at gmail.com;
kantyzc at 163.com; xuwei (O)
Subject: Re: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices
whose dependency has not met

On Thu, Mar 16, 2017 at 3:21 AM, zhichang.yuan
[off-list ref] wrote:

quoted

Hi, Rafael,

Thanks for your review!

On 2017/3/14 5:24, Rafael J. Wysocki wrote:

quoted

On Monday, March 13, 2017 10:42:41 AM zhichang.yuan wrote:

quoted

In commit 40e7fcb1929(ACPI: Add _DEP support to fix battery issue

on Asus

quoted

quoted

quoted

T100TA), the '_DEP' was supported to solve the dependency of Asus

battery. But

quoted

quoted

quoted

this patch is specific to Asus battery device.
In the real world, there are other devices which need the

dependency to play the

quoted

quoted

quoted

role on the enumeration order. For example, all the Hip06 LPC
periperals(IPMI-BT, uart, etc) must be scanned after the LPC host

driver

quoted

quoted

quoted

finished the probing. So, it makes sense to add a checking whether

the ACPI

quoted

quoted

quoted

device meet all the dependencies during its enumeration slot, if

not, the

quoted

quoted

quoted

enumeration will be delayed till all dependency master finish their

work.

quoted

quoted

quoted

This patch adds the dependency checking in ACPI enumeration, also

the

quoted

quoted

quoted

corresponding handling to retrigger the Hip06 LPC peripherals'

scanning.

quoted

quoted

AFAICS, _DEP is generally abused in the wild and cannot be made

generic.  Sorry.

quoted

quoted

From the ACPI specification, _DEP is for operation region accesses.
You are right...

How about we add a ACPI handler for our LPC bus?? Just like amba.
In this way, we also can solve the issue about LPC enumeration order.

As far as I can tell, PCI and LPC have exactly the same requirement
here,
so whatever you end up doing for one should be used for the other as
well.

Well as you know PCI has got his own handler, identified by his own
namespace id "PNP0A03".
Now when you say "you end up doing for one should be used for the other"
are you saying that we should introduce a new class of devices?
i.e. should we have an ACPI namespace identifier for non-PCI IO Host
Controllers?  

Otherwise, if my understanding is correct, having a specific new ACPI
handler for HiSilicon LPC would mean to adding another function_init()
in the list of acpi handlers inits in acpi_scan_init().

But then every vendor would declare his own one...is this really correct?

Many Thanks
Gab

      Arnd