Lv Zheng | 23 Oct 04:11 2014

[PATCH 0/6] ACPI/OSL: Rework of ACPICA memory OSLs to improve performance.

It is reported that there is a performance issue in the ACPICA OSL
implementation around memory mappings.

On the reported platforms, there is a debugging facility implemented in the
ACPI namespace using circular logging buffer:
        Name (DPTR, 0x3AFEB000)
        Name (EPTR, 0x3AFFB000)
        Name (CPTR, 0x3AFEB010)
        Mutex (MMUT, 0x00)
        Method (MDBG, 1, Serialized)
            Store (Acquire (MMUT, 0x03E8), Local0)
            If (Local0 == Zero)
                OperationRegion (ABLK, SystemMemory, CPTR, 0x10)
                Field (ABLK, ByteAcc, NoLock, Preserve)
                    AAAA,   128
                Store (Arg0, AAAA) /* \MDBG.AAAA */
                CPTR = (CPTR + 0x10) /* \CPTR */
                If (CPTR >= EPTR)
                    CPTR = (DPTR + 0x10) /* \CPTR */
                Release (MMUT)
            Return (Local0)
This function is heavily invoked by other ACPI control methods.
(Continue reading)

Darren Hart | 21 Oct 23:50 2014

Re: [PATCH v4 00/13] Add ACPI _DSD and unified device properties? support

On Sat, Oct 18, 2014 at 10:35:49AM +0200, Grant Likely wrote:
> On Wed, 15 Oct 2014 17:43:01 +0200
> , Darren Hart <dvhart <at>>
>  wrote:
> > 
> > 
> > On 10/15/14 17:17, Mark Rutland wrote:
> > > On Wed, Oct 15, 2014 at 03:46:39PM +0100, Darren Hart wrote:
> > 
> > >> Mark, what would you propose we do differently to enable this driver to
> > >> be firmware-type agnostic?
> > > 
> > > For this particular driver, all I'm asking for is that the
> > > "used-by-rtas" property is not moved over from of_find_property to
> > > device_get_property. It is irrelevant for all ACPI systems. Evidently my
> > > comment was unclear; I apologise for that.
> > 
> > So my objection here is that by keeping the of_* terms in the driver we
> > are required to include of, although it does safely convert to returning
> > NULL if !CONFIG_OF I suppose.
> This shouldn't be that controversial. There will be things that only make
> sense for DT or only ACPI. Allowing the property to be processed when
> the other interface is being used may tempt firmware authors to use the
> property because it just happens to have a side effect that looks right
> to them.
> I don't see any problem with factoring out those bits into a function
> that is only called (or built) when the associated firmware interface is
> used. In these situations, the driver isn't 100% generic, so having
(Continue reading)

Alexandre Courbot | 21 Oct 07:14 2014

GPIO bindings guidelines (Was: Re: [PATCH v5 10/12] gpio: Support for unified device properties interface)

On Mon, Oct 20, 2014 at 11:26 PM, Arnd Bergmann <arnd <at>> wrote:
> On Monday 20 October 2014 15:12:50 Alexandre Courbot wrote:
>> On Sat, Oct 18, 2014 at 6:47 PM, Arnd Bergmann <arnd <at>> wrote:
>> > On Friday 17 October 2014 20:09:51 Arnd Bergmann wrote:
>> >> On October 17, 2014 2:16:00 PM CEST, "Rafael J. Wysocki" <rjw <at>> wrote:
>> >> >From: Mika Westerberg <mika.westerberg <at>>
>> >> >
>> >> >Some drivers need to deal with only firmware representation of its
>> >> >GPIOs. An example would be a GPIO button array driver where each button
>> >> >is described as a separate firmware node in device tree. Typically
>> >> >these
>> >> >child nodes do not have physical representation in the Linux device
>> >> >model.
>> >> >
>> >> >In order to help device drivers to handle such firmware child nodes we
>> >> >add dev[m]_get_named_gpiod_from_child() that takes a child firmware
>> >> >node pointer as its second argument (the first one is the parent device
>> >> >itself), finds the GPIO using whatever is the underlying firmware
>> >> >method, and requests the GPIO properly.
>> >>
>> >> Could we also have a wrapper around this function without a "name" argument,
>> >> using just the index?
>> >
>> > Expanding on this thought: I think we should mandate for new bindings
>> > that they use either a name and no index, or an index but not name,
>> I'm afraid this could forbid some useful use-cases, namely the ones
>> where several GPIOs serve the same function (and are typically set
>> together). We had a few patch proposals to handle such GPIO groups,
>> and even though one was in pretty good shape the submitter did not
(Continue reading)

Williams Scott | 21 Oct 04:22 2014

Financial Aid at 2% Interest Rate

Business and personal finance assistance (loan) Available at Two percent(2%) Interest Rate, *No Credit
Check * Presentation of Collateral are not important, if interested, Kindly contacts us for detail as you
click reply. You can also call us via: +1 623 239 1600. Thank You
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at>
More majordomo info at

Jiang Liu | 20 Oct 16:45 2014

[Patch] ACPI, irq: fix regression casued by 6b9fb7082409

When IOAPIC is disabled, acpi_gsi_to_irq() should return gsi directly
instead of calling mp_map_gsi_to_irq() to translate gsi to IRQ by IOAPIC.
It fixes

Reported-and-Tested-by: Thomas Richter <thor <at>>
Signed-off-by: Jiang Liu <jiang.liu <at>>
Cc: Thomas Richter <thor <at>>
Cc: rui.zhang <at>
Cc: <stable <at>> # 3.17
 arch/x86/kernel/acpi/boot.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index b436fc735aa4..eceba9d9e116 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
 <at>  <at>  -604,14 +604,19  <at>  <at>  void __init acpi_pic_sci_set_trigger(unsigned int irq, u16 trigger)

 int acpi_gsi_to_irq(u32 gsi, unsigned int *irqp)
-	int irq = mp_map_gsi_to_irq(gsi, IOAPIC_MAP_ALLOC | IOAPIC_MAP_CHECK);
+	int irq;

-	if (irq >= 0) {
+	if (acpi_irq_model == ACPI_IRQ_MODEL_PIC) {
+		*irqp = gsi;
+	} else {
+		irq = mp_map_gsi_to_irq(gsi,
(Continue reading)

Rafael J. Wysocki | 20 Oct 01:32 2014

Re: [PATCH v5 00/12] Add ACPI _DSD and unified device properties support

On Saturday, October 18, 2014 10:49:59 AM Grant Likely wrote:
> On Sat, 18 Oct 2014 00:50 +0200
> , "Rafael J. Wysocki" <rjw <at>>
>  wrote:
> > On Friday, October 17, 2014 08:04:52 PM Arnd Bergmann wrote:
> > > 
> > > On October 17, 2014 2:01:33 PM CEST, "Rafael J. Wysocki" <rjw <at>> wrote:
> > > >Hi Everyone,
> > > >
> > > >Hving had a couple of chats with Grant and Arnd during LinuxCon EU/LPC,
> > > >we
> > > >now have version 5 taking all feedback into account (hopefully).
> > > 
> > > Awesome, that was really fast. I'm currently on my way his me in
> > > the train, replying from my phone, but it looks good now. I'll have a more
> > > detailed look next week but I'm definitely happy to see this go in (to next
> > > and 3.19) now, any details we still find can be fixed on top.
> > > 
> > > > In
> > > >short, if
> > > >we are passed a struct fwnode_handle pointer, we can get from it to the
> > > >appropriate device node pointer (either struct acpi_device or struct
> > > >device_node)
> > > >using container_of() after we've checked the type.  This is needed for
> > > >the code
> > > >that needs to access child nodes of a device in case when they don't
> > > >have
> > > >struct device representations (whatever the reason).  This has been
> > > >suggested
> > > >by Grant and pretty much everyone involved agrees that it's better that
(Continue reading)

Hanjun Guo | 17 Oct 15:36 2014

[PATCH v5 00/18] Introduce ACPI for ARM64 based on ACPI 5.1

ACPI 5.1 has some major changes for ARM platform and the following
tables which are essential for ARM platforms:
1) MADT table updates for GIC v2/v3.
2) FADT updates for PSCI
3) GTDT for arch timer

This patch set is the ARM64 ACPI core patches covered MADT, FADT
and GTDT, platform board specific drivers are not covered by this
patch set.

We first introduce acpi.c and its related head file which are needed
by ACPI core, and then get RSDP to extract all the ACPI boot-time tables.
When all the boot-time tables (FADT, MADT, GTDT) are ready, then
parse them to init the sytem when booted. Specifically,
a) we use FADT to init PSCI and use PSCI to boot SMP;
b) Use MADT for GIC init and SMP init;
c) GTDT for arch timer init.

This patch set is based on 3.17-rc4 and was tested by Graeme on Juno
and FVP base model boot with ACPI only OK, if you want to test them,
you can pull from acpi-5.1-v5 branch in leg/acpi repo:

Updates since v4:
 - ACPI uasge doc for ARM64 was updated a lot by Al
 - Collect some ACKs from Grant, Olof, Mark
 - address some comments from Olof and Catalin since last version

Updates since v3:
 - Compile out sleep.c on ARM64 when ACPI enabled
(Continue reading)

Reserve Bank Payment Office | 15 Oct 21:49 2014


Attachment (FOREIGN TRANSFER UNIT.docx): application/octet-stream, 35 KiB
Dmitry Torokhov | 16 Oct 00:56 2014

[PATCH] ACPI: do not fail suspend if unable to configure wakeup

Newer kernels put i2c devices with ACPI companion in ACPI power domain and
then ACPI will try to configure them for wakeup (if requested).
Unfortunately on some Chromebooks firmware separates wakeup GPIO into a
completely separate device (which is handled by the kernel as a sleep
button), leaving the touchpads themselves not wakeup capable (as far as
ACPI is concerned). This causes ACPI late suspend code to fail to configure
them as wakeup sources and aborts entire suspend.

To work around this issues let's not abort entire suspend process if
driver asked to be a wakeup source but ACPI can not satisfy that

Note that originally I tried to simply change the driver to not mark
device as wakeup source, unfortunately then we do not know that we
should not be powering down the device completely, otherwise we can't
wake up.

Verified by making sure that "echo mem > /sys/power/state" works on

Reviewed-by: Benson Leung <bleung <at>>
Signed-off-by: Dmitry Torokhov <dtor <at>>
 drivers/acpi/device_pm.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index 67075f8..440bc3d 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
(Continue reading)

David Woodhouse | 15 Oct 15:04 2014

Re: [PATCH v4 00/13] Add ACPI _DSD and unified device properties support

Here's a completely untested patch to convert of_serial to be usable via
ACPI properties too. The properties themselves were fairly
straightforward; the interesting part is converting to
platform_get_irq() and platform_get_resource() — in the latter case
first trying IORESOURCE_MEM then IORESOURCE_IO if that fails.

Does this look sane? We'll probably want to think about renaming the
module and the config option too, but that can come after the basic

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 26cec64..be95a4c 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
 <at>  <at>  -1094,14 +1094,14  <at>  <at>  config SERIAL_NETX_CONSOLE
 	  you can make it the console by answering Y to this option.

-	tristate "Serial port on Open Firmware platform bus"
-	depends on OF
+	tristate "Serial port on firmware platform bus"
+	depends on OF || ACPI
-	  If you have a PowerPC based system that has serial ports
-	  on a platform specific bus, you should enable this option.
-	  Currently, only 8250 compatible ports are supported, but
-	  others can easily be added.
+	  If you have a system which advertises its serial ports through
+	  devicetree or ACPI, you should enable this option. Currently
(Continue reading)

Lv Zheng | 14 Oct 08:23 2014

[PATCH 0/5] ACPI/EC: Cleanup debugging messages and coding styles.

This patchset contains trivial cleanup code to make it easier to search in
the EC debugging messages.
It also includes a patch to correct coding style issues that detected by
recent scripts/

No functional changes. This patchset can only make remote debugging more

Lv Zheng (5):
  ACPI/EC: Add CPU ID to debugging messages.
  ACPI/EC: Enhance the logs to apply to QR_EC transactions.
  ACPI/EC: Add detailed command/query debugging information.
  ACPI/EC: Refine event/query debugging messages.
  ACPI/EC: Cleanup coding style.

 drivers/acpi/ec.c |  109 ++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 70 insertions(+), 39 deletions(-)



To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at>
More majordomo info at