Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Grant Likely]

On Wed, 25 Mar 2015 11:38:43 +
, Will Deacon 
 wrote:
> On Wed, Mar 25, 2015 at 11:54:25AM +, Rafael J. Wysocki wrote:
> > On Wednesday, March 25, 2015 11:24:11 AM Will Deacon wrote:
> > > On Tue, Mar 24, 2015 at 10:02:53PM +, Grant Likely wrote:
> > > > On Thu, 19 Mar 2015 19:39:27 + , Will Deacon 
> > > > wrote:
> > > > > On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
> > > > > > Not only that, Sudeep has a patch to consolidate DT and ACPI SMP 
> > > > > > code,
> > > > > > I am working on it, I do not think it should be a blocking point, 
> > > > > > patch
> > > > > > coming asap on top of your series.
> > > > > 
> > > > > Well, I don't really want to merge the series without those patches 
> > > > > so I
> > > > > do think it blocks the code from getting into mainline.
> > > > 
> > > > Really? It's a pretty minor duplication problem and it's been identified
> > > > as something requiring refactoring to both the ACPI and DT code. It
> > > > isn't at all dangerous. Why is this a blocking point?
> > > 
> > > Because I don't really see a valid excuse not to get this right first time
> > > around. Lorenzo already has patches on top, so we just need a co-ordinated
> > > review effort.
> > > 
> > > I wouldn't accept another patch series that needed minor rework (which by
> > > its very nature is easily addressed), so why should ACPI be treated any
> > > differently?
> > 
> > Not ACPI, but this particular patchset I think.  The problem is that it has
> > already been reviewed and ACKed by multiple people and it would be a shame
> > to require all of those people to do their reviews once again because of
> > that minor rework (which arguably can be done on top of the patchset just
> > fine).
> > 
> > Of course, if the minor rework in question would not involve the need to
> > review things once again, then I agree that it'd be better to do it upfront,
> > but otherwise there's a good reason not to.
> 
> Aha, I think this is just a misunderstanding -- I'm certainly not suggesting
> that Hanjun rework the current set! What I *am* asking for is that they go
> into mainline with Lorenzo's patches on top, which means that his series [1]
> needs some review (and I plan to look at it later today).

Okay, thanks for the clarification.

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Grant Likely]

On Wed, 25 Mar 2015 11:38:43 +
, Will Deacon will.dea...@arm.com
 wrote:
 On Wed, Mar 25, 2015 at 11:54:25AM +, Rafael J. Wysocki wrote:
  On Wednesday, March 25, 2015 11:24:11 AM Will Deacon wrote:
   On Tue, Mar 24, 2015 at 10:02:53PM +, Grant Likely wrote:
On Thu, 19 Mar 2015 19:39:27 + , Will Deacon will.dea...@arm.com
wrote:
 On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
  Not only that, Sudeep has a patch to consolidate DT and ACPI SMP 
  code,
  I am working on it, I do not think it should be a blocking point, 
  patch
  coming asap on top of your series.
 
 Well, I don't really want to merge the series without those patches 
 so I
 do think it blocks the code from getting into mainline.

Really? It's a pretty minor duplication problem and it's been identified
as something requiring refactoring to both the ACPI and DT code. It
isn't at all dangerous. Why is this a blocking point?
   
   Because I don't really see a valid excuse not to get this right first time
   around. Lorenzo already has patches on top, so we just need a co-ordinated
   review effort.
   
   I wouldn't accept another patch series that needed minor rework (which by
   its very nature is easily addressed), so why should ACPI be treated any
   differently?
  
  Not ACPI, but this particular patchset I think.  The problem is that it has
  already been reviewed and ACKed by multiple people and it would be a shame
  to require all of those people to do their reviews once again because of
  that minor rework (which arguably can be done on top of the patchset just
  fine).
  
  Of course, if the minor rework in question would not involve the need to
  review things once again, then I agree that it'd be better to do it upfront,
  but otherwise there's a good reason not to.
 
 Aha, I think this is just a misunderstanding -- I'm certainly not suggesting
 that Hanjun rework the current set! What I *am* asking for is that they go
 into mainline with Lorenzo's patches on top, which means that his series [1]
 needs some review (and I plan to look at it later today).

Okay, thanks for the clarification.

g.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Lorenzo Pieralisi]

On Tue, Mar 24, 2015 at 10:02:53PM +, Grant Likely wrote:
> On Thu, 19 Mar 2015 19:39:27 +
> , Will Deacon 
>  wrote:
> > On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
> > > On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
> > > > On 2015/3/19 3:05, Will Deacon wrote:
> > > > > On Wed, Mar 11, 2015 at 12:39:26PM +, Hanjun Guo wrote:
> > > > >> This patch set already tested on multi platforms:
> > > > >>  - AMD Seattle board;
> > > > >>  - Cavium Thunder board;
> > > > >>  - Huawei D02 board;
> > > > >>  - Qualcomm ARM64 platform
> > > > >>
> > > > >> This version 10 patch set address some minor comments and collect 
> > > > >> ACKs and
> > > > >> Reviewed-bys for v9:
> > > > >>
> > > > >>  - new Acks from Rafael, Olof, Grant, Lorenzo
> > > > >>  - new way to handle typdef phys_cpuid_t which suggested by Rafael,
> > > > >>but no functional change
> > > > >>  - Remove if(!phys) for early ioremappings
> > > > >>  - Rework sleep function for ARM64
> > > > >>  - Introduce linux/acpi_irq.h to hold acpi_irq_init()
> > > > >>  - Disable ACPI if not HW_REDUCED_ACPI compliant
> > > > >>  - Remove the doc of why ACPI on ARM
> > > > > So I've had a look at the current state of this series and I think 
> > > > > there
> > > > > are a few immediate things left to do:
> > > > >
> > > > >   (1) Resolve the acpi=force cmdline issue highlighted by Lorenzo and
> > > > >   Catalin
> > > > 
> > > > Sure, it will be done after the confirmation with Ard.
> > > > 
> > > > >
> > > > >   (2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP 
> > > > > init),
> > > > >   so I'm assuming there will be additional patches from them that 
> > > > > are
> > > > >   required.
> > > > 
> > > > Sorry, I assume that it is about the print information for PSCI absent 
> > > > for SMP init, right?
> > > 
> > > Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
> > > I am working on it, I do not think it should be a blocking point, patch
> > > coming asap on top of your series.
> > 
> > Well, I don't really want to merge the series without those patches so I
> > do think it blocks the code from getting into mainline.
> 
> Really? It's a pretty minor duplication problem and it's been identified
> as something requiring refactoring to both the ACPI and DT code. It
> isn't at all dangerous. Why is this a blocking point?

The SMP init ACPI/DT consolidation, in particular in relation to cpu_ops may
not be a blocking point, but it is not a whim either and it deserves some
thought.

I will post a patch asap and the ACPI parking protocol support patches
strictly depend on this clean-up to be completed.

Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Lorenzo Pieralisi]

On Tue, Mar 24, 2015 at 10:02:53PM +, Grant Likely wrote:
 On Thu, 19 Mar 2015 19:39:27 +
 , Will Deacon will.dea...@arm.com
  wrote:
  On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
   On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
On 2015/3/19 3:05, Will Deacon wrote:
 On Wed, Mar 11, 2015 at 12:39:26PM +, Hanjun Guo wrote:
 This patch set already tested on multi platforms:
  - AMD Seattle board;
  - Cavium Thunder board;
  - Huawei D02 board;
  - Qualcomm ARM64 platform

 This version 10 patch set address some minor comments and collect 
 ACKs and
 Reviewed-bys for v9:

  - new Acks from Rafael, Olof, Grant, Lorenzo
  - new way to handle typdef phys_cpuid_t which suggested by Rafael,
but no functional change
  - Remove if(!phys) for early ioremappings
  - Rework sleep function for ARM64
  - Introduce linux/acpi_irq.h to hold acpi_irq_init()
  - Disable ACPI if not HW_REDUCED_ACPI compliant
  - Remove the doc of why ACPI on ARM
 So I've had a look at the current state of this series and I think 
 there
 are a few immediate things left to do:

   (1) Resolve the acpi=force cmdline issue highlighted by Lorenzo and
   Catalin

Sure, it will be done after the confirmation with Ard.


   (2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP 
 init),
   so I'm assuming there will be additional patches from them that 
 are
   required.

Sorry, I assume that it is about the print information for PSCI absent 
for SMP init, right?
   
   Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
   I am working on it, I do not think it should be a blocking point, patch
   coming asap on top of your series.
  
  Well, I don't really want to merge the series without those patches so I
  do think it blocks the code from getting into mainline.
 
 Really? It's a pretty minor duplication problem and it's been identified
 as something requiring refactoring to both the ACPI and DT code. It
 isn't at all dangerous. Why is this a blocking point?

The SMP init ACPI/DT consolidation, in particular in relation to cpu_ops may
not be a blocking point, but it is not a whim either and it deserves some
thought.

I will post a patch asap and the ACPI parking protocol support patches
strictly depend on this clean-up to be completed.

Lorenzo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Rafael J. Wysocki]

On Wednesday, March 25, 2015 11:38:43 AM Will Deacon wrote:
> On Wed, Mar 25, 2015 at 11:54:25AM +, Rafael J. Wysocki wrote:
> > On Wednesday, March 25, 2015 11:24:11 AM Will Deacon wrote:
> > > On Tue, Mar 24, 2015 at 10:02:53PM +, Grant Likely wrote:
> > > > On Thu, 19 Mar 2015 19:39:27 + , Will Deacon 
> > > > wrote:
> > > > > On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
> > > > > > Not only that, Sudeep has a patch to consolidate DT and ACPI SMP 
> > > > > > code,
> > > > > > I am working on it, I do not think it should be a blocking point, 
> > > > > > patch
> > > > > > coming asap on top of your series.
> > > > > 
> > > > > Well, I don't really want to merge the series without those patches 
> > > > > so I
> > > > > do think it blocks the code from getting into mainline.
> > > > 
> > > > Really? It's a pretty minor duplication problem and it's been identified
> > > > as something requiring refactoring to both the ACPI and DT code. It
> > > > isn't at all dangerous. Why is this a blocking point?
> > > 
> > > Because I don't really see a valid excuse not to get this right first time
> > > around. Lorenzo already has patches on top, so we just need a co-ordinated
> > > review effort.
> > > 
> > > I wouldn't accept another patch series that needed minor rework (which by
> > > its very nature is easily addressed), so why should ACPI be treated any
> > > differently?
> > 
> > Not ACPI, but this particular patchset I think.  The problem is that it has
> > already been reviewed and ACKed by multiple people and it would be a shame
> > to require all of those people to do their reviews once again because of
> > that minor rework (which arguably can be done on top of the patchset just
> > fine).
> > 
> > Of course, if the minor rework in question would not involve the need to
> > review things once again, then I agree that it'd be better to do it upfront,
> > but otherwise there's a good reason not to.
> 
> Aha, I think this is just a misunderstanding -- I'm certainly not suggesting
> that Hanjun rework the current set! What I *am* asking for is that they go
> into mainline with Lorenzo's patches on top, which means that his series [1]
> needs some review (and I plan to look at it later today).

OK, that works for me, thanks for the clarification!

For the record, I've looked at the Lorenzo's series already and I don't see
anything particularly objectionable in it.

> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333257.html


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Will Deacon]

On Wed, Mar 25, 2015 at 11:54:25AM +, Rafael J. Wysocki wrote:
> On Wednesday, March 25, 2015 11:24:11 AM Will Deacon wrote:
> > On Tue, Mar 24, 2015 at 10:02:53PM +, Grant Likely wrote:
> > > On Thu, 19 Mar 2015 19:39:27 + , Will Deacon 
> > > wrote:
> > > > On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
> > > > > Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
> > > > > I am working on it, I do not think it should be a blocking point, 
> > > > > patch
> > > > > coming asap on top of your series.
> > > > 
> > > > Well, I don't really want to merge the series without those patches so I
> > > > do think it blocks the code from getting into mainline.
> > > 
> > > Really? It's a pretty minor duplication problem and it's been identified
> > > as something requiring refactoring to both the ACPI and DT code. It
> > > isn't at all dangerous. Why is this a blocking point?
> > 
> > Because I don't really see a valid excuse not to get this right first time
> > around. Lorenzo already has patches on top, so we just need a co-ordinated
> > review effort.
> > 
> > I wouldn't accept another patch series that needed minor rework (which by
> > its very nature is easily addressed), so why should ACPI be treated any
> > differently?
> 
> Not ACPI, but this particular patchset I think.  The problem is that it has
> already been reviewed and ACKed by multiple people and it would be a shame
> to require all of those people to do their reviews once again because of
> that minor rework (which arguably can be done on top of the patchset just
> fine).
> 
> Of course, if the minor rework in question would not involve the need to
> review things once again, then I agree that it'd be better to do it upfront,
> but otherwise there's a good reason not to.

Aha, I think this is just a misunderstanding -- I'm certainly not suggesting
that Hanjun rework the current set! What I *am* asking for is that they go
into mainline with Lorenzo's patches on top, which means that his series [1]
needs some review (and I plan to look at it later today).

> And, as a maintainer, you can always say "Well, I'm taking this conditional on
> doing this-and-that on top of it and I won't be taking any more patches from
> you in the future if that doesn't happen."

I can't really take that stance for a new feature like this.

Will

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333257.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Rafael J. Wysocki]

On Wednesday, March 25, 2015 11:24:11 AM Will Deacon wrote:
> On Tue, Mar 24, 2015 at 10:02:53PM +, Grant Likely wrote:
> > On Thu, 19 Mar 2015 19:39:27 + , Will Deacon 
> > wrote:
> > > On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
> > > > Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
> > > > I am working on it, I do not think it should be a blocking point, patch
> > > > coming asap on top of your series.
> > > 
> > > Well, I don't really want to merge the series without those patches so I
> > > do think it blocks the code from getting into mainline.
> > 
> > Really? It's a pretty minor duplication problem and it's been identified
> > as something requiring refactoring to both the ACPI and DT code. It
> > isn't at all dangerous. Why is this a blocking point?
> 
> Because I don't really see a valid excuse not to get this right first time
> around. Lorenzo already has patches on top, so we just need a co-ordinated
> review effort.
> 
> I wouldn't accept another patch series that needed minor rework (which by
> its very nature is easily addressed), so why should ACPI be treated any
> differently?

Not ACPI, but this particular patchset I think.  The problem is that it has
already been reviewed and ACKed by multiple people and it would be a shame
to require all of those people to do their reviews once again because of
that minor rework (which arguably can be done on top of the patchset just
fine).

Of course, if the minor rework in question would not involve the need to
review things once again, then I agree that it'd be better to do it upfront,
but otherwise there's a good reason not to.

And, as a maintainer, you can always say "Well, I'm taking this conditional on
doing this-and-that on top of it and I won't be taking any more patches from
you in the future if that doesn't happen."


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Will Deacon]

On Tue, Mar 24, 2015 at 10:02:53PM +, Grant Likely wrote:
> On Thu, 19 Mar 2015 19:39:27 + , Will Deacon 
> wrote:
> > On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
> > > Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
> > > I am working on it, I do not think it should be a blocking point, patch
> > > coming asap on top of your series.
> > 
> > Well, I don't really want to merge the series without those patches so I
> > do think it blocks the code from getting into mainline.
> 
> Really? It's a pretty minor duplication problem and it's been identified
> as something requiring refactoring to both the ACPI and DT code. It
> isn't at all dangerous. Why is this a blocking point?

Because I don't really see a valid excuse not to get this right first time
around. Lorenzo already has patches on top, so we just need a co-ordinated
review effort.

I wouldn't accept another patch series that needed minor rework (which by
its very nature is easily addressed), so why should ACPI be treated any
differently?

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Grant Likely]

On Thu, 19 Mar 2015 19:39:27 +
, Will Deacon 
 wrote:
> On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
> > On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
> > > On 2015/3/19 3:05, Will Deacon wrote:
> > > > On Wed, Mar 11, 2015 at 12:39:26PM +, Hanjun Guo wrote:
> > > >> This patch set already tested on multi platforms:
> > > >>  - AMD Seattle board;
> > > >>  - Cavium Thunder board;
> > > >>  - Huawei D02 board;
> > > >>  - Qualcomm ARM64 platform
> > > >>
> > > >> This version 10 patch set address some minor comments and collect ACKs 
> > > >> and
> > > >> Reviewed-bys for v9:
> > > >>
> > > >>  - new Acks from Rafael, Olof, Grant, Lorenzo
> > > >>  - new way to handle typdef phys_cpuid_t which suggested by Rafael,
> > > >>but no functional change
> > > >>  - Remove if(!phys) for early ioremappings
> > > >>  - Rework sleep function for ARM64
> > > >>  - Introduce linux/acpi_irq.h to hold acpi_irq_init()
> > > >>  - Disable ACPI if not HW_REDUCED_ACPI compliant
> > > >>  - Remove the doc of why ACPI on ARM
> > > > So I've had a look at the current state of this series and I think there
> > > > are a few immediate things left to do:
> > > >
> > > >   (1) Resolve the acpi=force cmdline issue highlighted by Lorenzo and
> > > >   Catalin
> > > 
> > > Sure, it will be done after the confirmation with Ard.
> > > 
> > > >
> > > >   (2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP 
> > > > init),
> > > >   so I'm assuming there will be additional patches from them that 
> > > > are
> > > >   required.
> > > 
> > > Sorry, I assume that it is about the print information for PSCI absent 
> > > for SMP init, right?
> > 
> > Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
> > I am working on it, I do not think it should be a blocking point, patch
> > coming asap on top of your series.
> 
> Well, I don't really want to merge the series without those patches so I
> do think it blocks the code from getting into mainline.

Really? It's a pretty minor duplication problem and it's been identified
as something requiring refactoring to both the ACPI and DT code. It
isn't at all dangerous. Why is this a blocking point?

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Grant Likely]

On Thu, 19 Mar 2015 19:39:27 +
, Will Deacon will.dea...@arm.com
 wrote:
 On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
  On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
   On 2015/3/19 3:05, Will Deacon wrote:
On Wed, Mar 11, 2015 at 12:39:26PM +, Hanjun Guo wrote:
This patch set already tested on multi platforms:
 - AMD Seattle board;
 - Cavium Thunder board;
 - Huawei D02 board;
 - Qualcomm ARM64 platform
   
This version 10 patch set address some minor comments and collect ACKs 
and
Reviewed-bys for v9:
   
 - new Acks from Rafael, Olof, Grant, Lorenzo
 - new way to handle typdef phys_cpuid_t which suggested by Rafael,
   but no functional change
 - Remove if(!phys) for early ioremappings
 - Rework sleep function for ARM64
 - Introduce linux/acpi_irq.h to hold acpi_irq_init()
 - Disable ACPI if not HW_REDUCED_ACPI compliant
 - Remove the doc of why ACPI on ARM
So I've had a look at the current state of this series and I think there
are a few immediate things left to do:
   
  (1) Resolve the acpi=force cmdline issue highlighted by Lorenzo and
  Catalin
   
   Sure, it will be done after the confirmation with Ard.
   
   
  (2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP 
init),
  so I'm assuming there will be additional patches from them that 
are
  required.
   
   Sorry, I assume that it is about the print information for PSCI absent 
   for SMP init, right?
  
  Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
  I am working on it, I do not think it should be a blocking point, patch
  coming asap on top of your series.
 
 Well, I don't really want to merge the series without those patches so I
 do think it blocks the code from getting into mainline.

Really? It's a pretty minor duplication problem and it's been identified
as something requiring refactoring to both the ACPI and DT code. It
isn't at all dangerous. Why is this a blocking point?

g.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Rafael J. Wysocki]

On Wednesday, March 25, 2015 11:24:11 AM Will Deacon wrote:
 On Tue, Mar 24, 2015 at 10:02:53PM +, Grant Likely wrote:
  On Thu, 19 Mar 2015 19:39:27 + , Will Deacon will.dea...@arm.com
  wrote:
   On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
I am working on it, I do not think it should be a blocking point, patch
coming asap on top of your series.
   
   Well, I don't really want to merge the series without those patches so I
   do think it blocks the code from getting into mainline.
  
  Really? It's a pretty minor duplication problem and it's been identified
  as something requiring refactoring to both the ACPI and DT code. It
  isn't at all dangerous. Why is this a blocking point?
 
 Because I don't really see a valid excuse not to get this right first time
 around. Lorenzo already has patches on top, so we just need a co-ordinated
 review effort.
 
 I wouldn't accept another patch series that needed minor rework (which by
 its very nature is easily addressed), so why should ACPI be treated any
 differently?

Not ACPI, but this particular patchset I think.  The problem is that it has
already been reviewed and ACKed by multiple people and it would be a shame
to require all of those people to do their reviews once again because of
that minor rework (which arguably can be done on top of the patchset just
fine).

Of course, if the minor rework in question would not involve the need to
review things once again, then I agree that it'd be better to do it upfront,
but otherwise there's a good reason not to.

And, as a maintainer, you can always say Well, I'm taking this conditional on
doing this-and-that on top of it and I won't be taking any more patches from
you in the future if that doesn't happen.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Will Deacon]

On Wed, Mar 25, 2015 at 11:54:25AM +, Rafael J. Wysocki wrote:
 On Wednesday, March 25, 2015 11:24:11 AM Will Deacon wrote:
  On Tue, Mar 24, 2015 at 10:02:53PM +, Grant Likely wrote:
   On Thu, 19 Mar 2015 19:39:27 + , Will Deacon will.dea...@arm.com
   wrote:
On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
 Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
 I am working on it, I do not think it should be a blocking point, 
 patch
 coming asap on top of your series.

Well, I don't really want to merge the series without those patches so I
do think it blocks the code from getting into mainline.
   
   Really? It's a pretty minor duplication problem and it's been identified
   as something requiring refactoring to both the ACPI and DT code. It
   isn't at all dangerous. Why is this a blocking point?
  
  Because I don't really see a valid excuse not to get this right first time
  around. Lorenzo already has patches on top, so we just need a co-ordinated
  review effort.
  
  I wouldn't accept another patch series that needed minor rework (which by
  its very nature is easily addressed), so why should ACPI be treated any
  differently?
 
 Not ACPI, but this particular patchset I think.  The problem is that it has
 already been reviewed and ACKed by multiple people and it would be a shame
 to require all of those people to do their reviews once again because of
 that minor rework (which arguably can be done on top of the patchset just
 fine).
 
 Of course, if the minor rework in question would not involve the need to
 review things once again, then I agree that it'd be better to do it upfront,
 but otherwise there's a good reason not to.

Aha, I think this is just a misunderstanding -- I'm certainly not suggesting
that Hanjun rework the current set! What I *am* asking for is that they go
into mainline with Lorenzo's patches on top, which means that his series [1]
needs some review (and I plan to look at it later today).

 And, as a maintainer, you can always say Well, I'm taking this conditional on
 doing this-and-that on top of it and I won't be taking any more patches from
 you in the future if that doesn't happen.

I can't really take that stance for a new feature like this.

Will

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333257.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Rafael J. Wysocki]

On Wednesday, March 25, 2015 11:38:43 AM Will Deacon wrote:
 On Wed, Mar 25, 2015 at 11:54:25AM +, Rafael J. Wysocki wrote:
  On Wednesday, March 25, 2015 11:24:11 AM Will Deacon wrote:
   On Tue, Mar 24, 2015 at 10:02:53PM +, Grant Likely wrote:
On Thu, 19 Mar 2015 19:39:27 + , Will Deacon will.dea...@arm.com
wrote:
 On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
  Not only that, Sudeep has a patch to consolidate DT and ACPI SMP 
  code,
  I am working on it, I do not think it should be a blocking point, 
  patch
  coming asap on top of your series.
 
 Well, I don't really want to merge the series without those patches 
 so I
 do think it blocks the code from getting into mainline.

Really? It's a pretty minor duplication problem and it's been identified
as something requiring refactoring to both the ACPI and DT code. It
isn't at all dangerous. Why is this a blocking point?
   
   Because I don't really see a valid excuse not to get this right first time
   around. Lorenzo already has patches on top, so we just need a co-ordinated
   review effort.
   
   I wouldn't accept another patch series that needed minor rework (which by
   its very nature is easily addressed), so why should ACPI be treated any
   differently?
  
  Not ACPI, but this particular patchset I think.  The problem is that it has
  already been reviewed and ACKed by multiple people and it would be a shame
  to require all of those people to do their reviews once again because of
  that minor rework (which arguably can be done on top of the patchset just
  fine).
  
  Of course, if the minor rework in question would not involve the need to
  review things once again, then I agree that it'd be better to do it upfront,
  but otherwise there's a good reason not to.
 
 Aha, I think this is just a misunderstanding -- I'm certainly not suggesting
 that Hanjun rework the current set! What I *am* asking for is that they go
 into mainline with Lorenzo's patches on top, which means that his series [1]
 needs some review (and I plan to look at it later today).

OK, that works for me, thanks for the clarification!

For the record, I've looked at the Lorenzo's series already and I don't see
anything particularly objectionable in it.

 [1] 
 http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333257.html


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Will Deacon]

On Tue, Mar 24, 2015 at 10:02:53PM +, Grant Likely wrote:
 On Thu, 19 Mar 2015 19:39:27 + , Will Deacon will.dea...@arm.com
 wrote:
  On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
   Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
   I am working on it, I do not think it should be a blocking point, patch
   coming asap on top of your series.
  
  Well, I don't really want to merge the series without those patches so I
  do think it blocks the code from getting into mainline.
 
 Really? It's a pretty minor duplication problem and it's been identified
 as something requiring refactoring to both the ACPI and DT code. It
 isn't at all dangerous. Why is this a blocking point?

Because I don't really see a valid excuse not to get this right first time
around. Lorenzo already has patches on top, so we just need a co-ordinated
review effort.

I wouldn't accept another patch series that needed minor rework (which by
its very nature is easily addressed), so why should ACPI be treated any
differently?

Will
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

On 2015年03月24日 02:32, Stefano Stabellini wrote:

On Sat, 21 Mar 2015, Hanjun Guo wrote:

+CC Parth Dixit, Stefano Stabellini.

On 2015年03月21日 02:54, Will Deacon wrote:

On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:

On 2015/3/19 3:05, Will Deacon wrote:

If you can get that in place, I'm not opposed to putting this into
linux-next ahead of the firmware summit in San Jose next week. Note that
this is not a commitment for 4.1, since I'm keen to see the outcomes of
next week before setting anything in stone.


OK, I will stick to this mailing list and respond as soon as I can.


This doesn't even build for me:


$ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- allmodconfig
$ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- Image

[...]

In file included from drivers/xen/acpi.c:33:0:


Sorry, I didn't build ACPI with XEN enabled on ARM64.


include/xen/acpi.h: In function ‘xen_acpi_sleep_register’:
include/xen/acpi.h:102:3: error: ‘acpi_suspend_lowlevel’ undeclared (first
use in this function)
 acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;


acpi_suspend_lowlevel is defined only for X86 and IA64 for now.


 ^
include/xen/acpi.h:102:3: note: each undeclared identifier is reported only
once for each function it appears in
drivers/xen/acpi.c: In function ‘xen_acpi_notify_hypervisor_state’:
drivers/xen/acpi.c:61:2: error: implicit declaration of function
‘HYPERVISOR_dom0_op’ [-Werror=implicit-function-declaration]
HYPERVISOR_dom0_op();


And this is only for x86:
./arch/x86/include/asm/xen/hypercall.h:HYPERVISOR_dom0_op(struct
xen_platform_op *platform_op)


^
cc1: some warnings being treated as errors
make[2]: *** [drivers/xen/acpi.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [drivers/xen] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [drivers] Error 2


Am I missing some other patches?


No, you miss nothing. Parth Dixit is still working on XEN ACPI for
ARM64, before it's in full function, how about introduce a Kconfig
CONFIG_XEN_ACPI and let it depends on x86? when XEN ACPI for ARM64
comes, we can enable ARM64 for CONFIG_XEN_ACPI and fix the problems
above.

Stefano, Parth, what do you think?


To be precise, Parth is working on ACPI enablement for the Xen
hypervisor at the moment (on the Xen tree), I don't think he has any
patches for Linux (Dom0 is the key use case). The two works could be
carried on in parallel, even though you would obviously need Parth's Xen
patches to test the Linux side.


Sure, I saw a workaround patch for the Linux side, if Parth need
any help for the further development, I will be there.



That said, I am OK with disabling ACPI for Xen on ARM and ARM64 for now
-- I wouldn't want to cause any significant delays to your patch series.


Thanks!

Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

On 2015年03月24日 02:32, Stefano Stabellini wrote:

On Sat, 21 Mar 2015, Hanjun Guo wrote:

+CC Parth Dixit, Stefano Stabellini.

On 2015年03月21日 02:54, Will Deacon wrote:

On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:

On 2015/3/19 3:05, Will Deacon wrote:

If you can get that in place, I'm not opposed to putting this into
linux-next ahead of the firmware summit in San Jose next week. Note that
this is not a commitment for 4.1, since I'm keen to see the outcomes of
next week before setting anything in stone.


OK, I will stick to this mailing list and respond as soon as I can.


This doesn't even build for me:


$ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- allmodconfig
$ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- Image

[...]

In file included from drivers/xen/acpi.c:33:0:


Sorry, I didn't build ACPI with XEN enabled on ARM64.


include/xen/acpi.h: In function ‘xen_acpi_sleep_register’:
include/xen/acpi.h:102:3: error: ‘acpi_suspend_lowlevel’ undeclared (first
use in this function)
 acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;


acpi_suspend_lowlevel is defined only for X86 and IA64 for now.


 ^
include/xen/acpi.h:102:3: note: each undeclared identifier is reported only
once for each function it appears in
drivers/xen/acpi.c: In function ‘xen_acpi_notify_hypervisor_state’:
drivers/xen/acpi.c:61:2: error: implicit declaration of function
‘HYPERVISOR_dom0_op’ [-Werror=implicit-function-declaration]
HYPERVISOR_dom0_op(op);


And this is only for x86:
./arch/x86/include/asm/xen/hypercall.h:HYPERVISOR_dom0_op(struct
xen_platform_op *platform_op)


^
cc1: some warnings being treated as errors
make[2]: *** [drivers/xen/acpi.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [drivers/xen] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [drivers] Error 2


Am I missing some other patches?


No, you miss nothing. Parth Dixit is still working on XEN ACPI for
ARM64, before it's in full function, how about introduce a Kconfig
CONFIG_XEN_ACPI and let it depends on x86? when XEN ACPI for ARM64
comes, we can enable ARM64 for CONFIG_XEN_ACPI and fix the problems
above.

Stefano, Parth, what do you think?


To be precise, Parth is working on ACPI enablement for the Xen
hypervisor at the moment (on the Xen tree), I don't think he has any
patches for Linux (Dom0 is the key use case). The two works could be
carried on in parallel, even though you would obviously need Parth's Xen
patches to test the Linux side.


Sure, I saw a workaround patch for the Linux side, if Parth need
any help for the further development, I will be there.



That said, I am OK with disabling ACPI for Xen on ARM and ARM64 for now
-- I wouldn't want to cause any significant delays to your patch series.


Thanks!

Hanjun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Stefano Stabellini]

On Mon, 23 Mar 2015, Hanjun Guo wrote:
> On 2015/3/23 6:11, Rafael J. Wysocki wrote:
> > On Sunday, March 22, 2015 09:32:48 PM Julien Grall wrote:
> >> On 22/03/2015 21:49, Rafael J. Wysocki wrote:
> >>> On Sunday, March 22, 2015 09:05:21 PM Julien Grall wrote:
>  Hello,
> 
>  On 21/03/2015 12:09, Naresh Bhat wrote:
> >   From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 
> > 2001
> >  From: Hanjun Guo  > >
> >  Date: Sat, 21 Mar 2015 14:43:54 +0800
> >  Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86
> >
> >  When ACPI is enabled on ARM64, XEN ACPI will also compiled
> >  into the kernel, but XEN ACPI is x86 dependent, so introduce
> >  CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
> >  functional on ARM64.
> >
> >  Signed-off-by: Hanjun Guo  >  >
> >  ---
> >drivers/xen/Kconfig  | 4 
> >drivers/xen/Makefile | 2 +-
> >2 files changed, 5 insertions(+), 1 deletion(-)
> >
> >  diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> >  index b812462..a31cd29 100644
> >  --- a/drivers/xen/Kconfig
> >  +++ b/drivers/xen/Kconfig
> >  @@ -253,4 +253,8 @@ config XEN_EFI
> >def_bool y
> >depends on X86_64 && EFI
> >
> >  +config XEN_ACPI
> >  +def_bool y
> >  +depends on X86 && ACPI
> >  +
> >endmenu
> >  diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> >  index 2ccd359..f4622ab 100644
> >  --- a/drivers/xen/Makefile
> >  +++ b/drivers/xen/Makefile
> >  @@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar
> >
> >dom0-$(CONFIG_PCI) += pci.o
> >dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
> >  -dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
> >  +dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
> >xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
> >dom0-$(CONFIG_X86) += pcpu.o
> >obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
>  [..]
> 
> > AFAIK,  There is already a kernel patch exists to fix this issue.  I
> > think  Julien or Parth is a right person to ask.  Hence I am CCed Julien
> > Grall too.
>  The ACPI support for Xen is not ready. So I think avoiding to compile
>  drivers/xen/acpi.c on ARM64/ARM seems the better solution for now.
> 
>  Although, rather than introducing a new CONFIG option, I would use the
>  same trick we use within the Makefile to avoid hotplug.c on ARM/ARM64.
> 
>  ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)), )
>  dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
>  endif
> >>> Well, is avoiding an extra CONFIG_ option worth the ugliness of this?
> >> When the support of ACPI for Xen will come, the CONFIG_ option will be 
> >> an alias to CONFIG_XEN.
> >>
> >> In this case the CONFIG_ option won't bring much improvement to the code 
> >> and add an extra indirection.
> >>
> >> The "ugliness" option has, at least, the advantage to be tiny and 
> >> self-contained.
> > Oh well, not really.  You're moving a config-time check to compile time
> > which means that it will be done every time this Makefile is executed
> > and for all architectures that execute it.  Not nice.
> >
> > Also I think that ia64 is missing from the list, but I may be wrong.
> 
> In commit d52eefb47d (ia64/xen: Remove Xen support for ia64), XEN is
> not supported anymore on ia64 now.
> 
> >
> > Not to mention the fact that the dependency will be rather difficult to find
> > for tools like xconfig ...
> 
> I also think introducing a CONFIG_ option is a better idea.

Me too
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Stefano Stabellini]

On Sat, 21 Mar 2015, Hanjun Guo wrote:
> +CC Parth Dixit, Stefano Stabellini.
> 
> On 2015年03月21日 02:54, Will Deacon wrote:
> > On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
> > > On 2015/3/19 3:05, Will Deacon wrote:
> > > > If you can get that in place, I'm not opposed to putting this into
> > > > linux-next ahead of the firmware summit in San Jose next week. Note that
> > > > this is not a commitment for 4.1, since I'm keen to see the outcomes of
> > > > next week before setting anything in stone.
> > > 
> > > OK, I will stick to this mailing list and respond as soon as I can.
> > 
> > This doesn't even build for me:
> > 
> > 
> > $ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- allmodconfig
> > $ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- Image
> > 
> > [...]
> > 
> > In file included from drivers/xen/acpi.c:33:0:
> 
> Sorry, I didn't build ACPI with XEN enabled on ARM64.
> 
> > include/xen/acpi.h: In function ‘xen_acpi_sleep_register’:
> > include/xen/acpi.h:102:3: error: ‘acpi_suspend_lowlevel’ undeclared (first
> > use in this function)
> > acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;
> 
> acpi_suspend_lowlevel is defined only for X86 and IA64 for now.
> 
> > ^
> > include/xen/acpi.h:102:3: note: each undeclared identifier is reported only
> > once for each function it appears in
> > drivers/xen/acpi.c: In function ‘xen_acpi_notify_hypervisor_state’:
> > drivers/xen/acpi.c:61:2: error: implicit declaration of function
> > ‘HYPERVISOR_dom0_op’ [-Werror=implicit-function-declaration]
> >HYPERVISOR_dom0_op();
> 
> And this is only for x86:
> ./arch/x86/include/asm/xen/hypercall.h:HYPERVISOR_dom0_op(struct
> xen_platform_op *platform_op)
> 
> >^
> > cc1: some warnings being treated as errors
> > make[2]: *** [drivers/xen/acpi.o] Error 1
> > make[2]: *** Waiting for unfinished jobs
> > make[1]: *** [drivers/xen] Error 2
> > make[1]: *** Waiting for unfinished jobs
> > make: *** [drivers] Error 2
> > 
> > 
> > Am I missing some other patches?
> 
> No, you miss nothing. Parth Dixit is still working on XEN ACPI for
> ARM64, before it's in full function, how about introduce a Kconfig
> CONFIG_XEN_ACPI and let it depends on x86? when XEN ACPI for ARM64
> comes, we can enable ARM64 for CONFIG_XEN_ACPI and fix the problems
> above.
> 
> Stefano, Parth, what do you think?
 
To be precise, Parth is working on ACPI enablement for the Xen
hypervisor at the moment (on the Xen tree), I don't think he has any
patches for Linux (Dom0 is the key use case). The two works could be
carried on in parallel, even though you would obviously need Parth's Xen
patches to test the Linux side.

That said, I am OK with disabling ACPI for Xen on ARM and ARM64 for now
-- I wouldn't want to cause any significant delays to your patch series.

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Stefano Stabellini]

On Mon, 23 Mar 2015, Hanjun Guo wrote:
 On 2015/3/23 6:11, Rafael J. Wysocki wrote:
  On Sunday, March 22, 2015 09:32:48 PM Julien Grall wrote:
  On 22/03/2015 21:49, Rafael J. Wysocki wrote:
  On Sunday, March 22, 2015 09:05:21 PM Julien Grall wrote:
  Hello,
 
  On 21/03/2015 12:09, Naresh Bhat wrote:
From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 
  2001
   From: Hanjun Guo hanjun@linaro.org 
  mailto:hanjun@linaro.org
   Date: Sat, 21 Mar 2015 14:43:54 +0800
   Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86
 
   When ACPI is enabled on ARM64, XEN ACPI will also compiled
   into the kernel, but XEN ACPI is x86 dependent, so introduce
   CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
   functional on ARM64.
 
   Signed-off-by: Hanjun Guo hanjun@linaro.org
   mailto:hanjun@linaro.org
   ---
 drivers/xen/Kconfig  | 4 
 drivers/xen/Makefile | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)
 
   diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
   index b812462..a31cd29 100644
   --- a/drivers/xen/Kconfig
   +++ b/drivers/xen/Kconfig
   @@ -253,4 +253,8 @@ config XEN_EFI
 def_bool y
 depends on X86_64  EFI
 
   +config XEN_ACPI
   +def_bool y
   +depends on X86  ACPI
   +
 endmenu
   diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
   index 2ccd359..f4622ab 100644
   --- a/drivers/xen/Makefile
   +++ b/drivers/xen/Makefile
   @@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar
 
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
   -dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
   +dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
 xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
 dom0-$(CONFIG_X86) += pcpu.o
 obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
  [..]
 
  AFAIK,  There is already a kernel patch exists to fix this issue.  I
  think  Julien or Parth is a right person to ask.  Hence I am CCed Julien
  Grall too.
  The ACPI support for Xen is not ready. So I think avoiding to compile
  drivers/xen/acpi.c on ARM64/ARM seems the better solution for now.
 
  Although, rather than introducing a new CONFIG option, I would use the
  same trick we use within the Makefile to avoid hotplug.c on ARM/ARM64.
 
  ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)), )
  dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
  endif
  Well, is avoiding an extra CONFIG_ option worth the ugliness of this?
  When the support of ACPI for Xen will come, the CONFIG_ option will be 
  an alias to CONFIG_XEN.
 
  In this case the CONFIG_ option won't bring much improvement to the code 
  and add an extra indirection.
 
  The ugliness option has, at least, the advantage to be tiny and 
  self-contained.
  Oh well, not really.  You're moving a config-time check to compile time
  which means that it will be done every time this Makefile is executed
  and for all architectures that execute it.  Not nice.
 
  Also I think that ia64 is missing from the list, but I may be wrong.
 
 In commit d52eefb47d (ia64/xen: Remove Xen support for ia64), XEN is
 not supported anymore on ia64 now.
 
 
  Not to mention the fact that the dependency will be rather difficult to find
  for tools like xconfig ...
 
 I also think introducing a CONFIG_ option is a better idea.

Me too
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Stefano Stabellini]

On Sat, 21 Mar 2015, Hanjun Guo wrote:
 +CC Parth Dixit, Stefano Stabellini.
 
 On 2015年03月21日 02:54, Will Deacon wrote:
  On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
   On 2015/3/19 3:05, Will Deacon wrote:
If you can get that in place, I'm not opposed to putting this into
linux-next ahead of the firmware summit in San Jose next week. Note that
this is not a commitment for 4.1, since I'm keen to see the outcomes of
next week before setting anything in stone.
   
   OK, I will stick to this mailing list and respond as soon as I can.
  
  This doesn't even build for me:
  
  
  $ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- allmodconfig
  $ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- Image
  
  [...]
  
  In file included from drivers/xen/acpi.c:33:0:
 
 Sorry, I didn't build ACPI with XEN enabled on ARM64.
 
  include/xen/acpi.h: In function ‘xen_acpi_sleep_register’:
  include/xen/acpi.h:102:3: error: ‘acpi_suspend_lowlevel’ undeclared (first
  use in this function)
  acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;
 
 acpi_suspend_lowlevel is defined only for X86 and IA64 for now.
 
  ^
  include/xen/acpi.h:102:3: note: each undeclared identifier is reported only
  once for each function it appears in
  drivers/xen/acpi.c: In function ‘xen_acpi_notify_hypervisor_state’:
  drivers/xen/acpi.c:61:2: error: implicit declaration of function
  ‘HYPERVISOR_dom0_op’ [-Werror=implicit-function-declaration]
 HYPERVISOR_dom0_op(op);
 
 And this is only for x86:
 ./arch/x86/include/asm/xen/hypercall.h:HYPERVISOR_dom0_op(struct
 xen_platform_op *platform_op)
 
 ^
  cc1: some warnings being treated as errors
  make[2]: *** [drivers/xen/acpi.o] Error 1
  make[2]: *** Waiting for unfinished jobs
  make[1]: *** [drivers/xen] Error 2
  make[1]: *** Waiting for unfinished jobs
  make: *** [drivers] Error 2
  
  
  Am I missing some other patches?
 
 No, you miss nothing. Parth Dixit is still working on XEN ACPI for
 ARM64, before it's in full function, how about introduce a Kconfig
 CONFIG_XEN_ACPI and let it depends on x86? when XEN ACPI for ARM64
 comes, we can enable ARM64 for CONFIG_XEN_ACPI and fix the problems
 above.
 
 Stefano, Parth, what do you think?
 
To be precise, Parth is working on ACPI enablement for the Xen
hypervisor at the moment (on the Xen tree), I don't think he has any
patches for Linux (Dom0 is the key use case). The two works could be
carried on in parallel, even though you would obviously need Parth's Xen
patches to test the Linux side.

That said, I am OK with disabling ACPI for Xen on ARM and ARM64 for now
-- I wouldn't want to cause any significant delays to your patch series.

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

On 2015/3/23 6:11, Rafael J. Wysocki wrote:
> On Sunday, March 22, 2015 09:32:48 PM Julien Grall wrote:
>> On 22/03/2015 21:49, Rafael J. Wysocki wrote:
>>> On Sunday, March 22, 2015 09:05:21 PM Julien Grall wrote:
 Hello,

 On 21/03/2015 12:09, Naresh Bhat wrote:
>   From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 
> 2001
>  From: Hanjun Guo  >
>  Date: Sat, 21 Mar 2015 14:43:54 +0800
>  Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86
>
>  When ACPI is enabled on ARM64, XEN ACPI will also compiled
>  into the kernel, but XEN ACPI is x86 dependent, so introduce
>  CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
>  functional on ARM64.
>
>  Signed-off-by: Hanjun Guo   >
>  ---
>drivers/xen/Kconfig  | 4 
>drivers/xen/Makefile | 2 +-
>2 files changed, 5 insertions(+), 1 deletion(-)
>
>  diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
>  index b812462..a31cd29 100644
>  --- a/drivers/xen/Kconfig
>  +++ b/drivers/xen/Kconfig
>  @@ -253,4 +253,8 @@ config XEN_EFI
>def_bool y
>depends on X86_64 && EFI
>
>  +config XEN_ACPI
>  +def_bool y
>  +depends on X86 && ACPI
>  +
>endmenu
>  diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
>  index 2ccd359..f4622ab 100644
>  --- a/drivers/xen/Makefile
>  +++ b/drivers/xen/Makefile
>  @@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar
>
>dom0-$(CONFIG_PCI) += pci.o
>dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
>  -dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
>  +dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
>xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
>dom0-$(CONFIG_X86) += pcpu.o
>obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
 [..]

> AFAIK,  There is already a kernel patch exists to fix this issue.  I
> think  Julien or Parth is a right person to ask.  Hence I am CCed Julien
> Grall too.
 The ACPI support for Xen is not ready. So I think avoiding to compile
 drivers/xen/acpi.c on ARM64/ARM seems the better solution for now.

 Although, rather than introducing a new CONFIG option, I would use the
 same trick we use within the Makefile to avoid hotplug.c on ARM/ARM64.

 ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)), )
 dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
 endif
>>> Well, is avoiding an extra CONFIG_ option worth the ugliness of this?
>> When the support of ACPI for Xen will come, the CONFIG_ option will be 
>> an alias to CONFIG_XEN.
>>
>> In this case the CONFIG_ option won't bring much improvement to the code 
>> and add an extra indirection.
>>
>> The "ugliness" option has, at least, the advantage to be tiny and 
>> self-contained.
> Oh well, not really.  You're moving a config-time check to compile time
> which means that it will be done every time this Makefile is executed
> and for all architectures that execute it.  Not nice.
>
> Also I think that ia64 is missing from the list, but I may be wrong.

In commit d52eefb47d (ia64/xen: Remove Xen support for ia64), XEN is
not supported anymore on ia64 now.

>
> Not to mention the fact that the dependency will be rather difficult to find
> for tools like xconfig ...

I also think introducing a CONFIG_ option is a better idea.

Thanks
Hanjun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Rafael J. Wysocki]

On Sunday, March 22, 2015 09:32:48 PM Julien Grall wrote:
> 
> On 22/03/2015 21:49, Rafael J. Wysocki wrote:
> > On Sunday, March 22, 2015 09:05:21 PM Julien Grall wrote:
> >> Hello,
> >>
> >> On 21/03/2015 12:09, Naresh Bhat wrote:
> >>>   From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 
> >>> 2001
> >>>  From: Hanjun Guo  >>> >
> >>>  Date: Sat, 21 Mar 2015 14:43:54 +0800
> >>>  Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86
> >>>
> >>>  When ACPI is enabled on ARM64, XEN ACPI will also compiled
> >>>  into the kernel, but XEN ACPI is x86 dependent, so introduce
> >>>  CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
> >>>  functional on ARM64.
> >>>
> >>>  Signed-off-by: Hanjun Guo  >>>  >
> >>>  ---
> >>>drivers/xen/Kconfig  | 4 
> >>>drivers/xen/Makefile | 2 +-
> >>>2 files changed, 5 insertions(+), 1 deletion(-)
> >>>
> >>>  diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> >>>  index b812462..a31cd29 100644
> >>>  --- a/drivers/xen/Kconfig
> >>>  +++ b/drivers/xen/Kconfig
> >>>  @@ -253,4 +253,8 @@ config XEN_EFI
> >>>def_bool y
> >>>depends on X86_64 && EFI
> >>>
> >>>  +config XEN_ACPI
> >>>  +def_bool y
> >>>  +depends on X86 && ACPI
> >>>  +
> >>>endmenu
> >>>  diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> >>>  index 2ccd359..f4622ab 100644
> >>>  --- a/drivers/xen/Makefile
> >>>  +++ b/drivers/xen/Makefile
> >>>  @@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar
> >>>
> >>>dom0-$(CONFIG_PCI) += pci.o
> >>>dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
> >>>  -dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
> >>>  +dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
> >>>xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
> >>>dom0-$(CONFIG_X86) += pcpu.o
> >>>obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
> >>
> >> [..]
> >>
> >>>
> >>> AFAIK,  There is already a kernel patch exists to fix this issue.  I
> >>> think  Julien or Parth is a right person to ask.  Hence I am CCed Julien
> >>> Grall too.
> >>
> >> The ACPI support for Xen is not ready. So I think avoiding to compile
> >> drivers/xen/acpi.c on ARM64/ARM seems the better solution for now.
> >>
> >> Although, rather than introducing a new CONFIG option, I would use the
> >> same trick we use within the Makefile to avoid hotplug.c on ARM/ARM64.
> >>
> >> ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)), )
> >> dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
> >> endif
> >
> > Well, is avoiding an extra CONFIG_ option worth the ugliness of this?
> 
> When the support of ACPI for Xen will come, the CONFIG_ option will be 
> an alias to CONFIG_XEN.
> 
> In this case the CONFIG_ option won't bring much improvement to the code 
> and add an extra indirection.
> 
> The "ugliness" option has, at least, the advantage to be tiny and 
> self-contained.

Oh well, not really.  You're moving a config-time check to compile time
which means that it will be done every time this Makefile is executed
and for all architectures that execute it.  Not nice.

Also I think that ia64 is missing from the list, but I may be wrong.

Not to mention the fact that the dependency will be rather difficult to find
for tools like xconfig ...


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Julien Grall]

On 22/03/2015 21:49, Rafael J. Wysocki wrote:

On Sunday, March 22, 2015 09:05:21 PM Julien Grall wrote:

Hello,

On 21/03/2015 12:09, Naresh Bhat wrote:

  From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 2001
 From: Hanjun Guo mailto:hanjun@linaro.org>>
 Date: Sat, 21 Mar 2015 14:43:54 +0800
 Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86

 When ACPI is enabled on ARM64, XEN ACPI will also compiled
 into the kernel, but XEN ACPI is x86 dependent, so introduce
 CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
 functional on ARM64.

 Signed-off-by: Hanjun Guo mailto:hanjun@linaro.org>>
 ---
   drivers/xen/Kconfig  | 4 
   drivers/xen/Makefile | 2 +-
   2 files changed, 5 insertions(+), 1 deletion(-)

 diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
 index b812462..a31cd29 100644
 --- a/drivers/xen/Kconfig
 +++ b/drivers/xen/Kconfig
 @@ -253,4 +253,8 @@ config XEN_EFI
   def_bool y
   depends on X86_64 && EFI

 +config XEN_ACPI
 +def_bool y
 +depends on X86 && ACPI
 +
   endmenu
 diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
 index 2ccd359..f4622ab 100644
 --- a/drivers/xen/Makefile
 +++ b/drivers/xen/Makefile
 @@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar

   dom0-$(CONFIG_PCI) += pci.o
   dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
 -dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
 +dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
   xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
   dom0-$(CONFIG_X86) += pcpu.o
   obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)


[..]



AFAIK,  There is already a kernel patch exists to fix this issue.  I
think  Julien or Parth is a right person to ask.  Hence I am CCed Julien
Grall too.


The ACPI support for Xen is not ready. So I think avoiding to compile
drivers/xen/acpi.c on ARM64/ARM seems the better solution for now.

Although, rather than introducing a new CONFIG option, I would use the
same trick we use within the Makefile to avoid hotplug.c on ARM/ARM64.

ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)), )
dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
endif


Well, is avoiding an extra CONFIG_ option worth the ugliness of this?


When the support of ACPI for Xen will come, the CONFIG_ option will be 
an alias to CONFIG_XEN.


In this case the CONFIG_ option won't bring much improvement to the code 
and add an extra indirection.


The "ugliness" option has, at least, the advantage to be tiny and 
self-contained.


Regards,

--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Rafael J. Wysocki]

On Sunday, March 22, 2015 09:05:21 PM Julien Grall wrote:
> Hello,
> 
> On 21/03/2015 12:09, Naresh Bhat wrote:
> >  From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 2001
> > From: Hanjun Guo mailto:hanjun@linaro.org>>
> > Date: Sat, 21 Mar 2015 14:43:54 +0800
> > Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86
> >
> > When ACPI is enabled on ARM64, XEN ACPI will also compiled
> > into the kernel, but XEN ACPI is x86 dependent, so introduce
> > CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
> > functional on ARM64.
> >
> > Signed-off-by: Hanjun Guo  > >
> > ---
> >   drivers/xen/Kconfig  | 4 
> >   drivers/xen/Makefile | 2 +-
> >   2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > index b812462..a31cd29 100644
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -253,4 +253,8 @@ config XEN_EFI
> >   def_bool y
> >   depends on X86_64 && EFI
> >
> > +config XEN_ACPI
> > +def_bool y
> > +depends on X86 && ACPI
> > +
> >   endmenu
> > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> > index 2ccd359..f4622ab 100644
> > --- a/drivers/xen/Makefile
> > +++ b/drivers/xen/Makefile
> > @@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar
> >
> >   dom0-$(CONFIG_PCI) += pci.o
> >   dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
> > -dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
> > +dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
> >   xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
> >   dom0-$(CONFIG_X86) += pcpu.o
> >   obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
> 
> [..]
> 
> >
> > AFAIK,  There is already a kernel patch exists to fix this issue.  I
> > think  Julien or Parth is a right person to ask.  Hence I am CCed Julien
> > Grall too.
> 
> The ACPI support for Xen is not ready. So I think avoiding to compile 
> drivers/xen/acpi.c on ARM64/ARM seems the better solution for now.
> 
> Although, rather than introducing a new CONFIG option, I would use the 
> same trick we use within the Makefile to avoid hotplug.c on ARM/ARM64.
> 
> ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)), )
> dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
> endif

Well, is avoiding an extra CONFIG_ option worth the ugliness of this?


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Julien Grall]

Hello,

On 21/03/2015 12:09, Naresh Bhat wrote:

 From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 2001
From: Hanjun Guo mailto:hanjun@linaro.org>>
Date: Sat, 21 Mar 2015 14:43:54 +0800
Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86

When ACPI is enabled on ARM64, XEN ACPI will also compiled
into the kernel, but XEN ACPI is x86 dependent, so introduce
CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
functional on ARM64.

Signed-off-by: Hanjun Guo mailto:hanjun@linaro.org>>
---
  drivers/xen/Kconfig  | 4 
  drivers/xen/Makefile | 2 +-
  2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index b812462..a31cd29 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -253,4 +253,8 @@ config XEN_EFI
  def_bool y
  depends on X86_64 && EFI

+config XEN_ACPI
+def_bool y
+depends on X86 && ACPI
+
  endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 2ccd359..f4622ab 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar

  dom0-$(CONFIG_PCI) += pci.o
  dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
-dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
+dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
  xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
  dom0-$(CONFIG_X86) += pcpu.o
  obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)


[..]



AFAIK,  There is already a kernel patch exists to fix this issue.  I
think  Julien or Parth is a right person to ask.  Hence I am CCed Julien
Grall too.


The ACPI support for Xen is not ready. So I think avoiding to compile 
drivers/xen/acpi.c on ARM64/ARM seems the better solution for now.


Although, rather than introducing a new CONFIG option, I would use the 
same trick we use within the Makefile to avoid hotplug.c on ARM/ARM64.


ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)), )
dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
endif

Regards,

--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Julien Grall]

Hello,

On 21/03/2015 12:09, Naresh Bhat wrote:

 From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 2001
From: Hanjun Guo hanjun@linaro.org mailto:hanjun@linaro.org
Date: Sat, 21 Mar 2015 14:43:54 +0800
Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86

When ACPI is enabled on ARM64, XEN ACPI will also compiled
into the kernel, but XEN ACPI is x86 dependent, so introduce
CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
functional on ARM64.

Signed-off-by: Hanjun Guo hanjun@linaro.org
mailto:hanjun@linaro.org
---
  drivers/xen/Kconfig  | 4 
  drivers/xen/Makefile | 2 +-
  2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index b812462..a31cd29 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -253,4 +253,8 @@ config XEN_EFI
  def_bool y
  depends on X86_64  EFI

+config XEN_ACPI
+def_bool y
+depends on X86  ACPI
+
  endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 2ccd359..f4622ab 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar

  dom0-$(CONFIG_PCI) += pci.o
  dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
-dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
+dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
  xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
  dom0-$(CONFIG_X86) += pcpu.o
  obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)


[..]



AFAIK,  There is already a kernel patch exists to fix this issue.  I
think  Julien or Parth is a right person to ask.  Hence I am CCed Julien
Grall too.


The ACPI support for Xen is not ready. So I think avoiding to compile 
drivers/xen/acpi.c on ARM64/ARM seems the better solution for now.


Although, rather than introducing a new CONFIG option, I would use the 
same trick we use within the Makefile to avoid hotplug.c on ARM/ARM64.


ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)), )
dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
endif

Regards,

--
Julien Grall
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Rafael J. Wysocki]

On Sunday, March 22, 2015 09:05:21 PM Julien Grall wrote:
 Hello,
 
 On 21/03/2015 12:09, Naresh Bhat wrote:
   From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 2001
  From: Hanjun Guo hanjun@linaro.org mailto:hanjun@linaro.org
  Date: Sat, 21 Mar 2015 14:43:54 +0800
  Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86
 
  When ACPI is enabled on ARM64, XEN ACPI will also compiled
  into the kernel, but XEN ACPI is x86 dependent, so introduce
  CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
  functional on ARM64.
 
  Signed-off-by: Hanjun Guo hanjun@linaro.org
  mailto:hanjun@linaro.org
  ---
drivers/xen/Kconfig  | 4 
drivers/xen/Makefile | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
  index b812462..a31cd29 100644
  --- a/drivers/xen/Kconfig
  +++ b/drivers/xen/Kconfig
  @@ -253,4 +253,8 @@ config XEN_EFI
def_bool y
depends on X86_64  EFI
 
  +config XEN_ACPI
  +def_bool y
  +depends on X86  ACPI
  +
endmenu
  diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
  index 2ccd359..f4622ab 100644
  --- a/drivers/xen/Makefile
  +++ b/drivers/xen/Makefile
  @@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar
 
dom0-$(CONFIG_PCI) += pci.o
dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
  -dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
  +dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
dom0-$(CONFIG_X86) += pcpu.o
obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
 
 [..]
 
 
  AFAIK,  There is already a kernel patch exists to fix this issue.  I
  think  Julien or Parth is a right person to ask.  Hence I am CCed Julien
  Grall too.
 
 The ACPI support for Xen is not ready. So I think avoiding to compile 
 drivers/xen/acpi.c on ARM64/ARM seems the better solution for now.
 
 Although, rather than introducing a new CONFIG option, I would use the 
 same trick we use within the Makefile to avoid hotplug.c on ARM/ARM64.
 
 ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)), )
 dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
 endif

Well, is avoiding an extra CONFIG_ option worth the ugliness of this?


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Julien Grall]

On 22/03/2015 21:49, Rafael J. Wysocki wrote:

On Sunday, March 22, 2015 09:05:21 PM Julien Grall wrote:

Hello,

On 21/03/2015 12:09, Naresh Bhat wrote:

  From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 2001
 From: Hanjun Guo hanjun@linaro.org mailto:hanjun@linaro.org
 Date: Sat, 21 Mar 2015 14:43:54 +0800
 Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86

 When ACPI is enabled on ARM64, XEN ACPI will also compiled
 into the kernel, but XEN ACPI is x86 dependent, so introduce
 CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
 functional on ARM64.

 Signed-off-by: Hanjun Guo hanjun@linaro.org
 mailto:hanjun@linaro.org
 ---
   drivers/xen/Kconfig  | 4 
   drivers/xen/Makefile | 2 +-
   2 files changed, 5 insertions(+), 1 deletion(-)

 diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
 index b812462..a31cd29 100644
 --- a/drivers/xen/Kconfig
 +++ b/drivers/xen/Kconfig
 @@ -253,4 +253,8 @@ config XEN_EFI
   def_bool y
   depends on X86_64  EFI

 +config XEN_ACPI
 +def_bool y
 +depends on X86  ACPI
 +
   endmenu
 diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
 index 2ccd359..f4622ab 100644
 --- a/drivers/xen/Makefile
 +++ b/drivers/xen/Makefile
 @@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar

   dom0-$(CONFIG_PCI) += pci.o
   dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
 -dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
 +dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
   xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
   dom0-$(CONFIG_X86) += pcpu.o
   obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)


[..]



AFAIK,  There is already a kernel patch exists to fix this issue.  I
think  Julien or Parth is a right person to ask.  Hence I am CCed Julien
Grall too.


The ACPI support for Xen is not ready. So I think avoiding to compile
drivers/xen/acpi.c on ARM64/ARM seems the better solution for now.

Although, rather than introducing a new CONFIG option, I would use the
same trick we use within the Makefile to avoid hotplug.c on ARM/ARM64.

ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)), )
dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
endif


Well, is avoiding an extra CONFIG_ option worth the ugliness of this?


When the support of ACPI for Xen will come, the CONFIG_ option will be 
an alias to CONFIG_XEN.


In this case the CONFIG_ option won't bring much improvement to the code 
and add an extra indirection.


The ugliness option has, at least, the advantage to be tiny and 
self-contained.


Regards,

--
Julien Grall
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Rafael J. Wysocki]

On Sunday, March 22, 2015 09:32:48 PM Julien Grall wrote:
 
 On 22/03/2015 21:49, Rafael J. Wysocki wrote:
  On Sunday, March 22, 2015 09:05:21 PM Julien Grall wrote:
  Hello,
 
  On 21/03/2015 12:09, Naresh Bhat wrote:
From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 
  2001
   From: Hanjun Guo hanjun@linaro.org 
  mailto:hanjun@linaro.org
   Date: Sat, 21 Mar 2015 14:43:54 +0800
   Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86
 
   When ACPI is enabled on ARM64, XEN ACPI will also compiled
   into the kernel, but XEN ACPI is x86 dependent, so introduce
   CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
   functional on ARM64.
 
   Signed-off-by: Hanjun Guo hanjun@linaro.org
   mailto:hanjun@linaro.org
   ---
 drivers/xen/Kconfig  | 4 
 drivers/xen/Makefile | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)
 
   diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
   index b812462..a31cd29 100644
   --- a/drivers/xen/Kconfig
   +++ b/drivers/xen/Kconfig
   @@ -253,4 +253,8 @@ config XEN_EFI
 def_bool y
 depends on X86_64  EFI
 
   +config XEN_ACPI
   +def_bool y
   +depends on X86  ACPI
   +
 endmenu
   diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
   index 2ccd359..f4622ab 100644
   --- a/drivers/xen/Makefile
   +++ b/drivers/xen/Makefile
   @@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar
 
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
   -dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
   +dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
 xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
 dom0-$(CONFIG_X86) += pcpu.o
 obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
 
  [..]
 
 
  AFAIK,  There is already a kernel patch exists to fix this issue.  I
  think  Julien or Parth is a right person to ask.  Hence I am CCed Julien
  Grall too.
 
  The ACPI support for Xen is not ready. So I think avoiding to compile
  drivers/xen/acpi.c on ARM64/ARM seems the better solution for now.
 
  Although, rather than introducing a new CONFIG option, I would use the
  same trick we use within the Makefile to avoid hotplug.c on ARM/ARM64.
 
  ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)), )
  dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
  endif
 
  Well, is avoiding an extra CONFIG_ option worth the ugliness of this?
 
 When the support of ACPI for Xen will come, the CONFIG_ option will be 
 an alias to CONFIG_XEN.
 
 In this case the CONFIG_ option won't bring much improvement to the code 
 and add an extra indirection.
 
 The ugliness option has, at least, the advantage to be tiny and 
 self-contained.

Oh well, not really.  You're moving a config-time check to compile time
which means that it will be done every time this Makefile is executed
and for all architectures that execute it.  Not nice.

Also I think that ia64 is missing from the list, but I may be wrong.

Not to mention the fact that the dependency will be rather difficult to find
for tools like xconfig ...


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

On 2015/3/23 6:11, Rafael J. Wysocki wrote:
 On Sunday, March 22, 2015 09:32:48 PM Julien Grall wrote:
 On 22/03/2015 21:49, Rafael J. Wysocki wrote:
 On Sunday, March 22, 2015 09:05:21 PM Julien Grall wrote:
 Hello,

 On 21/03/2015 12:09, Naresh Bhat wrote:
   From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 
 2001
  From: Hanjun Guo hanjun@linaro.org 
 mailto:hanjun@linaro.org
  Date: Sat, 21 Mar 2015 14:43:54 +0800
  Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86

  When ACPI is enabled on ARM64, XEN ACPI will also compiled
  into the kernel, but XEN ACPI is x86 dependent, so introduce
  CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
  functional on ARM64.

  Signed-off-by: Hanjun Guo hanjun@linaro.org
  mailto:hanjun@linaro.org
  ---
drivers/xen/Kconfig  | 4 
drivers/xen/Makefile | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)

  diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
  index b812462..a31cd29 100644
  --- a/drivers/xen/Kconfig
  +++ b/drivers/xen/Kconfig
  @@ -253,4 +253,8 @@ config XEN_EFI
def_bool y
depends on X86_64  EFI

  +config XEN_ACPI
  +def_bool y
  +depends on X86  ACPI
  +
endmenu
  diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
  index 2ccd359..f4622ab 100644
  --- a/drivers/xen/Makefile
  +++ b/drivers/xen/Makefile
  @@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar

dom0-$(CONFIG_PCI) += pci.o
dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
  -dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
  +dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
dom0-$(CONFIG_X86) += pcpu.o
obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
 [..]

 AFAIK,  There is already a kernel patch exists to fix this issue.  I
 think  Julien or Parth is a right person to ask.  Hence I am CCed Julien
 Grall too.
 The ACPI support for Xen is not ready. So I think avoiding to compile
 drivers/xen/acpi.c on ARM64/ARM seems the better solution for now.

 Although, rather than introducing a new CONFIG option, I would use the
 same trick we use within the Makefile to avoid hotplug.c on ARM/ARM64.

 ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)), )
 dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
 endif
 Well, is avoiding an extra CONFIG_ option worth the ugliness of this?
 When the support of ACPI for Xen will come, the CONFIG_ option will be 
 an alias to CONFIG_XEN.

 In this case the CONFIG_ option won't bring much improvement to the code 
 and add an extra indirection.

 The ugliness option has, at least, the advantage to be tiny and 
 self-contained.
 Oh well, not really.  You're moving a config-time check to compile time
 which means that it will be done every time this Makefile is executed
 and for all architectures that execute it.  Not nice.

 Also I think that ia64 is missing from the list, but I may be wrong.

In commit d52eefb47d (ia64/xen: Remove Xen support for ia64), XEN is
not supported anymore on ia64 now.


 Not to mention the fact that the dependency will be rather difficult to find
 for tools like xconfig ...

I also think introducing a CONFIG_ option is a better idea.

Thanks
Hanjun

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

On 2015/3/21 11:17, Hanjun Guo wrote:
> +CC Parth Dixit, Stefano Stabellini.
>
> On 2015年03月21日 02:54, Will Deacon wrote:
>> On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
>>> On 2015/3/19 3:05, Will Deacon wrote:
 If you can get that in place, I'm not opposed to putting this into
 linux-next ahead of the firmware summit in San Jose next week. Note that
 this is not a commitment for 4.1, since I'm keen to see the outcomes of
 next week before setting anything in stone.
>>>
>>> OK, I will stick to this mailing list and respond as soon as I can.
>>
>> This doesn't even build for me:
>>
>>
>> $ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- allmodconfig
>> $ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- Image
>>
>> [...]
>>
>> In file included from drivers/xen/acpi.c:33:0:
>
> Sorry, I didn't build ACPI with XEN enabled on ARM64.
>
>> include/xen/acpi.h: In function ‘xen_acpi_sleep_register’:
>> include/xen/acpi.h:102:3: error: ‘acpi_suspend_lowlevel’ undeclared (first 
>> use in this function)
>> acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;
>
> acpi_suspend_lowlevel is defined only for X86 and IA64 for now.
>
>> ^
>> include/xen/acpi.h:102:3: note: each undeclared identifier is reported only 
>> once for each function it appears in
>> drivers/xen/acpi.c: In function ‘xen_acpi_notify_hypervisor_state’:
>> drivers/xen/acpi.c:61:2: error: implicit declaration of function 
>> ‘HYPERVISOR_dom0_op’ [-Werror=implicit-function-declaration]
>>HYPERVISOR_dom0_op();
>
> And this is only for x86:
> ./arch/x86/include/asm/xen/hypercall.h:HYPERVISOR_dom0_op(struct 
> xen_platform_op *platform_op)
>
>>^
>> cc1: some warnings being treated as errors
>> make[2]: *** [drivers/xen/acpi.o] Error 1
>> make[2]: *** Waiting for unfinished jobs
>> make[1]: *** [drivers/xen] Error 2
>> make[1]: *** Waiting for unfinished jobs
>> make: *** [drivers] Error 2
>>
>>
>> Am I missing some other patches?
>
> No, you miss nothing. Parth Dixit is still working on XEN ACPI for
> ARM64, before it's in full function, how about introduce a Kconfig
> CONFIG_XEN_ACPI and let it depends on x86? when XEN ACPI for ARM64
> comes, we can enable ARM64 for CONFIG_XEN_ACPI and fix the problems
> above.
>
> Stefano, Parth, what do you think?

I prepared a patch for further reference:

>From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 2001
From: Hanjun Guo 
Date: Sat, 21 Mar 2015 14:43:54 +0800
Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86

When ACPI is enabled on ARM64, XEN ACPI will also compiled
into the kernel, but XEN ACPI is x86 dependent, so introduce
CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
functional on ARM64.

Signed-off-by: Hanjun Guo 
---
 drivers/xen/Kconfig  | 4 
 drivers/xen/Makefile | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index b812462..a31cd29 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -253,4 +253,8 @@ config XEN_EFI
 def_bool y
 depends on X86_64 && EFI
 
+config XEN_ACPI
+def_bool y
+depends on X86 && ACPI
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 2ccd359..f4622ab 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar
 
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
-dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
+dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
 xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
 dom0-$(CONFIG_X86) += pcpu.o
 obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
-- 
1.7.12.4



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

On 2015/3/21 11:17, Hanjun Guo wrote:
 +CC Parth Dixit, Stefano Stabellini.

 On 2015年03月21日 02:54, Will Deacon wrote:
 On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
 On 2015/3/19 3:05, Will Deacon wrote:
 If you can get that in place, I'm not opposed to putting this into
 linux-next ahead of the firmware summit in San Jose next week. Note that
 this is not a commitment for 4.1, since I'm keen to see the outcomes of
 next week before setting anything in stone.

 OK, I will stick to this mailing list and respond as soon as I can.

 This doesn't even build for me:


 $ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- allmodconfig
 $ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- Image

 [...]

 In file included from drivers/xen/acpi.c:33:0:

 Sorry, I didn't build ACPI with XEN enabled on ARM64.

 include/xen/acpi.h: In function ‘xen_acpi_sleep_register’:
 include/xen/acpi.h:102:3: error: ‘acpi_suspend_lowlevel’ undeclared (first 
 use in this function)
 acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;

 acpi_suspend_lowlevel is defined only for X86 and IA64 for now.

 ^
 include/xen/acpi.h:102:3: note: each undeclared identifier is reported only 
 once for each function it appears in
 drivers/xen/acpi.c: In function ‘xen_acpi_notify_hypervisor_state’:
 drivers/xen/acpi.c:61:2: error: implicit declaration of function 
 ‘HYPERVISOR_dom0_op’ [-Werror=implicit-function-declaration]
HYPERVISOR_dom0_op(op);

 And this is only for x86:
 ./arch/x86/include/asm/xen/hypercall.h:HYPERVISOR_dom0_op(struct 
 xen_platform_op *platform_op)

^
 cc1: some warnings being treated as errors
 make[2]: *** [drivers/xen/acpi.o] Error 1
 make[2]: *** Waiting for unfinished jobs
 make[1]: *** [drivers/xen] Error 2
 make[1]: *** Waiting for unfinished jobs
 make: *** [drivers] Error 2


 Am I missing some other patches?

 No, you miss nothing. Parth Dixit is still working on XEN ACPI for
 ARM64, before it's in full function, how about introduce a Kconfig
 CONFIG_XEN_ACPI and let it depends on x86? when XEN ACPI for ARM64
 comes, we can enable ARM64 for CONFIG_XEN_ACPI and fix the problems
 above.

 Stefano, Parth, what do you think?

I prepared a patch for further reference:

From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 2001
From: Hanjun Guo hanjun@linaro.org
Date: Sat, 21 Mar 2015 14:43:54 +0800
Subject: [PATCH] XEN / ACPI: Make XEN ACPI depend on X86

When ACPI is enabled on ARM64, XEN ACPI will also compiled
into the kernel, but XEN ACPI is x86 dependent, so introduce
CONFIG_XEN_ACPI to make it depend on x86 before XEN ACPI is
functional on ARM64.

Signed-off-by: Hanjun Guo hanjun@linaro.org
---
 drivers/xen/Kconfig  | 4 
 drivers/xen/Makefile | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index b812462..a31cd29 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -253,4 +253,8 @@ config XEN_EFI
 def_bool y
 depends on X86_64  EFI
 
+config XEN_ACPI
+def_bool y
+depends on X86  ACPI
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 2ccd359..f4622ab 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -13,7 +13,7 @@ CFLAGS_efi.o+= -fshort-wchar
 
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
-dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
+dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
 xen-pad-$(CONFIG_X86) += xen-acpi-pad.o
 dom0-$(CONFIG_X86) += pcpu.o
 obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
-- 
1.7.12.4



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

+CC Parth Dixit, Stefano Stabellini.

On 2015年03月21日 02:54, Will Deacon wrote:

On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:

On 2015/3/19 3:05, Will Deacon wrote:

If you can get that in place, I'm not opposed to putting this into
linux-next ahead of the firmware summit in San Jose next week. Note that
this is not a commitment for 4.1, since I'm keen to see the outcomes of
next week before setting anything in stone.


OK, I will stick to this mailing list and respond as soon as I can.


This doesn't even build for me:


$ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- allmodconfig
$ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- Image

[...]

In file included from drivers/xen/acpi.c:33:0:


Sorry, I didn't build ACPI with XEN enabled on ARM64.


include/xen/acpi.h: In function ‘xen_acpi_sleep_register’:
include/xen/acpi.h:102:3: error: ‘acpi_suspend_lowlevel’ undeclared (first use 
in this function)
acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;


acpi_suspend_lowlevel is defined only for X86 and IA64 for now.


^
include/xen/acpi.h:102:3: note: each undeclared identifier is reported only 
once for each function it appears in
drivers/xen/acpi.c: In function ‘xen_acpi_notify_hypervisor_state’:
drivers/xen/acpi.c:61:2: error: implicit declaration of function 
‘HYPERVISOR_dom0_op’ [-Werror=implicit-function-declaration]
   HYPERVISOR_dom0_op();


And this is only for x86:
./arch/x86/include/asm/xen/hypercall.h:HYPERVISOR_dom0_op(struct 
xen_platform_op *platform_op)



   ^
cc1: some warnings being treated as errors
make[2]: *** [drivers/xen/acpi.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [drivers/xen] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [drivers] Error 2


Am I missing some other patches?


No, you miss nothing. Parth Dixit is still working on XEN ACPI for
ARM64, before it's in full function, how about introduce a Kconfig
CONFIG_XEN_ACPI and let it depends on x86? when XEN ACPI for ARM64
comes, we can enable ARM64 for CONFIG_XEN_ACPI and fix the problems
above.

Stefano, Parth, what do you think?

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Will Deacon]

On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
> On 2015/3/19 3:05, Will Deacon wrote:
> > If you can get that in place, I'm not opposed to putting this into
> > linux-next ahead of the firmware summit in San Jose next week. Note that
> > this is not a commitment for 4.1, since I'm keen to see the outcomes of
> > next week before setting anything in stone.
> 
> OK, I will stick to this mailing list and respond as soon as I can.

This doesn't even build for me:


$ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- allmodconfig
$ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- Image

[...]

In file included from drivers/xen/acpi.c:33:0:
include/xen/acpi.h: In function ‘xen_acpi_sleep_register’:
include/xen/acpi.h:102:3: error: ‘acpi_suspend_lowlevel’ undeclared (first use 
in this function)
   acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;
   ^
include/xen/acpi.h:102:3: note: each undeclared identifier is reported only 
once for each function it appears in
drivers/xen/acpi.c: In function ‘xen_acpi_notify_hypervisor_state’:
drivers/xen/acpi.c:61:2: error: implicit declaration of function 
‘HYPERVISOR_dom0_op’ [-Werror=implicit-function-declaration]
  HYPERVISOR_dom0_op();
  ^
cc1: some warnings being treated as errors
make[2]: *** [drivers/xen/acpi.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [drivers/xen] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [drivers] Error 2


Am I missing some other patches?

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Mark Salter]

On Wed, 2015-03-11 at 20:39 +0800, Hanjun Guo wrote:
> This patch set already tested on multi platforms:
>  - AMD Seattle board;
>  - Cavium Thunder board;
>  - Huawei D02 board;
>  - Qualcomm ARM64 platform

For the whole series:

Tested-by: Mark Salter 

on AMD Seattle and APM Mustang.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Mark Salter]

On Wed, 2015-03-11 at 20:39 +0800, Hanjun Guo wrote:
 This patch set already tested on multi platforms:
  - AMD Seattle board;
  - Cavium Thunder board;
  - Huawei D02 board;
  - Qualcomm ARM64 platform

For the whole series:

Tested-by: Mark Salter msal...@redhat.com

on AMD Seattle and APM Mustang.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

+CC Parth Dixit, Stefano Stabellini.

On 2015年03月21日 02:54, Will Deacon wrote:

On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:

On 2015/3/19 3:05, Will Deacon wrote:

If you can get that in place, I'm not opposed to putting this into
linux-next ahead of the firmware summit in San Jose next week. Note that
this is not a commitment for 4.1, since I'm keen to see the outcomes of
next week before setting anything in stone.


OK, I will stick to this mailing list and respond as soon as I can.


This doesn't even build for me:


$ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- allmodconfig
$ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- Image

[...]

In file included from drivers/xen/acpi.c:33:0:


Sorry, I didn't build ACPI with XEN enabled on ARM64.


include/xen/acpi.h: In function ‘xen_acpi_sleep_register’:
include/xen/acpi.h:102:3: error: ‘acpi_suspend_lowlevel’ undeclared (first use 
in this function)
acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;


acpi_suspend_lowlevel is defined only for X86 and IA64 for now.


^
include/xen/acpi.h:102:3: note: each undeclared identifier is reported only 
once for each function it appears in
drivers/xen/acpi.c: In function ‘xen_acpi_notify_hypervisor_state’:
drivers/xen/acpi.c:61:2: error: implicit declaration of function 
‘HYPERVISOR_dom0_op’ [-Werror=implicit-function-declaration]
   HYPERVISOR_dom0_op(op);


And this is only for x86:
./arch/x86/include/asm/xen/hypercall.h:HYPERVISOR_dom0_op(struct 
xen_platform_op *platform_op)



   ^
cc1: some warnings being treated as errors
make[2]: *** [drivers/xen/acpi.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [drivers/xen] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [drivers] Error 2


Am I missing some other patches?


No, you miss nothing. Parth Dixit is still working on XEN ACPI for
ARM64, before it's in full function, how about introduce a Kconfig
CONFIG_XEN_ACPI and let it depends on x86? when XEN ACPI for ARM64
comes, we can enable ARM64 for CONFIG_XEN_ACPI and fix the problems
above.

Stefano, Parth, what do you think?

Thanks
Hanjun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Will Deacon]

On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
 On 2015/3/19 3:05, Will Deacon wrote:
  If you can get that in place, I'm not opposed to putting this into
  linux-next ahead of the firmware summit in San Jose next week. Note that
  this is not a commitment for 4.1, since I'm keen to see the outcomes of
  next week before setting anything in stone.
 
 OK, I will stick to this mailing list and respond as soon as I can.

This doesn't even build for me:


$ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- allmodconfig
$ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- Image

[...]

In file included from drivers/xen/acpi.c:33:0:
include/xen/acpi.h: In function ‘xen_acpi_sleep_register’:
include/xen/acpi.h:102:3: error: ‘acpi_suspend_lowlevel’ undeclared (first use 
in this function)
   acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;
   ^
include/xen/acpi.h:102:3: note: each undeclared identifier is reported only 
once for each function it appears in
drivers/xen/acpi.c: In function ‘xen_acpi_notify_hypervisor_state’:
drivers/xen/acpi.c:61:2: error: implicit declaration of function 
‘HYPERVISOR_dom0_op’ [-Werror=implicit-function-declaration]
  HYPERVISOR_dom0_op(op);
  ^
cc1: some warnings being treated as errors
make[2]: *** [drivers/xen/acpi.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [drivers/xen] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [drivers] Error 2


Am I missing some other patches?

Will
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Will Deacon]

On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
> On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
> > On 2015/3/19 3:05, Will Deacon wrote:
> > > On Wed, Mar 11, 2015 at 12:39:26PM +, Hanjun Guo wrote:
> > >> This patch set already tested on multi platforms:
> > >>  - AMD Seattle board;
> > >>  - Cavium Thunder board;
> > >>  - Huawei D02 board;
> > >>  - Qualcomm ARM64 platform
> > >>
> > >> This version 10 patch set address some minor comments and collect ACKs 
> > >> and
> > >> Reviewed-bys for v9:
> > >>
> > >>  - new Acks from Rafael, Olof, Grant, Lorenzo
> > >>  - new way to handle typdef phys_cpuid_t which suggested by Rafael,
> > >>but no functional change
> > >>  - Remove if(!phys) for early ioremappings
> > >>  - Rework sleep function for ARM64
> > >>  - Introduce linux/acpi_irq.h to hold acpi_irq_init()
> > >>  - Disable ACPI if not HW_REDUCED_ACPI compliant
> > >>  - Remove the doc of why ACPI on ARM
> > > So I've had a look at the current state of this series and I think there
> > > are a few immediate things left to do:
> > >
> > >   (1) Resolve the acpi=force cmdline issue highlighted by Lorenzo and
> > >   Catalin
> > 
> > Sure, it will be done after the confirmation with Ard.
> > 
> > >
> > >   (2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP 
> > > init),
> > >   so I'm assuming there will be additional patches from them that are
> > >   required.
> > 
> > Sorry, I assume that it is about the print information for PSCI absent for 
> > SMP init, right?
> 
> Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
> I am working on it, I do not think it should be a blocking point, patch
> coming asap on top of your series.

Well, I don't really want to merge the series without those patches so I
do think it blocks the code from getting into mainline.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Lorenzo Pieralisi]

On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
> On 2015/3/19 3:05, Will Deacon wrote:
> > Hanjun,
> 
> Hi Will,
> 
> >
> > On Wed, Mar 11, 2015 at 12:39:26PM +, Hanjun Guo wrote:
> >> This patch set already tested on multi platforms:
> >>  - AMD Seattle board;
> >>  - Cavium Thunder board;
> >>  - Huawei D02 board;
> >>  - Qualcomm ARM64 platform
> >>
> >> This version 10 patch set address some minor comments and collect ACKs and
> >> Reviewed-bys for v9:
> >>
> >>  - new Acks from Rafael, Olof, Grant, Lorenzo
> >>  - new way to handle typdef phys_cpuid_t which suggested by Rafael,
> >>but no functional change
> >>  - Remove if(!phys) for early ioremappings
> >>  - Rework sleep function for ARM64
> >>  - Introduce linux/acpi_irq.h to hold acpi_irq_init()
> >>  - Disable ACPI if not HW_REDUCED_ACPI compliant
> >>  - Remove the doc of why ACPI on ARM
> > So I've had a look at the current state of this series and I think there
> > are a few immediate things left to do:
> >
> >   (1) Resolve the acpi=force cmdline issue highlighted by Lorenzo and
> >   Catalin
> 
> Sure, it will be done after the confirmation with Ard.
> 
> >
> >   (2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP init),
> >   so I'm assuming there will be additional patches from them that are
> >   required.
> 
> Sorry, I assume that it is about the print information for PSCI absent for 
> SMP init, right?

Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
I am working on it, I do not think it should be a blocking point, patch
coming asap on top of your series.

Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Lorenzo Pieralisi]

On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
 On 2015/3/19 3:05, Will Deacon wrote:
  Hanjun,
 
 Hi Will,
 
 
  On Wed, Mar 11, 2015 at 12:39:26PM +, Hanjun Guo wrote:
  This patch set already tested on multi platforms:
   - AMD Seattle board;
   - Cavium Thunder board;
   - Huawei D02 board;
   - Qualcomm ARM64 platform
 
  This version 10 patch set address some minor comments and collect ACKs and
  Reviewed-bys for v9:
 
   - new Acks from Rafael, Olof, Grant, Lorenzo
   - new way to handle typdef phys_cpuid_t which suggested by Rafael,
 but no functional change
   - Remove if(!phys) for early ioremappings
   - Rework sleep function for ARM64
   - Introduce linux/acpi_irq.h to hold acpi_irq_init()
   - Disable ACPI if not HW_REDUCED_ACPI compliant
   - Remove the doc of why ACPI on ARM
  So I've had a look at the current state of this series and I think there
  are a few immediate things left to do:
 
(1) Resolve the acpi=force cmdline issue highlighted by Lorenzo and
Catalin
 
 Sure, it will be done after the confirmation with Ard.
 
 
(2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP init),
so I'm assuming there will be additional patches from them that are
required.
 
 Sorry, I assume that it is about the print information for PSCI absent for 
 SMP init, right?

Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
I am working on it, I do not think it should be a blocking point, patch
coming asap on top of your series.

Lorenzo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Will Deacon]

On Thu, Mar 19, 2015 at 10:17:27AM +, Lorenzo Pieralisi wrote:
 On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
  On 2015/3/19 3:05, Will Deacon wrote:
   On Wed, Mar 11, 2015 at 12:39:26PM +, Hanjun Guo wrote:
   This patch set already tested on multi platforms:
- AMD Seattle board;
- Cavium Thunder board;
- Huawei D02 board;
- Qualcomm ARM64 platform
  
   This version 10 patch set address some minor comments and collect ACKs 
   and
   Reviewed-bys for v9:
  
- new Acks from Rafael, Olof, Grant, Lorenzo
- new way to handle typdef phys_cpuid_t which suggested by Rafael,
  but no functional change
- Remove if(!phys) for early ioremappings
- Rework sleep function for ARM64
- Introduce linux/acpi_irq.h to hold acpi_irq_init()
- Disable ACPI if not HW_REDUCED_ACPI compliant
- Remove the doc of why ACPI on ARM
   So I've had a look at the current state of this series and I think there
   are a few immediate things left to do:
  
 (1) Resolve the acpi=force cmdline issue highlighted by Lorenzo and
 Catalin
  
  Sure, it will be done after the confirmation with Ard.
  
  
 (2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP 
   init),
 so I'm assuming there will be additional patches from them that are
 required.
  
  Sorry, I assume that it is about the print information for PSCI absent for 
  SMP init, right?
 
 Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code,
 I am working on it, I do not think it should be a blocking point, patch
 coming asap on top of your series.

Well, I don't really want to merge the series without those patches so I
do think it blocks the code from getting into mainline.

Will
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

On 2015/3/19 3:05, Will Deacon wrote:
> Hanjun,

Hi Will,

>
> On Wed, Mar 11, 2015 at 12:39:26PM +, Hanjun Guo wrote:
>> This patch set already tested on multi platforms:
>>  - AMD Seattle board;
>>  - Cavium Thunder board;
>>  - Huawei D02 board;
>>  - Qualcomm ARM64 platform
>>
>> This version 10 patch set address some minor comments and collect ACKs and
>> Reviewed-bys for v9:
>>
>>  - new Acks from Rafael, Olof, Grant, Lorenzo
>>  - new way to handle typdef phys_cpuid_t which suggested by Rafael,
>>but no functional change
>>  - Remove if(!phys) for early ioremappings
>>  - Rework sleep function for ARM64
>>  - Introduce linux/acpi_irq.h to hold acpi_irq_init()
>>  - Disable ACPI if not HW_REDUCED_ACPI compliant
>>  - Remove the doc of why ACPI on ARM
> So I've had a look at the current state of this series and I think there
> are a few immediate things left to do:
>
>   (1) Resolve the acpi=force cmdline issue highlighted by Lorenzo and
>   Catalin

Sure, it will be done after the confirmation with Ard.

>
>   (2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP init),
>   so I'm assuming there will be additional patches from them that are
>   required.

Sorry, I assume that it is about the print information for PSCI absent for SMP 
init, right?

>
>   (3) I have an open comment about moving the IRQ domain code into the
>   core, which I'd like to see addressed.

I replied your email, please share your ideas for what I said.

>
>   (4) We need an ack from Daniel on the arch-timer patch

OK, thanks for your ping to Daniel :)

>
> If you can get that in place, I'm not opposed to putting this into
> linux-next ahead of the firmware summit in San Jose next week. Note that
> this is not a commitment for 4.1, since I'm keen to see the outcomes of
> next week before setting anything in stone.

OK, I will stick to this mailing list and respond as soon as I can.

>
> Also, there's no need to repost patches if you're just adding Acks. I
> think I'm up to speed with those on my local branch and the Tested-by
> party is starting to look a little silly.

Should I send another version, and add some incremental cleanup/fix patches
on top of that?

Thanks
Hanjun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Will Deacon]

On Wed, Mar 18, 2015 at 07:05:09PM +, Will Deacon wrote:
>   (2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP init),
>   so I'm assuming there will be additional patches from them that are
>   required.

Bah, getting ahead of myself. This is in fact patch *12* of the series :)

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Will Deacon]

Hanjun,

On Wed, Mar 11, 2015 at 12:39:26PM +, Hanjun Guo wrote:
> This patch set already tested on multi platforms:
>  - AMD Seattle board;
>  - Cavium Thunder board;
>  - Huawei D02 board;
>  - Qualcomm ARM64 platform
> 
> This version 10 patch set address some minor comments and collect ACKs and
> Reviewed-bys for v9:
> 
>  - new Acks from Rafael, Olof, Grant, Lorenzo
>  - new way to handle typdef phys_cpuid_t which suggested by Rafael,
>but no functional change
>  - Remove if(!phys) for early ioremappings
>  - Rework sleep function for ARM64
>  - Introduce linux/acpi_irq.h to hold acpi_irq_init()
>  - Disable ACPI if not HW_REDUCED_ACPI compliant
>  - Remove the doc of why ACPI on ARM

So I've had a look at the current state of this series and I think there
are a few immediate things left to do:

  (1) Resolve the acpi=force cmdline issue highlighted by Lorenzo and
  Catalin

  (2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP init),
  so I'm assuming there will be additional patches from them that are
  required.

  (3) I have an open comment about moving the IRQ domain code into the
  core, which I'd like to see addressed.

  (4) We need an ack from Daniel on the arch-timer patch

If you can get that in place, I'm not opposed to putting this into
linux-next ahead of the firmware summit in San Jose next week. Note that
this is not a commitment for 4.1, since I'm keen to see the outcomes of
next week before setting anything in stone.

Also, there's no need to repost patches if you're just adding Acks. I
think I'm up to speed with those on my local branch and the Tested-by
party is starting to look a little silly.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Will Deacon]

Hanjun,

On Wed, Mar 11, 2015 at 12:39:26PM +, Hanjun Guo wrote:
 This patch set already tested on multi platforms:
  - AMD Seattle board;
  - Cavium Thunder board;
  - Huawei D02 board;
  - Qualcomm ARM64 platform
 
 This version 10 patch set address some minor comments and collect ACKs and
 Reviewed-bys for v9:
 
  - new Acks from Rafael, Olof, Grant, Lorenzo
  - new way to handle typdef phys_cpuid_t which suggested by Rafael,
but no functional change
  - Remove if(!phys) for early ioremappings
  - Rework sleep function for ARM64
  - Introduce linux/acpi_irq.h to hold acpi_irq_init()
  - Disable ACPI if not HW_REDUCED_ACPI compliant
  - Remove the doc of why ACPI on ARM

So I've had a look at the current state of this series and I think there
are a few immediate things left to do:

  (1) Resolve the acpi=force cmdline issue highlighted by Lorenzo and
  Catalin

  (2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP init),
  so I'm assuming there will be additional patches from them that are
  required.

  (3) I have an open comment about moving the IRQ domain code into the
  core, which I'd like to see addressed.

  (4) We need an ack from Daniel on the arch-timer patch

If you can get that in place, I'm not opposed to putting this into
linux-next ahead of the firmware summit in San Jose next week. Note that
this is not a commitment for 4.1, since I'm keen to see the outcomes of
next week before setting anything in stone.

Also, there's no need to repost patches if you're just adding Acks. I
think I'm up to speed with those on my local branch and the Tested-by
party is starting to look a little silly.

Will
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Will Deacon]

On Wed, Mar 18, 2015 at 07:05:09PM +, Will Deacon wrote:
   (2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP init),
   so I'm assuming there will be additional patches from them that are
   required.

Bah, getting ahead of myself. This is in fact patch *12* of the series :)

Will
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

On 2015/3/19 3:05, Will Deacon wrote:
 Hanjun,

Hi Will,


 On Wed, Mar 11, 2015 at 12:39:26PM +, Hanjun Guo wrote:
 This patch set already tested on multi platforms:
  - AMD Seattle board;
  - Cavium Thunder board;
  - Huawei D02 board;
  - Qualcomm ARM64 platform

 This version 10 patch set address some minor comments and collect ACKs and
 Reviewed-bys for v9:

  - new Acks from Rafael, Olof, Grant, Lorenzo
  - new way to handle typdef phys_cpuid_t which suggested by Rafael,
but no functional change
  - Remove if(!phys) for early ioremappings
  - Rework sleep function for ARM64
  - Introduce linux/acpi_irq.h to hold acpi_irq_init()
  - Disable ACPI if not HW_REDUCED_ACPI compliant
  - Remove the doc of why ACPI on ARM
 So I've had a look at the current state of this series and I think there
 are a few immediate things left to do:

   (1) Resolve the acpi=force cmdline issue highlighted by Lorenzo and
   Catalin

Sure, it will be done after the confirmation with Ard.


   (2) I believe Sudeep and Lorenzo have concerns about patch 13 (SMP init),
   so I'm assuming there will be additional patches from them that are
   required.

Sorry, I assume that it is about the print information for PSCI absent for SMP 
init, right?


   (3) I have an open comment about moving the IRQ domain code into the
   core, which I'd like to see addressed.

I replied your email, please share your ideas for what I said.


   (4) We need an ack from Daniel on the arch-timer patch

OK, thanks for your ping to Daniel :)


 If you can get that in place, I'm not opposed to putting this into
 linux-next ahead of the firmware summit in San Jose next week. Note that
 this is not a commitment for 4.1, since I'm keen to see the outcomes of
 next week before setting anything in stone.

OK, I will stick to this mailing list and respond as soon as I can.


 Also, there's no need to repost patches if you're just adding Acks. I
 think I'm up to speed with those on my local branch and the Tested-by
 party is starting to look a little silly.

Should I send another version, and add some incremental cleanup/fix patches
on top of that?

Thanks
Hanjun

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Suthikulpanit, Suravee]

On 3/12/15, 08:26, "Timur Tabi"  wrote:

>Hanjun Guo wrote:
>> This patch set already tested on multi platforms:
>>   - AMD Seattle board;
>>   - Cavium Thunder board;
>>   - Huawei D02 board;
>>   - Qualcomm ARM64 platform
>>
>> This version 10 patch set address some minor comments and collect ACKs
>>and
>> Reviewed-bys for v9:
>>
>>   - new Acks from Rafael, Olof, Grant, Lorenzo
>>   - new way to handle typdef phys_cpuid_t which suggested by Rafael,
>> but no functional change
>>   - Remove if(!phys) for early ioremappings
>>   - Rework sleep function for ARM64
>>   - Introduce linux/acpi_irq.h to hold acpi_irq_init()
>>   - Disable ACPI if not HW_REDUCED_ACPI compliant
>>   - Remove the doc of why ACPI on ARM
>
>v10 retested and working as before, so ...
>
>   Tested-by: Timur Tabi 
>
>for the whole patchset.


Also retested on AMD Seattle.

Tested-by: Suravee Suthikulpanit 

>
>-- 
>Sent by an employee of the Qualcomm Innovation Center, Inc.
>The Qualcomm Innovation Center, Inc. is a member of the
>Code Aurora Forum, hosted by The Linux Foundation.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Suthikulpanit, Suravee]

On 3/12/15, 08:26, Timur Tabi ti...@codeaurora.org wrote:

Hanjun Guo wrote:
 This patch set already tested on multi platforms:
   - AMD Seattle board;
   - Cavium Thunder board;
   - Huawei D02 board;
   - Qualcomm ARM64 platform

 This version 10 patch set address some minor comments and collect ACKs
and
 Reviewed-bys for v9:

   - new Acks from Rafael, Olof, Grant, Lorenzo
   - new way to handle typdef phys_cpuid_t which suggested by Rafael,
 but no functional change
   - Remove if(!phys) for early ioremappings
   - Rework sleep function for ARM64
   - Introduce linux/acpi_irq.h to hold acpi_irq_init()
   - Disable ACPI if not HW_REDUCED_ACPI compliant
   - Remove the doc of why ACPI on ARM

v10 retested and working as before, so ...

   Tested-by: Timur Tabi ti...@codeaurora.org

for the whole patchset.


Also retested on AMD Seattle.

Tested-by: Suravee Suthikulpanit suravee.suthikulpa...@amd.com


-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Timur Tabi]

Hanjun Guo wrote:

This patch set already tested on multi platforms:
  - AMD Seattle board;
  - Cavium Thunder board;
  - Huawei D02 board;
  - Qualcomm ARM64 platform

This version 10 patch set address some minor comments and collect ACKs and
Reviewed-bys for v9:

  - new Acks from Rafael, Olof, Grant, Lorenzo
  - new way to handle typdef phys_cpuid_t which suggested by Rafael,
but no functional change
  - Remove if(!phys) for early ioremappings
  - Rework sleep function for ARM64
  - Introduce linux/acpi_irq.h to hold acpi_irq_init()
  - Disable ACPI if not HW_REDUCED_ACPI compliant
  - Remove the doc of why ACPI on ARM


v10 retested and working as before, so ...

Tested-by: Timur Tabi 

for the whole patchset.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Timur Tabi]

Hanjun Guo wrote:

This patch set already tested on multi platforms:
  - AMD Seattle board;
  - Cavium Thunder board;
  - Huawei D02 board;
  - Qualcomm ARM64 platform

This version 10 patch set address some minor comments and collect ACKs and
Reviewed-bys for v9:

  - new Acks from Rafael, Olof, Grant, Lorenzo
  - new way to handle typdef phys_cpuid_t which suggested by Rafael,
but no functional change
  - Remove if(!phys) for early ioremappings
  - Rework sleep function for ARM64
  - Introduce linux/acpi_irq.h to hold acpi_irq_init()
  - Disable ACPI if not HW_REDUCED_ACPI compliant
  - Remove the doc of why ACPI on ARM


v10 retested and working as before, so ...

Tested-by: Timur Tabi ti...@codeaurora.org

for the whole patchset.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

This patch set already tested on multi platforms:
 - AMD Seattle board;
 - Cavium Thunder board;
 - Huawei D02 board;
 - Qualcomm ARM64 platform

This version 10 patch set address some minor comments and collect ACKs and
Reviewed-bys for v9:

 - new Acks from Rafael, Olof, Grant, Lorenzo
 - new way to handle typdef phys_cpuid_t which suggested by Rafael,
   but no functional change
 - Remove if(!phys) for early ioremappings
 - Rework sleep function for ARM64
 - Introduce linux/acpi_irq.h to hold acpi_irq_init()
 - Disable ACPI if not HW_REDUCED_ACPI compliant
 - Remove the doc of why ACPI on ARM

Thanks
Hanjun

Al Stone (4):
  ARM64 / ACPI: Get RSDP and ACPI boot-time tables
  ARM64 / ACPI: Introduce early_param "acpi=" to enable/disable ACPI
  ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on
ARM64
  ARM64 / ACPI: additions of ACPI documentation for arm64

Graeme Gregory (6):
  ACPI: add arm64 to the platforms that use ioremap
  ACPI / sleep: Introduce CONFIG_ACPI_GENERIC_SLEEP
  ARM64 / ACPI: If we chose to boot from acpi then disable FDT
  ARM64 / ACPI: Get PSCI flags in FADT for PSCI init
  ARM64 / ACPI: Enable ARM64 in Kconfig
  Documentation: ACPI for ARM64

Hanjun Guo (8):
  ACPI / table: Use pr_debug() instead of pr_info() for MADT table
scanning
  ARM64 / ACPI: Introduce PCI stub functions for ACPI
  ACPI / table: Print GIC information when MADT is parsed
  ARM64 / ACPI: Parse MADT for SMP initialization
  ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID
  ACPI / processor: Make it possible to get CPU hardware ID via GICC
  ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
  clocksource / arch_timer: Parse GTDT to initialize arch timer

Mark Salter (2):
  ARM64: allow late use of early_ioremap
  ACPI: fix acpi_os_ioremap for arm64

Tomasz Nowicki (1):
  irqchip: Add GICv2 specific ACPI boot support

 Documentation/arm64/acpi_object_usage.txt | 593 ++
 Documentation/arm64/arm-acpi.txt  | 505 +
 Documentation/kernel-parameters.txt   |   3 +-
 arch/arm64/Kconfig|   3 +
 arch/arm64/include/asm/acenv.h|  18 +
 arch/arm64/include/asm/acpi.h |  96 +
 arch/arm64/include/asm/cpu_ops.h  |   1 +
 arch/arm64/include/asm/fixmap.h   |   3 +
 arch/arm64/include/asm/irq.h  |  13 +
 arch/arm64/include/asm/pci.h  |   6 +
 arch/arm64/include/asm/psci.h |   3 +-
 arch/arm64/include/asm/smp.h  |   5 +-
 arch/arm64/kernel/Makefile|   1 +
 arch/arm64/kernel/acpi.c  | 392 
 arch/arm64/kernel/cpu_ops.c   |   2 +-
 arch/arm64/kernel/pci.c   |  25 ++
 arch/arm64/kernel/psci.c  |  78 ++--
 arch/arm64/kernel/setup.c |  21 +-
 arch/arm64/kernel/smp.c   |   2 +-
 arch/arm64/kernel/time.c  |   7 +
 arch/ia64/Kconfig |   1 +
 arch/ia64/kernel/acpi.c   |   2 +-
 arch/x86/Kconfig  |   1 +
 arch/x86/kernel/acpi/boot.c   |   2 +-
 drivers/acpi/Kconfig  |   7 +-
 drivers/acpi/Makefile |   2 +-
 drivers/acpi/acpi_processor.c |   7 +-
 drivers/acpi/bus.c|   3 +
 drivers/acpi/internal.h   |   4 +
 drivers/acpi/osl.c|   6 +-
 drivers/acpi/processor_core.c |  60 ++-
 drivers/acpi/tables.c |  52 ++-
 drivers/clocksource/arm_arch_timer.c  | 132 +--
 drivers/irqchip/irq-gic.c | 102 +
 drivers/irqchip/irqchip.c |   3 +
 include/acpi/acpi_io.h|   4 +
 include/acpi/processor.h  |   6 +-
 include/linux/acpi.h  |   8 +-
 include/linux/acpi_irq.h  |  10 +
 include/linux/clocksource.h   |   6 +
 include/linux/irqchip/arm-gic-acpi.h  |  31 ++
 41 files changed, 2121 insertions(+), 105 deletions(-)
 create mode 100644 Documentation/arm64/acpi_object_usage.txt
 create mode 100644 Documentation/arm64/arm-acpi.txt
 create mode 100644 arch/arm64/include/asm/acenv.h
 create mode 100644 arch/arm64/include/asm/acpi.h
 create mode 100644 arch/arm64/kernel/acpi.c
 create mode 100644 include/linux/acpi_irq.h
 create mode 100644 include/linux/irqchip/arm-gic-acpi.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v10 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

This patch set already tested on multi platforms:
 - AMD Seattle board;
 - Cavium Thunder board;
 - Huawei D02 board;
 - Qualcomm ARM64 platform

This version 10 patch set address some minor comments and collect ACKs and
Reviewed-bys for v9:

 - new Acks from Rafael, Olof, Grant, Lorenzo
 - new way to handle typdef phys_cpuid_t which suggested by Rafael,
   but no functional change
 - Remove if(!phys) for early ioremappings
 - Rework sleep function for ARM64
 - Introduce linux/acpi_irq.h to hold acpi_irq_init()
 - Disable ACPI if not HW_REDUCED_ACPI compliant
 - Remove the doc of why ACPI on ARM

Thanks
Hanjun

Al Stone (4):
  ARM64 / ACPI: Get RSDP and ACPI boot-time tables
  ARM64 / ACPI: Introduce early_param acpi= to enable/disable ACPI
  ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on
ARM64
  ARM64 / ACPI: additions of ACPI documentation for arm64

Graeme Gregory (6):
  ACPI: add arm64 to the platforms that use ioremap
  ACPI / sleep: Introduce CONFIG_ACPI_GENERIC_SLEEP
  ARM64 / ACPI: If we chose to boot from acpi then disable FDT
  ARM64 / ACPI: Get PSCI flags in FADT for PSCI init
  ARM64 / ACPI: Enable ARM64 in Kconfig
  Documentation: ACPI for ARM64

Hanjun Guo (8):
  ACPI / table: Use pr_debug() instead of pr_info() for MADT table
scanning
  ARM64 / ACPI: Introduce PCI stub functions for ACPI
  ACPI / table: Print GIC information when MADT is parsed
  ARM64 / ACPI: Parse MADT for SMP initialization
  ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID
  ACPI / processor: Make it possible to get CPU hardware ID via GICC
  ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
  clocksource / arch_timer: Parse GTDT to initialize arch timer

Mark Salter (2):
  ARM64: allow late use of early_ioremap
  ACPI: fix acpi_os_ioremap for arm64

Tomasz Nowicki (1):
  irqchip: Add GICv2 specific ACPI boot support

 Documentation/arm64/acpi_object_usage.txt | 593 ++
 Documentation/arm64/arm-acpi.txt  | 505 +
 Documentation/kernel-parameters.txt   |   3 +-
 arch/arm64/Kconfig|   3 +
 arch/arm64/include/asm/acenv.h|  18 +
 arch/arm64/include/asm/acpi.h |  96 +
 arch/arm64/include/asm/cpu_ops.h  |   1 +
 arch/arm64/include/asm/fixmap.h   |   3 +
 arch/arm64/include/asm/irq.h  |  13 +
 arch/arm64/include/asm/pci.h  |   6 +
 arch/arm64/include/asm/psci.h |   3 +-
 arch/arm64/include/asm/smp.h  |   5 +-
 arch/arm64/kernel/Makefile|   1 +
 arch/arm64/kernel/acpi.c  | 392 
 arch/arm64/kernel/cpu_ops.c   |   2 +-
 arch/arm64/kernel/pci.c   |  25 ++
 arch/arm64/kernel/psci.c  |  78 ++--
 arch/arm64/kernel/setup.c |  21 +-
 arch/arm64/kernel/smp.c   |   2 +-
 arch/arm64/kernel/time.c  |   7 +
 arch/ia64/Kconfig |   1 +
 arch/ia64/kernel/acpi.c   |   2 +-
 arch/x86/Kconfig  |   1 +
 arch/x86/kernel/acpi/boot.c   |   2 +-
 drivers/acpi/Kconfig  |   7 +-
 drivers/acpi/Makefile |   2 +-
 drivers/acpi/acpi_processor.c |   7 +-
 drivers/acpi/bus.c|   3 +
 drivers/acpi/internal.h   |   4 +
 drivers/acpi/osl.c|   6 +-
 drivers/acpi/processor_core.c |  60 ++-
 drivers/acpi/tables.c |  52 ++-
 drivers/clocksource/arm_arch_timer.c  | 132 +--
 drivers/irqchip/irq-gic.c | 102 +
 drivers/irqchip/irqchip.c |   3 +
 include/acpi/acpi_io.h|   4 +
 include/acpi/processor.h  |   6 +-
 include/linux/acpi.h  |   8 +-
 include/linux/acpi_irq.h  |  10 +
 include/linux/clocksource.h   |   6 +
 include/linux/irqchip/arm-gic-acpi.h  |  31 ++
 41 files changed, 2121 insertions(+), 105 deletions(-)
 create mode 100644 Documentation/arm64/acpi_object_usage.txt
 create mode 100644 Documentation/arm64/arm-acpi.txt
 create mode 100644 arch/arm64/include/asm/acenv.h
 create mode 100644 arch/arm64/include/asm/acpi.h
 create mode 100644 arch/arm64/kernel/acpi.c
 create mode 100644 include/linux/acpi_irq.h
 create mode 100644 include/linux/irqchip/arm-gic-acpi.h

-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/