Hanjun Guo | 27 Mar 14:55 2015

[PATCH 0/7] minor cleanups for ACPI processor driver

This patch set are some minor cleanups for ACPI processor driver
to address the comments which raised by Rafael in ARM64 ACPI core
patches, so this patch set is on top of ARM64 ACPI core patches
the git tree is

git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
branch for-next/acpi.

Rafael, I assume this patchset will be taken with your tree if
it makes sense, any rebase work needed please let me know.

the last patch - ACPI / processor: Introduce invalid_phys_cpuid()
will cut u64 mpidr to int, but I think it is ok for error values,
correct me if I'm wrong.

Comments are welcomed.

Hanjun Guo (7):
  ACPI / processor: remove cpu_index in acpi_processor_get_info()
  ACPI / processor: remove phys_id in acpi_processor_get_info()
  ACPI / processor: Introduce invalid_logical_cpuid()
  Xen / ACPI / processor: use invalid_logical_cpuid()
  Xen / ACPI / processor: Remove unneeded NULL check in
    xen_acpi_processor_enable()
  ACPI / processor: return specific error instead of -1
  ACPI / processor: Introduce invalid_phys_cpuid()

 drivers/acpi/acpi_processor.c     | 20 +++++++++-----------
 drivers/acpi/processor_core.c     | 10 +++++-----
 drivers/acpi/processor_pdc.c      |  5 +----
(Continue reading)

Hanjun Guo | 27 Mar 13:14 2015

[PATCH 1/2] ARM64 / ACPI: Ignore the return error value of acpi_map_gic_cpu_interface()

MADT table scannig will stopped once it gets the errors
returned by the handler, which is acpi_map_gic_cpu_interface()
in for ARM64, so Ignore the return error value to search for
all enabled CPUs for SMP init.

Signed-off-by: Hanjun Guo <hanjun.guo <at> linaro.org>
---
 arch/arm64/kernel/acpi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 07649e4..c263cba 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
 <at>  <at>  -181,7 +181,8  <at>  <at>  acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
 		return -EINVAL;

 	acpi_table_print_madt_entry(header);
-	return acpi_map_gic_cpu_interface(processor);
+	acpi_map_gic_cpu_interface(processor);
+	return 0;
 }

 /* Parse GIC cpu interface entries in MADT for SMP init */
--

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Borislav Petkov | 27 Mar 10:22 2015
Picon

[RFC PATCH 0/5] GHES NMI handler cleanup

From: Borislav Petkov <bp <at> suse.de>

So this patchset is the result of us seeing this while debugging a
customer issue:

[  118.113136] INFO: NMI handler (ghes_notify_nmi) took too long to run: 1.005 msecs

Looking at that NMI handler, it could use a good scrubbing as it has
grown some needless fat. So let's try it.

First 4 patches simplify it and clean it, and the last one does the
bold move of making the status reader CPU be a single one based on
the not-100-percent-confirmed observation that GHES error sources are
global in the firmware glue and thus only one reader suffices to see all
errors.

This last thing still needs to be confirmed but I'm sending the patches
now so that people can look at them and poke holes. Thus the RFC tag.

Thanks.

Borislav Petkov (4):
  GHES: Carve out error queueing in a separate function
  GHES: Carve out the panic functionality
  GHES: Panic right after detection
  GHES: Elliminate double-loop in the NMI handler

Jiri Kosina (1):
  GHES: Make NMI handler have a single reader

(Continue reading)

Will Deacon | 25 Mar 18:20 2015

Request for additional arm64 branch in linux-next

Hi Stephen,

We've got a series of patches introducing ACPI support for arm64 that
are tentatively targetting the 4.1 merge window. Whilst there are
face-to-face discussions set to happen in the next day or so around this
topic, could you please pull this into linux-next under the assumption
that we decide to go ahead for mainline inclusion?

  git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/acpi

I've kept the series separate from the usual arm64 branch (for-next/core)
but they merge without conflicts. Merging with today's next, I see two
trivial Kconfig conflicts (resolution below).

I'll let you know when the branch is no longer needed.

Thanks,

Will

--->8

diff --cc arch/arm64/Kconfig
index 4085df18e558,0659db374731..0eae06cdac27
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
 <at>  <at>  <at>  -1,7 -1,9 +1,9  <at>  <at>  <at> 
  config ARM64
  	def_bool y
+ 	select ACPI_GENERIC_GSI if ACPI
(Continue reading)

Lorenzo Pieralisi | 24 Mar 18:58 2015

[PATCH 0/5] ARM64: ACPI core updates

This patch series implements some refactoring/clean-ups of arm64 ACPI
core code implemented in Hanjun Guo's series:

http://www.spinics.net/lists/kernel/msg1953211.html

available at:

git://git.linaro.org/leg/acpi/acpi.git acpi-5.1-v11

Patch [1] is a proposal to move the arm64 GSI IRQ mapping layer to generic
ACPI code, in that the arm64 GSI layer is based on IRQ domains that are
generic data structures in the kernel that are not tied to an arch specific
implementation.

Patches [2-5] implement some fixes/clean-up of arm64 ACPI core code.

Tested on Juno v8 chip.

Lorenzo Pieralisi (5):
  ACPI: move arm64 GSI IRQ model to generic GSI IRQ layer
  ARM64: kernel: psci: factor out probe function
  ARM64: kernel: psci: let ACPI probe PSCI version
  ARM64: kernel: acpi: refactor ACPI tables init and checks
  ARM64: kernel: acpi: honour acpi=force command line parameter

 arch/arm64/Kconfig            |   1 +
 arch/arm64/include/asm/acpi.h |   3 -
 arch/arm64/kernel/acpi.c      | 167 +++++++++++++++++-------------------------
 arch/arm64/kernel/psci.c      |  54 +++++++++-----
 arch/arm64/kernel/setup.c     |   2 +-
(Continue reading)

Hanjun Guo | 24 Mar 15:02 2015

[patch v11 00/23] Introduce ACPI for ARM64 based on ACPI 5.1

Some fixes since last version:

 - Add a patch 19/23 for disabling ACPI for Xen on ARM64 for now to fix
   compile errors on XEN ACPI, Stefano and Julien are ok with this
   temporary solution.
 - Add patch "ARM64 / ACPI: Don't unflatten device tree if acpi=force 
   is passed", which will fix the problem that the device tree will
   be unflattened even if acpi=force passed, that will not obey the
   policy.
 - update patch "irqchip: Add GICv2 specific ACPI boot support",
   which will cause compile error on i386 with both DT and ACPI
   enabled:

   All error/warnings:

    In file included from include/linux/acpi_irq.h:4:0,
                     from drivers/irqchip/irqchip.c:11:
    arch/x86/include/asm/irq.h:35:8: error: unknown type name 'bool'
     extern bool handle_irq(unsigned irq, struct pt_regs *regs);
            ^
    arch/x86/include/asm/irq.h:35:45: warning: 'struct pt_regs' declared 
    inside parameter list
     extern bool handle_irq(unsigned irq, struct pt_regs *regs);
                                                 ^
    arch/x86/include/asm/irq.h:35:45: warning: its scope is only this 
    definition or declaration, which is probably not what you want
    ....

   That's because of I include the <asm/irq.h> in <linux/acpi_irq.h>,
   and <linux/acpi_irq.h> will be put on the top of all head files,
(Continue reading)

Rafael J. Wysocki | 24 Mar 01:40 2015
Picon

[PATCH] driver core: property: Update fwnode_property_read_string_array()

From: Rafael J. Wysocki <rafael.j.wysocki <at> intel.com>

Commit 5c0acf3b4f96 (driver core: Add comments about returning array
counts) forgot to update fwnode_property_read_string_array() along
the lines of device_property_read_string_array(), although it did
change the kerneldoc comment of it.  Fix that.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki <at> intel.com>
---
 drivers/base/property.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/base/property.c
===================================================================
--- linux-pm.orig/drivers/base/property.c
+++ linux-pm/drivers/base/property.c
 <at>  <at>  -347,8 +347,10  <at>  <at>  int fwnode_property_read_string_array(st
 				      size_t nval)
 {
 	if (is_of_node(fwnode))
-		return of_property_read_string_array(of_node(fwnode), propname,
-						     val, nval);
+		return val ?
+			of_property_read_string_array(of_node(fwnode), propname,
+						      val, nval) :
+			of_property_count_strings(of_node(fwnode), propname);
 	else if (is_acpi_node(fwnode))
 		return acpi_dev_prop_read(acpi_node(fwnode), propname,
 					  DEV_PROP_STRING, val, nval);

(Continue reading)

Julien Grall | 22 Mar 22:05 2015

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

Hello,

On 21/03/2015 12:09, Naresh Bhat wrote:
>      From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 2001
>     From: Hanjun Guo <hanjun.guo <at> linaro.org <mailto:hanjun.guo <at> 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.guo <at> linaro.org
>     <mailto:hanjun.guo <at> 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
>      <at>  <at>  -253,4 +253,8  <at>  <at>  config XEN_EFI
>           def_bool y
>           depends on X86_64 && EFI
>
>     +config XEN_ACPI
>     +    def_bool y
(Continue reading)

Hans de Goede | 20 Mar 09:59 2015
Picon

[PATCH 0/1] acpi: video: Add enable native backlight quirk for Lenovo Ideapad Z570

Hi All,

Here is a patch fixing the backlight issues on Lenovo Ideapad Z570 laptops
discussed a while back.

Note that this patch depends on Aaron Lu's
"acpi: video: Allow forcing native backlight on non win8 machines" patch.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hans de Goede | 19 Mar 13:50 2015
Picon

Re: Backlight control broken on Lenovo Ideapad Z570

Hi,

On 18-03-15 22:31, Stepan Bujnak wrote:
> Hi, unfortunately I moved to San Francisco and left my old laptop at
> home, so I cannot debug the issue anymore. As far as I remember
> correctly, the problem was that I only had the intel_backlight interface
> which did not work as expected (value always on top, the buttons did not
> work, neither did writing the value manually). Once I blacklisted the
> intel_backlight using the patch I submitted I was able to get the
> backlight working.
>
> However, I'm reading that you've got fix for the problem and my patch
> conflicts with it? If this is the case, please replace my code with your
> fix, and once I get back home (April 28th) we can continue debugging the
> issue using my laptop.

Ok, I'll do a patch with what I believe is a more complete fix, and then
I'll ask Be to test it, and if that goes well send it upstream.

Regards,

Hams

>
> Best wishes,
> Stepan
>
> On Wed, Mar 18, 2015, at 06:12 AM, Hans de Goede wrote:
>> Hi Stepan,
>>
(Continue reading)

Bernhard Thaler | 19 Mar 08:10 2015
Picon

Re: [Debug 0/2] Fix regressions caused by commit 593669c2ac0f

Hi,

I think this regression is not yet solved.

I encounter this or a similar problem with an PC Engines APU.1C device
(see: http://pcengines.ch/apu.htm). It has 3 network interfaces each
requiring the r8169 kernel module.

With 4.0.0-rc4 I get this error message at boot (for each of the 3 devices):

[    3.562301] r8169 0000:01:00.0 (unnamed net_device) (uninitialized):
rtl_chipcmd_cond == 1 (loop: 100, delay: 100).

"ifconfig -a" shows ff:ff:ff:ff:ff:ff as MAC address for each of the
interfaces (see eth0 as example):

eth0      Link encap:Ethernet  HWaddr ff:ff:ff:ff:ff:ff
          BROADCAST PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

The network interfaces cannot be brought up/used.

The same device and setup did work with a previously used 3.18.0-rc5
kernel. When I boot it with this 3.18.0-rc5 kernel everything i OK,
interfaces come up and work.

Please find attached:
(Continue reading)


Gmane