Hi Arnd > -----Original Message----- > From: linuxarm-boun...@huawei.com [mailto:linuxarm-boun...@huawei.com] > On Behalf Of Gabriele Paoloni > Sent: 16 March 2017 16:14 > To: Arnd Bergmann; Yuanzhichang > Cc: Mark Rutland; Benjamin Herrenschmidt; Rafael Wysocki; linux-pci; > Will Deacon; Linuxarm; Frank Rowand; Lorenzo Pieralisi; ACPI Devel > Maling List; linux-ser...@vger.kernel.org; Catalin Marinas; > devicet...@vger.kernel.org; Corey Minyard; liviu.du...@arm.com; Rob > Herring; Bjorn Helgaas; kant...@163.com; zhichang.yua...@gmail.com; > Linux ARM; Rafael J. Wysocki; Linux Kernel Mailing List; Zou Rongrong > Subject: RE: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices > whose dependency has not met > > Hi Arnd > > > -----Original Message----- > > From: arndbergm...@gmail.com [mailto:arndbergm...@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; devicet...@vger.kernel.org; linux-pci; > > linux-ser...@vger.kernel.org; Corey Minyard; liviu.du...@arm.com; Zou > > Rongrong; John Garry; Gabriele Paoloni; zhichang.yua...@gmail.com; > > kant...@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 > > <yuanzhich...@hisilicon.com> wrote: > > > Hi, Rafael, > > > > > > Thanks for your review! > > > > > > On 2017/3/14 5:24, Rafael J. Wysocki wrote: > > >> On Monday, March 13, 2017 10:42:41 AM zhichang.yuan wrote: > > >>> In commit 40e7fcb1929(ACPI: Add _DEP support to fix battery issue > > on Asus > > >>> T100TA), the '_DEP' was supported to solve the dependency of Asus > > battery. But > > >>> this patch is specific to Asus battery device. > > >>> In the real world, there are other devices which need the > > dependency to play the > > >>> role on the enumeration order. For example, all the Hip06 LPC > > >>> periperals(IPMI-BT, uart, etc) must be scanned after the LPC host > > driver > > >>> finished the probing. So, it makes sense to add a checking > whether > > the ACPI > > >>> device meet all the dependencies during its enumeration slot, if > > not, the > > >>> enumeration will be delayed till all dependency master finish > their > > work. > > >>> > > >>> This patch adds the dependency checking in ACPI enumeration, also > > the > > >>> corresponding handling to retrigger the Hip06 LPC peripherals' > > scanning. > > >> > > >> AFAICS, _DEP is generally abused in the wild and cannot be made > > generic. Sorry. > > >> > > > > > > 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?
Do you have any feedback on this? Otherwise I think that maybe we could consider moving back to the arch_initcall approach as proposed in V6: https://lkml.org/lkml/2017/1/24/28 Thanks Gab > > Many Thanks > Gab > > > > > Arnd > _______________________________________________ > linuxarm mailing list > linux...@huawei.com > http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
