Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1601881 > unrolled thread

Re: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices whose dependency has not met

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices whose  dependency has not met "zhichang.yuan" <yuanzhichang@hisilicon.com> - 2017-03-16 03:30 +0100
    Re: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices whose  dependency has not met Arnd Bergmann <arnd@arndb.de> - 2017-03-16 11:20 +0100
      Re: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices whose  dependency has not met "zhichang.yuan" <zhichang.yuan02@gmail.com> - 2017-03-16 16:00 +0100
      RE: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices whose  dependency has not met Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2017-03-16 17:20 +0100
        RE: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices whose         dependency has not met Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2017-03-24 01:50 +0100

#1601881 — Re: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices whose dependency has not met

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.

Thanks,
Zhichang


> Thanks,
> Rafael
> 
> 
> .
> 

[toc] | [next] | [standalone]

#1602158

On Thu, Mar 16, 2017 at 3:21 AM, zhichang.yuan
<yuanzhichang@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.

      Arnd

[toc] | [prev] | [next] | [standalone]

#1602450

Hi, Arnd,



On 03/16/2017 06:13 PM, Arnd Bergmann wrote:
> On Thu, Mar 16, 2017 at 3:21 AM, zhichang.yuan
> <yuanzhichang@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.
> 

Thanks for your remind!

To some extend, our LPC is similar to PCI. We also need to setup the host
resources before scanning the children. For PCI, there is an ACPI handler of
pci_root_handler. Although our LPC is not so complicated and powerful as PCI(for
example, LPC can't probe downside devices), I think, we can still make LPC host
ready to work in its own ACPI handler callback....

Cheers,
Zhichang


>       Arnd
> 

[toc] | [prev] | [next] | [standalone]

#1602610

Hi Arnd

> -----Original Message-----
> From: arndbergmann@gmail.com [mailto:arndbergmann@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@vger.kernel.org; linux-pci;
> linux-serial@vger.kernel.org; Corey Minyard; liviu.dudau@arm.com; Zou
> Rongrong; John Garry; Gabriele Paoloni; zhichang.yuan02@gmail.com;
> kantyzc@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
> <yuanzhichang@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?

Many Thanks
Gab

> 
>       Arnd

[toc] | [prev] | [next] | [standalone]

#1608034 — RE: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices whose dependency has not met

Hi Arnd

> -----Original Message-----
> From: linuxarm-bounces@huawei.com [mailto:linuxarm-bounces@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-serial@vger.kernel.org; Catalin Marinas;
> devicetree@vger.kernel.org; Corey Minyard; liviu.dudau@arm.com; Rob
> Herring; Bjorn Helgaas; kantyzc@163.com; zhichang.yuan02@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: arndbergmann@gmail.com [mailto:arndbergmann@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@vger.kernel.org; linux-pci;
> > linux-serial@vger.kernel.org; Corey Minyard; liviu.dudau@arm.com; Zou
> > Rongrong; John Garry; Gabriele Paoloni; zhichang.yuan02@gmail.com;
> > kantyzc@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
> > <yuanzhichang@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
> linuxarm@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web