Re: [RESEND PATCH 0/6] thermal: sti: Add new Thermal driver

[Zhang Rui]

On Wed, 2014-07-09 at 13:08 +0100, Lee Jones wrote:
 On Tue, 24 Jun 2014, Lee Jones wrote:
 
   I'm re-sending this set, as one of the maintainers' email addresses
   is incorrect in the MAINTAINERS file.
   
   This patchset adds full support for 2 types of Thermal Controllers
   produced by STMicroelectronics.  One is a more traditional memory
   mapped variant, the other is controlled solely by system configuration
   registers.
  
  Any thing from the Thermal guys? Has this set fallen through the gaps?
 
 Anything at all?  It's been well over a month now.
 
Well, for the soc thermal drivers, I'd prefer to take them via Eduardo,
but as we didn't get any feedback from Eduardo, I will take them.

thanks,
rui
Documentation/devicetree/bindings/thermal/st-thermal.txt |  42 
   
arch/arm/boot/dts/stih416.dtsi   |  18 +++
arch/arm/configs/multi_v7_defconfig  |   2 +
drivers/thermal/Kconfig  |   5 ++
drivers/thermal/Makefile |   1 +
drivers/thermal/st/Kconfig   |  12 +
drivers/thermal/st/Makefile  |   3 ++
drivers/thermal/st/st_thermal.c  | 313 
   ++
   
drivers/thermal/st/st_thermal.h  | 104 
   ++
drivers/thermal/st/st_thermal_memmap.c   | 209 
   
drivers/thermal/st/st_thermal_syscfg.c   | 179 
   +
11 files changed, 888 insertions(+)
   
  
 


--
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/

[GIT PULL] Thermal Management updates for v3.16-rc5

[Zhang Rui]

Please pull from the git repository at

  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git for-rc

to receive Thermal management updates for v3.16-rc5 with
top-most commit 4adccf9fc84aaf5e4d18442e163d549e0b603075:

  tmon: set umask to a reasonable value (2014-07-01 22:00:51 +0800)

on top of commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:

  Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)

Specifics:

- Update Email address of Thermal subsystem maintainer Eduardo Valentin.

- Fix a problem that unloading thermal module results in kernel crash
because a non-exist device file is removed on thermal unload.

- Fix a problem that critical trip point is set wrongly on latest i.MX6
SOC and results in system critical shutdown.

- a couple of fixes to Tmon tool, of-thermal code and ti thermal driver.

thanks,
rui


Aaron Lu (1):
  thermal: hwmon: Make the check for critical temp valid consistent

Anson Huang (1):
  Thermal: imx: correct critical trip temperature setting

Javi Merino (1):
  tools/thermal: tmon: fix compilation errors when building
statically

Lee Jones (1):
  MAINTAINERS: Update Eduardo Valentin's email address

Neil Horman (2):
  tmon: Check log file for common secuirty issues
  tmon: set umask to a reasonable value

Punit Agrawal (1):
  thermal: Bind cooling devices with the correct arguments

Rickard Strandqvist (1):
  thermal: ti-soc-thermal: ti-bandgap.c: Cleaning up wrong address
is checked

Stephen Boyd (1):
  thermal: Add braces around suspect code

 MAINTAINERS |  4 ++--
 drivers/thermal/imx_thermal.c   | 18 +++---
 drivers/thermal/of-thermal.c|  7 ---
 drivers/thermal/thermal_hwmon.c | 33
++---
 drivers/thermal/ti-soc-thermal/ti-bandgap.c |  2 +-
 tools/thermal/tmon/Makefile |  2 +-
 tools/thermal/tmon/tmon.c   | 26
+-
 7 files changed, 58 insertions(+), 34 deletions(-)


--
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: ACPI resource change triggers loss of serial ports

[Zhang Rui]

On Mon, 2014-07-07 at 14:57 +0200, Rafael J. Wysocki wrote:
> On Thursday, June 19, 2014 11:41:30 AM Andy Whitcroft wrote:
> > The recently merged change (in v3.14-rc6) to ACPI resource detection
> > (below) causes all zero length ACPI resources to be elided from the table:
> > 
> >   commit b355cee88e3b1a193f0e9a81db810f6f83ad728b
> >   Author: Zhang Rui 
> >   Date:   Thu Feb 27 11:37:15 2014 +0800
> > 
> > ACPI / resources: ignore invalid ACPI device resources
> > 
> > This change has caused a regression in (at least) serial port detection
> > for a number of machines (see LP#1313981 [1]).  These seem to represent
> > their IO regions (presumably incorrectly) as a zero length region.
> > Reverting the above commit restores these serial devices.
> > 
> > For Zhang's case I wonder if this check could be tightened up to cover
> > only the zero base, something like the (untested) patch below.
> > 
> > -apw
> > 
> > [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313981
> 
> I'm going to queue up the patch below for 3.16.
> 
> Rui, can you please have a look at this and let me know if there's
> anything wrong with it?
> 
> Rafael
> 
> 
> > From e5211c68278387ef65e483bcfedd5581a79ec783 Mon Sep 17 00:00:00 2001
> > From: Andy Whitcroft 
> > Date: Thu, 19 Jun 2014 11:19:16 +0100
> > Subject: [PATCH] ACPI / Resources: only reject zero length resources based 
> > at
> >  address zero
> > 
> > The recently merged change (in v3.14-rc6) to ACPI resource detection
> > (below) causes all zero length ACPI resources to be elided from the
> > table:
> > 
> >   commit b355cee88e3b1a193f0e9a81db810f6f83ad728b
> >   Author: Zhang Rui 
> >   Date:   Thu Feb 27 11:37:15 2014 +0800
> > 
> > ACPI / resources: ignore invalid ACPI device resources
> > 
> > This change has caused a regression in (at least) serial port detection
> > for a number of machines (see LP#1313981 [1]).  These seem to represent
> > their IO regions (presumably incorrectly) as a zero length region.
> > Reverting the above commit restores these serial devices.
> > 
> > Only elide zero length resources which lie at address 0.
> > 
> > Signed-off-by: Andy Whitcroft 
The patch looks okay to me.

Acked-by: Zhang Rui 

thanks,
rui
> > ---
> >  drivers/acpi/resource.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> > index 0bdacc5..2ba8f02 100644
> > --- a/drivers/acpi/resource.c
> > +++ b/drivers/acpi/resource.c
> > @@ -77,7 +77,7 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, 
> > struct resource *res)
> > switch (ares->type) {
> > case ACPI_RESOURCE_TYPE_MEMORY24:
> > memory24 = >data.memory24;
> > -   if (!memory24->address_length)
> > +   if (!memory24->minimum && !memory24->address_length)
> > return false;
> > acpi_dev_get_memresource(res, memory24->minimum,
> >  memory24->address_length,
> > @@ -85,7 +85,7 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, 
> > struct resource *res)
> > break;
> > case ACPI_RESOURCE_TYPE_MEMORY32:
> > memory32 = >data.memory32;
> > -   if (!memory32->address_length)
> > +   if (!memory32->minimum && !memory32->address_length)
> > return false;
> > acpi_dev_get_memresource(res, memory32->minimum,
> >  memory32->address_length,
> > @@ -93,7 +93,7 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, 
> > struct resource *res)
> > break;
> > case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
> > fixed_memory32 = >data.fixed_memory32;
> > -   if (!fixed_memory32->address_length)
> > +   if (!fixed_memory32->address && !fixed_memory32->address_length)
> > return false;
> > acpi_dev_get_memresource(res, fixed_memory32->address,
> >  fixed_memory32->address_length,
> > @@ -150,7 +150,7 @@ bool acpi_dev_resource_io(struct acpi_resource *ares, 
> > struct resource *res)
> > switch (ares->type) {
> > case ACPI_RESOURCE_TYPE_IO:
> > io = >data.io;
> > -   if (!io->addr

Re: ACPI resource change triggers loss of serial ports

[Zhang Rui]

On Mon, 2014-07-07 at 14:57 +0200, Rafael J. Wysocki wrote:
 On Thursday, June 19, 2014 11:41:30 AM Andy Whitcroft wrote:
  The recently merged change (in v3.14-rc6) to ACPI resource detection
  (below) causes all zero length ACPI resources to be elided from the table:
  
commit b355cee88e3b1a193f0e9a81db810f6f83ad728b
Author: Zhang Rui rui.zh...@intel.com
Date:   Thu Feb 27 11:37:15 2014 +0800
  
  ACPI / resources: ignore invalid ACPI device resources
  
  This change has caused a regression in (at least) serial port detection
  for a number of machines (see LP#1313981 [1]).  These seem to represent
  their IO regions (presumably incorrectly) as a zero length region.
  Reverting the above commit restores these serial devices.
  
  For Zhang's case I wonder if this check could be tightened up to cover
  only the zero base, something like the (untested) patch below.
  
  -apw
  
  [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313981
 
 I'm going to queue up the patch below for 3.16.
 
 Rui, can you please have a look at this and let me know if there's
 anything wrong with it?
 
 Rafael
 
 
  From e5211c68278387ef65e483bcfedd5581a79ec783 Mon Sep 17 00:00:00 2001
  From: Andy Whitcroft a...@canonical.com
  Date: Thu, 19 Jun 2014 11:19:16 +0100
  Subject: [PATCH] ACPI / Resources: only reject zero length resources based 
  at
   address zero
  
  The recently merged change (in v3.14-rc6) to ACPI resource detection
  (below) causes all zero length ACPI resources to be elided from the
  table:
  
commit b355cee88e3b1a193f0e9a81db810f6f83ad728b
Author: Zhang Rui rui.zh...@intel.com
Date:   Thu Feb 27 11:37:15 2014 +0800
  
  ACPI / resources: ignore invalid ACPI device resources
  
  This change has caused a regression in (at least) serial port detection
  for a number of machines (see LP#1313981 [1]).  These seem to represent
  their IO regions (presumably incorrectly) as a zero length region.
  Reverting the above commit restores these serial devices.
  
  Only elide zero length resources which lie at address 0.
  
  Signed-off-by: Andy Whitcroft a...@canonical.com
The patch looks okay to me.

Acked-by: Zhang Rui rui.zh...@intel.com

thanks,
rui
  ---
   drivers/acpi/resource.c | 10 +-
   1 file changed, 5 insertions(+), 5 deletions(-)
  
  diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
  index 0bdacc5..2ba8f02 100644
  --- a/drivers/acpi/resource.c
  +++ b/drivers/acpi/resource.c
  @@ -77,7 +77,7 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, 
  struct resource *res)
  switch (ares-type) {
  case ACPI_RESOURCE_TYPE_MEMORY24:
  memory24 = ares-data.memory24;
  -   if (!memory24-address_length)
  +   if (!memory24-minimum  !memory24-address_length)
  return false;
  acpi_dev_get_memresource(res, memory24-minimum,
   memory24-address_length,
  @@ -85,7 +85,7 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, 
  struct resource *res)
  break;
  case ACPI_RESOURCE_TYPE_MEMORY32:
  memory32 = ares-data.memory32;
  -   if (!memory32-address_length)
  +   if (!memory32-minimum  !memory32-address_length)
  return false;
  acpi_dev_get_memresource(res, memory32-minimum,
   memory32-address_length,
  @@ -93,7 +93,7 @@ bool acpi_dev_resource_memory(struct acpi_resource *ares, 
  struct resource *res)
  break;
  case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
  fixed_memory32 = ares-data.fixed_memory32;
  -   if (!fixed_memory32-address_length)
  +   if (!fixed_memory32-address  !fixed_memory32-address_length)
  return false;
  acpi_dev_get_memresource(res, fixed_memory32-address,
   fixed_memory32-address_length,
  @@ -150,7 +150,7 @@ bool acpi_dev_resource_io(struct acpi_resource *ares, 
  struct resource *res)
  switch (ares-type) {
  case ACPI_RESOURCE_TYPE_IO:
  io = ares-data.io;
  -   if (!io-address_length)
  +   if (!io-minimum  !io-address_length)
  return false;
  acpi_dev_get_ioresource(res, io-minimum,
  io-address_length,
  @@ -158,7 +158,7 @@ bool acpi_dev_resource_io(struct acpi_resource *ares, 
  struct resource *res)
  break;
  case ACPI_RESOURCE_TYPE_FIXED_IO:
  fixed_io = ares-data.fixed_io;
  -   if (!fixed_io-address_length)
  +   if (!fixed_io-address  !fixed_io-address_length)
  return false;
  acpi_dev_get_ioresource(res, fixed_io-address,
  fixed_io-address_length,
  
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord

[GIT PULL] Thermal Management updates for v3.16-rc5

[Zhang Rui]

Please pull from the git repository at

  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git for-rc

to receive Thermal management updates for v3.16-rc5 with
top-most commit 4adccf9fc84aaf5e4d18442e163d549e0b603075:

  tmon: set umask to a reasonable value (2014-07-01 22:00:51 +0800)

on top of commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:

  Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)

Specifics:

- Update Email address of Thermal subsystem maintainer Eduardo Valentin.

- Fix a problem that unloading thermal module results in kernel crash
because a non-exist device file is removed on thermal unload.

- Fix a problem that critical trip point is set wrongly on latest i.MX6
SOC and results in system critical shutdown.

- a couple of fixes to Tmon tool, of-thermal code and ti thermal driver.

thanks,
rui


Aaron Lu (1):
  thermal: hwmon: Make the check for critical temp valid consistent

Anson Huang (1):
  Thermal: imx: correct critical trip temperature setting

Javi Merino (1):
  tools/thermal: tmon: fix compilation errors when building
statically

Lee Jones (1):
  MAINTAINERS: Update Eduardo Valentin's email address

Neil Horman (2):
  tmon: Check log file for common secuirty issues
  tmon: set umask to a reasonable value

Punit Agrawal (1):
  thermal: Bind cooling devices with the correct arguments

Rickard Strandqvist (1):
  thermal: ti-soc-thermal: ti-bandgap.c: Cleaning up wrong address
is checked

Stephen Boyd (1):
  thermal: Add braces around suspect code

 MAINTAINERS |  4 ++--
 drivers/thermal/imx_thermal.c   | 18 +++---
 drivers/thermal/of-thermal.c|  7 ---
 drivers/thermal/thermal_hwmon.c | 33
++---
 drivers/thermal/ti-soc-thermal/ti-bandgap.c |  2 +-
 tools/thermal/tmon/Makefile |  2 +-
 tools/thermal/tmon/tmon.c   | 26
+-
 7 files changed, 58 insertions(+), 34 deletions(-)


--
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] soc_button_array: fix the issue that button device can't be enumerated since 3.16-rc1

[Zhang Rui]

>From c2ee1886ba230d9d93d2ea2f350b1dc1a2d5ead5 Mon Sep 17 00:00:00 2001
From: Jin Yao 
Date: Thu, 26 Jun 2014 10:26:44 +0800
Subject: [PATCH] soc_button_array: fix the issue that button device can't be
 enumerated since 3.16-rc1

ACPI device enumeration mechanism changed a lot since 3.16-rc1.
ACPI device objects with _HID will be enumerated to platform bus by default.
For the existing PNP drivers that probe the PNPACPI devices, the device ids
are listed explicitly in drivers/acpi/acpi_pnp.c. And ACPI folks will
continue their effort on shrinking this id list by converting the PNP drivers
to platform drivers.
But unfortunately, soc_button_array device id, aka, "PNP0C40", is missing
during this transition.

Thus soc_button_array driver fails to probe any device since 3.16-rc1 because
the device is enumerated to platform bus instead.

A simply fix is to add device id PNP0C40 back to drivers/acpi/acpi_pnp.c,
but given that the soc_button_array driver will be converted to platform
driver sooner or later, and the id will be removed from the list again,
it is better to fix the problem in one time.

This patch fixes the problem by converting the soc_button_driver
from PNP bus to platform bus.

Signed-off-by: Jin Yao 
Signed-off-by: Zhang Rui 
---
 drivers/input/misc/soc_button_array.c | 60 ++-
 1 file changed, 31 insertions(+), 29 deletions(-)

diff --git a/drivers/input/misc/soc_button_array.c 
b/drivers/input/misc/soc_button_array.c
index 5a6334b..16ca162 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /*
  * Definition of buttons on the tablet. The ACPI index of each button
@@ -67,7 +67,7 @@ static int soc_button_lookup_gpio(struct device *dev, int 
acpi_index)
 }
 
 static struct platform_device *
-soc_button_device_create(struct pnp_dev *pdev,
+soc_button_device_create(struct platform_device *pdev,
 const struct soc_button_info *button_info,
 bool autorepeat)
 {
@@ -135,30 +135,40 @@ soc_button_device_create(struct pnp_dev *pdev,
return ERR_PTR(error);
 }
 
-static void soc_button_remove(struct pnp_dev *pdev)
+static int soc_button_remove(struct platform_device *pdev)
 {
-   struct soc_button_data *priv = pnp_get_drvdata(pdev);
+   struct soc_button_data *priv = platform_get_drvdata(pdev);
+
int i;
 
for (i = 0; i < BUTTON_TYPES; i++)
if (priv->children[i])
platform_device_unregister(priv->children[i]);
+
+   return 0;
 }
 
-static int soc_button_pnp_probe(struct pnp_dev *pdev,
-   const struct pnp_device_id *id)
+static int soc_button_probe(struct platform_device *pdev)
 {
-   const struct soc_button_info *button_info = (void *)id->driver_data;
+   struct device *dev = >dev;
+   const struct acpi_device_id *id;
+   struct soc_button_info *button_info;
struct soc_button_data *priv;
struct platform_device *pd;
int i;
int error;
 
+   id = acpi_match_device(dev->driver->acpi_match_table, dev);
+   if (!id)
+   return -ENODEV;
+
+   button_info = (struct soc_button_info *)id->driver_data;
+
priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
 
-   pnp_set_drvdata(pdev, priv);
+   platform_set_drvdata(pdev, priv);
 
for (i = 0; i < BUTTON_TYPES; i++) {
pd = soc_button_device_create(pdev, button_info, i == 0);
@@ -189,30 +199,22 @@ static struct soc_button_info soc_button_PNP0C40[] = {
{ }
 };
 
-static const struct pnp_device_id soc_button_pnp_match[] = {
-   { .id = "PNP0C40", .driver_data = (long)soc_button_PNP0C40 },
-   { .id = "" }
+static const struct acpi_device_id soc_button_acpi_match[] = {
+   { "PNP0C40", (unsigned long)soc_button_PNP0C40 },
+   { }
 };
-MODULE_DEVICE_TABLE(pnp, soc_button_pnp_match);
 
-static struct pnp_driver soc_button_pnp_driver = {
-   .name   = KBUILD_MODNAME,
-   .id_table   = soc_button_pnp_match,
-   .probe  = soc_button_pnp_probe,
+MODULE_DEVICE_TABLE(acpi, soc_button_acpi_match);
+
+static struct platform_driver soc_button_driver = {
+   .probe  = soc_button_probe,
.remove = soc_button_remove,
+   .driver = {
+   .name = KBUILD_MODNAME,
+   .owner = THIS_MODULE,
+   .acpi_match_table = ACPI_PTR(soc_button_acpi_match),
+   },
 };
-
-static int __init soc_button_init(void)
-{
-   return pnp_register_driver(_button_pnp_driver);
-}
-
-static void __exit soc_button_exit(void)
-{
-   pnp_unregister_driver(_button_pnp_driver);
-}
-
-module_init(soc_button_init);
-module_exit(soc_button_exit);
+module_

[PATCH] soc_button_array: fix the issue that button device can't be enumerated since 3.16-rc1

[Zhang Rui]

From c2ee1886ba230d9d93d2ea2f350b1dc1a2d5ead5 Mon Sep 17 00:00:00 2001
From: Jin Yao yao@linux.intel.com
Date: Thu, 26 Jun 2014 10:26:44 +0800
Subject: [PATCH] soc_button_array: fix the issue that button device can't be
 enumerated since 3.16-rc1

ACPI device enumeration mechanism changed a lot since 3.16-rc1.
ACPI device objects with _HID will be enumerated to platform bus by default.
For the existing PNP drivers that probe the PNPACPI devices, the device ids
are listed explicitly in drivers/acpi/acpi_pnp.c. And ACPI folks will
continue their effort on shrinking this id list by converting the PNP drivers
to platform drivers.
But unfortunately, soc_button_array device id, aka, PNP0C40, is missing
during this transition.

Thus soc_button_array driver fails to probe any device since 3.16-rc1 because
the device is enumerated to platform bus instead.

A simply fix is to add device id PNP0C40 back to drivers/acpi/acpi_pnp.c,
but given that the soc_button_array driver will be converted to platform
driver sooner or later, and the id will be removed from the list again,
it is better to fix the problem in one time.

This patch fixes the problem by converting the soc_button_driver
from PNP bus to platform bus.

Signed-off-by: Jin Yao yao@intel.com
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/input/misc/soc_button_array.c | 60 ++-
 1 file changed, 31 insertions(+), 29 deletions(-)

diff --git a/drivers/input/misc/soc_button_array.c 
b/drivers/input/misc/soc_button_array.c
index 5a6334b..16ca162 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -18,7 +18,7 @@
 #include linux/gpio/consumer.h
 #include linux/gpio_keys.h
 #include linux/platform_device.h
-#include linux/pnp.h
+#include linux/acpi.h
 
 /*
  * Definition of buttons on the tablet. The ACPI index of each button
@@ -67,7 +67,7 @@ static int soc_button_lookup_gpio(struct device *dev, int 
acpi_index)
 }
 
 static struct platform_device *
-soc_button_device_create(struct pnp_dev *pdev,
+soc_button_device_create(struct platform_device *pdev,
 const struct soc_button_info *button_info,
 bool autorepeat)
 {
@@ -135,30 +135,40 @@ soc_button_device_create(struct pnp_dev *pdev,
return ERR_PTR(error);
 }
 
-static void soc_button_remove(struct pnp_dev *pdev)
+static int soc_button_remove(struct platform_device *pdev)
 {
-   struct soc_button_data *priv = pnp_get_drvdata(pdev);
+   struct soc_button_data *priv = platform_get_drvdata(pdev);
+
int i;
 
for (i = 0; i  BUTTON_TYPES; i++)
if (priv-children[i])
platform_device_unregister(priv-children[i]);
+
+   return 0;
 }
 
-static int soc_button_pnp_probe(struct pnp_dev *pdev,
-   const struct pnp_device_id *id)
+static int soc_button_probe(struct platform_device *pdev)
 {
-   const struct soc_button_info *button_info = (void *)id-driver_data;
+   struct device *dev = pdev-dev;
+   const struct acpi_device_id *id;
+   struct soc_button_info *button_info;
struct soc_button_data *priv;
struct platform_device *pd;
int i;
int error;
 
+   id = acpi_match_device(dev-driver-acpi_match_table, dev);
+   if (!id)
+   return -ENODEV;
+
+   button_info = (struct soc_button_info *)id-driver_data;
+
priv = devm_kzalloc(pdev-dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
 
-   pnp_set_drvdata(pdev, priv);
+   platform_set_drvdata(pdev, priv);
 
for (i = 0; i  BUTTON_TYPES; i++) {
pd = soc_button_device_create(pdev, button_info, i == 0);
@@ -189,30 +199,22 @@ static struct soc_button_info soc_button_PNP0C40[] = {
{ }
 };
 
-static const struct pnp_device_id soc_button_pnp_match[] = {
-   { .id = PNP0C40, .driver_data = (long)soc_button_PNP0C40 },
-   { .id =  }
+static const struct acpi_device_id soc_button_acpi_match[] = {
+   { PNP0C40, (unsigned long)soc_button_PNP0C40 },
+   { }
 };
-MODULE_DEVICE_TABLE(pnp, soc_button_pnp_match);
 
-static struct pnp_driver soc_button_pnp_driver = {
-   .name   = KBUILD_MODNAME,
-   .id_table   = soc_button_pnp_match,
-   .probe  = soc_button_pnp_probe,
+MODULE_DEVICE_TABLE(acpi, soc_button_acpi_match);
+
+static struct platform_driver soc_button_driver = {
+   .probe  = soc_button_probe,
.remove = soc_button_remove,
+   .driver = {
+   .name = KBUILD_MODNAME,
+   .owner = THIS_MODULE,
+   .acpi_match_table = ACPI_PTR(soc_button_acpi_match),
+   },
 };
-
-static int __init soc_button_init(void)
-{
-   return pnp_register_driver(soc_button_pnp_driver);
-}
-
-static void __exit soc_button_exit(void)
-{
-   pnp_unregister_driver(soc_button_pnp_driver

Re: PATCH 0/2 tmon: fix a few minor security issues

[Zhang Rui]

On Tue, 2014-07-01 at 07:42 -0400, Neil Horman wrote:
> On Tue, Jun 17, 2014 at 04:05:07PM -0400, Neil Horman wrote:
> > Just a few little fixups for tmon, to prevent abuse of its logging facility
> > 
> > Best
> > Neil
> > 
> Ping, Zhang, Jacob acked these, but I've not seen them go into your tree yet.
> Do you have an issue with them?
> 
Oh, next time when you send thermal related patches, please send them to
linux...@vger.kernel.org mailing list so that I can review the patches
in https://patchwork.kernel.org/project/linux-pm/list/

Both patches applied. Thanks!

-rui
> Neil
> 
> > --
> > 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/
> > 


--
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 0/2 tmon: fix a few minor security issues

[Zhang Rui]

On Tue, 2014-07-01 at 07:42 -0400, Neil Horman wrote:
 On Tue, Jun 17, 2014 at 04:05:07PM -0400, Neil Horman wrote:
  Just a few little fixups for tmon, to prevent abuse of its logging facility
  
  Best
  Neil
  
 Ping, Zhang, Jacob acked these, but I've not seen them go into your tree yet.
 Do you have an issue with them?
 
Oh, next time when you send thermal related patches, please send them to
linux...@vger.kernel.org mailing list so that I can review the patches
in https://patchwork.kernel.org/project/linux-pm/list/

Both patches applied. Thanks!

-rui
 Neil
 
  --
  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/
  


--
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 v2 0/9] thermal: exynos: various cleanups

[Zhang Rui]

Eduardo,

what do you think of this patch set?

thanks,
rui

On Tue, 2014-06-17 at 19:27 +0200, Bartlomiej Zolnierkiewicz wrote:
> Hi,
> 
> This patch series contains various cleanups for EXYNOS thermal
> driver.  Overall it decreases driver's LOC by 12%.  It is based
> on next-20140617 kernel.  It should not cause any functionality
> changes.
> 
> Changes since v1:
> - synced patches against next-20140617
> - merged patch "thermal: exynos: remove unused defines" into
>   "thermal: exynos: remove unused struct exynos_tmu_registers
>   entries" one (per request from Eduardo)
> - improved patch descriptions for patches #1-5
> - fixed documentation for pdata->gain and pdata->reference_voltage
> - added Reviewed-by from Amit to patches #6, #7 and #10
> - added missing Acked-by from Kyungmin Park
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
> 
> 
> Bartlomiej Zolnierkiewicz (9):
>   thermal: exynos: remove unused struct exynos_tmu_registers entries
>   thermal: exynos: remove dead code for HW_MODE calibration
>   thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING
> calibration
>   thermal: exynos: remove redundant pdata checks from
> exynos_tmu_initialize()
>   thermal: exynos: remove redundant threshold_code checks from
> exynos_tmu_initialize()
>   thermal: exynos: simplify temp_to_code() and code_to_temp()
>   thermal: exynos: cache non_hw_trigger_levels in pdata
>   thermal: exynos: remove redundant pdata checks from
> exynos_tmu_control()
>   thermal: exynos: remove identical values from exynos*_tmu_registers
> structures
> 
>  drivers/thermal/samsung/exynos_thermal_common.h |   1 -
>  drivers/thermal/samsung/exynos_tmu.c| 181 
> 
>  drivers/thermal/samsung/exynos_tmu.h|  90 +---
>  drivers/thermal/samsung/exynos_tmu_data.c   |  64 +
>  drivers/thermal/samsung/exynos_tmu_data.h   |  33 +
>  5 files changed, 41 insertions(+), 328 deletions(-)
> 


--
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 0/6] thermal: sti: Add new Thermal driver

[Zhang Rui]

Hi, Eduardo,

what do you think of this patch set?

thanks,
rui

On Fri, 2014-05-30 at 10:38 +0100, Lee Jones wrote:
> This patchset adds full support for 2 types of Thermal Controllers
> produced by STMicroelectronics.  One is a more traditional memory
> mapped variant, the other is controlled solely by system configuration
> registers.
> 
>  Documentation/devicetree/bindings/thermal/st-thermal.txt |  42 
> 
>  arch/arm/boot/dts/stih416.dtsi   |  18 +++
>  arch/arm/configs/multi_v7_defconfig  |   2 +
>  drivers/thermal/Kconfig  |   5 ++
>  drivers/thermal/Makefile |   1 +
>  drivers/thermal/st/Kconfig   |  12 +
>  drivers/thermal/st/Makefile  |   3 ++
>  drivers/thermal/st/st_thermal.c  | 313 
> ++
>  drivers/thermal/st/st_thermal.h  | 104 
> ++
>  drivers/thermal/st/st_thermal_memmap.c   | 209 
> 
>  drivers/thermal/st/st_thermal_syscfg.c   | 179 
> +
>  11 files changed, 888 insertions(+)
> 


--
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] tools/thermal: tmon: fix compilation errors when building statically

[Zhang Rui]

On Tue, 2014-06-10 at 16:16 +0100, Javi Merino wrote:
> Hi Rui,
> 
> On Mon, Jun 02, 2014 at 12:54:57PM +0100, Jacob Pan wrote:
> > On Mon,  2 Jun 2014 18:08:17 +0100
> > "Javi Merino"  wrote:
> > 
> > > tmon fails to build statically with the following error:
> > > 
> > > $ make LDFLAGS=-static
> > > gcc -O1 -Wall -Wshadow -W -Wformat -Wimplicit-function-declaration
> > > -Wimplicit-int -fstack-protector -D VERSION=\"1.0\" -static tmon.o
> > > tui.o sysfs.o pid.o   -o tmon -lm -lpanel -lncursesw  -lpthread
> > > tmon.o: In function `tmon_sig_handler': tmon.c:(.text+0x21):
> > > undefined reference to `stdscr' tmon.o: In function `tmon_cleanup':
> > > tmon.c:(.text+0xb9): undefined reference to `stdscr'
> > > tmon.c:(.text+0x11e): undefined reference to `stdscr'
> > > tmon.c:(.text+0x123): undefined reference to `keypad'
> > > tmon.c:(.text+0x12d): undefined reference to `nocbreak' tmon.o: In
> > > function `main': tmon.c:(.text+0x785): undefined reference to `stdscr'
> > > tmon.c:(.text+0x78a): undefined reference to `nodelay'
> > > tui.o: In function `setup_windows':
> > > tui.c:(.text+0x131): undefined reference to `stdscr'
> > > tui.c:(.text+0x176): undefined reference to `stdscr'
> > > tui.c:(.text+0x19f): undefined reference to `stdscr'
> > > tui.c:(.text+0x1cc): undefined reference to `stdscr'
> > > tui.c:(.text+0x1ff): undefined reference to `stdscr'
> > > tui.o:tui.c:(.text+0x229): more undefined references to `stdscr'
> > > follow tui.o: In function `show_cooling_device':
> > > [...]
> > > 
> > > stdscr() and friends are in libtinfo (part of ncurses) so add it to
> > > the libraries that are linked in when compiling tmon to fix it.
> > > 
> > Acked-by: Jacob Pan 
> 
> Thanks!
> 
> Rui, can you pick this up?

Done, thanks!

-rui
> 
> Cheers,
> Javi
> 


--
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] thermal: ti-soc-thermal: ti-bandgap.c: Cleaning up wrong address is checked

[Zhang Rui]

On Mon, 2014-06-02 at 23:25 +0200, Rickard Strandqvist wrote:
> Wrong address is checked after memory allocation.
> 
> Signed-off-by: Rickard Strandqvist 

applied, thanks.

-rui
> ---
>  drivers/thermal/ti-soc-thermal/ti-bandgap.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c 
> b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> index 3ab12ee..43c0f83 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> @@ -1155,7 +1155,7 @@ static struct ti_bandgap *ti_bandgap_build(struct 
> platform_device *pdev)
>   /* register shadow for context save and restore */
>   bgp->regval = devm_kzalloc(>dev, sizeof(*bgp->regval) *
>  bgp->conf->sensor_count, GFP_KERNEL);
> - if (!bgp) {
> + if (!bgp->regval) {
>   dev_err(>dev, "Unable to allocate mem for driver ref\n");
>   return ERR_PTR(-ENOMEM);
>   }


--
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: [BUG] rc3 Oops: unable to handle kernel NULL pointer dereference at 0000074c

[Zhang Rui]

On Mon, 2014-06-30 at 16:18 +0800, Zhang Rui wrote:
> On Mon, 2014-06-30 at 09:52 +0200, Martin Kepplinger wrote:
> > I now booted 3.16-rc3 and suddenly see an oops during boot:
> > 
> > the oops during boot: http://tny.cz/2301e393
> > also below
> > 
> > lshw if interesting: http://tny.cz/3c9a7609
> > 
> > the full boot log: http://tny.cz/88260b19
> > 
> > does anyone have an idea?
> 
> what if you rebuild the kernel with CONFIG_SENSORS_CORETEMP=n?
> 
BTW, can this be 100% reproduced on a rc3 kernel?

thanks,
rui
> thanks,
> rui
> >thanks
> > 
> > the oops:
> > 
> > Jun 30 08:35:08 laptop kernel: [5.245811] bus: 'platform':
> > really_probe: probing driver coretemp with device coretemp.0
> > Jun 30 08:35:08 laptop kernel: [5.246134] BUG: unable to handle
> > kernel NULL pointer dereference at 074c
> > Jun 30 08:35:08 laptop kernel: [5.246145] IP: []
> > is_highmem+0x1/0x2b
> > Jun 30 08:35:08 laptop kernel: [5.246158] *pdpt = 33e49001
> > *pde = 
> > Jun 30 08:35:08 laptop kernel: [5.246167] Oops:  [#1] SMP
> > Jun 30 08:35:08 laptop kernel: [5.246175] Modules linked in:
> > coretemp(+) kvm_intel kvm snd_hda_codec_hdmi snd_hda_codec_realtek
> > snd_hda_codec_generic microcode snd_hda_intel i915(+) snd_hda_controller
> > evdev psmouse snd_hda_codec serio_raw snd_hwdep snd_pcm iwlwifi i2c_i801
> > lpc_ich mfd_core snd_seq drm_kms_helper snd_timer battery ehci_pci
> > snd_seq_device drm cfg80211 ehci_hcd snd i2c_algo_bit ac video i2c_core
> > rfkill soundcore wmi acpi_cpufreq button processor thermal_sys ext4
> > crc16 jbd2 mbcache sg sd_mod crct10dif_generic crc_t10dif
> > crct10dif_common ahci libahci crc32c_intel tg3 ptp libata pps_core
> > sdhci_pci sdhci scsi_mod mmc_core libphy xhci_hcd usbcore usb_common
> > Jun 30 08:35:08 laptop kernel: [5.246320] CPU: 1 PID: 491 Comm:
> > modprobe Not tainted 3.16.0-rc3 #83
> > Jun 30 08:35:08 laptop kernel: [5.246330] Hardware name: Acer
> > TravelMate B113/BA10_HX   , BIOS V1.09 10/30/2012
> > Jun 30 08:35:08 laptop kernel: [5.246344] task: f3828a90 ti:
> > f3e88000 task.ti: f3e88000
> > Jun 30 08:35:08 laptop kernel: [5.246355] EIP: 0060:[]
> > EFLAGS: 00010206 CPU: 1
> > Jun 30 08:35:08 laptop kernel: [5.246367] EIP is at is_highmem+0x1/0x2b
> > Jun 30 08:35:08 laptop kernel: [5.246376] EAX: 03c0 EBX:
> > ffb76000 ECX: 0001 EDX: 03c0
> > Jun 30 08:35:08 laptop kernel: [5.246386] ESI: f86cd279 EDI:
> >  EBP: f3e89c10 ESP: f3e89c04
> > Jun 30 08:35:08 laptop kernel: [5.246396]  DS: 007b ES: 007b FS:
> > 00d8 GS: 00e0 SS: 0068
> > Jun 30 08:35:08 laptop kernel: [5.246405] CR0: 80050033 CR2:
> > 074c CR3: 2e3fc000 CR4: 000407f0
> > Jun 30 08:35:08 laptop kernel: [5.246414] Stack:
> > Jun 30 08:35:08 laptop kernel: [5.246421]  f3e89c10 c1032889
> > f3cbcc60 f3e89c4c f86b52bf 0005  0448
> > Jun 30 08:35:08 laptop kernel: [5.246442]  f3e89c30 0006
> > 00165000 ffb76000 0113 f870f010 ee881128 ee881128
> > Jun 30 08:35:08 laptop kernel: [5.246465]  0001 f418b980
> > f3e89c74 f86b4e5c  f3911e00 f3911e00 ee881128
> > Jun 30 08:35:08 laptop kernel: [5.246487] Call Trace:
> > Jun 30 08:35:08 laptop kernel: [5.246500]  [] ?
> > kunmap+0x3b/0x4e
> > Jun 30 08:35:08 laptop kernel: [5.246578]  [] ?
> > i915_gem_render_state_init+0x24f/0x28c [i915]
> > Jun 30 08:35:08 laptop kernel: [5.246634]  [] ?
> > i915_switch_context+0x348/0x387 [i915]
> > Jun 30 08:35:08 laptop kernel: [5.246684]  [] ?
> > i915_gem_context_enable+0x74/0x7c [i915]
> > Jun 30 08:35:08 laptop kernel: [5.246742]  [] ?
> > i915_gem_init_hw+0x23e/0x285 [i915]
> > Jun 30 08:35:08 laptop kernel: [5.246818]  [] ?
> > i915_gem_init+0xff/0x179 [i915]
> > Jun 30 08:35:08 laptop kernel: [5.246924]  [] ?
> > i915_driver_load+0x989/0xc1d [i915]
> > Jun 30 08:35:08 laptop kernel: [5.246940]  [] ?
> > get_device+0x14/0x1d
> > Jun 30 08:35:08 laptop kernel: [5.246955]  [] ?
> > device_add+0x3b7/0x4a9
> > Jun 30 08:35:08 laptop kernel: [5.246996]  [] ?
> > drm_minor_register+0x104/0x15c [drm]
> > Jun 30 08:35:08 laptop kernel: [5.247033]  [] ?
> > drm_dev_register+0x6c/0xce [drm]
> > Jun 30 08:35:08 laptop kernel: [5.247072]  [] ?
> > drm_get_pci_dev+0xde/0x174 [drm]
> > Jun 30 08:35:08 laptop kernel: [5.247088]  [] ?
> > local_pci_probe+0x33/0x6c
>

Re: [BUG] rc3 Oops: unable to handle kernel NULL pointer dereference at 0000074c

[Zhang Rui]

On Mon, 2014-06-30 at 09:52 +0200, Martin Kepplinger wrote:
> I now booted 3.16-rc3 and suddenly see an oops during boot:
> 
> the oops during boot: http://tny.cz/2301e393
>   also below
> 
> lshw if interesting: http://tny.cz/3c9a7609
> 
> the full boot log: http://tny.cz/88260b19
> 
> does anyone have an idea?

what if you rebuild the kernel with CONFIG_SENSORS_CORETEMP=n?

thanks,
rui
>thanks
> 
> the oops:
> 
> Jun 30 08:35:08 laptop kernel: [5.245811] bus: 'platform':
> really_probe: probing driver coretemp with device coretemp.0
> Jun 30 08:35:08 laptop kernel: [5.246134] BUG: unable to handle
> kernel NULL pointer dereference at 074c
> Jun 30 08:35:08 laptop kernel: [5.246145] IP: []
> is_highmem+0x1/0x2b
> Jun 30 08:35:08 laptop kernel: [5.246158] *pdpt = 33e49001
> *pde = 
> Jun 30 08:35:08 laptop kernel: [5.246167] Oops:  [#1] SMP
> Jun 30 08:35:08 laptop kernel: [5.246175] Modules linked in:
> coretemp(+) kvm_intel kvm snd_hda_codec_hdmi snd_hda_codec_realtek
> snd_hda_codec_generic microcode snd_hda_intel i915(+) snd_hda_controller
> evdev psmouse snd_hda_codec serio_raw snd_hwdep snd_pcm iwlwifi i2c_i801
> lpc_ich mfd_core snd_seq drm_kms_helper snd_timer battery ehci_pci
> snd_seq_device drm cfg80211 ehci_hcd snd i2c_algo_bit ac video i2c_core
> rfkill soundcore wmi acpi_cpufreq button processor thermal_sys ext4
> crc16 jbd2 mbcache sg sd_mod crct10dif_generic crc_t10dif
> crct10dif_common ahci libahci crc32c_intel tg3 ptp libata pps_core
> sdhci_pci sdhci scsi_mod mmc_core libphy xhci_hcd usbcore usb_common
> Jun 30 08:35:08 laptop kernel: [5.246320] CPU: 1 PID: 491 Comm:
> modprobe Not tainted 3.16.0-rc3 #83
> Jun 30 08:35:08 laptop kernel: [5.246330] Hardware name: Acer
> TravelMate B113/BA10_HX   , BIOS V1.09 10/30/2012
> Jun 30 08:35:08 laptop kernel: [5.246344] task: f3828a90 ti:
> f3e88000 task.ti: f3e88000
> Jun 30 08:35:08 laptop kernel: [5.246355] EIP: 0060:[]
> EFLAGS: 00010206 CPU: 1
> Jun 30 08:35:08 laptop kernel: [5.246367] EIP is at is_highmem+0x1/0x2b
> Jun 30 08:35:08 laptop kernel: [5.246376] EAX: 03c0 EBX:
> ffb76000 ECX: 0001 EDX: 03c0
> Jun 30 08:35:08 laptop kernel: [5.246386] ESI: f86cd279 EDI:
>  EBP: f3e89c10 ESP: f3e89c04
> Jun 30 08:35:08 laptop kernel: [5.246396]  DS: 007b ES: 007b FS:
> 00d8 GS: 00e0 SS: 0068
> Jun 30 08:35:08 laptop kernel: [5.246405] CR0: 80050033 CR2:
> 074c CR3: 2e3fc000 CR4: 000407f0
> Jun 30 08:35:08 laptop kernel: [5.246414] Stack:
> Jun 30 08:35:08 laptop kernel: [5.246421]  f3e89c10 c1032889
> f3cbcc60 f3e89c4c f86b52bf 0005  0448
> Jun 30 08:35:08 laptop kernel: [5.246442]  f3e89c30 0006
> 00165000 ffb76000 0113 f870f010 ee881128 ee881128
> Jun 30 08:35:08 laptop kernel: [5.246465]  0001 f418b980
> f3e89c74 f86b4e5c  f3911e00 f3911e00 ee881128
> Jun 30 08:35:08 laptop kernel: [5.246487] Call Trace:
> Jun 30 08:35:08 laptop kernel: [5.246500]  [] ?
> kunmap+0x3b/0x4e
> Jun 30 08:35:08 laptop kernel: [5.246578]  [] ?
> i915_gem_render_state_init+0x24f/0x28c [i915]
> Jun 30 08:35:08 laptop kernel: [5.246634]  [] ?
> i915_switch_context+0x348/0x387 [i915]
> Jun 30 08:35:08 laptop kernel: [5.246684]  [] ?
> i915_gem_context_enable+0x74/0x7c [i915]
> Jun 30 08:35:08 laptop kernel: [5.246742]  [] ?
> i915_gem_init_hw+0x23e/0x285 [i915]
> Jun 30 08:35:08 laptop kernel: [5.246818]  [] ?
> i915_gem_init+0xff/0x179 [i915]
> Jun 30 08:35:08 laptop kernel: [5.246924]  [] ?
> i915_driver_load+0x989/0xc1d [i915]
> Jun 30 08:35:08 laptop kernel: [5.246940]  [] ?
> get_device+0x14/0x1d
> Jun 30 08:35:08 laptop kernel: [5.246955]  [] ?
> device_add+0x3b7/0x4a9
> Jun 30 08:35:08 laptop kernel: [5.246996]  [] ?
> drm_minor_register+0x104/0x15c [drm]
> Jun 30 08:35:08 laptop kernel: [5.247033]  [] ?
> drm_dev_register+0x6c/0xce [drm]
> Jun 30 08:35:08 laptop kernel: [5.247072]  [] ?
> drm_get_pci_dev+0xde/0x174 [drm]
> Jun 30 08:35:08 laptop kernel: [5.247088]  [] ?
> local_pci_probe+0x33/0x6c
> Jun 30 08:35:08 laptop kernel: [5.247101]  [] ?
> pci_device_probe+0xa8/0xca
> Jun 30 08:35:08 laptop kernel: [5.247115]  [] ?
> driver_probe_device+0xd3/0x225
> Jun 30 08:35:08 laptop kernel: [5.247128]  [] ?
> __driver_attach+0x4c/0x68
> Jun 30 08:35:08 laptop kernel: [5.247141]  [] ?
> bus_for_each_dev+0x41/0x6b
> Jun 30 08:35:08 laptop kernel: [5.247155]  [] ?
> driver_attach+0x19/0x1b
> Jun 30 08:35:08 laptop kernel: [5.247166]  [] ?
> driver_probe_device+0x225/0x225
> Jun 30 08:35:08 laptop kernel: [5.247176]  [] ?
> bus_add_driver+0xcf/0x192
> Jun 30 08:35:08 laptop kernel: [5.247184]  [] ?
> driver_register+0x73/0xa5
> Jun 30 08:35:08 laptop kernel: [5.247193]  [] ? 0xf85edfff
> Jun 30 08:35:08 laptop kernel: [5.247200]  [] ?
> do_one_initcall+0xe0/0x17a
> 

Re: [BUG] rc3 Oops: unable to handle kernel NULL pointer dereference at 0000074c

[Zhang Rui]

On Mon, 2014-06-30 at 09:52 +0200, Martin Kepplinger wrote:
 I now booted 3.16-rc3 and suddenly see an oops during boot:
 
 the oops during boot: http://tny.cz/2301e393
   also below
 
 lshw if interesting: http://tny.cz/3c9a7609
 
 the full boot log: http://tny.cz/88260b19
 
 does anyone have an idea?

what if you rebuild the kernel with CONFIG_SENSORS_CORETEMP=n?

thanks,
rui
thanks
 
 the oops:
 
 Jun 30 08:35:08 laptop kernel: [5.245811] bus: 'platform':
 really_probe: probing driver coretemp with device coretemp.0
 Jun 30 08:35:08 laptop kernel: [5.246134] BUG: unable to handle
 kernel NULL pointer dereference at 074c
 Jun 30 08:35:08 laptop kernel: [5.246145] IP: [c10325d9]
 is_highmem+0x1/0x2b
 Jun 30 08:35:08 laptop kernel: [5.246158] *pdpt = 33e49001
 *pde = 
 Jun 30 08:35:08 laptop kernel: [5.246167] Oops:  [#1] SMP
 Jun 30 08:35:08 laptop kernel: [5.246175] Modules linked in:
 coretemp(+) kvm_intel kvm snd_hda_codec_hdmi snd_hda_codec_realtek
 snd_hda_codec_generic microcode snd_hda_intel i915(+) snd_hda_controller
 evdev psmouse snd_hda_codec serio_raw snd_hwdep snd_pcm iwlwifi i2c_i801
 lpc_ich mfd_core snd_seq drm_kms_helper snd_timer battery ehci_pci
 snd_seq_device drm cfg80211 ehci_hcd snd i2c_algo_bit ac video i2c_core
 rfkill soundcore wmi acpi_cpufreq button processor thermal_sys ext4
 crc16 jbd2 mbcache sg sd_mod crct10dif_generic crc_t10dif
 crct10dif_common ahci libahci crc32c_intel tg3 ptp libata pps_core
 sdhci_pci sdhci scsi_mod mmc_core libphy xhci_hcd usbcore usb_common
 Jun 30 08:35:08 laptop kernel: [5.246320] CPU: 1 PID: 491 Comm:
 modprobe Not tainted 3.16.0-rc3 #83
 Jun 30 08:35:08 laptop kernel: [5.246330] Hardware name: Acer
 TravelMate B113/BA10_HX   , BIOS V1.09 10/30/2012
 Jun 30 08:35:08 laptop kernel: [5.246344] task: f3828a90 ti:
 f3e88000 task.ti: f3e88000
 Jun 30 08:35:08 laptop kernel: [5.246355] EIP: 0060:[c10325d9]
 EFLAGS: 00010206 CPU: 1
 Jun 30 08:35:08 laptop kernel: [5.246367] EIP is at is_highmem+0x1/0x2b
 Jun 30 08:35:08 laptop kernel: [5.246376] EAX: 03c0 EBX:
 ffb76000 ECX: 0001 EDX: 03c0
 Jun 30 08:35:08 laptop kernel: [5.246386] ESI: f86cd279 EDI:
  EBP: f3e89c10 ESP: f3e89c04
 Jun 30 08:35:08 laptop kernel: [5.246396]  DS: 007b ES: 007b FS:
 00d8 GS: 00e0 SS: 0068
 Jun 30 08:35:08 laptop kernel: [5.246405] CR0: 80050033 CR2:
 074c CR3: 2e3fc000 CR4: 000407f0
 Jun 30 08:35:08 laptop kernel: [5.246414] Stack:
 Jun 30 08:35:08 laptop kernel: [5.246421]  f3e89c10 c1032889
 f3cbcc60 f3e89c4c f86b52bf 0005  0448
 Jun 30 08:35:08 laptop kernel: [5.246442]  f3e89c30 0006
 00165000 ffb76000 0113 f870f010 ee881128 ee881128
 Jun 30 08:35:08 laptop kernel: [5.246465]  0001 f418b980
 f3e89c74 f86b4e5c  f3911e00 f3911e00 ee881128
 Jun 30 08:35:08 laptop kernel: [5.246487] Call Trace:
 Jun 30 08:35:08 laptop kernel: [5.246500]  [c1032889] ?
 kunmap+0x3b/0x4e
 Jun 30 08:35:08 laptop kernel: [5.246578]  [f86b52bf] ?
 i915_gem_render_state_init+0x24f/0x28c [i915]
 Jun 30 08:35:08 laptop kernel: [5.246634]  [f86b4e5c] ?
 i915_switch_context+0x348/0x387 [i915]
 Jun 30 08:35:08 laptop kernel: [5.246684]  [f86b4f0f] ?
 i915_gem_context_enable+0x74/0x7c [i915]
 Jun 30 08:35:08 laptop kernel: [5.246742]  [f86bcd38] ?
 i915_gem_init_hw+0x23e/0x285 [i915]
 Jun 30 08:35:08 laptop kernel: [5.246818]  [f86bce7e] ?
 i915_gem_init+0xff/0x179 [i915]
 Jun 30 08:35:08 laptop kernel: [5.246924]  [f87047d9] ?
 i915_driver_load+0x989/0xc1d [i915]
 Jun 30 08:35:08 laptop kernel: [5.246940]  [c1267429] ?
 get_device+0x14/0x1d
 Jun 30 08:35:08 laptop kernel: [5.246955]  [c1268832] ?
 device_add+0x3b7/0x4a9
 Jun 30 08:35:08 laptop kernel: [5.246996]  [f8619c80] ?
 drm_minor_register+0x104/0x15c [drm]
 Jun 30 08:35:08 laptop kernel: [5.247033]  [f8619d44] ?
 drm_dev_register+0x6c/0xce [drm]
 Jun 30 08:35:08 laptop kernel: [5.247072]  [f861bbb4] ?
 drm_get_pci_dev+0xde/0x174 [drm]
 Jun 30 08:35:08 laptop kernel: [5.247088]  [c11dcc58] ?
 local_pci_probe+0x33/0x6c
 Jun 30 08:35:08 laptop kernel: [5.247101]  [c11dcd39] ?
 pci_device_probe+0xa8/0xca
 Jun 30 08:35:08 laptop kernel: [5.247115]  [c126a75a] ?
 driver_probe_device+0xd3/0x225
 Jun 30 08:35:08 laptop kernel: [5.247128]  [c126a8f8] ?
 __driver_attach+0x4c/0x68
 Jun 30 08:35:08 laptop kernel: [5.247141]  [c1269260] ?
 bus_for_each_dev+0x41/0x6b
 Jun 30 08:35:08 laptop kernel: [5.247155]  [c126a26c] ?
 driver_attach+0x19/0x1b
 Jun 30 08:35:08 laptop kernel: [5.247166]  [c126a8ac] ?
 driver_probe_device+0x225/0x225
 Jun 30 08:35:08 laptop kernel: [5.247176]  [c126a027] ?
 bus_add_driver+0xcf/0x192
 Jun 30 08:35:08 laptop kernel: [5.247184]  [c126ae69] ?
 driver_register+0x73/0xa5
 Jun 30 08:35:08 laptop kernel: [5.247193]  [f85ee000] ? 

Re: [BUG] rc3 Oops: unable to handle kernel NULL pointer dereference at 0000074c

[Zhang Rui]

On Mon, 2014-06-30 at 16:18 +0800, Zhang Rui wrote:
 On Mon, 2014-06-30 at 09:52 +0200, Martin Kepplinger wrote:
  I now booted 3.16-rc3 and suddenly see an oops during boot:
  
  the oops during boot: http://tny.cz/2301e393
  also below
  
  lshw if interesting: http://tny.cz/3c9a7609
  
  the full boot log: http://tny.cz/88260b19
  
  does anyone have an idea?
 
 what if you rebuild the kernel with CONFIG_SENSORS_CORETEMP=n?
 
BTW, can this be 100% reproduced on a rc3 kernel?

thanks,
rui
 thanks,
 rui
 thanks
  
  the oops:
  
  Jun 30 08:35:08 laptop kernel: [5.245811] bus: 'platform':
  really_probe: probing driver coretemp with device coretemp.0
  Jun 30 08:35:08 laptop kernel: [5.246134] BUG: unable to handle
  kernel NULL pointer dereference at 074c
  Jun 30 08:35:08 laptop kernel: [5.246145] IP: [c10325d9]
  is_highmem+0x1/0x2b
  Jun 30 08:35:08 laptop kernel: [5.246158] *pdpt = 33e49001
  *pde = 
  Jun 30 08:35:08 laptop kernel: [5.246167] Oops:  [#1] SMP
  Jun 30 08:35:08 laptop kernel: [5.246175] Modules linked in:
  coretemp(+) kvm_intel kvm snd_hda_codec_hdmi snd_hda_codec_realtek
  snd_hda_codec_generic microcode snd_hda_intel i915(+) snd_hda_controller
  evdev psmouse snd_hda_codec serio_raw snd_hwdep snd_pcm iwlwifi i2c_i801
  lpc_ich mfd_core snd_seq drm_kms_helper snd_timer battery ehci_pci
  snd_seq_device drm cfg80211 ehci_hcd snd i2c_algo_bit ac video i2c_core
  rfkill soundcore wmi acpi_cpufreq button processor thermal_sys ext4
  crc16 jbd2 mbcache sg sd_mod crct10dif_generic crc_t10dif
  crct10dif_common ahci libahci crc32c_intel tg3 ptp libata pps_core
  sdhci_pci sdhci scsi_mod mmc_core libphy xhci_hcd usbcore usb_common
  Jun 30 08:35:08 laptop kernel: [5.246320] CPU: 1 PID: 491 Comm:
  modprobe Not tainted 3.16.0-rc3 #83
  Jun 30 08:35:08 laptop kernel: [5.246330] Hardware name: Acer
  TravelMate B113/BA10_HX   , BIOS V1.09 10/30/2012
  Jun 30 08:35:08 laptop kernel: [5.246344] task: f3828a90 ti:
  f3e88000 task.ti: f3e88000
  Jun 30 08:35:08 laptop kernel: [5.246355] EIP: 0060:[c10325d9]
  EFLAGS: 00010206 CPU: 1
  Jun 30 08:35:08 laptop kernel: [5.246367] EIP is at is_highmem+0x1/0x2b
  Jun 30 08:35:08 laptop kernel: [5.246376] EAX: 03c0 EBX:
  ffb76000 ECX: 0001 EDX: 03c0
  Jun 30 08:35:08 laptop kernel: [5.246386] ESI: f86cd279 EDI:
   EBP: f3e89c10 ESP: f3e89c04
  Jun 30 08:35:08 laptop kernel: [5.246396]  DS: 007b ES: 007b FS:
  00d8 GS: 00e0 SS: 0068
  Jun 30 08:35:08 laptop kernel: [5.246405] CR0: 80050033 CR2:
  074c CR3: 2e3fc000 CR4: 000407f0
  Jun 30 08:35:08 laptop kernel: [5.246414] Stack:
  Jun 30 08:35:08 laptop kernel: [5.246421]  f3e89c10 c1032889
  f3cbcc60 f3e89c4c f86b52bf 0005  0448
  Jun 30 08:35:08 laptop kernel: [5.246442]  f3e89c30 0006
  00165000 ffb76000 0113 f870f010 ee881128 ee881128
  Jun 30 08:35:08 laptop kernel: [5.246465]  0001 f418b980
  f3e89c74 f86b4e5c  f3911e00 f3911e00 ee881128
  Jun 30 08:35:08 laptop kernel: [5.246487] Call Trace:
  Jun 30 08:35:08 laptop kernel: [5.246500]  [c1032889] ?
  kunmap+0x3b/0x4e
  Jun 30 08:35:08 laptop kernel: [5.246578]  [f86b52bf] ?
  i915_gem_render_state_init+0x24f/0x28c [i915]
  Jun 30 08:35:08 laptop kernel: [5.246634]  [f86b4e5c] ?
  i915_switch_context+0x348/0x387 [i915]
  Jun 30 08:35:08 laptop kernel: [5.246684]  [f86b4f0f] ?
  i915_gem_context_enable+0x74/0x7c [i915]
  Jun 30 08:35:08 laptop kernel: [5.246742]  [f86bcd38] ?
  i915_gem_init_hw+0x23e/0x285 [i915]
  Jun 30 08:35:08 laptop kernel: [5.246818]  [f86bce7e] ?
  i915_gem_init+0xff/0x179 [i915]
  Jun 30 08:35:08 laptop kernel: [5.246924]  [f87047d9] ?
  i915_driver_load+0x989/0xc1d [i915]
  Jun 30 08:35:08 laptop kernel: [5.246940]  [c1267429] ?
  get_device+0x14/0x1d
  Jun 30 08:35:08 laptop kernel: [5.246955]  [c1268832] ?
  device_add+0x3b7/0x4a9
  Jun 30 08:35:08 laptop kernel: [5.246996]  [f8619c80] ?
  drm_minor_register+0x104/0x15c [drm]
  Jun 30 08:35:08 laptop kernel: [5.247033]  [f8619d44] ?
  drm_dev_register+0x6c/0xce [drm]
  Jun 30 08:35:08 laptop kernel: [5.247072]  [f861bbb4] ?
  drm_get_pci_dev+0xde/0x174 [drm]
  Jun 30 08:35:08 laptop kernel: [5.247088]  [c11dcc58] ?
  local_pci_probe+0x33/0x6c
  Jun 30 08:35:08 laptop kernel: [5.247101]  [c11dcd39] ?
  pci_device_probe+0xa8/0xca
  Jun 30 08:35:08 laptop kernel: [5.247115]  [c126a75a] ?
  driver_probe_device+0xd3/0x225
  Jun 30 08:35:08 laptop kernel: [5.247128]  [c126a8f8] ?
  __driver_attach+0x4c/0x68
  Jun 30 08:35:08 laptop kernel: [5.247141]  [c1269260] ?
  bus_for_each_dev+0x41/0x6b
  Jun 30 08:35:08 laptop kernel: [5.247155]  [c126a26c] ?
  driver_attach+0x19/0x1b
  Jun 30 08:35:08 laptop kernel: [5.247166]  [c126a8ac] ?
  driver_probe_device+0x225/0x225
  Jun 30 08:35:08 laptop

Re: [PATCH] thermal: ti-soc-thermal: ti-bandgap.c: Cleaning up wrong address is checked

[Zhang Rui]

On Mon, 2014-06-02 at 23:25 +0200, Rickard Strandqvist wrote:
 Wrong address is checked after memory allocation.
 
 Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se

applied, thanks.

-rui
 ---
  drivers/thermal/ti-soc-thermal/ti-bandgap.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c 
 b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
 index 3ab12ee..43c0f83 100644
 --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
 +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
 @@ -1155,7 +1155,7 @@ static struct ti_bandgap *ti_bandgap_build(struct 
 platform_device *pdev)
   /* register shadow for context save and restore */
   bgp-regval = devm_kzalloc(pdev-dev, sizeof(*bgp-regval) *
  bgp-conf-sensor_count, GFP_KERNEL);
 - if (!bgp) {
 + if (!bgp-regval) {
   dev_err(pdev-dev, Unable to allocate mem for driver ref\n);
   return ERR_PTR(-ENOMEM);
   }


--
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] tools/thermal: tmon: fix compilation errors when building statically

[Zhang Rui]

On Tue, 2014-06-10 at 16:16 +0100, Javi Merino wrote:
 Hi Rui,
 
 On Mon, Jun 02, 2014 at 12:54:57PM +0100, Jacob Pan wrote:
  On Mon,  2 Jun 2014 18:08:17 +0100
  Javi Merino javi.mer...@arm.com wrote:
  
   tmon fails to build statically with the following error:
   
   $ make LDFLAGS=-static
   gcc -O1 -Wall -Wshadow -W -Wformat -Wimplicit-function-declaration
   -Wimplicit-int -fstack-protector -D VERSION=\1.0\ -static tmon.o
   tui.o sysfs.o pid.o   -o tmon -lm -lpanel -lncursesw  -lpthread
   tmon.o: In function `tmon_sig_handler': tmon.c:(.text+0x21):
   undefined reference to `stdscr' tmon.o: In function `tmon_cleanup':
   tmon.c:(.text+0xb9): undefined reference to `stdscr'
   tmon.c:(.text+0x11e): undefined reference to `stdscr'
   tmon.c:(.text+0x123): undefined reference to `keypad'
   tmon.c:(.text+0x12d): undefined reference to `nocbreak' tmon.o: In
   function `main': tmon.c:(.text+0x785): undefined reference to `stdscr'
   tmon.c:(.text+0x78a): undefined reference to `nodelay'
   tui.o: In function `setup_windows':
   tui.c:(.text+0x131): undefined reference to `stdscr'
   tui.c:(.text+0x176): undefined reference to `stdscr'
   tui.c:(.text+0x19f): undefined reference to `stdscr'
   tui.c:(.text+0x1cc): undefined reference to `stdscr'
   tui.c:(.text+0x1ff): undefined reference to `stdscr'
   tui.o:tui.c:(.text+0x229): more undefined references to `stdscr'
   follow tui.o: In function `show_cooling_device':
   [...]
   
   stdscr() and friends are in libtinfo (part of ncurses) so add it to
   the libraries that are linked in when compiling tmon to fix it.
   
  Acked-by: Jacob Pan jacob.jun@linux.intel.com
 
 Thanks!
 
 Rui, can you pick this up?

Done, thanks!

-rui
 
 Cheers,
 Javi
 


--
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 0/6] thermal: sti: Add new Thermal driver

[Zhang Rui]

Hi, Eduardo,

what do you think of this patch set?

thanks,
rui

On Fri, 2014-05-30 at 10:38 +0100, Lee Jones wrote:
 This patchset adds full support for 2 types of Thermal Controllers
 produced by STMicroelectronics.  One is a more traditional memory
 mapped variant, the other is controlled solely by system configuration
 registers.
 
  Documentation/devicetree/bindings/thermal/st-thermal.txt |  42 
 
  arch/arm/boot/dts/stih416.dtsi   |  18 +++
  arch/arm/configs/multi_v7_defconfig  |   2 +
  drivers/thermal/Kconfig  |   5 ++
  drivers/thermal/Makefile |   1 +
  drivers/thermal/st/Kconfig   |  12 +
  drivers/thermal/st/Makefile  |   3 ++
  drivers/thermal/st/st_thermal.c  | 313 
 ++
  drivers/thermal/st/st_thermal.h  | 104 
 ++
  drivers/thermal/st/st_thermal_memmap.c   | 209 
 
  drivers/thermal/st/st_thermal_syscfg.c   | 179 
 +
  11 files changed, 888 insertions(+)
 


--
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 v2 0/9] thermal: exynos: various cleanups

[Zhang Rui]

Eduardo,

what do you think of this patch set?

thanks,
rui

On Tue, 2014-06-17 at 19:27 +0200, Bartlomiej Zolnierkiewicz wrote:
 Hi,
 
 This patch series contains various cleanups for EXYNOS thermal
 driver.  Overall it decreases driver's LOC by 12%.  It is based
 on next-20140617 kernel.  It should not cause any functionality
 changes.
 
 Changes since v1:
 - synced patches against next-20140617
 - merged patch thermal: exynos: remove unused defines into
   thermal: exynos: remove unused struct exynos_tmu_registers
   entries one (per request from Eduardo)
 - improved patch descriptions for patches #1-5
 - fixed documentation for pdata-gain and pdata-reference_voltage
 - added Reviewed-by from Amit to patches #6, #7 and #10
 - added missing Acked-by from Kyungmin Park
 
 Best regards,
 --
 Bartlomiej Zolnierkiewicz
 Samsung RD Institute Poland
 Samsung Electronics
 
 
 Bartlomiej Zolnierkiewicz (9):
   thermal: exynos: remove unused struct exynos_tmu_registers entries
   thermal: exynos: remove dead code for HW_MODE calibration
   thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING
 calibration
   thermal: exynos: remove redundant pdata checks from
 exynos_tmu_initialize()
   thermal: exynos: remove redundant threshold_code checks from
 exynos_tmu_initialize()
   thermal: exynos: simplify temp_to_code() and code_to_temp()
   thermal: exynos: cache non_hw_trigger_levels in pdata
   thermal: exynos: remove redundant pdata checks from
 exynos_tmu_control()
   thermal: exynos: remove identical values from exynos*_tmu_registers
 structures
 
  drivers/thermal/samsung/exynos_thermal_common.h |   1 -
  drivers/thermal/samsung/exynos_tmu.c| 181 
 
  drivers/thermal/samsung/exynos_tmu.h|  90 +---
  drivers/thermal/samsung/exynos_tmu_data.c   |  64 +
  drivers/thermal/samsung/exynos_tmu_data.h   |  33 +
  5 files changed, 41 insertions(+), 328 deletions(-)
 


--
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 TRIVIAL] thermal: cpu_cooling: fix typo highjack -> hijack

[Zhang Rui]

On Wed, 2014-06-25 at 18:11 +0100, Javi Merino wrote:
> Cc: Eduardo Valentin 
> Cc: Zhang Rui 
> Signed-off-by: Javi Merino 

applied, thanks!

-rui
> ---
>  drivers/thermal/cpu_cooling.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 84a75f89bf74..1ab0018271c5 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -305,7 +305,7 @@ static int cpufreq_apply_cooling(struct 
> cpufreq_cooling_device *cpufreq_device,
>   * @event: value showing cpufreq event for which this function invoked.
>   * @data: callback-specific data
>   *
> - * Callback to highjack the notification on cpufreq policy transition.
> + * Callback to hijack the notification on cpufreq policy transition.
>   * Every time there is a change in policy, we will intercept and
>   * update the cpufreq policy with thermal constraints.
>   *


--
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 TRIVIAL] thermal: cpu_cooling: fix typo highjack - hijack

[Zhang Rui]

On Wed, 2014-06-25 at 18:11 +0100, Javi Merino wrote:
 Cc: Eduardo Valentin eduardo.valen...@ti.com
 Cc: Zhang Rui rui.zh...@intel.com
 Signed-off-by: Javi Merino javi.mer...@arm.com

applied, thanks!

-rui
 ---
  drivers/thermal/cpu_cooling.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
 index 84a75f89bf74..1ab0018271c5 100644
 --- a/drivers/thermal/cpu_cooling.c
 +++ b/drivers/thermal/cpu_cooling.c
 @@ -305,7 +305,7 @@ static int cpufreq_apply_cooling(struct 
 cpufreq_cooling_device *cpufreq_device,
   * @event: value showing cpufreq event for which this function invoked.
   * @data: callback-specific data
   *
 - * Callback to highjack the notification on cpufreq policy transition.
 + * Callback to hijack the notification on cpufreq policy transition.
   * Every time there is a change in policy, we will intercept and
   * update the cpufreq policy with thermal constraints.
   *


--
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: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black instead of native resolution

[Zhang Rui]

On Mon, 2014-06-23 at 16:46 +0200, Martin Kepplinger wrote:
> Am 2014-06-23 15:14, schrieb Zhang Rui:
> > On Mon, 2014-06-23 at 14:22 +0200, Martin Kepplinger wrote:
> >> Am 2014-06-23 03:10, schrieb Zhang, Rui:
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Martin Kepplinger [mailto:mart...@posteo.de]
> >>>> Sent: Sunday, June 22, 2014 10:25 PM
> >>>> To: Zhang, Rui
> >>>> Cc: r...@rjwysocki.net; l...@kernel.org; linux-a...@vger.kernel.org;
> >>>> linux-kernel@vger.kernel.org
> >>>> Subject: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black
> >>>> instead of native resolution
> >>>> Importance: High
> >>>>
> >>>> Since 3.16-rc1 my laptop's just goes black while booting, instead of
> >>>> switching to native screen resolution and showing me the starting
> >>>> system there. It's an Acer TravelMate B113 with i915 driver and
> >>>> acer_wmi. It stays black and is unusable.
> >>>>
> > This looks like a duplicate of
> > https://bugzilla.kernel.org/show_bug.cgi?id=78601
> > 
> > thanks,
> > rui
> I'm not sure about that. I have no problem with v3.15 and the screen
> goes black way before a display manager is started. It's right after the
> kernel loaded and usually the screen is set to native resolution.
> 
> Bisect told me aaeb2554337217dfa4eac2fcc90da7be540b9a73 as the first bad
> one. Although, checking that out and running it, works good. not sure if
> that makes sense.
> 
could you please check if the comment in
https://bugzilla.kernel.org/show_bug.cgi?id=78601#c5 solves your problem
or not?

thanks,
rui
> >>>> Do you have other people complain about that? Bisecting didn't lead to
> >>>> a good result. I could be wrong but I somehow suspect the mistake to be
> >>>> somewhere in commit 99678ed73a50d2df8b5f3c801e29e9b7a3e5aa85
> >>>>
> >>> In order to confirm if the problem is introduced by the above commit,
> >>> why not checkout the kernel just before and after this commit and see if 
> >>> the problem exists?
> >>>
> >>> Thanks,
> >>> rui
> >>>
> >> So maybe I was wrong. d27050641e9bc056446deb0814e7ba1aa7911f5a is still
> >> good and aaeb2554337217dfa4eac2fcc90da7be540b9a73 is the fist bad one.
> >> This is a big v4l merge. I added the linux-media list in cc now.
> >>
> >> What could be the problem here?
> >>
> >>>
> >>>> There is nothing unusual in the kernel log.
> >>>>
> >>>> This is quite unusual for an -rc2. Hence my question. I'm happy to test
> >>>> changes.
> >>>>
> >>>>  martin
> >>>> --
> >>>> Martin Kepplinger
> >>>> e-mailmartink AT posteo DOT at
> >>>> chat (XMPP)   martink AT jabber DOT at
> >>
> > 
> > 
> 


--
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: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black instead of native resolution

[Zhang Rui]

On Mon, 2014-06-23 at 16:46 +0200, Martin Kepplinger wrote:
 Am 2014-06-23 15:14, schrieb Zhang Rui:
  On Mon, 2014-06-23 at 14:22 +0200, Martin Kepplinger wrote:
  Am 2014-06-23 03:10, schrieb Zhang, Rui:
 
 
  -Original Message-
  From: Martin Kepplinger [mailto:mart...@posteo.de]
  Sent: Sunday, June 22, 2014 10:25 PM
  To: Zhang, Rui
  Cc: r...@rjwysocki.net; l...@kernel.org; linux-a...@vger.kernel.org;
  linux-kernel@vger.kernel.org
  Subject: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black
  instead of native resolution
  Importance: High
 
  Since 3.16-rc1 my laptop's just goes black while booting, instead of
  switching to native screen resolution and showing me the starting
  system there. It's an Acer TravelMate B113 with i915 driver and
  acer_wmi. It stays black and is unusable.
 
  This looks like a duplicate of
  https://bugzilla.kernel.org/show_bug.cgi?id=78601
  
  thanks,
  rui
 I'm not sure about that. I have no problem with v3.15 and the screen
 goes black way before a display manager is started. It's right after the
 kernel loaded and usually the screen is set to native resolution.
 
 Bisect told me aaeb2554337217dfa4eac2fcc90da7be540b9a73 as the first bad
 one. Although, checking that out and running it, works good. not sure if
 that makes sense.
 
could you please check if the comment in
https://bugzilla.kernel.org/show_bug.cgi?id=78601#c5 solves your problem
or not?

thanks,
rui
  Do you have other people complain about that? Bisecting didn't lead to
  a good result. I could be wrong but I somehow suspect the mistake to be
  somewhere in commit 99678ed73a50d2df8b5f3c801e29e9b7a3e5aa85
 
  In order to confirm if the problem is introduced by the above commit,
  why not checkout the kernel just before and after this commit and see if 
  the problem exists?
 
  Thanks,
  rui
 
  So maybe I was wrong. d27050641e9bc056446deb0814e7ba1aa7911f5a is still
  good and aaeb2554337217dfa4eac2fcc90da7be540b9a73 is the fist bad one.
  This is a big v4l merge. I added the linux-media list in cc now.
 
  What could be the problem here?
 
 
  There is nothing unusual in the kernel log.
 
  This is quite unusual for an -rc2. Hence my question. I'm happy to test
  changes.
 
   martin
  --
  Martin Kepplinger
  e-mailmartink AT posteo DOT at
  chat (XMPP)   martink AT jabber DOT at
 
  
  
 


--
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] MAINTAINERS: Update Eduardo Valentin's email address

[Zhang Rui]

On Thu, 2014-06-26 at 10:00 +0100, Javi Merino wrote:
> On Mon, Jun 02, 2014 at 06:28:00PM +0100, Eduardo Valentin wrote:
> > Hello Lee Jones,
> > 
> > On Fri, May 30, 2014 at 11:03:28AM +0100, Lee Jones wrote:
> > > Eduardo TI address is bouncing, but it looks like he's still
> > > contributing via his Gmail address.
> > > 
> > 
> > Thanks for being proactive! I actually sent the very same patch a while
> > ago:
> > 
> > 
> > https://lkml.org/lkml/2014/4/2/644
> > 
> > 
> > Maybe it's fallen into the cracks.
> > 
> > Rui, any idea what is the status of that patch?
> 

Oops, sorry for the late response.
I thought all the patches that touches MAINTAINER file should go to
Linus directly, thus I did not take a patch in the beginning.

Patch applied and queued for 3.16-rc4.

thanks,
rui
> I've been bitten by this *again*.  This patch should've been in
> 3.15-rc1, it's 3.16-rc2 and Eduardo's email is still outdated in the
> MAINTAINERS file.  The thermal tree seems to be pretty stale lately
> and patches are rotting in the list, but this update should really get
> into the kernel ASAP.
> 
> Eduardo, can you send this to triv...@kernel.org ?
> 


--
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] MAINTAINERS: Update Eduardo Valentin's email address

[Zhang Rui]

On Thu, 2014-06-26 at 10:00 +0100, Javi Merino wrote:
 On Mon, Jun 02, 2014 at 06:28:00PM +0100, Eduardo Valentin wrote:
  Hello Lee Jones,
  
  On Fri, May 30, 2014 at 11:03:28AM +0100, Lee Jones wrote:
   Eduardo TI address is bouncing, but it looks like he's still
   contributing via his Gmail address.
   
  
  Thanks for being proactive! I actually sent the very same patch a while
  ago:
  
  
  https://lkml.org/lkml/2014/4/2/644
  
  
  Maybe it's fallen into the cracks.
  
  Rui, any idea what is the status of that patch?
 

Oops, sorry for the late response.
I thought all the patches that touches MAINTAINER file should go to
Linus directly, thus I did not take a patch in the beginning.

Patch applied and queued for 3.16-rc4.

thanks,
rui
 I've been bitten by this *again*.  This patch should've been in
 3.15-rc1, it's 3.16-rc2 and Eduardo's email is still outdated in the
 MAINTAINERS file.  The thermal tree seems to be pretty stale lately
 and patches are rotting in the list, but this update should really get
 into the kernel ASAP.
 
 Eduardo, can you send this to triv...@kernel.org ?
 


--
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: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black instead of native resolution

[Zhang Rui]

On Mon, 2014-06-23 at 14:22 +0200, Martin Kepplinger wrote:
> Am 2014-06-23 03:10, schrieb Zhang, Rui:
> > 
> > 
> >> -Original Message-
> >> From: Martin Kepplinger [mailto:mart...@posteo.de]
> >> Sent: Sunday, June 22, 2014 10:25 PM
> >> To: Zhang, Rui
> >> Cc: r...@rjwysocki.net; l...@kernel.org; linux-a...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org
> >> Subject: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black
> >> instead of native resolution
> >> Importance: High
> >>
> >> Since 3.16-rc1 my laptop's just goes black while booting, instead of
> >> switching to native screen resolution and showing me the starting
> >> system there. It's an Acer TravelMate B113 with i915 driver and
> >> acer_wmi. It stays black and is unusable.
> >>
This looks like a duplicate of
https://bugzilla.kernel.org/show_bug.cgi?id=78601

thanks,
rui
> >> Do you have other people complain about that? Bisecting didn't lead to
> >> a good result. I could be wrong but I somehow suspect the mistake to be
> >> somewhere in commit 99678ed73a50d2df8b5f3c801e29e9b7a3e5aa85
> >>
> > In order to confirm if the problem is introduced by the above commit,
> > why not checkout the kernel just before and after this commit and see if 
> > the problem exists?
> > 
> > Thanks,
> > rui
> > 
> So maybe I was wrong. d27050641e9bc056446deb0814e7ba1aa7911f5a is still
> good and aaeb2554337217dfa4eac2fcc90da7be540b9a73 is the fist bad one.
> This is a big v4l merge. I added the linux-media list in cc now.
> 
> What could be the problem here?
> 
> > 
> >> There is nothing unusual in the kernel log.
> >>
> >> This is quite unusual for an -rc2. Hence my question. I'm happy to test
> >> changes.
> >>
> >>  martin
> >> --
> >> Martin Kepplinger
> >> e-mailmartink AT posteo DOT at
> >> chat (XMPP)   martink AT jabber DOT at
> 


--
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: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black instead of native resolution

[Zhang Rui]

On Mon, 2014-06-23 at 14:22 +0200, Martin Kepplinger wrote:
 Am 2014-06-23 03:10, schrieb Zhang, Rui:
  
  
  -Original Message-
  From: Martin Kepplinger [mailto:mart...@posteo.de]
  Sent: Sunday, June 22, 2014 10:25 PM
  To: Zhang, Rui
  Cc: r...@rjwysocki.net; l...@kernel.org; linux-a...@vger.kernel.org;
  linux-kernel@vger.kernel.org
  Subject: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black
  instead of native resolution
  Importance: High
 
  Since 3.16-rc1 my laptop's just goes black while booting, instead of
  switching to native screen resolution and showing me the starting
  system there. It's an Acer TravelMate B113 with i915 driver and
  acer_wmi. It stays black and is unusable.
 
This looks like a duplicate of
https://bugzilla.kernel.org/show_bug.cgi?id=78601

thanks,
rui
  Do you have other people complain about that? Bisecting didn't lead to
  a good result. I could be wrong but I somehow suspect the mistake to be
  somewhere in commit 99678ed73a50d2df8b5f3c801e29e9b7a3e5aa85
 
  In order to confirm if the problem is introduced by the above commit,
  why not checkout the kernel just before and after this commit and see if 
  the problem exists?
  
  Thanks,
  rui
  
 So maybe I was wrong. d27050641e9bc056446deb0814e7ba1aa7911f5a is still
 good and aaeb2554337217dfa4eac2fcc90da7be540b9a73 is the fist bad one.
 This is a big v4l merge. I added the linux-media list in cc now.
 
 What could be the problem here?
 
  
  There is nothing unusual in the kernel log.
 
  This is quite unusual for an -rc2. Hence my question. I'm happy to test
  changes.
 
   martin
  --
  Martin Kepplinger
  e-mailmartink AT posteo DOT at
  chat (XMPP)   martink AT jabber DOT at
 


--
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: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black instead of native resolution

[Zhang, Rui]

> -Original Message-
> From: Martin Kepplinger [mailto:mart...@posteo.de]
> Sent: Sunday, June 22, 2014 10:25 PM
> To: Zhang, Rui
> Cc: r...@rjwysocki.net; l...@kernel.org; linux-a...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black
> instead of native resolution
> Importance: High
> 
> Since 3.16-rc1 my laptop's just goes black while booting, instead of
> switching to native screen resolution and showing me the starting
> system there. It's an Acer TravelMate B113 with i915 driver and
> acer_wmi. It stays black and is unusable.
> 
> Do you have other people complain about that? Bisecting didn't lead to
> a good result. I could be wrong but I somehow suspect the mistake to be
> somewhere in commit 99678ed73a50d2df8b5f3c801e29e9b7a3e5aa85
> 
In order to confirm if the problem is introduced by the above commit,
why not checkout the kernel just before and after this commit and see if the 
problem exists?

Thanks,
rui


> There is nothing unusual in the kernel log.
> 
> This is quite unusual for an -rc2. Hence my question. I'm happy to test
> changes.
> 
>  martin
> --
> Martin Kepplinger
> e-mailmartink AT posteo DOT at
> chat (XMPP)   martink AT jabber DOT at
--
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: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black instead of native resolution

[Zhang, Rui]

 -Original Message-
 From: Martin Kepplinger [mailto:mart...@posteo.de]
 Sent: Sunday, June 22, 2014 10:25 PM
 To: Zhang, Rui
 Cc: r...@rjwysocki.net; l...@kernel.org; linux-a...@vger.kernel.org;
 linux-kernel@vger.kernel.org
 Subject: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black
 instead of native resolution
 Importance: High
 
 Since 3.16-rc1 my laptop's just goes black while booting, instead of
 switching to native screen resolution and showing me the starting
 system there. It's an Acer TravelMate B113 with i915 driver and
 acer_wmi. It stays black and is unusable.
 
 Do you have other people complain about that? Bisecting didn't lead to
 a good result. I could be wrong but I somehow suspect the mistake to be
 somewhere in commit 99678ed73a50d2df8b5f3c801e29e9b7a3e5aa85
 
In order to confirm if the problem is introduced by the above commit,
why not checkout the kernel just before and after this commit and see if the 
problem exists?

Thanks,
rui


 There is nothing unusual in the kernel log.
 
 This is quite unusual for an -rc2. Hence my question. I'm happy to test
 changes.
 
  martin
 --
 Martin Kepplinger
 e-mailmartink AT posteo DOT at
 chat (XMPP)   martink AT jabber DOT at
--
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/

[GIT PULL] Thermal Management updates for v3.16-rc1

[Zhang Rui]

Hi, Linus,

Please pull from the git repository at

  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive Thermal management updates for v3.16-rc1 with
top-most commit 63745aa72ed16154b82a0c9ed22a88001d6ea0fa:

  Merge branches 'armada-375-380-soc-support',
'eduardo-thermal-soc-fixes', 'intel-soc-dts-thermal' and
'thermal-soc-fixes' of .git into next (2014-05-15 17:18:02 +0800)

on top of commit d6d211db37e75de2ddc3a4f979038c40df7cc79c:

  Linux 3.15-rc5 (2014-05-09 13:10:52 -0700)

Specifics:

- fix a bug in Exynos thermal driver, which overwrites the hardware trip
  point threshold when updating software trigger levels and results in
  emergency shutdown. From: Tushar Behera.

- add thermal sensor support for Armada 375 and 38x SoCs. From Ezequiel
  Garcia.

- add TMU (Thermal Management Unit) support for Exynos5260 and
  Exynos5420 SoCs. From Naveen Krishna Chatradhi.

- add support for the additional digital temperature sensors in the
  Intel SoCs like Bay Trail. From: Srinivas Pandruvada.

- a couple of cleanups and small fixes from Jingoo Han, Bartlomiej
  Zolnierkiewicz, Geert Uytterhoeven, Jacob Pan, Paul Walmsley and
  Lan,Tianyu.
 


Bartlomiej Zolnierkiewicz (1):
  thermal: offer Samsung thermal support only when ARCH_EXYNOS is
defined

Ezequiel Garcia (7):
  thermal: armada: Rename armada_thermal_ops struct
  thermal: armada: Add infrastructure to support generic formulas
  thermal: armada: Add generic infrastructure to handle the sensor
  thermal: armada: Pass the platform_device to init_sensor()
  thermal: armada: Allow to specify an 'inverted readout' sensor
  thermal: armada: Support Armada 375 SoC
  thermal: armada: Support Armada 380 SoC

Geert Uytterhoeven (1):
  thermal: rcar: Use pm_runtime_put() i.s.o. pm_runtime_put_sync()

Jacob Pan (1):
  thermal/intel_powerclamp: add newer cpu ids

Jingoo Han (3):
  thermal: rcar: remove unnecessary OOM messages
  thermal: exynos: remove unnecessary OOM messages
  thermal: spear: remove unnecessary OOM messages

Naveen Krishna Chatradhi (4):
  thermal: samsung: replace inten_ bit fields with intclr_
  thermal: samsung: change base_common to more meaningful
base_second
  thermal: samsung: Add TMU support for Exynos5420 SoCs
  thermal: samsung: Add TMU support for Exynos5260 SoCs

Paul Walmsley (1):
  thermal: ti-soc-thermal: clk_round_rate() can return a zero upon
error

Srinivas Pandruvada (1):
  thermal: Intel SoC DTS thermal

Tushar Behera (1):
  thermal: samsung: Only update available threshold limits

Zhang Rui (2):
  Merge branch 'next' of
git://git.kernel.org/.../evalenti/linux-soc-thermal into
thermal-soc-fixes
  Merge branches 'armada-375-380-soc-support',
'eduardo-thermal-soc-fixes', 'intel-soc-dts-thermal' and
'thermal-soc-fixes' of .git into next

lan,Tianyu (1):
  Thermal/int3403: Fix thermal hysteresis unit conversion

 Documentation/devicetree/bindings/thermal/armada-thermal.txt |  12 +++-
 Documentation/devicetree/bindings/thermal/exynos-thermal.txt |  50
++-
 drivers/thermal/Kconfig  |  14 +++-
 drivers/thermal/Makefile |   1 +
 drivers/thermal/armada_thermal.c | 158
+++--
 drivers/thermal/int3403_thermal.c|   8 ++-
 drivers/thermal/intel_powerclamp.c   |   2 +
 drivers/thermal/intel_soc_dts_thermal.c  | 479

 drivers/thermal/rcar_thermal.c   |   9 +--
 drivers/thermal/samsung/exynos_tmu.c |  86
+++--
 drivers/thermal/samsung/exynos_tmu.h |  23
---
 drivers/thermal/samsung/exynos_tmu_data.c| 211
+---
 drivers/thermal/samsung/exynos_tmu_data.h|  31
-
 drivers/thermal/spear_thermal.c  |   4 +-
 drivers/thermal/ti-soc-thermal/ti-bandgap.c  |   2 +-
 15 files changed, 1015 insertions(+), 75 deletions(-)
 create mode 100644 drivers/thermal/intel_soc_dts_thermal.c


--
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/

[GIT PULL] Thermal Management updates for v3.16-rc1

[Zhang Rui]

Hi, Linus,

Please pull from the git repository at

  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive Thermal management updates for v3.16-rc1 with
top-most commit 63745aa72ed16154b82a0c9ed22a88001d6ea0fa:

  Merge branches 'armada-375-380-soc-support',
'eduardo-thermal-soc-fixes', 'intel-soc-dts-thermal' and
'thermal-soc-fixes' of .git into next (2014-05-15 17:18:02 +0800)

on top of commit d6d211db37e75de2ddc3a4f979038c40df7cc79c:

  Linux 3.15-rc5 (2014-05-09 13:10:52 -0700)

Specifics:

- fix a bug in Exynos thermal driver, which overwrites the hardware trip
  point threshold when updating software trigger levels and results in
  emergency shutdown. From: Tushar Behera.

- add thermal sensor support for Armada 375 and 38x SoCs. From Ezequiel
  Garcia.

- add TMU (Thermal Management Unit) support for Exynos5260 and
  Exynos5420 SoCs. From Naveen Krishna Chatradhi.

- add support for the additional digital temperature sensors in the
  Intel SoCs like Bay Trail. From: Srinivas Pandruvada.

- a couple of cleanups and small fixes from Jingoo Han, Bartlomiej
  Zolnierkiewicz, Geert Uytterhoeven, Jacob Pan, Paul Walmsley and
  Lan,Tianyu.
 


Bartlomiej Zolnierkiewicz (1):
  thermal: offer Samsung thermal support only when ARCH_EXYNOS is
defined

Ezequiel Garcia (7):
  thermal: armada: Rename armada_thermal_ops struct
  thermal: armada: Add infrastructure to support generic formulas
  thermal: armada: Add generic infrastructure to handle the sensor
  thermal: armada: Pass the platform_device to init_sensor()
  thermal: armada: Allow to specify an 'inverted readout' sensor
  thermal: armada: Support Armada 375 SoC
  thermal: armada: Support Armada 380 SoC

Geert Uytterhoeven (1):
  thermal: rcar: Use pm_runtime_put() i.s.o. pm_runtime_put_sync()

Jacob Pan (1):
  thermal/intel_powerclamp: add newer cpu ids

Jingoo Han (3):
  thermal: rcar: remove unnecessary OOM messages
  thermal: exynos: remove unnecessary OOM messages
  thermal: spear: remove unnecessary OOM messages

Naveen Krishna Chatradhi (4):
  thermal: samsung: replace inten_ bit fields with intclr_
  thermal: samsung: change base_common to more meaningful
base_second
  thermal: samsung: Add TMU support for Exynos5420 SoCs
  thermal: samsung: Add TMU support for Exynos5260 SoCs

Paul Walmsley (1):
  thermal: ti-soc-thermal: clk_round_rate() can return a zero upon
error

Srinivas Pandruvada (1):
  thermal: Intel SoC DTS thermal

Tushar Behera (1):
  thermal: samsung: Only update available threshold limits

Zhang Rui (2):
  Merge branch 'next' of
git://git.kernel.org/.../evalenti/linux-soc-thermal into
thermal-soc-fixes
  Merge branches 'armada-375-380-soc-support',
'eduardo-thermal-soc-fixes', 'intel-soc-dts-thermal' and
'thermal-soc-fixes' of .git into next

lan,Tianyu (1):
  Thermal/int3403: Fix thermal hysteresis unit conversion

 Documentation/devicetree/bindings/thermal/armada-thermal.txt |  12 +++-
 Documentation/devicetree/bindings/thermal/exynos-thermal.txt |  50
++-
 drivers/thermal/Kconfig  |  14 +++-
 drivers/thermal/Makefile |   1 +
 drivers/thermal/armada_thermal.c | 158
+++--
 drivers/thermal/int3403_thermal.c|   8 ++-
 drivers/thermal/intel_powerclamp.c   |   2 +
 drivers/thermal/intel_soc_dts_thermal.c  | 479

 drivers/thermal/rcar_thermal.c   |   9 +--
 drivers/thermal/samsung/exynos_tmu.c |  86
+++--
 drivers/thermal/samsung/exynos_tmu.h |  23
---
 drivers/thermal/samsung/exynos_tmu_data.c| 211
+---
 drivers/thermal/samsung/exynos_tmu_data.h|  31
-
 drivers/thermal/spear_thermal.c  |   4 +-
 drivers/thermal/ti-soc-thermal/ti-bandgap.c  |   2 +-
 15 files changed, 1015 insertions(+), 75 deletions(-)
 create mode 100644 drivers/thermal/intel_soc_dts_thermal.c


--
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 0/10] ACPI enumeration rework (was: Re: [PATCH V7 00/11] ACPI: ACPI enumeration rework)

[Zhang Rui]

On Fri, 2014-05-30 at 04:20 +0200, Rafael J. Wysocki wrote:
> On Friday, May 23, 2014 02:02:22 AM Zhang Rui wrote:
> > Hi, all,
> > 
> > Currently, PNP bus is used as the default bus for for enumerating ACPI
> > devices with _HID/_CID.
> > For a device that needs to be enumerated to platform bus, we need to add
> > its id string to the platform scan handler white list explicitly.
> > 
> > This becomes a problem as more and more _HID devices need to be
> > enumerated to platform bus nowadays, thus the list is continuously growing.
> > 
> > So, a solution that uses platform bus for _HID enumeration by default
> > is preferred.
> > 
> 
> OK, this has had several rounds of review already and we're really starting
> to run out of time with it, so my version of this patchset follows.
> 
> It is mostly based on your patches, but reordered and with some major
> changes.  Compiled only for now, so please let me know if there's any
> breakage in it.  [The last patch will not apply without update of the
> device list being removed, but generally this is on top of linux-next
> material.]
> 
Applied the patch set on top of linux-pm tree linux-next branch, with
some modifications of Patch 9/10 because of the updated lpss id list,
it works as expected on an IVB Ultrabook.

Tested-by: Zhang Rui 

thanks,
rui

--
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: [Update][PATCH 10/10] ACPI / scan: use platform bus type by default for _HID enumeration

[Zhang Rui]

On Sat, 2014-05-31 at 13:56 +0800, Zhang Rui wrote:
> On Fri, 2014-05-30 at 14:35 +0200, Rafael J. Wysocki wrote:
> > From: Zhang Rui 
> > 
> > Because of the growing demand for enumerating ACPI devices to
> > platform bus, change the code to enumerate ACPI device objects to
> > platform bus by default.  Namely, create platform devices for the
> > ACPI device objects that
> >  1. Have pnp.type.platform_id set (device objects with _HID currently).
> >  2. Do not have a scan handler attached.
> >  3. Are not SPI/I2C slave devices (that should be enumerated to the
> > appropriate buses bus by their parent).
> > 
> > Signed-off-by: Zhang Rui 
> > [rjw: Subject and changelog, rebase and code cleanup]
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> > 
> > Changelog rework and minor cleanups.
> > 
> > Thanks!
> > 
> > ---
> >  drivers/acpi/acpi_platform.c |   40 
> > 
> >  drivers/acpi/scan.c  |   42 
> > +-
> >  2 files changed, 49 insertions(+), 33 deletions(-)
> > 
> > Index: linux-pm/drivers/acpi/acpi_platform.c
> > ===
> > --- linux-pm.orig/drivers/acpi/acpi_platform.c
> > +++ linux-pm/drivers/acpi/acpi_platform.c
> > @@ -22,21 +22,11 @@
> >  
> >  ACPI_MODULE_NAME("platform");
> >  
> > -/*
> > - * The following ACPI IDs are known to be suitable for representing as
> > - * platform devices.
> > - */
> > -static const struct acpi_device_id acpi_platform_device_ids[] = {
> > -
> > -   { "PNP0D40" },
> > -   { "VPC2004" },
> > -   { "BCM4752" },
> > -
> > -   /* Intel Smart Sound Technology */
> > -   { "INT33C8" },
> > -   { "80860F28" },
> > -
> > -   { }
> > +static const struct acpi_device_id forbidden_id_list[] = {
> > +   {"PNP", 0}, /* PIC */
> > +   {"PNP0100", 0}, /* Timer */
> > +   {"PNP0200", 0}, /* AT DMA Controller */
> > +   {"", 0},
> >  };
> >  
> >  /**
> > @@ -63,6 +53,9 @@ struct platform_device *acpi_create_plat
> > if (adev->physical_node_count)
> > return NULL;
> >  
> > +   if (!acpi_match_device_ids(adev, forbidden_id_list))
> > +   return ERR_PTR(-EINVAL);
> > +
> > INIT_LIST_HEAD(_list);
> > count = acpi_dev_get_resources(adev, _list, NULL, NULL);
> > if (count < 0) {
> > @@ -120,20 +113,3 @@ struct platform_device *acpi_create_plat
> > kfree(resources);
> > return pdev;
> >  }
> > -
> > -static int acpi_platform_attach(struct acpi_device *adev,
> > -   const struct acpi_device_id *id)
> > -{
> > -   acpi_create_platform_device(adev);
> > -   return 1;
> > -}
> > -
> this patch does not apply.
> we do not have the above code in drivers/acpi/acpi_platform.c.

I see. this patch is made based on the drivers/acpi/acpi_platform.c
changes in your linux-next branch. Sorry for the noise.

thanks,
rui
> 
> thanks,
> rui
> > -static struct acpi_scan_handler platform_handler = {
> > -   .ids = acpi_platform_device_ids,
> > -   .attach = acpi_platform_attach,
> > -};
> > -
> > -void __init acpi_platform_init(void)
> > -{
> > -   acpi_scan_add_handler(_handler);
> > -}
> > Index: linux-pm/drivers/acpi/scan.c
> > ===
> > --- linux-pm.orig/drivers/acpi/scan.c
> > +++ linux-pm/drivers/acpi/scan.c
> > @@ -2070,6 +2070,44 @@ static acpi_status acpi_bus_check_add(ac
> > return AE_OK;
> >  }
> >  
> > +static int acpi_check_spi_i2c_slave(struct acpi_resource *ares, void *data)
> > +{
> > +   bool *is_spi_i2c_slave_p = data;
> > +
> > +   if (ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
> > +   return 1;
> > +
> > +   /*
> > +* devices that are connected to UART still need to be enumerated to
> > +* platform bus
> > +*/
> > +   if (ares->data.common_serial_bus.type != ACPI_RESOURCE_SERIAL_TYPE_UART)
> > +   *is_spi_i2c_slave_p = true;
> > +
> > +/* no need to do more checking */
> > +   return -1;
> > +}
> > +
> > +static void acpi_default_enumeration(struct acpi_device *device)
> > +{
> > +   struct list_head resource_list;
> > +   bool is_spi_i2c_

Re: [Update][PATCH 10/10] ACPI / scan: use platform bus type by default for _HID enumeration

[Zhang Rui]

On Sat, 2014-05-31 at 13:56 +0800, Zhang Rui wrote:
 On Fri, 2014-05-30 at 14:35 +0200, Rafael J. Wysocki wrote:
  From: Zhang Rui rui.zh...@intel.com
  
  Because of the growing demand for enumerating ACPI devices to
  platform bus, change the code to enumerate ACPI device objects to
  platform bus by default.  Namely, create platform devices for the
  ACPI device objects that
   1. Have pnp.type.platform_id set (device objects with _HID currently).
   2. Do not have a scan handler attached.
   3. Are not SPI/I2C slave devices (that should be enumerated to the
  appropriate buses bus by their parent).
  
  Signed-off-by: Zhang Rui rui.zh...@intel.com
  [rjw: Subject and changelog, rebase and code cleanup]
  Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
  ---
  
  Changelog rework and minor cleanups.
  
  Thanks!
  
  ---
   drivers/acpi/acpi_platform.c |   40 
  
   drivers/acpi/scan.c  |   42 
  +-
   2 files changed, 49 insertions(+), 33 deletions(-)
  
  Index: linux-pm/drivers/acpi/acpi_platform.c
  ===
  --- linux-pm.orig/drivers/acpi/acpi_platform.c
  +++ linux-pm/drivers/acpi/acpi_platform.c
  @@ -22,21 +22,11 @@
   
   ACPI_MODULE_NAME(platform);
   
  -/*
  - * The following ACPI IDs are known to be suitable for representing as
  - * platform devices.
  - */
  -static const struct acpi_device_id acpi_platform_device_ids[] = {
  -
  -   { PNP0D40 },
  -   { VPC2004 },
  -   { BCM4752 },
  -
  -   /* Intel Smart Sound Technology */
  -   { INT33C8 },
  -   { 80860F28 },
  -
  -   { }
  +static const struct acpi_device_id forbidden_id_list[] = {
  +   {PNP, 0}, /* PIC */
  +   {PNP0100, 0}, /* Timer */
  +   {PNP0200, 0}, /* AT DMA Controller */
  +   {, 0},
   };
   
   /**
  @@ -63,6 +53,9 @@ struct platform_device *acpi_create_plat
  if (adev-physical_node_count)
  return NULL;
   
  +   if (!acpi_match_device_ids(adev, forbidden_id_list))
  +   return ERR_PTR(-EINVAL);
  +
  INIT_LIST_HEAD(resource_list);
  count = acpi_dev_get_resources(adev, resource_list, NULL, NULL);
  if (count  0) {
  @@ -120,20 +113,3 @@ struct platform_device *acpi_create_plat
  kfree(resources);
  return pdev;
   }
  -
  -static int acpi_platform_attach(struct acpi_device *adev,
  -   const struct acpi_device_id *id)
  -{
  -   acpi_create_platform_device(adev);
  -   return 1;
  -}
  -
 this patch does not apply.
 we do not have the above code in drivers/acpi/acpi_platform.c.

I see. this patch is made based on the drivers/acpi/acpi_platform.c
changes in your linux-next branch. Sorry for the noise.

thanks,
rui
 
 thanks,
 rui
  -static struct acpi_scan_handler platform_handler = {
  -   .ids = acpi_platform_device_ids,
  -   .attach = acpi_platform_attach,
  -};
  -
  -void __init acpi_platform_init(void)
  -{
  -   acpi_scan_add_handler(platform_handler);
  -}
  Index: linux-pm/drivers/acpi/scan.c
  ===
  --- linux-pm.orig/drivers/acpi/scan.c
  +++ linux-pm/drivers/acpi/scan.c
  @@ -2070,6 +2070,44 @@ static acpi_status acpi_bus_check_add(ac
  return AE_OK;
   }
   
  +static int acpi_check_spi_i2c_slave(struct acpi_resource *ares, void *data)
  +{
  +   bool *is_spi_i2c_slave_p = data;
  +
  +   if (ares-type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
  +   return 1;
  +
  +   /*
  +* devices that are connected to UART still need to be enumerated to
  +* platform bus
  +*/
  +   if (ares-data.common_serial_bus.type != ACPI_RESOURCE_SERIAL_TYPE_UART)
  +   *is_spi_i2c_slave_p = true;
  +
  +/* no need to do more checking */
  +   return -1;
  +}
  +
  +static void acpi_default_enumeration(struct acpi_device *device)
  +{
  +   struct list_head resource_list;
  +   bool is_spi_i2c_slave = false;
  +
  +   if (!device-pnp.type.platform_id || device-handler)
  +   return;
  +
  +   /*
  +* Do not enemerate SPI/I2C slaves as they will be enuerated by their
  +* respective parents.
  +*/
  +   INIT_LIST_HEAD(resource_list);
  +   acpi_dev_get_resources(device, resource_list, acpi_check_spi_i2c_slave,
  +  is_spi_i2c_slave);
  +   acpi_dev_free_resource_list(resource_list);
  +   if (!is_spi_i2c_slave)
  +   acpi_create_platform_device(device);
  +}
  +
   static int acpi_scan_attach_handler(struct acpi_device *device)
   {
  struct acpi_hardware_id *hwid;
  @@ -2095,6 +2133,9 @@ static int acpi_scan_attach_handler(stru
  break;
  }
  }
  +   if (!ret)
  +   acpi_default_enumeration(device);
  +
  return ret;
   }
   
  @@ -2254,7 +2295,6 @@ int __init acpi_scan_init(void)
  acpi_pci_root_init();
  acpi_pci_link_init();
  acpi_processor_init();
  -   acpi_platform_init

Re: [PATCH 0/10] ACPI enumeration rework (was: Re: [PATCH V7 00/11] ACPI: ACPI enumeration rework)

[Zhang Rui]

On Fri, 2014-05-30 at 04:20 +0200, Rafael J. Wysocki wrote:
 On Friday, May 23, 2014 02:02:22 AM Zhang Rui wrote:
  Hi, all,
  
  Currently, PNP bus is used as the default bus for for enumerating ACPI
  devices with _HID/_CID.
  For a device that needs to be enumerated to platform bus, we need to add
  its id string to the platform scan handler white list explicitly.
  
  This becomes a problem as more and more _HID devices need to be
  enumerated to platform bus nowadays, thus the list is continuously growing.
  
  So, a solution that uses platform bus for _HID enumeration by default
  is preferred.
  
 
 OK, this has had several rounds of review already and we're really starting
 to run out of time with it, so my version of this patchset follows.
 
 It is mostly based on your patches, but reordered and with some major
 changes.  Compiled only for now, so please let me know if there's any
 breakage in it.  [The last patch will not apply without update of the
 device list being removed, but generally this is on top of linux-next
 material.]
 
Applied the patch set on top of linux-pm tree linux-next branch, with
some modifications of Patch 9/10 because of the updated lpss id list,
it works as expected on an IVB Ultrabook.

Tested-by: Zhang Rui rui.zh...@intel.com

thanks,
rui

--
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: [Update][PATCH 10/10] ACPI / scan: use platform bus type by default for _HID enumeration

[Zhang Rui]

On Fri, 2014-05-30 at 14:35 +0200, Rafael J. Wysocki wrote:
> From: Zhang Rui 
> 
> Because of the growing demand for enumerating ACPI devices to
> platform bus, change the code to enumerate ACPI device objects to
> platform bus by default.  Namely, create platform devices for the
> ACPI device objects that
>  1. Have pnp.type.platform_id set (device objects with _HID currently).
>  2. Do not have a scan handler attached.
>  3. Are not SPI/I2C slave devices (that should be enumerated to the
> appropriate buses bus by their parent).
> 
> Signed-off-by: Zhang Rui 
> [rjw: Subject and changelog, rebase and code cleanup]
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> Changelog rework and minor cleanups.
> 
> Thanks!
> 
> ---
>  drivers/acpi/acpi_platform.c |   40 
>  drivers/acpi/scan.c  |   42 
> +-
>  2 files changed, 49 insertions(+), 33 deletions(-)
> 
> Index: linux-pm/drivers/acpi/acpi_platform.c
> ===
> --- linux-pm.orig/drivers/acpi/acpi_platform.c
> +++ linux-pm/drivers/acpi/acpi_platform.c
> @@ -22,21 +22,11 @@
>  
>  ACPI_MODULE_NAME("platform");
>  
> -/*
> - * The following ACPI IDs are known to be suitable for representing as
> - * platform devices.
> - */
> -static const struct acpi_device_id acpi_platform_device_ids[] = {
> -
> - { "PNP0D40" },
> - { "VPC2004" },
> - { "BCM4752" },
> -
> - /* Intel Smart Sound Technology */
> - { "INT33C8" },
> - { "80860F28" },
> -
> - { }
> +static const struct acpi_device_id forbidden_id_list[] = {
> + {"PNP", 0}, /* PIC */
> + {"PNP0100", 0}, /* Timer */
> + {"PNP0200", 0}, /* AT DMA Controller */
> + {"", 0},
>  };
>  
>  /**
> @@ -63,6 +53,9 @@ struct platform_device *acpi_create_plat
>   if (adev->physical_node_count)
>   return NULL;
>  
> + if (!acpi_match_device_ids(adev, forbidden_id_list))
> + return ERR_PTR(-EINVAL);
> +
>   INIT_LIST_HEAD(_list);
>   count = acpi_dev_get_resources(adev, _list, NULL, NULL);
>   if (count < 0) {
> @@ -120,20 +113,3 @@ struct platform_device *acpi_create_plat
>   kfree(resources);
>   return pdev;
>  }
> -
> -static int acpi_platform_attach(struct acpi_device *adev,
> - const struct acpi_device_id *id)
> -{
> - acpi_create_platform_device(adev);
> - return 1;
> -}
> -
this patch does not apply.
we do not have the above code in drivers/acpi/acpi_platform.c.

thanks,
rui
> -static struct acpi_scan_handler platform_handler = {
> - .ids = acpi_platform_device_ids,
> - .attach = acpi_platform_attach,
> -};
> -
> -void __init acpi_platform_init(void)
> -{
> - acpi_scan_add_handler(_handler);
> -}
> Index: linux-pm/drivers/acpi/scan.c
> ===
> --- linux-pm.orig/drivers/acpi/scan.c
> +++ linux-pm/drivers/acpi/scan.c
> @@ -2070,6 +2070,44 @@ static acpi_status acpi_bus_check_add(ac
>   return AE_OK;
>  }
>  
> +static int acpi_check_spi_i2c_slave(struct acpi_resource *ares, void *data)
> +{
> + bool *is_spi_i2c_slave_p = data;
> +
> + if (ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
> + return 1;
> +
> + /*
> +  * devices that are connected to UART still need to be enumerated to
> +  * platform bus
> +  */
> + if (ares->data.common_serial_bus.type != ACPI_RESOURCE_SERIAL_TYPE_UART)
> + *is_spi_i2c_slave_p = true;
> +
> +  /* no need to do more checking */
> + return -1;
> +}
> +
> +static void acpi_default_enumeration(struct acpi_device *device)
> +{
> + struct list_head resource_list;
> + bool is_spi_i2c_slave = false;
> +
> + if (!device->pnp.type.platform_id || device->handler)
> + return;
> +
> + /*
> +  * Do not enemerate SPI/I2C slaves as they will be enuerated by their
> +  * respective parents.
> +  */
> + INIT_LIST_HEAD(_list);
> + acpi_dev_get_resources(device, _list, acpi_check_spi_i2c_slave,
> +_spi_i2c_slave);
> + acpi_dev_free_resource_list(_list);
> + if (!is_spi_i2c_slave)
> + acpi_create_platform_device(device);
> +}
> +
>  static int acpi_scan_attach_handler(struct acpi_device *device)
>  {
>   struct acpi_hardware_id *hwid;
> @@ -2095,6 +2133,9 @@ static int acp

Re: [Update][PATCH 10/10] ACPI / scan: use platform bus type by default for _HID enumeration

[Zhang Rui]

On Fri, 2014-05-30 at 14:35 +0200, Rafael J. Wysocki wrote:
 From: Zhang Rui rui.zh...@intel.com
 
 Because of the growing demand for enumerating ACPI devices to
 platform bus, change the code to enumerate ACPI device objects to
 platform bus by default.  Namely, create platform devices for the
 ACPI device objects that
  1. Have pnp.type.platform_id set (device objects with _HID currently).
  2. Do not have a scan handler attached.
  3. Are not SPI/I2C slave devices (that should be enumerated to the
 appropriate buses bus by their parent).
 
 Signed-off-by: Zhang Rui rui.zh...@intel.com
 [rjw: Subject and changelog, rebase and code cleanup]
 Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
 ---
 
 Changelog rework and minor cleanups.
 
 Thanks!
 
 ---
  drivers/acpi/acpi_platform.c |   40 
  drivers/acpi/scan.c  |   42 
 +-
  2 files changed, 49 insertions(+), 33 deletions(-)
 
 Index: linux-pm/drivers/acpi/acpi_platform.c
 ===
 --- linux-pm.orig/drivers/acpi/acpi_platform.c
 +++ linux-pm/drivers/acpi/acpi_platform.c
 @@ -22,21 +22,11 @@
  
  ACPI_MODULE_NAME(platform);
  
 -/*
 - * The following ACPI IDs are known to be suitable for representing as
 - * platform devices.
 - */
 -static const struct acpi_device_id acpi_platform_device_ids[] = {
 -
 - { PNP0D40 },
 - { VPC2004 },
 - { BCM4752 },
 -
 - /* Intel Smart Sound Technology */
 - { INT33C8 },
 - { 80860F28 },
 -
 - { }
 +static const struct acpi_device_id forbidden_id_list[] = {
 + {PNP, 0}, /* PIC */
 + {PNP0100, 0}, /* Timer */
 + {PNP0200, 0}, /* AT DMA Controller */
 + {, 0},
  };
  
  /**
 @@ -63,6 +53,9 @@ struct platform_device *acpi_create_plat
   if (adev-physical_node_count)
   return NULL;
  
 + if (!acpi_match_device_ids(adev, forbidden_id_list))
 + return ERR_PTR(-EINVAL);
 +
   INIT_LIST_HEAD(resource_list);
   count = acpi_dev_get_resources(adev, resource_list, NULL, NULL);
   if (count  0) {
 @@ -120,20 +113,3 @@ struct platform_device *acpi_create_plat
   kfree(resources);
   return pdev;
  }
 -
 -static int acpi_platform_attach(struct acpi_device *adev,
 - const struct acpi_device_id *id)
 -{
 - acpi_create_platform_device(adev);
 - return 1;
 -}
 -
this patch does not apply.
we do not have the above code in drivers/acpi/acpi_platform.c.

thanks,
rui
 -static struct acpi_scan_handler platform_handler = {
 - .ids = acpi_platform_device_ids,
 - .attach = acpi_platform_attach,
 -};
 -
 -void __init acpi_platform_init(void)
 -{
 - acpi_scan_add_handler(platform_handler);
 -}
 Index: linux-pm/drivers/acpi/scan.c
 ===
 --- linux-pm.orig/drivers/acpi/scan.c
 +++ linux-pm/drivers/acpi/scan.c
 @@ -2070,6 +2070,44 @@ static acpi_status acpi_bus_check_add(ac
   return AE_OK;
  }
  
 +static int acpi_check_spi_i2c_slave(struct acpi_resource *ares, void *data)
 +{
 + bool *is_spi_i2c_slave_p = data;
 +
 + if (ares-type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
 + return 1;
 +
 + /*
 +  * devices that are connected to UART still need to be enumerated to
 +  * platform bus
 +  */
 + if (ares-data.common_serial_bus.type != ACPI_RESOURCE_SERIAL_TYPE_UART)
 + *is_spi_i2c_slave_p = true;
 +
 +  /* no need to do more checking */
 + return -1;
 +}
 +
 +static void acpi_default_enumeration(struct acpi_device *device)
 +{
 + struct list_head resource_list;
 + bool is_spi_i2c_slave = false;
 +
 + if (!device-pnp.type.platform_id || device-handler)
 + return;
 +
 + /*
 +  * Do not enemerate SPI/I2C slaves as they will be enuerated by their
 +  * respective parents.
 +  */
 + INIT_LIST_HEAD(resource_list);
 + acpi_dev_get_resources(device, resource_list, acpi_check_spi_i2c_slave,
 +is_spi_i2c_slave);
 + acpi_dev_free_resource_list(resource_list);
 + if (!is_spi_i2c_slave)
 + acpi_create_platform_device(device);
 +}
 +
  static int acpi_scan_attach_handler(struct acpi_device *device)
  {
   struct acpi_hardware_id *hwid;
 @@ -2095,6 +2133,9 @@ static int acpi_scan_attach_handler(stru
   break;
   }
   }
 + if (!ret)
 + acpi_default_enumeration(device);
 +
   return ret;
  }
  
 @@ -2254,7 +2295,6 @@ int __init acpi_scan_init(void)
   acpi_pci_root_init();
   acpi_pci_link_init();
   acpi_processor_init();
 - acpi_platform_init();
   acpi_lpss_init();
   acpi_cmos_rtc_init();
   acpi_container_init();
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-acpi in
 the body of a message to majord...@vger.kernel.org
 More

Re: [PATCH V7 10/11] ACPI: use platform bus as the default bus for _HID enumeration

[Zhang Rui]

On Mon, 2014-05-26 at 13:21 +0300, Mika Westerberg wrote:
> On Fri, May 23, 2014 at 02:02:32AM +0800, Zhang Rui wrote:
> > Because of the growing demand for enumerating ACPI devices to
> > platform bus, this patch changes the code to enumerate ACPI
> > devices to platform bus by default, if the device
> > 1. has _HID.
> > 2. does not have a scan handler attached.
> > 3. is not SPB slave device, which should be enumerated by its parent.
> > 
> > Signed-off-by: Zhang Rui 
> > ---
> >  drivers/acpi/acpi_platform.c | 28 
> >  drivers/acpi/scan.c  | 43 
> > ++-
> >  2 files changed, 42 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> > index dbfe49e..33376a9 100644
> > --- a/drivers/acpi/acpi_platform.c
> > +++ b/drivers/acpi/acpi_platform.c
> > @@ -22,24 +22,6 @@
> >  
> >  ACPI_MODULE_NAME("platform");
> >  
> > -/*
> > - * The following ACPI IDs are known to be suitable for representing as
> > - * platform devices.
> > - */
> > -static const struct acpi_device_id acpi_platform_device_ids[] = {
> > -
> > -   { "PNP0D40" },
> > -   { "ACPI0003" },
> > -   { "VPC2004" },
> > -   { "BCM4752" },
> 
> You can't remove this one as it is bluetooth connected to HS-UART and
> thus has UARTSerialBus() connector.

refreshed patch attached.

>From 50f67c33fc686c8dc86507e478a5e7d6f01805c9 Mon Sep 17 00:00:00 2001
From: Zhang Rui 
Date: Thu, 22 May 2014 21:30:37 +0800
Subject: [PATCH 10/11] ACPI: use platform bus as the default bus for _HID
 enumeration

Because of the growing demand for enumerating ACPI devices to
platform bus, this patch changes the code to enumerate ACPI
devices to platform bus by default, if the device
1. has _HID.
2. does not have a scan handler attached.
3. is not SPI/I2C slave device, which should be enumerated
   to SPI/I2C bus by its parent.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_platform.c | 28 
 drivers/acpi/scan.c  | 51 +++-
 2 files changed, 50 insertions(+), 29 deletions(-)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index dbfe49e..33376a9 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -22,24 +22,6 @@
 
 ACPI_MODULE_NAME("platform");
 
-/*
- * The following ACPI IDs are known to be suitable for representing as
- * platform devices.
- */
-static const struct acpi_device_id acpi_platform_device_ids[] = {
-
-   { "PNP0D40" },
-   { "ACPI0003" },
-   { "VPC2004" },
-   { "BCM4752" },
-
-   /* Intel Smart Sound Technology */
-   { "INT33C8" },
-   { "80860F28" },
-
-   { }
-};
-
 /**
  * acpi_create_platform_device - Create platform device for ACPI device node
  * @adev: ACPI device node to create a platform device for.
@@ -125,13 +107,3 @@ int acpi_create_platform_device(struct acpi_device *adev,
kfree(resources);
return 1;
 }
-
-static struct acpi_scan_handler platform_handler = {
-   .ids = acpi_platform_device_ids,
-   .attach = acpi_create_platform_device,
-};
-
-void __init acpi_platform_init(void)
-{
-   acpi_scan_add_handler(_handler);
-}
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 6d50916..73417d6 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2079,6 +2079,53 @@ static int acpi_scan_handler_dummy_attach(struct 
acpi_device *device,
return 1;
 }
 
+static int acpi_check_spi_i2c_slave(struct acpi_resource *ares, void *data)
+{
+   struct acpi_resource_common_serialbus *res;
+   int *is_spi_i2c_slave = data;
+
+   if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
+   res = >data.common_serial_bus;
+
+   /*
+* devices that are connected to UART still need to
+* be enumerated to platform bus
+*/
+   if (res->type != ACPI_RESOURCE_SERIAL_TYPE_UART)
+   *is_spi_i2c_slave = 1;
+/* no need to do more checking */
+   return -1;
+   }
+   return 1;
+}
+
+static void acpi_do_default_enumeration(struct acpi_device *device)
+{
+   struct list_head resource_list;
+   int is_spi_i2c_slave = 0;
+
+   /* Do not do enumeration for device object w/o platform_id */
+   if (!device->pnp.type.platform_id)
+   return;
+
+   /* Do not do enumeration for device object with scan handler attached */
+   if (device->handler)
+   return;
+
+   /*
+* Do not do enemeration for SP

Re: [PATCH V7 10/11] ACPI: use platform bus as the default bus for _HID enumeration

[Zhang Rui]

On Mon, 2014-05-26 at 13:21 +0300, Mika Westerberg wrote:
 On Fri, May 23, 2014 at 02:02:32AM +0800, Zhang Rui wrote:
  Because of the growing demand for enumerating ACPI devices to
  platform bus, this patch changes the code to enumerate ACPI
  devices to platform bus by default, if the device
  1. has _HID.
  2. does not have a scan handler attached.
  3. is not SPB slave device, which should be enumerated by its parent.
  
  Signed-off-by: Zhang Rui rui.zh...@intel.com
  ---
   drivers/acpi/acpi_platform.c | 28 
   drivers/acpi/scan.c  | 43 
  ++-
   2 files changed, 42 insertions(+), 29 deletions(-)
  
  diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
  index dbfe49e..33376a9 100644
  --- a/drivers/acpi/acpi_platform.c
  +++ b/drivers/acpi/acpi_platform.c
  @@ -22,24 +22,6 @@
   
   ACPI_MODULE_NAME(platform);
   
  -/*
  - * The following ACPI IDs are known to be suitable for representing as
  - * platform devices.
  - */
  -static const struct acpi_device_id acpi_platform_device_ids[] = {
  -
  -   { PNP0D40 },
  -   { ACPI0003 },
  -   { VPC2004 },
  -   { BCM4752 },
 
 You can't remove this one as it is bluetooth connected to HS-UART and
 thus has UARTSerialBus() connector.

refreshed patch attached.

From 50f67c33fc686c8dc86507e478a5e7d6f01805c9 Mon Sep 17 00:00:00 2001
From: Zhang Rui rui.zh...@intel.com
Date: Thu, 22 May 2014 21:30:37 +0800
Subject: [PATCH 10/11] ACPI: use platform bus as the default bus for _HID
 enumeration

Because of the growing demand for enumerating ACPI devices to
platform bus, this patch changes the code to enumerate ACPI
devices to platform bus by default, if the device
1. has _HID.
2. does not have a scan handler attached.
3. is not SPI/I2C slave device, which should be enumerated
   to SPI/I2C bus by its parent.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/acpi_platform.c | 28 
 drivers/acpi/scan.c  | 51 +++-
 2 files changed, 50 insertions(+), 29 deletions(-)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index dbfe49e..33376a9 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -22,24 +22,6 @@
 
 ACPI_MODULE_NAME(platform);
 
-/*
- * The following ACPI IDs are known to be suitable for representing as
- * platform devices.
- */
-static const struct acpi_device_id acpi_platform_device_ids[] = {
-
-   { PNP0D40 },
-   { ACPI0003 },
-   { VPC2004 },
-   { BCM4752 },
-
-   /* Intel Smart Sound Technology */
-   { INT33C8 },
-   { 80860F28 },
-
-   { }
-};
-
 /**
  * acpi_create_platform_device - Create platform device for ACPI device node
  * @adev: ACPI device node to create a platform device for.
@@ -125,13 +107,3 @@ int acpi_create_platform_device(struct acpi_device *adev,
kfree(resources);
return 1;
 }
-
-static struct acpi_scan_handler platform_handler = {
-   .ids = acpi_platform_device_ids,
-   .attach = acpi_create_platform_device,
-};
-
-void __init acpi_platform_init(void)
-{
-   acpi_scan_add_handler(platform_handler);
-}
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 6d50916..73417d6 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2079,6 +2079,53 @@ static int acpi_scan_handler_dummy_attach(struct 
acpi_device *device,
return 1;
 }
 
+static int acpi_check_spi_i2c_slave(struct acpi_resource *ares, void *data)
+{
+   struct acpi_resource_common_serialbus *res;
+   int *is_spi_i2c_slave = data;
+
+   if (ares-type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
+   res = ares-data.common_serial_bus;
+
+   /*
+* devices that are connected to UART still need to
+* be enumerated to platform bus
+*/
+   if (res-type != ACPI_RESOURCE_SERIAL_TYPE_UART)
+   *is_spi_i2c_slave = 1;
+/* no need to do more checking */
+   return -1;
+   }
+   return 1;
+}
+
+static void acpi_do_default_enumeration(struct acpi_device *device)
+{
+   struct list_head resource_list;
+   int is_spi_i2c_slave = 0;
+
+   /* Do not do enumeration for device object w/o platform_id */
+   if (!device-pnp.type.platform_id)
+   return;
+
+   /* Do not do enumeration for device object with scan handler attached */
+   if (device-handler)
+   return;
+
+   /*
+* Do not do enemeration for SPI/I2C slaves
+* as they will be enuerated to SPI/I2C bus by their parents
+*/
+   INIT_LIST_HEAD(resource_list);
+   acpi_dev_get_resources(device, resource_list,
+   acpi_check_spi_i2c_slave, is_spi_i2c_slave);
+   acpi_dev_free_resource_list(resource_list);
+   if (is_spi_i2c_slave)
+   return

Re: [PATCH V7 02/11] PNPACPI: use whilte list for pnpacpi device enumeration

[Zhang Rui]

On Thu, 2014-05-22 at 12:14 -0600, Bjorn Helgaas wrote:
> "white" is misspelled in the subject line.  I mentioned this before.
> 
oops, forgot to update, thanks for the reminder.

>From a8e08d7a6e050f31cec069cc1704f21214b90566 Mon Sep 17 00:00:00 2001
From: Zhang Rui 
Date: Tue, 8 Apr 2014 00:06:49 +0800
Subject: [PATCH V7 02/11] PNPACPI: use white list for pnpacpi device
 enumeration

ACPI can be used to enumerate PNP devices, but the code does not
handle this in a good manner.

Currently, if an ACPI device
1. has _CRS method,
2. has an identifications of
   "three capital charactors followed by four hex numbers",
3. is not in the excluded id list,
it is enumerated to PNP bus.

So actually, PNP bus is used as the default bus for enumerating _HID devices.

But, nowadays, more and more _HID devices are needed to be enumerate to
platform bus instead. And a white list is used for those devices to avoid
overlapping with PNP bus.
The problem is that this list is continuously growing.

So, a solution that uses platform bus as the default bus for _HID enumeration
is preferred.
In order to do this, this patch changes the way of enumerating PNP devices.
As the first step, we use a white list (scan handler) to create PNP devices
instead. This white list contains all the pnp_device_id strings in all the pnp
drivers, thus this change is transparent to PNP core and all the PNP drivers.

Note: I just grep all the id strings in all pnp_device_id instances and
  copy them to the new white list, with a few changes to the comments
  only, to follow the format of:

  /* driver name, or file name if not a PNP driver */
  {"id-string"}, /* optional comments for the id-string */
  ...

Note: the PNPACPI devices are created in two step,
  1. mark the PNPACPI devices by the acpi pnp scan handler.
  2. create the PNPACPI devices in PNPACPI code in a fs_initcall()
  In this case, if PNP/PNPACPI is not set or "pnpacpi=off" kernel option
  is used, the acpi pnp scan handler is still there, to prevent those
  PNPACPI devices from being created to platform bus.

Note: For CMOS RTC devices, the acpi pnp scan handler does not work because
  there is already a cmos rtc scan handler installed, thus we need to
  check those devices and enumerate them to PNP bus explicitly.
  Plus, the cmos rtc scan handler needs to return 1 so that it will not
  be enumerated to platform bus.

TODO: Reduce this PNPACPI white list by
  1. remove the ids for the devices that are never enumerated via ACPI
  2. remove the ids and convert the drivers to platform bus drivers
 for the devices that are not PNP devices in nature.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/Makefile|   1 +
 drivers/acpi/acpi_cmos_rtc.c |   2 +-
 drivers/acpi/acpi_pnp.c  | 388 +++
 drivers/acpi/internal.h  |   1 +
 drivers/acpi/scan.c  |   1 +
 drivers/pnp/pnpacpi/core.c   |  28 +---
 include/linux/acpi.h |   2 +
 7 files changed, 398 insertions(+), 25 deletions(-)
 create mode 100644 drivers/acpi/acpi_pnp.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..9a43893 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,6 +41,7 @@ acpi-$(CONFIG_ACPI_DOCK)  += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
 acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
 acpi-y += acpi_platform.o
+acpi-y += acpi_pnp.o
 acpi-y += power.o
 acpi-y += event.o
 acpi-y += sysfs.o
diff --git a/drivers/acpi/acpi_cmos_rtc.c b/drivers/acpi/acpi_cmos_rtc.c
index 961b45d..2da8660 100644
--- a/drivers/acpi/acpi_cmos_rtc.c
+++ b/drivers/acpi/acpi_cmos_rtc.c
@@ -68,7 +68,7 @@ static int acpi_install_cmos_rtc_space_handler(struct 
acpi_device *adev,
return -ENODEV;
}
 
-   return 0;
+   return 1;
 }
 
 static void acpi_remove_cmos_rtc_space_handler(struct acpi_device *adev)
diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
new file mode 100644
index 000..57d14ed
--- /dev/null
+++ b/drivers/acpi/acpi_pnp.c
@@ -0,0 +1,388 @@
+/*
+ * ACPI support for PNP bus type
+ *
+ * Copyright (C) 2014, Intel Corporation
+ * Authors: Zhang Rui 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+static const struct acpi_device_id acpi_pnp_device_ids[] = {
+   /* pata_isapnp */
+   {"PNP0600"},/* Generic ESDI/IDE/ATA compatible hard disk 
controller */
+   /* floppy */
+   {"PNP0700"},
+   /* ipmi_si */
+   {"IPI0001"},
+   /* tpm_inf_pnp */
+   {"IFX010

[PATCH V7 03/11] ACPI: remove ids that does not comply with the ACPI PNP id rule

[Zhang Rui]

The acpi pnp scan handler id list just copies all the ids from all the
struct pnp_device_id instances, but some of them do not
comply with the ACPI PNP id rule (3 Alpha Charactors + 4 Hex numbers).

For those ids, the coressponding devices will never be enumerated
via ACPI, so it is safe to remove those ids from the PNPACPI white list.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_pnp.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
index 57d14ed..d206616 100644
--- a/drivers/acpi/acpi_pnp.c
+++ b/drivers/acpi/acpi_pnp.c
@@ -33,10 +33,6 @@ static const struct acpi_device_id acpi_pnp_device_ids[] = {
/* ide   */
{"PNP0600"},/* Generic ESDI/IDE/ATA compatible hard disk 
controller */
/* ns558 */
-   {"@P@0001"},/* ALS 100 */
-   {"@P@0020"},/* ALS 200 */
-   {"@P@1001"},/* ALS 100+ */
-   {"@P@2001"},/* ALS 120 */
{"ASB16fd"},/* AdLib NSC16 */
{"AZT3001"},/* AZT1008 */
{"CDC0001"},/* Opl3-SAx */
-- 
1.8.3.2

--
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 V7 04/11] ACPI: remove unsupported serial PNP ids from acpi pnp scan handler id lsit

[Zhang Rui]

The "serial" pnp driver supports some unknown PNP modems (PNPCXXX/PNPDXXX)
by matching magic strings in the pnp device name or the pnp device card name.

ACPI enumerated PNP device neither supports pnp card, nor supports those magic
strings in its device name, which means this mechamism never works for ACPI
enumerated PNPCXXX/PNPDXXX devices.
So it is safe to remove those two ids from the ACPI pnp scan handler id list.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_pnp.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
index d206616..a563a27 100644
--- a/drivers/acpi/acpi_pnp.c
+++ b/drivers/acpi/acpi_pnp.c
@@ -300,8 +300,6 @@ static const struct acpi_device_id acpi_pnp_device_ids[] = {
{"LTS0001"},/* LG C1 EXPRESS DUAL (C1-PB11A3) touch screen 
(actually a FUJ02E6 in disguise) */
{"WCI0003"},/* Rockwell's (PORALiNK) 33600 INT PNP */
{"WEC1022"},/* Winbond CIR port, should not be probed. We 
should keep track of it to prevent the legacy serial driver from probing it */
-   {"PNPCXXX"},/* Unknown PnP modems */
-   {"PNPDXXX"},/* More unknown PnP modems */
/* scl200wdt */
{"NSC0800"},/* National Semiconductor PC87307/PC97307 
watchdog component */
/* mpu401 */
-- 
1.8.3.2

--
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 V7 08/11] ACPI: always register memory hotplug scan handler even if CONFIG_X86_INTEL_LPSS is cleared

[Zhang Rui]

The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.

Fix this problem for lpss devices by always register the lpss scan handler,
but with meaningful callbacks only when CONFIG_X86_INTEL_LPSS is set.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/Makefile|  2 +-
 drivers/acpi/acpi_lpss.c | 63 ++--
 drivers/acpi/internal.h  |  4 ---
 3 files changed, 41 insertions(+), 28 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 171efc2..605eff7 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -39,7 +39,7 @@ acpi-y+= processor_core.o
 acpi-y += ec.o
 acpi-$(CONFIG_ACPI_DOCK)   += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
-acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
+acpi-y += acpi_lpss.o
 acpi-y += acpi_platform.o
 acpi-y += acpi_pnp.o
 acpi-y += power.o
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 69e29f4..bb5b3f2 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -24,6 +24,8 @@
 
 ACPI_MODULE_NAME("acpi_lpss");
 
+#ifdef CONFIG_X86_INTEL_LPSS
+
 #define LPSS_CLK_SIZE  0x04
 #define LPSS_LTR_SIZE  0x18
 
@@ -159,40 +161,50 @@ static struct lpss_device_desc byt_i2c_dev_desc = {
.shared_clock = _clock,
 };
 
+#define LPSS_PTR(desc) ((unsigned long))
+
+#else
+
+#define LPSS_PTR(desc) 0
+
+#endif
+
 static const struct acpi_device_id acpi_lpss_device_ids[] = {
/* Generic LPSS devices */
-   { "INTL9C60", (unsigned long)_dma_desc },
+   { "INTL9C60", LPSS_PTR(lpss_dma_desc) },
 
/* Lynxpoint LPSS devices */
-   { "INT33C0", (unsigned long)_dev_desc },
-   { "INT33C1", (unsigned long)_dev_desc },
-   { "INT33C2", (unsigned long)_dev_desc },
-   { "INT33C3", (unsigned long)_dev_desc },
-   { "INT33C4", (unsigned long)_uart_dev_desc },
-   { "INT33C5", (unsigned long)_uart_dev_desc },
-   { "INT33C6", (unsigned long)_sdio_dev_desc },
+   { "INT33C0", LPSS_PTR(lpt_dev_desc) },
+   { "INT33C1", LPSS_PTR(lpt_dev_desc) },
+   { "INT33C2", LPSS_PTR(lpt_dev_desc) },
+   { "INT33C3", LPSS_PTR(lpt_dev_desc) },
+   { "INT33C4", LPSS_PTR(lpt_uart_dev_desc) },
+   { "INT33C5", LPSS_PTR(lpt_uart_dev_desc) },
+   { "INT33C6", LPSS_PTR(lpt_sdio_dev_desc) },
{ "INT33C7", },
 
/* BayTrail LPSS devices */
-   { "80860F09", (unsigned long)_pwm_dev_desc },
-   { "80860F0A", (unsigned long)_uart_dev_desc },
-   { "80860F0E", (unsigned long)_spi_dev_desc },
-   { "80860F14", (unsigned long)_sdio_dev_desc },
-   { "80860F41", (unsigned long)_i2c_dev_desc },
+   { "80860F09", LPSS_PTR(byt_pwm_dev_desc) },
+   { "80860F0A", LPSS_PTR(byt_uart_dev_desc) },
+   { "80860F0E", LPSS_PTR(byt_spi_dev_desc) },
+   { "80860F14", LPSS_PTR(byt_sdio_dev_desc) },
+   { "80860F41", LPSS_PTR(byt_i2c_dev_desc) },
{ "INT33B2", },
 
-   { "INT3430", (unsigned long)_dev_desc },
-   { "INT3431", (unsigned long)_dev_desc },
-   { "INT3432", (unsigned long)_dev_desc },
-   { "INT3433", (unsigned long)_dev_desc },
-   { "INT3434", (unsigned long)_uart_dev_desc },
-   { "INT3435", (unsigned long)_uart_dev_desc },
-   { "INT3436", (unsigned long)_sdio_dev_desc },
+   { "INT3430", LPSS_PTR(lpt_dev_desc) },
+   { "INT3431", LPSS_PTR(lpt_dev_desc) },
+   { "INT3432", LPSS_PTR(lpt_dev_desc) },
+   { "INT3433", LPSS_PTR(lpt_dev_desc) },
+   { "INT3434", LPSS_PTR(lpt_uart_dev_desc) },
+   { "INT3435", LPSS_PTR(lpt_uart_dev_desc) },
+   { "INT3436", LPSS_PTR(lpt_sdio_dev_desc) },
{ "INT3437", },
 
{ }
 };
 
+#ifdef CONFIG_X86_INTEL_LPSS
+
 static int is_memory(struct acpi_resource *res, void *not_used)
 {
struct resource r;
@@ -503,18 +515,23 @@ static void acpi_lpss_unbind(struct device *dev)
 {
dev->power.set_latency_tolerance = NULL;
 }
+#endif /* CONFIG_X86_INTEL_LPSS */
 
 static struct acpi_scan_handler lpss_handler = {
.ids = acpi_lpss_device_ids,
-

[PATCH V7 09/11] ACPI: introduce platform_id flag

[Zhang Rui]

Only certain kind of ACPI device objects can be enumerated to platform bus.
These ACPI device objects include
1. ACPI device objects that have _HID control method.
2. some ACPI device objects that have Linux specified HID strings.

In order to distinguish those device objects from the others, a new flag
platform_id and a new function acpi_add_platform_id() are introduced
in this patch.

Currently, only devices with _HID method have this flag set.
If you want platform devices to be created for device objects without _HID,
use acpi_add_platform_id() when adding artificial Linux-specific ID strings
to them.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/scan.c | 9 -
 include/acpi/acpi_bus.h | 3 ++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index e9c2f6f..6d50916 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1730,6 +1730,13 @@ static void acpi_add_id(struct acpi_device_pnp *pnp, 
const char *dev_id)
pnp->type.hardware_id = 1;
 }
 
+static void acpi_add_platform_id(struct acpi_device_pnp *pnp,
+const char *dev_id)
+{
+   acpi_add_id(pnp, dev_id);
+   pnp->type.platform_id = 1;
+}
+
 /*
  * Old IBM workstations have a DSDT bug wherein the SMBus object
  * lacks the SMBUS01 HID and the methods do not have the necessary "_"
@@ -1794,7 +1801,7 @@ static void acpi_set_pnp_ids(acpi_handle handle, struct 
acpi_device_pnp *pnp,
}
 
if (info->valid & ACPI_VALID_HID)
-   acpi_add_id(pnp, info->hardware_id.string);
+   acpi_add_platform_id(pnp, info->hardware_id.string);
if (info->valid & ACPI_VALID_CID) {
cid_list = >compatible_id_list;
for (i = 0; i < cid_list->count; i++)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index ba679af..ec92ad3 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -233,7 +233,8 @@ struct acpi_hardware_id {
 struct acpi_pnp_type {
u32 hardware_id:1;
u32 bus_address:1;
-   u32 reserved:30;
+   u32 platform_id:1;
+   u32 reserved:29;
 };
 
 struct acpi_device_pnp {
-- 
1.8.3.2

--
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 V7 10/11] ACPI: use platform bus as the default bus for _HID enumeration

[Zhang Rui]

Because of the growing demand for enumerating ACPI devices to
platform bus, this patch changes the code to enumerate ACPI
devices to platform bus by default, if the device
1. has _HID.
2. does not have a scan handler attached.
3. is not SPB slave device, which should be enumerated by its parent.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_platform.c | 28 
 drivers/acpi/scan.c  | 43 ++-
 2 files changed, 42 insertions(+), 29 deletions(-)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index dbfe49e..33376a9 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -22,24 +22,6 @@
 
 ACPI_MODULE_NAME("platform");
 
-/*
- * The following ACPI IDs are known to be suitable for representing as
- * platform devices.
- */
-static const struct acpi_device_id acpi_platform_device_ids[] = {
-
-   { "PNP0D40" },
-   { "ACPI0003" },
-   { "VPC2004" },
-   { "BCM4752" },
-
-   /* Intel Smart Sound Technology */
-   { "INT33C8" },
-   { "80860F28" },
-
-   { }
-};
-
 /**
  * acpi_create_platform_device - Create platform device for ACPI device node
  * @adev: ACPI device node to create a platform device for.
@@ -125,13 +107,3 @@ int acpi_create_platform_device(struct acpi_device *adev,
kfree(resources);
return 1;
 }
-
-static struct acpi_scan_handler platform_handler = {
-   .ids = acpi_platform_device_ids,
-   .attach = acpi_create_platform_device,
-};
-
-void __init acpi_platform_init(void)
-{
-   acpi_scan_add_handler(_handler);
-}
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 6d50916..c061284 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2079,6 +2079,45 @@ static int acpi_scan_handler_dummy_attach(struct 
acpi_device *device,
return 1;
 }
 
+static int acpi_check_spb_slave(struct acpi_resource *ares, void *data)
+{
+   int *is_spb_slave = data;
+
+   if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
+   *is_spb_slave = 1;
+   /* no need to do more checking */
+   return -1;
+   }
+   return 1;
+}
+
+static void acpi_do_default_enumeration(struct acpi_device *device)
+{
+   struct list_head resource_list;
+   int is_spb_slave = 0;
+
+   /* Do not do enumeration for device object w/o platform_id */
+   if (!device->pnp.type.platform_id)
+   return;
+
+   /* Do not do enumeration for device object with scan handler attached */
+   if (device->handler)
+   return;
+
+   /*
+* Do not do enemeration for SPB slaves
+* as they will be enuerated by their parents
+*/
+   INIT_LIST_HEAD(_list);
+   acpi_dev_get_resources(device, _list,
+   acpi_check_spb_slave, _spb_slave);
+   acpi_dev_free_resource_list(_list);
+   if (is_spb_slave)
+   return;
+
+   acpi_create_platform_device(device, NULL);
+}
+
 static int acpi_scan_attach_handler(struct acpi_device *device)
 {
struct acpi_hardware_id *hwid;
@@ -2103,6 +2142,9 @@ static int acpi_scan_attach_handler(struct acpi_device 
*device)
break;
}
}
+
+   acpi_do_default_enumeration(device);
+
return ret;
 }
 
@@ -2262,7 +2304,6 @@ int __init acpi_scan_init(void)
acpi_pci_root_init();
acpi_pci_link_init();
acpi_processor_init();
-   acpi_platform_init();
acpi_lpss_init();
acpi_cmos_rtc_init();
acpi_container_init();
-- 
1.8.3.2

--
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 V7 11/11] ACPI: introduce acpi platform exclude id list

[Zhang Rui]

For ACPI PIC (PNP), Timer (PNP0100) and DMA controller (PNP0200)
device objects, although they have _HID control method, but they
should not be enumerated to platform bus, because there will never be
any platform drivers for them.

Thus an exclude id list is introduced in this patch to prevent
those platform device nodes from being created.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_platform.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 33376a9..db89480 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -22,6 +22,18 @@
 
 ACPI_MODULE_NAME("platform");
 
+static const struct acpi_device_id excluded_id_list[] = {
+   {"PNP", 0}, /* PIC */
+   {"PNP0100", 0}, /* Timer */
+   {"PNP0200", 0}, /* AT DMA Controller */
+   {"", 0},
+};
+
+static bool is_exclusive_device(struct acpi_device *dev)
+{
+   return !acpi_match_device_ids(dev, excluded_id_list);
+}
+
 /**
  * acpi_create_platform_device - Create platform device for ACPI device node
  * @adev: ACPI device node to create a platform device for.
@@ -48,6 +60,9 @@ int acpi_create_platform_device(struct acpi_device *adev,
if (adev->physical_node_count)
return 0;
 
+   if (is_exclusive_device(adev))
+   return 0;
+
INIT_LIST_HEAD(_list);
count = acpi_dev_get_resources(adev, _list, NULL, NULL);
if (count < 0) {
-- 
1.8.3.2

--
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 V7 07/11] ACPI: always register memory hotplug scan handler even if CONFIG_ACPI_HOTPLUG_MEMORY is cleared

[Zhang Rui]

The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.

Fix this problem for memory hotplug devices by always register the
memery hotplug scan handler, but with meaningful callbacks
only when CONFIG_ACPI_HOTPLUG_MEMORY is set.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/Makefile  |  2 +-
 drivers/acpi/acpi_memhotplug.c | 46 ++
 drivers/acpi/internal.h|  6 +-
 3 files changed, 26 insertions(+), 28 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 5611a07..171efc2 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -65,7 +65,7 @@ obj-$(CONFIG_ACPI_PCI_SLOT)   += pci_slot.o
 obj-$(CONFIG_ACPI_PROCESSOR)   += processor.o
 obj-y  += container.o
 obj-$(CONFIG_ACPI_THERMAL) += thermal.o
-obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
+obj-y  += acpi_memhotplug.o
 obj-$(CONFIG_ACPI_BATTERY) += battery.o
 obj-$(CONFIG_ACPI_SBS) += sbshc.o
 obj-$(CONFIG_ACPI_SBS) += sbs.o
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index b67be85..c54f824 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -44,15 +44,6 @@
 
 ACPI_MODULE_NAME("acpi_memhotplug");
 
-/* Memory Device States */
-#define MEMORY_INVALID_STATE   0
-#define MEMORY_POWER_ON_STATE  1
-#define MEMORY_POWER_OFF_STATE 2
-
-static int acpi_memory_device_add(struct acpi_device *device,
- const struct acpi_device_id *not_used);
-static void acpi_memory_device_remove(struct acpi_device *device);
-
 static const struct acpi_device_id memory_device_ids[] = {
{ACPI_MEMORY_DEVICE_HID, 0},
{"", 0},
@@ -60,13 +51,15 @@ static const struct acpi_device_id memory_device_ids[] = {
 
 static struct acpi_scan_handler memory_device_handler = {
.ids = memory_device_ids,
-   .attach = acpi_memory_device_add,
-   .detach = acpi_memory_device_remove,
-   .hotplug = {
-   .enabled = true,
-   },
 };
 
+#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
+
+/* Memory Device States */
+#define MEMORY_INVALID_STATE   0
+#define MEMORY_POWER_ON_STATE  1
+#define MEMORY_POWER_OFF_STATE 2
+
 struct acpi_memory_info {
struct list_head list;
u64 start_addr; /* Memory Range start physical addr */
@@ -362,17 +355,26 @@ static void acpi_memory_device_remove(struct acpi_device 
*device)
 
 static bool __initdata acpi_no_memhotplug;
 
-void __init acpi_memory_hotplug_init(void)
-{
-   if (acpi_no_memhotplug)
-   return;
-
-   acpi_scan_add_handler_with_hotplug(_device_handler, "memory");
-}
-
 static int __init disable_acpi_memory_hotplug(char *str)
 {
acpi_no_memhotplug = true;
return 1;
 }
 __setup("acpi_no_memhotplug", disable_acpi_memory_hotplug);
+
+#endif
+
+void __init acpi_memory_hotplug_init(void)
+{
+#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
+   if (!acpi_no_memhotplug) {
+   memory_device_handler.attach = acpi_memory_device_add;
+   memory_device_handler.detach = acpi_memory_device_remove;
+   memory_device_handler.hotplug.enabled = true;
+   acpi_scan_add_handler_with_hotplug(_device_handler,
+   "memory");
+   return;
+   }
+#endif
+   acpi_scan_add_handler(_device_handler);
+}
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 499908e..4a9e999 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -33,6 +33,7 @@ void acpi_platform_init(void);
 void acpi_pnp_init(void);
 int acpi_sysfs_init(void);
 void acpi_container_init(void);
+void acpi_memory_hotplug_init(void);
 #ifdef CONFIG_ACPI_DOCK
 void register_dock_dependent_device(struct acpi_device *adev,
acpi_handle dshandle);
@@ -44,11 +45,6 @@ static inline void register_dock_dependent_device(struct 
acpi_device *adev,
 static inline int dock_notify(struct acpi_device *adev, u32 event) { return 
-ENODEV; }
 static inline void acpi_dock_add(struct acpi_device *adev) {}
 #endif
-#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
-void acpi_memory_hotplug_init(void);
-#else
-static inline void acpi_memory_hotplug_init(void) {}
-#endif
 #ifdef CONFIG_X86
 void acpi_cmos_rtc_init(void);
 #else
-- 
1.8.3.2

--
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 V7 06/11] ACPI: always register container scan handler even if CONFIG_ACPI_CONTAINER is cleared

[Zhang Rui]

The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.

Fix this problem for container devices by always registering the
container scan handler, but with meaningful callbacks
only when CONFIG_ACPI_CONTAINER is set.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/Makefile|  2 +-
 drivers/acpi/container.c | 18 --
 drivers/acpi/internal.h  |  4 
 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9a43893..5611a07 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -63,7 +63,7 @@ obj-$(CONFIG_ACPI_FAN)+= fan.o
 obj-$(CONFIG_ACPI_VIDEO)   += video.o
 obj-$(CONFIG_ACPI_PCI_SLOT)+= pci_slot.o
 obj-$(CONFIG_ACPI_PROCESSOR)   += processor.o
-obj-$(CONFIG_ACPI_CONTAINER)   += container.o
+obj-y  += container.o
 obj-$(CONFIG_ACPI_THERMAL) += thermal.o
 obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
 obj-$(CONFIG_ACPI_BATTERY) += battery.o
diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
index 63119d0..b78f52e 100644
--- a/drivers/acpi/container.c
+++ b/drivers/acpi/container.c
@@ -41,6 +41,8 @@ static const struct acpi_device_id container_device_ids[] = {
{"", 0},
 };
 
+#ifdef CONFIG_ACPI_CONTAINER
+
 static int acpi_container_offline(struct container_dev *cdev)
 {
struct acpi_device *adev = ACPI_COMPANION(>dev);
@@ -97,17 +99,21 @@ static void container_device_detach(struct acpi_device 
*adev)
device_unregister(dev);
 }
 
+#endif /* CONFIG_ACPI_CONTAINER */
+
 static struct acpi_scan_handler container_handler = {
.ids = container_device_ids,
-   .attach = container_device_attach,
-   .detach = container_device_detach,
-   .hotplug = {
-   .enabled = true,
-   .demand_offline = true,
-   },
 };
 
 void __init acpi_container_init(void)
 {
+#ifdef CONFIG_ACPI_CONTAINER
+   container_handler.attach = container_device_attach;
+   container_handler.detach = container_device_detach;
+   container_handler.hotplug.enabled = true;
+   container_handler.hotplug.demand_offline = true;
acpi_scan_add_handler_with_hotplug(_handler, "container");
+#else
+   acpi_scan_add_handler(_handler);
+#endif /* CONFIG_ACPI_CONTAINER */
 }
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 3a12866..499908e 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -32,11 +32,7 @@ void acpi_processor_init(void);
 void acpi_platform_init(void);
 void acpi_pnp_init(void);
 int acpi_sysfs_init(void);
-#ifdef CONFIG_ACPI_CONTAINER
 void acpi_container_init(void);
-#else
-static inline void acpi_container_init(void) {}
-#endif
 #ifdef CONFIG_ACPI_DOCK
 void register_dock_dependent_device(struct acpi_device *adev,
acpi_handle dshandle);
-- 
1.8.3.2

--
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 V7 02/11] PNPACPI: use whilte list for pnpacpi device enumeration

[Zhang Rui]

ACPI can be used to enumerate PNP devices, but the code does not
handle this in a good manner.

Currently, if an ACPI device
1. has _CRS method,
2. has an identifications of
   "three capital charactors followed by four hex numbers",
3. is not in the excluded id list,
it is enumerated to PNP bus.

So actually, PNP bus is used as the default bus for enumerating _HID devices.

But, nowadays, more and more _HID devices are needed to be enumerate to
platform bus instead. And a white list is used for those devices to avoid
overlapping with PNP bus.
The problem is that this list is continuously growing.

So, a solution that uses platform bus as the default bus for _HID enumeration
is preferred.
In order to do this, this patch changes the way of enumerating PNP devices.
As the first step, we use a white list (scan handler) to create PNP devices
instead. This white list contains all the pnp_device_id strings in all the pnp
drivers, thus this change is transparent to PNP core and all the PNP drivers.

Note: I just grep all the id strings in all pnp_device_id instances and
  copy them to the new white list, with a few changes to the comments
  only, to follow the format of:

  /* driver name, or file name if not a PNP driver */
  {"id-string"}, /* optional comments for the id-string */
  ...

Note: the PNPACPI devices are created in two step,
  1. mark the PNPACPI devices by the acpi pnp scan handler.
  2. create the PNPACPI devices in PNPACPI code in a fs_initcall()
  In this case, if PNP/PNPACPI is not set or "pnpacpi=off" kernel option
  is used, the acpi pnp scan handler is still there, to prevent those
  PNPACPI devices from being created to platform bus.

Note: For CMOS RTC devices, the acpi pnp scan handler does not work because
  there is already a cmos rtc scan handler installed, thus we need to
  check those devices and enumerate them to PNP bus explicitly.
  Plus, the cmos rtc scan handler needs to return 1 so that it will not
  be enumerated to platform bus.

TODO: Reduce this PNPACPI white list by
  1. remove the ids for the devices that are never enumerated via ACPI
  2. remove the ids and convert the drivers to platform bus drivers
 for the devices that are not PNP devices in nature.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/Makefile|   1 +
 drivers/acpi/acpi_cmos_rtc.c |   2 +-
 drivers/acpi/acpi_pnp.c  | 388 +++
 drivers/acpi/internal.h  |   1 +
 drivers/acpi/scan.c  |   1 +
 drivers/pnp/pnpacpi/core.c   |  28 +---
 include/linux/acpi.h |   2 +
 7 files changed, 398 insertions(+), 25 deletions(-)
 create mode 100644 drivers/acpi/acpi_pnp.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..9a43893 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,6 +41,7 @@ acpi-$(CONFIG_ACPI_DOCK)  += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
 acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
 acpi-y += acpi_platform.o
+acpi-y += acpi_pnp.o
 acpi-y += power.o
 acpi-y += event.o
 acpi-y += sysfs.o
diff --git a/drivers/acpi/acpi_cmos_rtc.c b/drivers/acpi/acpi_cmos_rtc.c
index 961b45d..2da8660 100644
--- a/drivers/acpi/acpi_cmos_rtc.c
+++ b/drivers/acpi/acpi_cmos_rtc.c
@@ -68,7 +68,7 @@ static int acpi_install_cmos_rtc_space_handler(struct 
acpi_device *adev,
return -ENODEV;
}
 
-   return 0;
+   return 1;
 }
 
 static void acpi_remove_cmos_rtc_space_handler(struct acpi_device *adev)
diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
new file mode 100644
index 000..57d14ed
--- /dev/null
+++ b/drivers/acpi/acpi_pnp.c
@@ -0,0 +1,388 @@
+/*
+ * ACPI support for PNP bus type
+ *
+ * Copyright (C) 2014, Intel Corporation
+ * Authors: Zhang Rui 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+static const struct acpi_device_id acpi_pnp_device_ids[] = {
+   /* pata_isapnp */
+   {"PNP0600"},/* Generic ESDI/IDE/ATA compatible hard disk 
controller */
+   /* floppy */
+   {"PNP0700"},
+   /* ipmi_si */
+   {"IPI0001"},
+   /* tpm_inf_pnp */
+   {"IFX0101"},/* Infineon TPMs */
+   {"IFX0102"},/* Infineon TPMs */
+   /*tpm_tis */
+   {"PNP0C31"},/* TPM */
+   {"ATM1200"},/* Atmel */
+   {"IFX0102"},/* Infineon */
+   {"BCM0101"},/* Broadcom */
+   {"BCM0102"},/* Broadcom *

[PATCH V7 05/11] ACPI: allow scan handlers without .attach() callback

[Zhang Rui]

Devices that can be attached to scan handlers, are kind of different from
the others, because they are known that some special actions should be taken.

But we do not mark this difference when the configurable scan handlers
are compiled out. This is harmless currently, but it will be when
we want to take some common actions to the other "non-special" devices,
which will be done in a later patch.

This patch makes .attach() of the acpi scan handler optional.
So that the configurable scan handlers can provide NULL .attach() callback
when not supported.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/scan.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index c82ab73..e9c2f6f 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -84,7 +84,7 @@ EXPORT_SYMBOL_GPL(acpi_initialize_hp_context);
 
 int acpi_scan_add_handler(struct acpi_scan_handler *handler)
 {
-   if (!handler || !handler->attach)
+   if (!handler)
return -EINVAL;
 
list_add_tail(>list_node, _scan_handlers_list);
@@ -2066,6 +2066,12 @@ static acpi_status acpi_bus_check_add(acpi_handle 
handle, u32 lvl_not_used,
return AE_OK;
 }
 
+static int acpi_scan_handler_dummy_attach(struct acpi_device *device,
+   const struct acpi_device_id *devid)
+{
+   return 1;
+}
+
 static int acpi_scan_attach_handler(struct acpi_device *device)
 {
struct acpi_hardware_id *hwid;
@@ -2078,7 +2084,10 @@ static int acpi_scan_attach_handler(struct acpi_device 
*device)
handler = acpi_scan_match_handler(hwid->id, );
if (handler) {
device->handler = handler;
-   ret = handler->attach(device, devid);
+   if (handler->attach)
+   ret = handler->attach(device, devid);
+   else
+   ret = acpi_scan_handler_dummy_attach(device, 
devid);
if (ret > 0)
break;
 
-- 
1.8.3.2

--
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 V7 00/11] ACPI: ACPI enumeration rework

[Zhang Rui]

Hi, all,

Currently, PNP bus is used as the default bus for for enumerating ACPI
devices with _HID/_CID.
For a device that needs to be enumerated to platform bus, we need to add
its id string to the platform scan handler white list explicitly.

This becomes a problem as more and more _HID devices need to be
enumerated to platform bus nowadays, thus the list is continuously growing.

So, a solution that uses platform bus for _HID enumeration by default
is preferred.

In order to do this, this patch set
First (Patch 1~4), changes the way of enumerating PNP devices.
We introduce a white list to create PNP devices instead. The white list contains
all the pnp_device_id strings in all the pnp drivers, thus this change is
transparent to PNP core and all the PNP drivers.
Second (Patch 5~11), changes the code to enumerate ACPI _HID devices to platform
bus by default.

Tis patch set has been tested on my desktop machine,
and a TOSHIBA PORTEGE Z830 ultrabook.

Clarification:
Although it seems that we are introducing a much bigger white list to replace
a small one, the benefit is that
1. without the patch, the acpi_platform scan handler white list is
   continuously growing.
2. with the patch set, the PNPACPI scan handler white list will become
   smaller and smaller by
   a) remove the ids from the PNPACPI white list, for the devices
  that are never enumerated via ACPI
   b) remove the ids from the PNPACPI whilte list and convert the drivers to
  platform bus drivers, for the devices that are not PNP devices in nature.
   which will be done later.

Known Issue:
PNP bus does not check the device resources when adding a new PNP device,
while Platform bus does by invoking insert_resource() in platform_device_add().
This results in failure when creating platform device node for some ACPI
device objects in case there is resource conflict.
In my desktop, I can see that
Creating PNP0C02:02 fails because its resource (IO: 0x72 ~ 0x7f)
conflicts with "0070-0077 : PNP0B00:00" (CMOS RTC).

Known Issue:
Currently, we can't enumerate devices with _CID PNP0C01/PNP0C02 to platform bus
because we need them in PNP bus in order to reserve mother board resources.

thanks,
rui


Changes in V7:
1. always registering the same scan handler, but with an optional NULL 
.attach() callback
   instead of registering a dummy handler.
2. avoid enumerting SPB slave devices by checking the SPB resources
   instead of introduing & setting & checking a flag in the SPB master device.

Changes in V6:
1. Patch re-ordering to avoid bisect breakage.
2. rework the patch for fixing the "redudent platform devices created for lpss
   slaves" issue according to Rafael' comments.

Changes in V5:
1. fix a problem that ACPI tries to enumerate lpss slaves to platform bus
2. rebased on 3.14 kernel

Changes in V4:
1. coding style cleanups, fix checkpatch warnings/errors.

Changes in V3:
1. rename enumerable_id to platform_id according to Rafael' suggestion.
2. drop two patches to handle devices with _CID PNP0C01/PNP0C02 enumeration
   because the code in drivers/pnp/system.c is still under discussion.
3. make cmos rtc scan handler return 1 so that the device will not be
   enumerated to platform bus.

Changes in V2:
1.move acpi pnp scan handler from drivers/pnp/pnpacpi/core.c to
  drivers/acpi/acpi-pnp.c, because the scan handler needs to be always built
  in to prevent platform devices from being created for those ACPI devices.
2.remove the __init tag for the acpi pnp scan handler because the scan
  handler is still needed after system initialization, for hotplug.
3.introduce enumerable_id flag for devices that can be enumerated to platform
  bus.
4.introduce excluded id list for creating platform devices, because some
  devices have _HID but they will never be associated with a platform driver.
5.introduce dummy lpss/container/memory_hotplug scan handler to prevent
  platform devices from being created for those ACPI device objects.

--------
Zhang Rui (11):
  ACPI: introduce .match() callback for ACPI scan handler
  PNPACPI: use whilte list for pnpacpi device enumeration
  ACPI: remove ids that does not comply with the ACPI PNP id rule
  ACPI: remove unsupported serial PNP ids from acpi pnp scan handler id lsit
  ACPI: allow scan handlers without .attach() callback
  ACPI: always register container scan handler even if 
CONFIG_ACPI_CONTAINER is cleared
  ACPI: always register memory hotplug scan handler even if 
CONFIG_ACPI_HOTPLUG_MEMORY is cleared
  ACPI: always register memory hotplug scan handler even if 
CONFIG_X86_INTEL_LPSS is cleared
  ACPI: introduce platform_id flag
  ACPI: use platform bus as the default bus for _HID enumeration
  ACPI: introduce acpi platform exclude id list

 drivers/acpi/Makefile  |   7 ++--
 drivers/acpi/acpi_cmos_rt

[PATCH V7 01/11] ACPI: introduce .match() callback for ACPI scan handler

[Zhang Rui]

Currently, ACPI scan handler uses strcmp() to match device ids
and scan handler ids.

When converting PNPACPI enumeration into a scan handler, which I will do
later in this patch set, the current code becomes not flexible enough
because ACPI pnp scan handler requires wildcase and case insensitive support.

Thus a per scan handler .match() callback is introduced in this patch,
so that specified scan handler can have more flexible matching mechanism
by introduce its own .match() callback.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/scan.c | 17 +++--
 include/acpi/acpi_bus.h |  1 +
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 7efe546..e46e51c 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1974,14 +1974,19 @@ static bool acpi_scan_handler_matching(struct 
acpi_scan_handler *handler,
const struct acpi_device_id *devid;
 
for (devid = handler->ids; devid->id[0]; devid++)
-   if (!strcmp((char *)devid->id, idstr)) {
-   if (matchid)
-   *matchid = devid;
-
-   return true;
-   }
+   if (handler->match) {
+   if (handler->match(idstr, (char *)devid->id))
+   goto success;
+   } else
+   if (!strcmp((char *)devid->id, idstr))
+   goto success;
 
return false;
+
+success:
+   if (matchid)
+   *matchid = devid;
+   return true;
 }
 
 static struct acpi_scan_handler *acpi_scan_match_handler(char *idstr,
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 84a2e29..ba679af 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -131,6 +131,7 @@ static inline struct acpi_hotplug_profile 
*to_acpi_hotplug_profile(
 struct acpi_scan_handler {
const struct acpi_device_id *ids;
struct list_head list_node;
+   int (*match)(char *devid, char *handler_id);
int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
void (*detach)(struct acpi_device *dev);
void (*bind)(struct device *phys_dev);
-- 
1.8.3.2

--
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 V6 09/11] ACPI: introduce flag .is_master_device

[Zhang Rui]

On Thu, 2014-05-22 at 11:51 +0300, Mika Westerberg wrote:
> On Wed, May 21, 2014 at 10:43:07PM +0800, Zhang Rui wrote:
> > On 三, 2014-05-21 at 11:52 +0300, Mika Westerberg wrote:
> > > On Thu, May 15, 2014 at 02:44:14PM +0800, Zhang Rui wrote:
> > > > For some ACPI device objects, they represent master devices,
> > > > and their children devices are enumerated by bus controller drivers
> > > > for the buses they are on.
> > > > 
> > > > In this case, we do not want to enumerate their children devices to
> > > > platform bus explicitly in acpi scan code.
> > > > 
> > > > Thus a new flag .is_master_device is introduced in this patch.
> > > > 
> > > > For devices with this flag set, we will not do default enumeration
> > > > for their children.
> > > 
> > > Is there any particular reason we would like to enumerate everything
> > > below the first device by default?
> > 
> > we do not enumerate everything below the first device by default, we
> > just enumerate all the devices with _HID.
> 
> OK.
> 
> > But if a device has _HID and it is enumerated by its parents to a
> > separate bus, we need this flag set for its parent.
> 
> How about checking if the device has *SerialBus() connector and in such
> case skip the device (given that it is not listed in a special list,
> like acpi_platform_device_ids)?

This sounds like a good idea.
I think we can just ignore devices with ACPI_RESOURCE_TYPE_SERIAL_BUS
resources, and this can be done in drivers/acpi/scan.c for all _HID
devices w/o handler attached, right?

thanks,
rui

--
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 V6 09/11] ACPI: introduce flag .is_master_device

[Zhang Rui]

On Thu, 2014-05-22 at 11:51 +0300, Mika Westerberg wrote:
 On Wed, May 21, 2014 at 10:43:07PM +0800, Zhang Rui wrote:
  On 三, 2014-05-21 at 11:52 +0300, Mika Westerberg wrote:
   On Thu, May 15, 2014 at 02:44:14PM +0800, Zhang Rui wrote:
For some ACPI device objects, they represent master devices,
and their children devices are enumerated by bus controller drivers
for the buses they are on.

In this case, we do not want to enumerate their children devices to
platform bus explicitly in acpi scan code.

Thus a new flag .is_master_device is introduced in this patch.

For devices with this flag set, we will not do default enumeration
for their children.
   
   Is there any particular reason we would like to enumerate everything
   below the first device by default?
  
  we do not enumerate everything below the first device by default, we
  just enumerate all the devices with _HID.
 
 OK.
 
  But if a device has _HID and it is enumerated by its parents to a
  separate bus, we need this flag set for its parent.
 
 How about checking if the device has *SerialBus() connector and in such
 case skip the device (given that it is not listed in a special list,
 like acpi_platform_device_ids)?

This sounds like a good idea.
I think we can just ignore devices with ACPI_RESOURCE_TYPE_SERIAL_BUS
resources, and this can be done in drivers/acpi/scan.c for all _HID
devices w/o handler attached, right?

thanks,
rui

--
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 V7 00/11] ACPI: ACPI enumeration rework

[Zhang Rui]

Hi, all,

Currently, PNP bus is used as the default bus for for enumerating ACPI
devices with _HID/_CID.
For a device that needs to be enumerated to platform bus, we need to add
its id string to the platform scan handler white list explicitly.

This becomes a problem as more and more _HID devices need to be
enumerated to platform bus nowadays, thus the list is continuously growing.

So, a solution that uses platform bus for _HID enumeration by default
is preferred.

In order to do this, this patch set
First (Patch 1~4), changes the way of enumerating PNP devices.
We introduce a white list to create PNP devices instead. The white list contains
all the pnp_device_id strings in all the pnp drivers, thus this change is
transparent to PNP core and all the PNP drivers.
Second (Patch 5~11), changes the code to enumerate ACPI _HID devices to platform
bus by default.

Tis patch set has been tested on my desktop machine,
and a TOSHIBA PORTEGE Z830 ultrabook.

Clarification:
Although it seems that we are introducing a much bigger white list to replace
a small one, the benefit is that
1. without the patch, the acpi_platform scan handler white list is
   continuously growing.
2. with the patch set, the PNPACPI scan handler white list will become
   smaller and smaller by
   a) remove the ids from the PNPACPI white list, for the devices
  that are never enumerated via ACPI
   b) remove the ids from the PNPACPI whilte list and convert the drivers to
  platform bus drivers, for the devices that are not PNP devices in nature.
   which will be done later.

Known Issue:
PNP bus does not check the device resources when adding a new PNP device,
while Platform bus does by invoking insert_resource() in platform_device_add().
This results in failure when creating platform device node for some ACPI
device objects in case there is resource conflict.
In my desktop, I can see that
Creating PNP0C02:02 fails because its resource (IO: 0x72 ~ 0x7f)
conflicts with 0070-0077 : PNP0B00:00 (CMOS RTC).

Known Issue:
Currently, we can't enumerate devices with _CID PNP0C01/PNP0C02 to platform bus
because we need them in PNP bus in order to reserve mother board resources.

thanks,
rui


Changes in V7:
1. always registering the same scan handler, but with an optional NULL 
.attach() callback
   instead of registering a dummy handler.
2. avoid enumerting SPB slave devices by checking the SPB resources
   instead of introduing  setting  checking a flag in the SPB master device.

Changes in V6:
1. Patch re-ordering to avoid bisect breakage.
2. rework the patch for fixing the redudent platform devices created for lpss
   slaves issue according to Rafael' comments.

Changes in V5:
1. fix a problem that ACPI tries to enumerate lpss slaves to platform bus
2. rebased on 3.14 kernel

Changes in V4:
1. coding style cleanups, fix checkpatch warnings/errors.

Changes in V3:
1. rename enumerable_id to platform_id according to Rafael' suggestion.
2. drop two patches to handle devices with _CID PNP0C01/PNP0C02 enumeration
   because the code in drivers/pnp/system.c is still under discussion.
3. make cmos rtc scan handler return 1 so that the device will not be
   enumerated to platform bus.

Changes in V2:
1.move acpi pnp scan handler from drivers/pnp/pnpacpi/core.c to
  drivers/acpi/acpi-pnp.c, because the scan handler needs to be always built
  in to prevent platform devices from being created for those ACPI devices.
2.remove the __init tag for the acpi pnp scan handler because the scan
  handler is still needed after system initialization, for hotplug.
3.introduce enumerable_id flag for devices that can be enumerated to platform
  bus.
4.introduce excluded id list for creating platform devices, because some
  devices have _HID but they will never be associated with a platform driver.
5.introduce dummy lpss/container/memory_hotplug scan handler to prevent
  platform devices from being created for those ACPI device objects.


Zhang Rui (11):
  ACPI: introduce .match() callback for ACPI scan handler
  PNPACPI: use whilte list for pnpacpi device enumeration
  ACPI: remove ids that does not comply with the ACPI PNP id rule
  ACPI: remove unsupported serial PNP ids from acpi pnp scan handler id lsit
  ACPI: allow scan handlers without .attach() callback
  ACPI: always register container scan handler even if 
CONFIG_ACPI_CONTAINER is cleared
  ACPI: always register memory hotplug scan handler even if 
CONFIG_ACPI_HOTPLUG_MEMORY is cleared
  ACPI: always register memory hotplug scan handler even if 
CONFIG_X86_INTEL_LPSS is cleared
  ACPI: introduce platform_id flag
  ACPI: use platform bus as the default bus for _HID enumeration
  ACPI: introduce acpi platform exclude id list

 drivers/acpi/Makefile  |   7 ++--
 drivers/acpi/acpi_cmos_rtc.c   |   2 +-
 drivers/acpi/acpi_lpss.c

[PATCH V7 01/11] ACPI: introduce .match() callback for ACPI scan handler

[Zhang Rui]

Currently, ACPI scan handler uses strcmp() to match device ids
and scan handler ids.

When converting PNPACPI enumeration into a scan handler, which I will do
later in this patch set, the current code becomes not flexible enough
because ACPI pnp scan handler requires wildcase and case insensitive support.

Thus a per scan handler .match() callback is introduced in this patch,
so that specified scan handler can have more flexible matching mechanism
by introduce its own .match() callback.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/scan.c | 17 +++--
 include/acpi/acpi_bus.h |  1 +
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 7efe546..e46e51c 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1974,14 +1974,19 @@ static bool acpi_scan_handler_matching(struct 
acpi_scan_handler *handler,
const struct acpi_device_id *devid;
 
for (devid = handler-ids; devid-id[0]; devid++)
-   if (!strcmp((char *)devid-id, idstr)) {
-   if (matchid)
-   *matchid = devid;
-
-   return true;
-   }
+   if (handler-match) {
+   if (handler-match(idstr, (char *)devid-id))
+   goto success;
+   } else
+   if (!strcmp((char *)devid-id, idstr))
+   goto success;
 
return false;
+
+success:
+   if (matchid)
+   *matchid = devid;
+   return true;
 }
 
 static struct acpi_scan_handler *acpi_scan_match_handler(char *idstr,
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 84a2e29..ba679af 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -131,6 +131,7 @@ static inline struct acpi_hotplug_profile 
*to_acpi_hotplug_profile(
 struct acpi_scan_handler {
const struct acpi_device_id *ids;
struct list_head list_node;
+   int (*match)(char *devid, char *handler_id);
int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
void (*detach)(struct acpi_device *dev);
void (*bind)(struct device *phys_dev);
-- 
1.8.3.2

--
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 V7 02/11] PNPACPI: use whilte list for pnpacpi device enumeration

[Zhang Rui]

ACPI can be used to enumerate PNP devices, but the code does not
handle this in a good manner.

Currently, if an ACPI device
1. has _CRS method,
2. has an identifications of
   three capital charactors followed by four hex numbers,
3. is not in the excluded id list,
it is enumerated to PNP bus.

So actually, PNP bus is used as the default bus for enumerating _HID devices.

But, nowadays, more and more _HID devices are needed to be enumerate to
platform bus instead. And a white list is used for those devices to avoid
overlapping with PNP bus.
The problem is that this list is continuously growing.

So, a solution that uses platform bus as the default bus for _HID enumeration
is preferred.
In order to do this, this patch changes the way of enumerating PNP devices.
As the first step, we use a white list (scan handler) to create PNP devices
instead. This white list contains all the pnp_device_id strings in all the pnp
drivers, thus this change is transparent to PNP core and all the PNP drivers.

Note: I just grep all the id strings in all pnp_device_id instances and
  copy them to the new white list, with a few changes to the comments
  only, to follow the format of:

  /* driver name, or file name if not a PNP driver */
  {id-string}, /* optional comments for the id-string */
  ...

Note: the PNPACPI devices are created in two step,
  1. mark the PNPACPI devices by the acpi pnp scan handler.
  2. create the PNPACPI devices in PNPACPI code in a fs_initcall()
  In this case, if PNP/PNPACPI is not set or pnpacpi=off kernel option
  is used, the acpi pnp scan handler is still there, to prevent those
  PNPACPI devices from being created to platform bus.

Note: For CMOS RTC devices, the acpi pnp scan handler does not work because
  there is already a cmos rtc scan handler installed, thus we need to
  check those devices and enumerate them to PNP bus explicitly.
  Plus, the cmos rtc scan handler needs to return 1 so that it will not
  be enumerated to platform bus.

TODO: Reduce this PNPACPI white list by
  1. remove the ids for the devices that are never enumerated via ACPI
  2. remove the ids and convert the drivers to platform bus drivers
 for the devices that are not PNP devices in nature.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/Makefile|   1 +
 drivers/acpi/acpi_cmos_rtc.c |   2 +-
 drivers/acpi/acpi_pnp.c  | 388 +++
 drivers/acpi/internal.h  |   1 +
 drivers/acpi/scan.c  |   1 +
 drivers/pnp/pnpacpi/core.c   |  28 +---
 include/linux/acpi.h |   2 +
 7 files changed, 398 insertions(+), 25 deletions(-)
 create mode 100644 drivers/acpi/acpi_pnp.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..9a43893 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,6 +41,7 @@ acpi-$(CONFIG_ACPI_DOCK)  += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
 acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
 acpi-y += acpi_platform.o
+acpi-y += acpi_pnp.o
 acpi-y += power.o
 acpi-y += event.o
 acpi-y += sysfs.o
diff --git a/drivers/acpi/acpi_cmos_rtc.c b/drivers/acpi/acpi_cmos_rtc.c
index 961b45d..2da8660 100644
--- a/drivers/acpi/acpi_cmos_rtc.c
+++ b/drivers/acpi/acpi_cmos_rtc.c
@@ -68,7 +68,7 @@ static int acpi_install_cmos_rtc_space_handler(struct 
acpi_device *adev,
return -ENODEV;
}
 
-   return 0;
+   return 1;
 }
 
 static void acpi_remove_cmos_rtc_space_handler(struct acpi_device *adev)
diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
new file mode 100644
index 000..57d14ed
--- /dev/null
+++ b/drivers/acpi/acpi_pnp.c
@@ -0,0 +1,388 @@
+/*
+ * ACPI support for PNP bus type
+ *
+ * Copyright (C) 2014, Intel Corporation
+ * Authors: Zhang Rui rui.zh...@intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/acpi.h
+#include linux/module.h
+
+static const struct acpi_device_id acpi_pnp_device_ids[] = {
+   /* pata_isapnp */
+   {PNP0600},/* Generic ESDI/IDE/ATA compatible hard disk 
controller */
+   /* floppy */
+   {PNP0700},
+   /* ipmi_si */
+   {IPI0001},
+   /* tpm_inf_pnp */
+   {IFX0101},/* Infineon TPMs */
+   {IFX0102},/* Infineon TPMs */
+   /*tpm_tis */
+   {PNP0C31},/* TPM */
+   {ATM1200},/* Atmel */
+   {IFX0102},/* Infineon */
+   {BCM0101},/* Broadcom */
+   {BCM0102},/* Broadcom */
+   {NSC1200},/* National */
+   {ICO0102},/* Intel */
+   /* ide

[PATCH V7 05/11] ACPI: allow scan handlers without .attach() callback

[Zhang Rui]

Devices that can be attached to scan handlers, are kind of different from
the others, because they are known that some special actions should be taken.

But we do not mark this difference when the configurable scan handlers
are compiled out. This is harmless currently, but it will be when
we want to take some common actions to the other non-special devices,
which will be done in a later patch.

This patch makes .attach() of the acpi scan handler optional.
So that the configurable scan handlers can provide NULL .attach() callback
when not supported.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/scan.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index c82ab73..e9c2f6f 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -84,7 +84,7 @@ EXPORT_SYMBOL_GPL(acpi_initialize_hp_context);
 
 int acpi_scan_add_handler(struct acpi_scan_handler *handler)
 {
-   if (!handler || !handler-attach)
+   if (!handler)
return -EINVAL;
 
list_add_tail(handler-list_node, acpi_scan_handlers_list);
@@ -2066,6 +2066,12 @@ static acpi_status acpi_bus_check_add(acpi_handle 
handle, u32 lvl_not_used,
return AE_OK;
 }
 
+static int acpi_scan_handler_dummy_attach(struct acpi_device *device,
+   const struct acpi_device_id *devid)
+{
+   return 1;
+}
+
 static int acpi_scan_attach_handler(struct acpi_device *device)
 {
struct acpi_hardware_id *hwid;
@@ -2078,7 +2084,10 @@ static int acpi_scan_attach_handler(struct acpi_device 
*device)
handler = acpi_scan_match_handler(hwid-id, devid);
if (handler) {
device-handler = handler;
-   ret = handler-attach(device, devid);
+   if (handler-attach)
+   ret = handler-attach(device, devid);
+   else
+   ret = acpi_scan_handler_dummy_attach(device, 
devid);
if (ret  0)
break;
 
-- 
1.8.3.2

--
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 V7 06/11] ACPI: always register container scan handler even if CONFIG_ACPI_CONTAINER is cleared

[Zhang Rui]

The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.

Fix this problem for container devices by always registering the
container scan handler, but with meaningful callbacks
only when CONFIG_ACPI_CONTAINER is set.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/Makefile|  2 +-
 drivers/acpi/container.c | 18 --
 drivers/acpi/internal.h  |  4 
 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9a43893..5611a07 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -63,7 +63,7 @@ obj-$(CONFIG_ACPI_FAN)+= fan.o
 obj-$(CONFIG_ACPI_VIDEO)   += video.o
 obj-$(CONFIG_ACPI_PCI_SLOT)+= pci_slot.o
 obj-$(CONFIG_ACPI_PROCESSOR)   += processor.o
-obj-$(CONFIG_ACPI_CONTAINER)   += container.o
+obj-y  += container.o
 obj-$(CONFIG_ACPI_THERMAL) += thermal.o
 obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
 obj-$(CONFIG_ACPI_BATTERY) += battery.o
diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
index 63119d0..b78f52e 100644
--- a/drivers/acpi/container.c
+++ b/drivers/acpi/container.c
@@ -41,6 +41,8 @@ static const struct acpi_device_id container_device_ids[] = {
{, 0},
 };
 
+#ifdef CONFIG_ACPI_CONTAINER
+
 static int acpi_container_offline(struct container_dev *cdev)
 {
struct acpi_device *adev = ACPI_COMPANION(cdev-dev);
@@ -97,17 +99,21 @@ static void container_device_detach(struct acpi_device 
*adev)
device_unregister(dev);
 }
 
+#endif /* CONFIG_ACPI_CONTAINER */
+
 static struct acpi_scan_handler container_handler = {
.ids = container_device_ids,
-   .attach = container_device_attach,
-   .detach = container_device_detach,
-   .hotplug = {
-   .enabled = true,
-   .demand_offline = true,
-   },
 };
 
 void __init acpi_container_init(void)
 {
+#ifdef CONFIG_ACPI_CONTAINER
+   container_handler.attach = container_device_attach;
+   container_handler.detach = container_device_detach;
+   container_handler.hotplug.enabled = true;
+   container_handler.hotplug.demand_offline = true;
acpi_scan_add_handler_with_hotplug(container_handler, container);
+#else
+   acpi_scan_add_handler(container_handler);
+#endif /* CONFIG_ACPI_CONTAINER */
 }
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 3a12866..499908e 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -32,11 +32,7 @@ void acpi_processor_init(void);
 void acpi_platform_init(void);
 void acpi_pnp_init(void);
 int acpi_sysfs_init(void);
-#ifdef CONFIG_ACPI_CONTAINER
 void acpi_container_init(void);
-#else
-static inline void acpi_container_init(void) {}
-#endif
 #ifdef CONFIG_ACPI_DOCK
 void register_dock_dependent_device(struct acpi_device *adev,
acpi_handle dshandle);
-- 
1.8.3.2

--
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 V7 07/11] ACPI: always register memory hotplug scan handler even if CONFIG_ACPI_HOTPLUG_MEMORY is cleared

[Zhang Rui]

The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.

Fix this problem for memory hotplug devices by always register the
memery hotplug scan handler, but with meaningful callbacks
only when CONFIG_ACPI_HOTPLUG_MEMORY is set.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/Makefile  |  2 +-
 drivers/acpi/acpi_memhotplug.c | 46 ++
 drivers/acpi/internal.h|  6 +-
 3 files changed, 26 insertions(+), 28 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 5611a07..171efc2 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -65,7 +65,7 @@ obj-$(CONFIG_ACPI_PCI_SLOT)   += pci_slot.o
 obj-$(CONFIG_ACPI_PROCESSOR)   += processor.o
 obj-y  += container.o
 obj-$(CONFIG_ACPI_THERMAL) += thermal.o
-obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
+obj-y  += acpi_memhotplug.o
 obj-$(CONFIG_ACPI_BATTERY) += battery.o
 obj-$(CONFIG_ACPI_SBS) += sbshc.o
 obj-$(CONFIG_ACPI_SBS) += sbs.o
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index b67be85..c54f824 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -44,15 +44,6 @@
 
 ACPI_MODULE_NAME(acpi_memhotplug);
 
-/* Memory Device States */
-#define MEMORY_INVALID_STATE   0
-#define MEMORY_POWER_ON_STATE  1
-#define MEMORY_POWER_OFF_STATE 2
-
-static int acpi_memory_device_add(struct acpi_device *device,
- const struct acpi_device_id *not_used);
-static void acpi_memory_device_remove(struct acpi_device *device);
-
 static const struct acpi_device_id memory_device_ids[] = {
{ACPI_MEMORY_DEVICE_HID, 0},
{, 0},
@@ -60,13 +51,15 @@ static const struct acpi_device_id memory_device_ids[] = {
 
 static struct acpi_scan_handler memory_device_handler = {
.ids = memory_device_ids,
-   .attach = acpi_memory_device_add,
-   .detach = acpi_memory_device_remove,
-   .hotplug = {
-   .enabled = true,
-   },
 };
 
+#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
+
+/* Memory Device States */
+#define MEMORY_INVALID_STATE   0
+#define MEMORY_POWER_ON_STATE  1
+#define MEMORY_POWER_OFF_STATE 2
+
 struct acpi_memory_info {
struct list_head list;
u64 start_addr; /* Memory Range start physical addr */
@@ -362,17 +355,26 @@ static void acpi_memory_device_remove(struct acpi_device 
*device)
 
 static bool __initdata acpi_no_memhotplug;
 
-void __init acpi_memory_hotplug_init(void)
-{
-   if (acpi_no_memhotplug)
-   return;
-
-   acpi_scan_add_handler_with_hotplug(memory_device_handler, memory);
-}
-
 static int __init disable_acpi_memory_hotplug(char *str)
 {
acpi_no_memhotplug = true;
return 1;
 }
 __setup(acpi_no_memhotplug, disable_acpi_memory_hotplug);
+
+#endif
+
+void __init acpi_memory_hotplug_init(void)
+{
+#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
+   if (!acpi_no_memhotplug) {
+   memory_device_handler.attach = acpi_memory_device_add;
+   memory_device_handler.detach = acpi_memory_device_remove;
+   memory_device_handler.hotplug.enabled = true;
+   acpi_scan_add_handler_with_hotplug(memory_device_handler,
+   memory);
+   return;
+   }
+#endif
+   acpi_scan_add_handler(memory_device_handler);
+}
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 499908e..4a9e999 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -33,6 +33,7 @@ void acpi_platform_init(void);
 void acpi_pnp_init(void);
 int acpi_sysfs_init(void);
 void acpi_container_init(void);
+void acpi_memory_hotplug_init(void);
 #ifdef CONFIG_ACPI_DOCK
 void register_dock_dependent_device(struct acpi_device *adev,
acpi_handle dshandle);
@@ -44,11 +45,6 @@ static inline void register_dock_dependent_device(struct 
acpi_device *adev,
 static inline int dock_notify(struct acpi_device *adev, u32 event) { return 
-ENODEV; }
 static inline void acpi_dock_add(struct acpi_device *adev) {}
 #endif
-#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
-void acpi_memory_hotplug_init(void);
-#else
-static inline void acpi_memory_hotplug_init(void) {}
-#endif
 #ifdef CONFIG_X86
 void acpi_cmos_rtc_init(void);
 #else
-- 
1.8.3.2

--
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 V7 10/11] ACPI: use platform bus as the default bus for _HID enumeration

[Zhang Rui]

Because of the growing demand for enumerating ACPI devices to
platform bus, this patch changes the code to enumerate ACPI
devices to platform bus by default, if the device
1. has _HID.
2. does not have a scan handler attached.
3. is not SPB slave device, which should be enumerated by its parent.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/acpi_platform.c | 28 
 drivers/acpi/scan.c  | 43 ++-
 2 files changed, 42 insertions(+), 29 deletions(-)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index dbfe49e..33376a9 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -22,24 +22,6 @@
 
 ACPI_MODULE_NAME(platform);
 
-/*
- * The following ACPI IDs are known to be suitable for representing as
- * platform devices.
- */
-static const struct acpi_device_id acpi_platform_device_ids[] = {
-
-   { PNP0D40 },
-   { ACPI0003 },
-   { VPC2004 },
-   { BCM4752 },
-
-   /* Intel Smart Sound Technology */
-   { INT33C8 },
-   { 80860F28 },
-
-   { }
-};
-
 /**
  * acpi_create_platform_device - Create platform device for ACPI device node
  * @adev: ACPI device node to create a platform device for.
@@ -125,13 +107,3 @@ int acpi_create_platform_device(struct acpi_device *adev,
kfree(resources);
return 1;
 }
-
-static struct acpi_scan_handler platform_handler = {
-   .ids = acpi_platform_device_ids,
-   .attach = acpi_create_platform_device,
-};
-
-void __init acpi_platform_init(void)
-{
-   acpi_scan_add_handler(platform_handler);
-}
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 6d50916..c061284 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2079,6 +2079,45 @@ static int acpi_scan_handler_dummy_attach(struct 
acpi_device *device,
return 1;
 }
 
+static int acpi_check_spb_slave(struct acpi_resource *ares, void *data)
+{
+   int *is_spb_slave = data;
+
+   if (ares-type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
+   *is_spb_slave = 1;
+   /* no need to do more checking */
+   return -1;
+   }
+   return 1;
+}
+
+static void acpi_do_default_enumeration(struct acpi_device *device)
+{
+   struct list_head resource_list;
+   int is_spb_slave = 0;
+
+   /* Do not do enumeration for device object w/o platform_id */
+   if (!device-pnp.type.platform_id)
+   return;
+
+   /* Do not do enumeration for device object with scan handler attached */
+   if (device-handler)
+   return;
+
+   /*
+* Do not do enemeration for SPB slaves
+* as they will be enuerated by their parents
+*/
+   INIT_LIST_HEAD(resource_list);
+   acpi_dev_get_resources(device, resource_list,
+   acpi_check_spb_slave, is_spb_slave);
+   acpi_dev_free_resource_list(resource_list);
+   if (is_spb_slave)
+   return;
+
+   acpi_create_platform_device(device, NULL);
+}
+
 static int acpi_scan_attach_handler(struct acpi_device *device)
 {
struct acpi_hardware_id *hwid;
@@ -2103,6 +2142,9 @@ static int acpi_scan_attach_handler(struct acpi_device 
*device)
break;
}
}
+
+   acpi_do_default_enumeration(device);
+
return ret;
 }
 
@@ -2262,7 +2304,6 @@ int __init acpi_scan_init(void)
acpi_pci_root_init();
acpi_pci_link_init();
acpi_processor_init();
-   acpi_platform_init();
acpi_lpss_init();
acpi_cmos_rtc_init();
acpi_container_init();
-- 
1.8.3.2

--
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 V7 11/11] ACPI: introduce acpi platform exclude id list

[Zhang Rui]

For ACPI PIC (PNP), Timer (PNP0100) and DMA controller (PNP0200)
device objects, although they have _HID control method, but they
should not be enumerated to platform bus, because there will never be
any platform drivers for them.

Thus an exclude id list is introduced in this patch to prevent
those platform device nodes from being created.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/acpi_platform.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 33376a9..db89480 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -22,6 +22,18 @@
 
 ACPI_MODULE_NAME(platform);
 
+static const struct acpi_device_id excluded_id_list[] = {
+   {PNP, 0}, /* PIC */
+   {PNP0100, 0}, /* Timer */
+   {PNP0200, 0}, /* AT DMA Controller */
+   {, 0},
+};
+
+static bool is_exclusive_device(struct acpi_device *dev)
+{
+   return !acpi_match_device_ids(dev, excluded_id_list);
+}
+
 /**
  * acpi_create_platform_device - Create platform device for ACPI device node
  * @adev: ACPI device node to create a platform device for.
@@ -48,6 +60,9 @@ int acpi_create_platform_device(struct acpi_device *adev,
if (adev-physical_node_count)
return 0;
 
+   if (is_exclusive_device(adev))
+   return 0;
+
INIT_LIST_HEAD(resource_list);
count = acpi_dev_get_resources(adev, resource_list, NULL, NULL);
if (count  0) {
-- 
1.8.3.2

--
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 V7 09/11] ACPI: introduce platform_id flag

[Zhang Rui]

Only certain kind of ACPI device objects can be enumerated to platform bus.
These ACPI device objects include
1. ACPI device objects that have _HID control method.
2. some ACPI device objects that have Linux specified HID strings.

In order to distinguish those device objects from the others, a new flag
platform_id and a new function acpi_add_platform_id() are introduced
in this patch.

Currently, only devices with _HID method have this flag set.
If you want platform devices to be created for device objects without _HID,
use acpi_add_platform_id() when adding artificial Linux-specific ID strings
to them.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/scan.c | 9 -
 include/acpi/acpi_bus.h | 3 ++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index e9c2f6f..6d50916 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1730,6 +1730,13 @@ static void acpi_add_id(struct acpi_device_pnp *pnp, 
const char *dev_id)
pnp-type.hardware_id = 1;
 }
 
+static void acpi_add_platform_id(struct acpi_device_pnp *pnp,
+const char *dev_id)
+{
+   acpi_add_id(pnp, dev_id);
+   pnp-type.platform_id = 1;
+}
+
 /*
  * Old IBM workstations have a DSDT bug wherein the SMBus object
  * lacks the SMBUS01 HID and the methods do not have the necessary _
@@ -1794,7 +1801,7 @@ static void acpi_set_pnp_ids(acpi_handle handle, struct 
acpi_device_pnp *pnp,
}
 
if (info-valid  ACPI_VALID_HID)
-   acpi_add_id(pnp, info-hardware_id.string);
+   acpi_add_platform_id(pnp, info-hardware_id.string);
if (info-valid  ACPI_VALID_CID) {
cid_list = info-compatible_id_list;
for (i = 0; i  cid_list-count; i++)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index ba679af..ec92ad3 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -233,7 +233,8 @@ struct acpi_hardware_id {
 struct acpi_pnp_type {
u32 hardware_id:1;
u32 bus_address:1;
-   u32 reserved:30;
+   u32 platform_id:1;
+   u32 reserved:29;
 };
 
 struct acpi_device_pnp {
-- 
1.8.3.2

--
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 V7 08/11] ACPI: always register memory hotplug scan handler even if CONFIG_X86_INTEL_LPSS is cleared

[Zhang Rui]

The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.

Fix this problem for lpss devices by always register the lpss scan handler,
but with meaningful callbacks only when CONFIG_X86_INTEL_LPSS is set.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/Makefile|  2 +-
 drivers/acpi/acpi_lpss.c | 63 ++--
 drivers/acpi/internal.h  |  4 ---
 3 files changed, 41 insertions(+), 28 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 171efc2..605eff7 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -39,7 +39,7 @@ acpi-y+= processor_core.o
 acpi-y += ec.o
 acpi-$(CONFIG_ACPI_DOCK)   += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
-acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
+acpi-y += acpi_lpss.o
 acpi-y += acpi_platform.o
 acpi-y += acpi_pnp.o
 acpi-y += power.o
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 69e29f4..bb5b3f2 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -24,6 +24,8 @@
 
 ACPI_MODULE_NAME(acpi_lpss);
 
+#ifdef CONFIG_X86_INTEL_LPSS
+
 #define LPSS_CLK_SIZE  0x04
 #define LPSS_LTR_SIZE  0x18
 
@@ -159,40 +161,50 @@ static struct lpss_device_desc byt_i2c_dev_desc = {
.shared_clock = i2c_clock,
 };
 
+#define LPSS_PTR(desc) ((unsigned long)desc)
+
+#else
+
+#define LPSS_PTR(desc) 0
+
+#endif
+
 static const struct acpi_device_id acpi_lpss_device_ids[] = {
/* Generic LPSS devices */
-   { INTL9C60, (unsigned long)lpss_dma_desc },
+   { INTL9C60, LPSS_PTR(lpss_dma_desc) },
 
/* Lynxpoint LPSS devices */
-   { INT33C0, (unsigned long)lpt_dev_desc },
-   { INT33C1, (unsigned long)lpt_dev_desc },
-   { INT33C2, (unsigned long)lpt_dev_desc },
-   { INT33C3, (unsigned long)lpt_dev_desc },
-   { INT33C4, (unsigned long)lpt_uart_dev_desc },
-   { INT33C5, (unsigned long)lpt_uart_dev_desc },
-   { INT33C6, (unsigned long)lpt_sdio_dev_desc },
+   { INT33C0, LPSS_PTR(lpt_dev_desc) },
+   { INT33C1, LPSS_PTR(lpt_dev_desc) },
+   { INT33C2, LPSS_PTR(lpt_dev_desc) },
+   { INT33C3, LPSS_PTR(lpt_dev_desc) },
+   { INT33C4, LPSS_PTR(lpt_uart_dev_desc) },
+   { INT33C5, LPSS_PTR(lpt_uart_dev_desc) },
+   { INT33C6, LPSS_PTR(lpt_sdio_dev_desc) },
{ INT33C7, },
 
/* BayTrail LPSS devices */
-   { 80860F09, (unsigned long)byt_pwm_dev_desc },
-   { 80860F0A, (unsigned long)byt_uart_dev_desc },
-   { 80860F0E, (unsigned long)byt_spi_dev_desc },
-   { 80860F14, (unsigned long)byt_sdio_dev_desc },
-   { 80860F41, (unsigned long)byt_i2c_dev_desc },
+   { 80860F09, LPSS_PTR(byt_pwm_dev_desc) },
+   { 80860F0A, LPSS_PTR(byt_uart_dev_desc) },
+   { 80860F0E, LPSS_PTR(byt_spi_dev_desc) },
+   { 80860F14, LPSS_PTR(byt_sdio_dev_desc) },
+   { 80860F41, LPSS_PTR(byt_i2c_dev_desc) },
{ INT33B2, },
 
-   { INT3430, (unsigned long)lpt_dev_desc },
-   { INT3431, (unsigned long)lpt_dev_desc },
-   { INT3432, (unsigned long)lpt_dev_desc },
-   { INT3433, (unsigned long)lpt_dev_desc },
-   { INT3434, (unsigned long)lpt_uart_dev_desc },
-   { INT3435, (unsigned long)lpt_uart_dev_desc },
-   { INT3436, (unsigned long)lpt_sdio_dev_desc },
+   { INT3430, LPSS_PTR(lpt_dev_desc) },
+   { INT3431, LPSS_PTR(lpt_dev_desc) },
+   { INT3432, LPSS_PTR(lpt_dev_desc) },
+   { INT3433, LPSS_PTR(lpt_dev_desc) },
+   { INT3434, LPSS_PTR(lpt_uart_dev_desc) },
+   { INT3435, LPSS_PTR(lpt_uart_dev_desc) },
+   { INT3436, LPSS_PTR(lpt_sdio_dev_desc) },
{ INT3437, },
 
{ }
 };
 
+#ifdef CONFIG_X86_INTEL_LPSS
+
 static int is_memory(struct acpi_resource *res, void *not_used)
 {
struct resource r;
@@ -503,18 +515,23 @@ static void acpi_lpss_unbind(struct device *dev)
 {
dev-power.set_latency_tolerance = NULL;
 }
+#endif /* CONFIG_X86_INTEL_LPSS */
 
 static struct acpi_scan_handler lpss_handler = {
.ids = acpi_lpss_device_ids,
-   .attach = acpi_lpss_create_device,
-   .bind = acpi_lpss_bind,
-   .unbind = acpi_lpss_unbind,
 };
 
 void __init acpi_lpss_init(void)
 {
+#ifdef CONFIG_X86_INTEL_LPSS
if (!lpt_clk_init()) {
bus_register_notifier(platform_bus_type, acpi_lpss_nb);
+   lpss_handler.attach = acpi_lpss_create_device;
+   lpss_handler.bind = acpi_lpss_bind;
+   lpss_handler.unbind = acpi_lpss_unbind

[PATCH V7 04/11] ACPI: remove unsupported serial PNP ids from acpi pnp scan handler id lsit

[Zhang Rui]

The serial pnp driver supports some unknown PNP modems (PNPCXXX/PNPDXXX)
by matching magic strings in the pnp device name or the pnp device card name.

ACPI enumerated PNP device neither supports pnp card, nor supports those magic
strings in its device name, which means this mechamism never works for ACPI
enumerated PNPCXXX/PNPDXXX devices.
So it is safe to remove those two ids from the ACPI pnp scan handler id list.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/acpi_pnp.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
index d206616..a563a27 100644
--- a/drivers/acpi/acpi_pnp.c
+++ b/drivers/acpi/acpi_pnp.c
@@ -300,8 +300,6 @@ static const struct acpi_device_id acpi_pnp_device_ids[] = {
{LTS0001},/* LG C1 EXPRESS DUAL (C1-PB11A3) touch screen 
(actually a FUJ02E6 in disguise) */
{WCI0003},/* Rockwell's (PORALiNK) 33600 INT PNP */
{WEC1022},/* Winbond CIR port, should not be probed. We 
should keep track of it to prevent the legacy serial driver from probing it */
-   {PNPCXXX},/* Unknown PnP modems */
-   {PNPDXXX},/* More unknown PnP modems */
/* scl200wdt */
{NSC0800},/* National Semiconductor PC87307/PC97307 
watchdog component */
/* mpu401 */
-- 
1.8.3.2

--
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 V7 03/11] ACPI: remove ids that does not comply with the ACPI PNP id rule

[Zhang Rui]

The acpi pnp scan handler id list just copies all the ids from all the
struct pnp_device_id instances, but some of them do not
comply with the ACPI PNP id rule (3 Alpha Charactors + 4 Hex numbers).

For those ids, the coressponding devices will never be enumerated
via ACPI, so it is safe to remove those ids from the PNPACPI white list.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/acpi_pnp.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
index 57d14ed..d206616 100644
--- a/drivers/acpi/acpi_pnp.c
+++ b/drivers/acpi/acpi_pnp.c
@@ -33,10 +33,6 @@ static const struct acpi_device_id acpi_pnp_device_ids[] = {
/* ide   */
{PNP0600},/* Generic ESDI/IDE/ATA compatible hard disk 
controller */
/* ns558 */
-   {@P@0001},/* ALS 100 */
-   {@P@0020},/* ALS 200 */
-   {@P@1001},/* ALS 100+ */
-   {@P@2001},/* ALS 120 */
{ASB16fd},/* AdLib NSC16 */
{AZT3001},/* AZT1008 */
{CDC0001},/* Opl3-SAx */
-- 
1.8.3.2

--
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 V7 02/11] PNPACPI: use whilte list for pnpacpi device enumeration

[Zhang Rui]

On Thu, 2014-05-22 at 12:14 -0600, Bjorn Helgaas wrote:
 white is misspelled in the subject line.  I mentioned this before.
 
oops, forgot to update, thanks for the reminder.

From a8e08d7a6e050f31cec069cc1704f21214b90566 Mon Sep 17 00:00:00 2001
From: Zhang Rui rui.zh...@intel.com
Date: Tue, 8 Apr 2014 00:06:49 +0800
Subject: [PATCH V7 02/11] PNPACPI: use white list for pnpacpi device
 enumeration

ACPI can be used to enumerate PNP devices, but the code does not
handle this in a good manner.

Currently, if an ACPI device
1. has _CRS method,
2. has an identifications of
   three capital charactors followed by four hex numbers,
3. is not in the excluded id list,
it is enumerated to PNP bus.

So actually, PNP bus is used as the default bus for enumerating _HID devices.

But, nowadays, more and more _HID devices are needed to be enumerate to
platform bus instead. And a white list is used for those devices to avoid
overlapping with PNP bus.
The problem is that this list is continuously growing.

So, a solution that uses platform bus as the default bus for _HID enumeration
is preferred.
In order to do this, this patch changes the way of enumerating PNP devices.
As the first step, we use a white list (scan handler) to create PNP devices
instead. This white list contains all the pnp_device_id strings in all the pnp
drivers, thus this change is transparent to PNP core and all the PNP drivers.

Note: I just grep all the id strings in all pnp_device_id instances and
  copy them to the new white list, with a few changes to the comments
  only, to follow the format of:

  /* driver name, or file name if not a PNP driver */
  {id-string}, /* optional comments for the id-string */
  ...

Note: the PNPACPI devices are created in two step,
  1. mark the PNPACPI devices by the acpi pnp scan handler.
  2. create the PNPACPI devices in PNPACPI code in a fs_initcall()
  In this case, if PNP/PNPACPI is not set or pnpacpi=off kernel option
  is used, the acpi pnp scan handler is still there, to prevent those
  PNPACPI devices from being created to platform bus.

Note: For CMOS RTC devices, the acpi pnp scan handler does not work because
  there is already a cmos rtc scan handler installed, thus we need to
  check those devices and enumerate them to PNP bus explicitly.
  Plus, the cmos rtc scan handler needs to return 1 so that it will not
  be enumerated to platform bus.

TODO: Reduce this PNPACPI white list by
  1. remove the ids for the devices that are never enumerated via ACPI
  2. remove the ids and convert the drivers to platform bus drivers
 for the devices that are not PNP devices in nature.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/Makefile|   1 +
 drivers/acpi/acpi_cmos_rtc.c |   2 +-
 drivers/acpi/acpi_pnp.c  | 388 +++
 drivers/acpi/internal.h  |   1 +
 drivers/acpi/scan.c  |   1 +
 drivers/pnp/pnpacpi/core.c   |  28 +---
 include/linux/acpi.h |   2 +
 7 files changed, 398 insertions(+), 25 deletions(-)
 create mode 100644 drivers/acpi/acpi_pnp.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..9a43893 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,6 +41,7 @@ acpi-$(CONFIG_ACPI_DOCK)  += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
 acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
 acpi-y += acpi_platform.o
+acpi-y += acpi_pnp.o
 acpi-y += power.o
 acpi-y += event.o
 acpi-y += sysfs.o
diff --git a/drivers/acpi/acpi_cmos_rtc.c b/drivers/acpi/acpi_cmos_rtc.c
index 961b45d..2da8660 100644
--- a/drivers/acpi/acpi_cmos_rtc.c
+++ b/drivers/acpi/acpi_cmos_rtc.c
@@ -68,7 +68,7 @@ static int acpi_install_cmos_rtc_space_handler(struct 
acpi_device *adev,
return -ENODEV;
}
 
-   return 0;
+   return 1;
 }
 
 static void acpi_remove_cmos_rtc_space_handler(struct acpi_device *adev)
diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
new file mode 100644
index 000..57d14ed
--- /dev/null
+++ b/drivers/acpi/acpi_pnp.c
@@ -0,0 +1,388 @@
+/*
+ * ACPI support for PNP bus type
+ *
+ * Copyright (C) 2014, Intel Corporation
+ * Authors: Zhang Rui rui.zh...@intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/acpi.h
+#include linux/module.h
+
+static const struct acpi_device_id acpi_pnp_device_ids[] = {
+   /* pata_isapnp */
+   {PNP0600},/* Generic ESDI/IDE/ATA compatible hard disk 
controller */
+   /* floppy */
+   {PNP0700},
+   /* ipmi_si */
+   {IPI0001},
+   /* tpm_inf_pnp */
+   {IFX0101},/* Infineon

Re: [PATCH V6 09/11] ACPI: introduce flag .is_master_device

[Zhang Rui]

On 三, 2014-05-21 at 13:10 +0200, Rafael J. Wysocki wrote:
> On Wednesday, May 21, 2014 11:52:07 AM Mika Westerberg wrote:
> > On Thu, May 15, 2014 at 02:44:14PM +0800, Zhang Rui wrote:
> > > For some ACPI device objects, they represent master devices,
> > > and their children devices are enumerated by bus controller drivers
> > > for the buses they are on.
> > > 
> > > In this case, we do not want to enumerate their children devices to
> > > platform bus explicitly in acpi scan code.
> > > 
> > > Thus a new flag .is_master_device is introduced in this patch.
> > > 
> > > For devices with this flag set, we will not do default enumeration
> > > for their children.
> > 
> > Is there any particular reason we would like to enumerate everything
> > below the first device by default?
> 
> Yes, there is.  Device objects without _ADR under the PCI host bridge.
> 
I'm confused. Mika, what do you mean by saying "first device"?

thanks,
rui
> Or we can skip the children under every *platform* device created by this by
> default and mark the ones where we want the children to be enumerated as
> platform devices too in a special way if needed.
> 
> I guess we could try that (that was the Rui's original idea IIRC).
> 
> Rafael
> 


--
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 V6 07/11] ACPI: introduce dummy lpss scan handler

[Zhang Rui]

On 三, 2014-05-21 at 11:48 +0300, Mika Westerberg wrote:
> On Thu, May 15, 2014 at 02:44:12PM +0800, Zhang Rui wrote:
> > The new ACPI device enumeration mechanism, which will be introduced
> > in a later patch, will enumerate the _HID devices w/o any scan
> > handler attached to platform bus.
> > This means that, for the devices that are attached to a configurable
> > scan handler, we should make sure no platform devices would be
> > created for them even if the scan handler is compiled out.
> > 
> > Fix this problem for lpss devices by introducing a dummy
> > lpss scan handler in this patch.
> > 
> > Plus, if lpt_clk_init() fails, we need this dummy scan handler as well.
> > 
> > Signed-off-by: Zhang Rui 
> > ---
> >  drivers/acpi/Makefile|  2 +-
> >  drivers/acpi/acpi_lpss.c | 69 
> > ++--
> >  drivers/acpi/internal.h  |  4 ---
> >  3 files changed, 50 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> > index 171efc2..605eff7 100644
> > --- a/drivers/acpi/Makefile
> > +++ b/drivers/acpi/Makefile
> > @@ -39,7 +39,7 @@ acpi-y+= processor_core.o
> >  acpi-y += ec.o
> >  acpi-$(CONFIG_ACPI_DOCK)   += dock.o
> >  acpi-y += pci_root.o pci_link.o pci_irq.o
> > -acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
> > +acpi-y += acpi_lpss.o
> >  acpi-y += acpi_platform.o
> >  acpi-y += acpi_pnp.o
> >  acpi-y += power.o
> > diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> > index 69e29f4..965428f 100644
> > --- a/drivers/acpi/acpi_lpss.c
> > +++ b/drivers/acpi/acpi_lpss.c
> > @@ -24,6 +24,8 @@
> >  
> >  ACPI_MODULE_NAME("acpi_lpss");
> >  
> > +#ifdef CONFIG_X86_INTEL_LPSS
> > +
> >  #define LPSS_CLK_SIZE  0x04
> >  #define LPSS_LTR_SIZE  0x18
> >  
> > @@ -159,40 +161,50 @@ static struct lpss_device_desc byt_i2c_dev_desc = {
> > .shared_clock = _clock,
> >  };
> >  
> > +#define LPSS_PTR(desc) ((unsigned long))
> > +
> > +#else
> > +
> > +#define LPSS_PTR(desc) 0
> > +
> > +#endif
> > +
> >  static const struct acpi_device_id acpi_lpss_device_ids[] = {
> > /* Generic LPSS devices */
> > -   { "INTL9C60", (unsigned long)_dma_desc },
> > +   { "INTL9C60", LPSS_PTR(lpss_dma_desc) },
> >  
> > /* Lynxpoint LPSS devices */
> > -   { "INT33C0", (unsigned long)_dev_desc },
> > -   { "INT33C1", (unsigned long)_dev_desc },
> > -   { "INT33C2", (unsigned long)_dev_desc },
> > -   { "INT33C3", (unsigned long)_dev_desc },
> > -   { "INT33C4", (unsigned long)_uart_dev_desc },
> > -   { "INT33C5", (unsigned long)_uart_dev_desc },
> > -   { "INT33C6", (unsigned long)_sdio_dev_desc },
> > +   { "INT33C0", LPSS_PTR(lpt_dev_desc) },
> > +   { "INT33C1", LPSS_PTR(lpt_dev_desc) },
> > +   { "INT33C2", LPSS_PTR(lpt_dev_desc) },
> > +   { "INT33C3", LPSS_PTR(lpt_dev_desc) },
> > +   { "INT33C4", LPSS_PTR(lpt_uart_dev_desc) },
> > +   { "INT33C5", LPSS_PTR(lpt_uart_dev_desc) },
> > +   { "INT33C6", LPSS_PTR(lpt_sdio_dev_desc) },
> > { "INT33C7", },
> >  
> > /* BayTrail LPSS devices */
> > -   { "80860F09", (unsigned long)_pwm_dev_desc },
> > -   { "80860F0A", (unsigned long)_uart_dev_desc },
> > -   { "80860F0E", (unsigned long)_spi_dev_desc },
> > -   { "80860F14", (unsigned long)_sdio_dev_desc },
> > -   { "80860F41", (unsigned long)_i2c_dev_desc },
> > +   { "80860F09", LPSS_PTR(byt_pwm_dev_desc) },
> > +   { "80860F0A", LPSS_PTR(byt_uart_dev_desc) },
> > +   { "80860F0E", LPSS_PTR(byt_spi_dev_desc) },
> > +   { "80860F14", LPSS_PTR(byt_sdio_dev_desc) },
> > +   { "80860F41", LPSS_PTR(byt_i2c_dev_desc) },
> > { "INT33B2", },
> >  
> > -   { "INT3430", (unsigned long)_dev_desc },
> > -   { "INT3431", (unsigned long)_dev_desc },
> > -   { "INT3432", (unsigned long)_dev_desc },
> > -   { "INT3433", (unsigned long)_dev_desc },
> > -   { "INT3434", (unsigned long)_uart_dev_desc },

Re: [PATCH V6 09/11] ACPI: introduce flag .is_master_device

[Zhang Rui]

On 三, 2014-05-21 at 11:52 +0300, Mika Westerberg wrote:
> On Thu, May 15, 2014 at 02:44:14PM +0800, Zhang Rui wrote:
> > For some ACPI device objects, they represent master devices,
> > and their children devices are enumerated by bus controller drivers
> > for the buses they are on.
> > 
> > In this case, we do not want to enumerate their children devices to
> > platform bus explicitly in acpi scan code.
> > 
> > Thus a new flag .is_master_device is introduced in this patch.
> > 
> > For devices with this flag set, we will not do default enumeration
> > for their children.
> 
> Is there any particular reason we would like to enumerate everything
> below the first device by default?

we do not enumerate everything below the first device by default, we
just enumerate all the devices with _HID.
But if a device has _HID and it is enumerated by its parents to a
separate bus, we need this flag set for its parent.

thanks,
rui

--
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 V6 09/11] ACPI: introduce flag .is_master_device

[Zhang Rui]

On 三, 2014-05-21 at 11:52 +0300, Mika Westerberg wrote:
 On Thu, May 15, 2014 at 02:44:14PM +0800, Zhang Rui wrote:
  For some ACPI device objects, they represent master devices,
  and their children devices are enumerated by bus controller drivers
  for the buses they are on.
  
  In this case, we do not want to enumerate their children devices to
  platform bus explicitly in acpi scan code.
  
  Thus a new flag .is_master_device is introduced in this patch.
  
  For devices with this flag set, we will not do default enumeration
  for their children.
 
 Is there any particular reason we would like to enumerate everything
 below the first device by default?

we do not enumerate everything below the first device by default, we
just enumerate all the devices with _HID.
But if a device has _HID and it is enumerated by its parents to a
separate bus, we need this flag set for its parent.

thanks,
rui

--
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 V6 07/11] ACPI: introduce dummy lpss scan handler

[Zhang Rui]

On 三, 2014-05-21 at 11:48 +0300, Mika Westerberg wrote:
 On Thu, May 15, 2014 at 02:44:12PM +0800, Zhang Rui wrote:
  The new ACPI device enumeration mechanism, which will be introduced
  in a later patch, will enumerate the _HID devices w/o any scan
  handler attached to platform bus.
  This means that, for the devices that are attached to a configurable
  scan handler, we should make sure no platform devices would be
  created for them even if the scan handler is compiled out.
  
  Fix this problem for lpss devices by introducing a dummy
  lpss scan handler in this patch.
  
  Plus, if lpt_clk_init() fails, we need this dummy scan handler as well.
  
  Signed-off-by: Zhang Rui rui.zh...@intel.com
  ---
   drivers/acpi/Makefile|  2 +-
   drivers/acpi/acpi_lpss.c | 69 
  ++--
   drivers/acpi/internal.h  |  4 ---
   3 files changed, 50 insertions(+), 25 deletions(-)
  
  diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
  index 171efc2..605eff7 100644
  --- a/drivers/acpi/Makefile
  +++ b/drivers/acpi/Makefile
  @@ -39,7 +39,7 @@ acpi-y+= processor_core.o
   acpi-y += ec.o
   acpi-$(CONFIG_ACPI_DOCK)   += dock.o
   acpi-y += pci_root.o pci_link.o pci_irq.o
  -acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
  +acpi-y += acpi_lpss.o
   acpi-y += acpi_platform.o
   acpi-y += acpi_pnp.o
   acpi-y += power.o
  diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
  index 69e29f4..965428f 100644
  --- a/drivers/acpi/acpi_lpss.c
  +++ b/drivers/acpi/acpi_lpss.c
  @@ -24,6 +24,8 @@
   
   ACPI_MODULE_NAME(acpi_lpss);
   
  +#ifdef CONFIG_X86_INTEL_LPSS
  +
   #define LPSS_CLK_SIZE  0x04
   #define LPSS_LTR_SIZE  0x18
   
  @@ -159,40 +161,50 @@ static struct lpss_device_desc byt_i2c_dev_desc = {
  .shared_clock = i2c_clock,
   };
   
  +#define LPSS_PTR(desc) ((unsigned long)desc)
  +
  +#else
  +
  +#define LPSS_PTR(desc) 0
  +
  +#endif
  +
   static const struct acpi_device_id acpi_lpss_device_ids[] = {
  /* Generic LPSS devices */
  -   { INTL9C60, (unsigned long)lpss_dma_desc },
  +   { INTL9C60, LPSS_PTR(lpss_dma_desc) },
   
  /* Lynxpoint LPSS devices */
  -   { INT33C0, (unsigned long)lpt_dev_desc },
  -   { INT33C1, (unsigned long)lpt_dev_desc },
  -   { INT33C2, (unsigned long)lpt_dev_desc },
  -   { INT33C3, (unsigned long)lpt_dev_desc },
  -   { INT33C4, (unsigned long)lpt_uart_dev_desc },
  -   { INT33C5, (unsigned long)lpt_uart_dev_desc },
  -   { INT33C6, (unsigned long)lpt_sdio_dev_desc },
  +   { INT33C0, LPSS_PTR(lpt_dev_desc) },
  +   { INT33C1, LPSS_PTR(lpt_dev_desc) },
  +   { INT33C2, LPSS_PTR(lpt_dev_desc) },
  +   { INT33C3, LPSS_PTR(lpt_dev_desc) },
  +   { INT33C4, LPSS_PTR(lpt_uart_dev_desc) },
  +   { INT33C5, LPSS_PTR(lpt_uart_dev_desc) },
  +   { INT33C6, LPSS_PTR(lpt_sdio_dev_desc) },
  { INT33C7, },
   
  /* BayTrail LPSS devices */
  -   { 80860F09, (unsigned long)byt_pwm_dev_desc },
  -   { 80860F0A, (unsigned long)byt_uart_dev_desc },
  -   { 80860F0E, (unsigned long)byt_spi_dev_desc },
  -   { 80860F14, (unsigned long)byt_sdio_dev_desc },
  -   { 80860F41, (unsigned long)byt_i2c_dev_desc },
  +   { 80860F09, LPSS_PTR(byt_pwm_dev_desc) },
  +   { 80860F0A, LPSS_PTR(byt_uart_dev_desc) },
  +   { 80860F0E, LPSS_PTR(byt_spi_dev_desc) },
  +   { 80860F14, LPSS_PTR(byt_sdio_dev_desc) },
  +   { 80860F41, LPSS_PTR(byt_i2c_dev_desc) },
  { INT33B2, },
   
  -   { INT3430, (unsigned long)lpt_dev_desc },
  -   { INT3431, (unsigned long)lpt_dev_desc },
  -   { INT3432, (unsigned long)lpt_dev_desc },
  -   { INT3433, (unsigned long)lpt_dev_desc },
  -   { INT3434, (unsigned long)lpt_uart_dev_desc },
  -   { INT3435, (unsigned long)lpt_uart_dev_desc },
  -   { INT3436, (unsigned long)lpt_sdio_dev_desc },
  +   { INT3430, LPSS_PTR(lpt_dev_desc) },
  +   { INT3431, LPSS_PTR(lpt_dev_desc) },
  +   { INT3432, LPSS_PTR(lpt_dev_desc) },
  +   { INT3433, LPSS_PTR(lpt_dev_desc) },
  +   { INT3434, LPSS_PTR(lpt_uart_dev_desc) },
  +   { INT3435, LPSS_PTR(lpt_uart_dev_desc) },
  +   { INT3436, LPSS_PTR(lpt_sdio_dev_desc) },
  { INT3437, },
   
  { }
   };
   
  +#ifdef CONFIG_X86_INTEL_LPSS
  +
   static int is_memory(struct acpi_resource *res, void *not_used)
   {
  struct resource r;
  @@ -511,10 +523,27 @@ static struct acpi_scan_handler lpss_handler = {
  .unbind = acpi_lpss_unbind,
   };
   
  +#endif /* CONFIG_X86_INTEL_LPSS */
  +
  +static int acpi_lpss_dummy_attach(struct acpi_device *adev,
  +   const struct acpi_device_id *id)
  +{
  +   return 1;
  +}
  +
  +static struct acpi_scan_handler lpss_dummy_handler = {
  +   .ids = acpi_lpss_device_ids,
  +   .attach = acpi_lpss_dummy_attach,
  +};
  +
   void __init acpi_lpss_init(void)
   {
  +#ifdef

Re: [PATCH V6 09/11] ACPI: introduce flag .is_master_device

[Zhang Rui]

On 三, 2014-05-21 at 13:10 +0200, Rafael J. Wysocki wrote:
 On Wednesday, May 21, 2014 11:52:07 AM Mika Westerberg wrote:
  On Thu, May 15, 2014 at 02:44:14PM +0800, Zhang Rui wrote:
   For some ACPI device objects, they represent master devices,
   and their children devices are enumerated by bus controller drivers
   for the buses they are on.
   
   In this case, we do not want to enumerate their children devices to
   platform bus explicitly in acpi scan code.
   
   Thus a new flag .is_master_device is introduced in this patch.
   
   For devices with this flag set, we will not do default enumeration
   for their children.
  
  Is there any particular reason we would like to enumerate everything
  below the first device by default?
 
 Yes, there is.  Device objects without _ADR under the PCI host bridge.
 
I'm confused. Mika, what do you mean by saying first device?

thanks,
rui
 Or we can skip the children under every *platform* device created by this by
 default and mark the ones where we want the children to be enumerated as
 platform devices too in a special way if needed.
 
 I guess we could try that (that was the Rui's original idea IIRC).
 
 Rafael
 


--
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 00/10] thermal: exynos: various cleanups

[Zhang Rui]

On 一, 2014-05-05 at 13:15 +0200, Bartlomiej Zolnierkiewicz wrote:
> Hi,
> 
> This patch series contains various cleanups for EXYNOS thermal
> driver.  Overall it decreases driver's LOC by 13%.  It is based
> on next-20140428 kernel.  It should not cause any functionality
> changes.
> 
Amit,

what do you think of this patch set?

thanks,
rui
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
> 
> 
> Bartlomiej Zolnierkiewicz (10):
>   thermal: exynos: remove unused struct exynos_tmu_registers entries
>   thermal: exynos: remove unused defines
>   thermal: exynos: remove dead code for HW_MODE calibration
>   thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING
> calibration
>   thermal: exynos: remove redundant pdata checks from
> exynos_tmu_initialize()
>   thermal: exynos: remove redundant threshold_code checks from
> exynos_tmu_initialize()
>   thermal: exynos: simplify temp_to_code() and code_to_temp()
>   thermal: exynos: cache non_hw_trigger_levels in pdata
>   thermal: exynos: remove redundant pdata checks from
> exynos_tmu_control()
>   thermal: exynos: remove identical values from exynos*_tmu_registers
> structures
> 
>  drivers/thermal/samsung/exynos_thermal_common.h |   1 -
>  drivers/thermal/samsung/exynos_tmu.c| 181 
> 
>  drivers/thermal/samsung/exynos_tmu.h|  86 +--
>  drivers/thermal/samsung/exynos_tmu_data.c   |  40 +-
>  drivers/thermal/samsung/exynos_tmu_data.h   |  32 +
>  5 files changed, 37 insertions(+), 303 deletions(-)
> 


--
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] thermal: rcar: Use pm_runtime_put() i.s.o. pm_runtime_put_sync()

[Zhang Rui]

On 一, 2014-04-14 at 19:02 +0200, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
> There's no need for this to be synchronous
> 
> Signed-off-by: Geert Uytterhoeven 

applied.

thanks,
rui
> ---
>  drivers/thermal/rcar_thermal.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
> index 5a37940b02c9..a8ed0e0265ae 100644
> --- a/drivers/thermal/rcar_thermal.c
> +++ b/drivers/thermal/rcar_thermal.c
> @@ -470,7 +470,7 @@ error_unregister:
>   rcar_thermal_irq_disable(priv);
>   }
>  
> - pm_runtime_put_sync(dev);
> + pm_runtime_put(dev);
>   pm_runtime_disable(dev);
>  
>   return ret;
> @@ -488,7 +488,7 @@ static int rcar_thermal_remove(struct platform_device 
> *pdev)
>   rcar_thermal_irq_disable(priv);
>   }
>  
> - pm_runtime_put_sync(dev);
> + pm_runtime_put(dev);
>   pm_runtime_disable(dev);
>  
>   return 0;


--
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] thermal: samsung: Only update available threshold limits

[Zhang Rui]

On 四, 2014-04-24 at 11:48 +0530, Amit Kachhap wrote:
> On 4/14/14, Tushar Behera  wrote:
> > Currently the threshold limits are updated in 2 stages, once for all
> > software trigger levels and again for hardware trip point.
> I guess the first stage is bootloader as could not find this in this file.
> Anyways the changes looks fine to me.
> 
> Acked-by: Amit Daniel Kachhap 

applied.

thanks,
rui
> 
> >
> > While updating the software trigger levels, it overwrites the threshold
> > limit for hardware trip point thereby forcing the Exynos core to issue
> > an emergency shutdown.
> >
> > Updating only the required fields in threshold register fixes this issue.
> >
> > Signed-off-by: Tushar Behera 
> > ---
> > Based on v3.15-rc1.
> >
> >  drivers/thermal/samsung/exynos_tmu.c |4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/thermal/samsung/exynos_tmu.c
> > b/drivers/thermal/samsung/exynos_tmu.c
> > index 0d96a51..ffccc89 100644
> > --- a/drivers/thermal/samsung/exynos_tmu.c
> > +++ b/drivers/thermal/samsung/exynos_tmu.c
> > @@ -225,6 +225,8 @@ skip_calib_data:
> > trigger_levs++;
> > }
> >
> > +   rising_threshold = readl(data->base + reg->threshold_th0);
> > +
> > if (data->soc == SOC_ARCH_EXYNOS4210) {
> > /* Write temperature code for threshold */
> > threshold_code = temp_to_code(data, pdata->threshold);
> > @@ -249,6 +251,7 @@ skip_calib_data:
> > ret = threshold_code;
> > goto out;
> > }
> > +   rising_threshold &= ~(0xff << 8 * i);
> > rising_threshold |= threshold_code << 8 * i;
> > if (pdata->threshold_falling) {
> > threshold_code = temp_to_code(data,
> > @@ -281,6 +284,7 @@ skip_calib_data:
> > }
> > if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
> > /* 1-4 level to be assigned in th0 reg */
> > +   rising_threshold &= ~(0xff << 8 * i);
> > rising_threshold |= threshold_code << 8 * i;
> > writel(rising_threshold,
> > data->base + reg->threshold_th0);
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> > in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.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/

[PATCH V6 00/11] ACPI: ACPI enumeration rework

[Zhang Rui]

Hi, all,

Currently, PNP bus is used as the default bus for for enumerating ACPI
devices with _HID/_CID.
For a device that needs to be enumerated to platform bus, we need to add
its id string to the platform scan handler white list explicitly.

This becomes a problem as more and more _HID devices need to be
enumerated to platform bus nowadays, thus the list is continuously growing.

So, a solution that uses platform bus for _HID enumeration by default
is preferred.

In order to do this, this patch set
First (Patch 1~4), changes the way of enumerating PNP devices.
We introduce a white list to create PNP devices instead. The white list contains
all the pnp_device_id strings in all the pnp drivers, thus this change is
transparent to PNP core and all the PNP drivers.
Second (Patch 5~11), changes the code to enumerate ACPI _HID devices to platform
bus by default.

Tis patch set has been tested on my desktop machine,
and a TOSHIBA PORTEGE Z830 ultrabook.

Clarification:
Although it seems that we are introducing a much bigger white list to replace
a small one, the benefit is that
1. without the patch, the acpi_platform scan handler white list is
   continuously growing.
2. with the patch set, the PNPACPI scan handler white list will become
   smaller and smaller by
   a) remove the ids from the PNPACPI white list, for the devices
  that are never enumerated via ACPI
   b) remove the ids from the PNPACPI whilte list and convert the drivers to
  platform bus drivers, for the devices that are not PNP devices in nature.
   which will be done later.

Known Issue:
PNP bus does not check the device resources when adding a new PNP device,
while Platform bus does by invoking insert_resource() in platform_device_add().
This results in failure when creating platform device node for some ACPI
device objects in case there is resource conflict.
In my desktop, I can see that
Creating PNP0C02:02 fails because its resource (IO: 0x72 ~ 0x7f)
conflicts with "0070-0077 : PNP0B00:00" (CMOS RTC).

Known Issue:
Currently, we can't enumerate devices with _CID PNP0C01/PNP0C02 to platform bus
because we need them in PNP bus in order to reserve mother board resources.

thanks,
rui


Changes in V6:
1. Patch re-ordering to avoid bisect breakage.
2. rework the patch for fixing the "redudent platform devices created for lpss
   slaves" issue according to Rafael' comments.

Changes in V5:
1. fix a problem that ACPI tries to enumerate lpss slaves to platform bus
2. rebased on 3.14 kernel

Changes in V4:
1. coding style cleanups, fix checkpatch warnings/errors.

Changes in V3:
1. rename enumerable_id to platform_id according to Rafael' suggestion.
2. drop two patches to handle devices with _CID PNP0C01/PNP0C02 enumeration
   because the code in drivers/pnp/system.c is still under discussion.
3. make cmos rtc scan handler return 1 so that the device will not be
   enumerated to platform bus.

Changes in V2:
1.move acpi pnp scan handler from drivers/pnp/pnpacpi/core.c to
  drivers/acpi/acpi-pnp.c, because the scan handler needs to be always built
  in to prevent platform devices from being created for those ACPI devices.
2.remove the __init tag for the acpi pnp scan handler because the scan
  handler is still needed after system initialization, for hotplug.
3.introduce enumerable_id flag for devices that can be enumerated to platform
  bus.
4.introduce excluded id list for creating platform devices, because some
  devices have _HID but they will never be associated with a platform driver.
5.introduce dummy lpss/container/memory_hotplug scan handler to prevent
  platform devices from being created for those ACPI device objects.

--------
Zhang Rui (11):
  ACPI: introduce .match() callback for ACPI scan handler
  PNPACPI: use whilte list for pnpacpi device enumeration
  ACPI: remove ids that does not comply with the ACPI PNP id rule
  ACPI: remove unsupported serial PNP ids from acpi pnp scan handler id lsit
  ACPI: introduce dummy container scan handler
  ACPI: introduce dummy memory hotplug scan handler
  ACPI: introduce dummy lpss scan handler
  ACPI: introduce platform_id flag
  ACPI: introduce flag .is_master_device
  ACPI: use platform bus as the default bus for _HID enumeration
  ACPI: introduce acpi platform exclude id list

 drivers/acpi/Makefile  |   7 ++--
 drivers/acpi/acpi_cmos_rtc.c   |   2 +-
 drivers/acpi/acpi_lpss.c   |  93 -
 drivers/acpi/acpi_memhotplug.c |  45 ++--
 drivers/acpi/acpi_platform.c   |  39 ++---
 drivers/acpi/acpi_pnp.c| 382 
++
 drivers/acpi/container.c   |  21 ++
 dri

[PATCH V6 03/11] ACPI: remove ids that does not comply with the ACPI PNP id rule

[Zhang Rui]

The acpi pnp scan handler id list just copies all the ids from all the
struct pnp_device_id instances, but some of them do not
comply with the ACPI PNP id rule (3 Alpha Charactors + 4 Hex numbers).

For those ids, the coressponding devices will never be enumerated
via ACPI, so it is safe to remove those ids from the PNPACPI white list.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_pnp.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
index 57d14ed..d206616 100644
--- a/drivers/acpi/acpi_pnp.c
+++ b/drivers/acpi/acpi_pnp.c
@@ -33,10 +33,6 @@ static const struct acpi_device_id acpi_pnp_device_ids[] = {
/* ide   */
{"PNP0600"},/* Generic ESDI/IDE/ATA compatible hard disk 
controller */
/* ns558 */
-   {"@P@0001"},/* ALS 100 */
-   {"@P@0020"},/* ALS 200 */
-   {"@P@1001"},/* ALS 100+ */
-   {"@P@2001"},/* ALS 120 */
{"ASB16fd"},/* AdLib NSC16 */
{"AZT3001"},/* AZT1008 */
{"CDC0001"},/* Opl3-SAx */
-- 
1.8.3.2

--
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 V6 06/11] ACPI: introduce dummy memory hotplug scan handler

[Zhang Rui]

The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.

Fix this problem for memory hotplug devuces by introducing a dummy
memory hotplug scan handler in this patch.

Plus, the dummy memory hotplug scan handler is also needed when
kernel parameter "acpi_no_memhotplug" is used.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/Makefile  |  2 +-
 drivers/acpi/acpi_memhotplug.c | 45 ++
 drivers/acpi/internal.h|  6 +-
 3 files changed, 34 insertions(+), 19 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 5611a07..171efc2 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -65,7 +65,7 @@ obj-$(CONFIG_ACPI_PCI_SLOT)   += pci_slot.o
 obj-$(CONFIG_ACPI_PROCESSOR)   += processor.o
 obj-y  += container.o
 obj-$(CONFIG_ACPI_THERMAL) += thermal.o
-obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
+obj-y  += acpi_memhotplug.o
 obj-$(CONFIG_ACPI_BATTERY) += battery.o
 obj-$(CONFIG_ACPI_SBS) += sbshc.o
 obj-$(CONFIG_ACPI_SBS) += sbs.o
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index b67be85..ed2f6a7 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -44,6 +44,13 @@
 
 ACPI_MODULE_NAME("acpi_memhotplug");
 
+static const struct acpi_device_id memory_device_ids[] = {
+   {ACPI_MEMORY_DEVICE_HID, 0},
+   {"", 0},
+};
+
+#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
+
 /* Memory Device States */
 #define MEMORY_INVALID_STATE   0
 #define MEMORY_POWER_ON_STATE  1
@@ -53,11 +60,6 @@ static int acpi_memory_device_add(struct acpi_device *device,
  const struct acpi_device_id *not_used);
 static void acpi_memory_device_remove(struct acpi_device *device);
 
-static const struct acpi_device_id memory_device_ids[] = {
-   {ACPI_MEMORY_DEVICE_HID, 0},
-   {"", 0},
-};
-
 static struct acpi_scan_handler memory_device_handler = {
.ids = memory_device_ids,
.attach = acpi_memory_device_add,
@@ -362,17 +364,34 @@ static void acpi_memory_device_remove(struct acpi_device 
*device)
 
 static bool __initdata acpi_no_memhotplug;
 
-void __init acpi_memory_hotplug_init(void)
-{
-   if (acpi_no_memhotplug)
-   return;
-
-   acpi_scan_add_handler_with_hotplug(_device_handler, "memory");
-}
-
 static int __init disable_acpi_memory_hotplug(char *str)
 {
acpi_no_memhotplug = true;
return 1;
 }
 __setup("acpi_no_memhotplug", disable_acpi_memory_hotplug);
+
+#endif
+
+static int acpi_memory_dummy_add(struct acpi_device *device,
+const struct acpi_device_id *not_used)
+{
+   return 1;
+}
+
+static struct acpi_scan_handler memory_dummy_handler = {
+   .ids = memory_device_ids,
+   .attach = acpi_memory_dummy_add,
+};
+
+void __init acpi_memory_hotplug_init(void)
+{
+#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
+   if (!acpi_no_memhotplug) {
+   acpi_scan_add_handler_with_hotplug(_device_handler,
+   "memory");
+   return;
+   }
+#endif
+   acpi_scan_add_handler(_dummy_handler);
+}
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 499908e..4a9e999 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -33,6 +33,7 @@ void acpi_platform_init(void);
 void acpi_pnp_init(void);
 int acpi_sysfs_init(void);
 void acpi_container_init(void);
+void acpi_memory_hotplug_init(void);
 #ifdef CONFIG_ACPI_DOCK
 void register_dock_dependent_device(struct acpi_device *adev,
acpi_handle dshandle);
@@ -44,11 +45,6 @@ static inline void register_dock_dependent_device(struct 
acpi_device *adev,
 static inline int dock_notify(struct acpi_device *adev, u32 event) { return 
-ENODEV; }
 static inline void acpi_dock_add(struct acpi_device *adev) {}
 #endif
-#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
-void acpi_memory_hotplug_init(void);
-#else
-static inline void acpi_memory_hotplug_init(void) {}
-#endif
 #ifdef CONFIG_X86
 void acpi_cmos_rtc_init(void);
 #else
-- 
1.8.3.2

--
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 V6 10/11] ACPI: use platform bus as the default bus for _HID enumeration

[Zhang Rui]

Because of the growing demand for enumerating ACPI devices to
platform bus, this patch changes the code to enumerate ACPI
devices to platform bus by default, if the device
1. has _HID.
2. does not have a scan handler attached.
3. will not be enumerated by its parent.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_platform.c | 28 
 drivers/acpi/scan.c  | 25 -
 2 files changed, 24 insertions(+), 29 deletions(-)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index dbfe49e..33376a9 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -22,24 +22,6 @@
 
 ACPI_MODULE_NAME("platform");
 
-/*
- * The following ACPI IDs are known to be suitable for representing as
- * platform devices.
- */
-static const struct acpi_device_id acpi_platform_device_ids[] = {
-
-   { "PNP0D40" },
-   { "ACPI0003" },
-   { "VPC2004" },
-   { "BCM4752" },
-
-   /* Intel Smart Sound Technology */
-   { "INT33C8" },
-   { "80860F28" },
-
-   { }
-};
-
 /**
  * acpi_create_platform_device - Create platform device for ACPI device node
  * @adev: ACPI device node to create a platform device for.
@@ -125,13 +107,3 @@ int acpi_create_platform_device(struct acpi_device *adev,
kfree(resources);
return 1;
 }
-
-static struct acpi_scan_handler platform_handler = {
-   .ids = acpi_platform_device_ids,
-   .attach = acpi_create_platform_device,
-};
-
-void __init acpi_platform_init(void)
-{
-   acpi_scan_add_handler(_handler);
-}
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 451e7d9..756977e 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2073,6 +2073,27 @@ static acpi_status acpi_bus_check_add(acpi_handle 
handle, u32 lvl_not_used,
return AE_OK;
 }
 
+static void acpi_do_default_enumeration(struct acpi_device *device)
+{
+   /*
+* Do not do enumeration for device object that has been/will be
+* enumerated by its parent.
+*/
+   if (device->parent && device->parent->flags.is_master_device)
+   return;
+
+   /* Do not do enumeration for device object with scan handler attached */
+   if (device->handler)
+   return;
+
+   /* Do not do enumeration for device object w/o platform_id */
+   if (!device->pnp.type.platform_id)
+   return;
+
+   acpi_create_platform_device(device, NULL);
+}
+
+
 static int acpi_scan_attach_handler(struct acpi_device *device)
 {
struct acpi_hardware_id *hwid;
@@ -2094,6 +2115,9 @@ static int acpi_scan_attach_handler(struct acpi_device 
*device)
break;
}
}
+
+   acpi_do_default_enumeration(device);
+
return ret;
 }
 
@@ -2253,7 +2277,6 @@ int __init acpi_scan_init(void)
acpi_pci_root_init();
acpi_pci_link_init();
acpi_processor_init();
-   acpi_platform_init();
acpi_lpss_init();
acpi_cmos_rtc_init();
acpi_container_init();
-- 
1.8.3.2

--
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 V6 04/11] ACPI: remove unsupported serial PNP ids from acpi pnp scan handler id lsit

[Zhang Rui]

The "serial" pnp driver supports some unknown PNP modems (PNPCXXX/PNPDXXX)
by matching magic strings in the pnp device name or the pnp device card name.

ACPI enumerated PNP device neither supports pnp card, nor supports those magic
strings in its device name, which means this mechamism never works for ACPI
enumerated PNPCXXX/PNPDXXX devices.
So it is safe to remove those two ids from the ACPI pnp scan handler id list.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_pnp.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
index d206616..a563a27 100644
--- a/drivers/acpi/acpi_pnp.c
+++ b/drivers/acpi/acpi_pnp.c
@@ -300,8 +300,6 @@ static const struct acpi_device_id acpi_pnp_device_ids[] = {
{"LTS0001"},/* LG C1 EXPRESS DUAL (C1-PB11A3) touch screen 
(actually a FUJ02E6 in disguise) */
{"WCI0003"},/* Rockwell's (PORALiNK) 33600 INT PNP */
{"WEC1022"},/* Winbond CIR port, should not be probed. We 
should keep track of it to prevent the legacy serial driver from probing it */
-   {"PNPCXXX"},/* Unknown PnP modems */
-   {"PNPDXXX"},/* More unknown PnP modems */
/* scl200wdt */
{"NSC0800"},/* National Semiconductor PC87307/PC97307 
watchdog component */
/* mpu401 */
-- 
1.8.3.2

--
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 V6 08/11] ACPI: introduce platform_id flag

[Zhang Rui]

Only certain kind of ACPI device objects can be enumerated to platform bus.
These ACPI device objects include
1. ACPI device objects that have _HID control method.
2. some ACPI device objects that have Linux specified HID strings.

In order to distinguish those device objects from the others, a new flag
platform_id and a new function acpi_add_platform_id() are introduced
in this patch.

Currently, only devices with _HID method have this flag set.
If you want platform devices to be created for device objects without _HID,
use acpi_add_platform_id() when adding artificial Linux-specific ID strings
to them.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/scan.c | 9 -
 include/acpi/acpi_bus.h | 3 ++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index c82ab73..451e7d9 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1730,6 +1730,13 @@ static void acpi_add_id(struct acpi_device_pnp *pnp, 
const char *dev_id)
pnp->type.hardware_id = 1;
 }
 
+static void acpi_add_platform_id(struct acpi_device_pnp *pnp,
+const char *dev_id)
+{
+   acpi_add_id(pnp, dev_id);
+   pnp->type.platform_id = 1;
+}
+
 /*
  * Old IBM workstations have a DSDT bug wherein the SMBus object
  * lacks the SMBUS01 HID and the methods do not have the necessary "_"
@@ -1794,7 +1801,7 @@ static void acpi_set_pnp_ids(acpi_handle handle, struct 
acpi_device_pnp *pnp,
}
 
if (info->valid & ACPI_VALID_HID)
-   acpi_add_id(pnp, info->hardware_id.string);
+   acpi_add_platform_id(pnp, info->hardware_id.string);
if (info->valid & ACPI_VALID_CID) {
cid_list = >compatible_id_list;
for (i = 0; i < cid_list->count; i++)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index ba679af..ec92ad3 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -233,7 +233,8 @@ struct acpi_hardware_id {
 struct acpi_pnp_type {
u32 hardware_id:1;
u32 bus_address:1;
-   u32 reserved:30;
+   u32 platform_id:1;
+   u32 reserved:29;
 };
 
 struct acpi_device_pnp {
-- 
1.8.3.2

--
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 V6 05/11] ACPI: introduce dummy container scan handler

[Zhang Rui]

The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.

Fix this problem for container devices by introducing a dummy
container scan handler in this patch.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/Makefile|  2 +-
 drivers/acpi/container.c | 21 +
 drivers/acpi/internal.h  |  4 
 3 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9a43893..5611a07 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -63,7 +63,7 @@ obj-$(CONFIG_ACPI_FAN)+= fan.o
 obj-$(CONFIG_ACPI_VIDEO)   += video.o
 obj-$(CONFIG_ACPI_PCI_SLOT)+= pci_slot.o
 obj-$(CONFIG_ACPI_PROCESSOR)   += processor.o
-obj-$(CONFIG_ACPI_CONTAINER)   += container.o
+obj-y  += container.o
 obj-$(CONFIG_ACPI_THERMAL) += thermal.o
 obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
 obj-$(CONFIG_ACPI_BATTERY) += battery.o
diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
index 63119d0..9100db7 100644
--- a/drivers/acpi/container.c
+++ b/drivers/acpi/container.c
@@ -41,6 +41,8 @@ static const struct acpi_device_id container_device_ids[] = {
{"", 0},
 };
 
+#ifdef CONFIG_ACPI_CONTAINER
+
 static int acpi_container_offline(struct container_dev *cdev)
 {
struct acpi_device *adev = ACPI_COMPANION(>dev);
@@ -111,3 +113,22 @@ void __init acpi_container_init(void)
 {
acpi_scan_add_handler_with_hotplug(_handler, "container");
 }
+
+#else
+
+static inline int container_device_attach(struct acpi_device *adev,
+   const struct acpi_device_id *not_used)
+{
+   return 1;
+}
+
+static struct acpi_scan_handler container_handler = {
+   .ids = container_device_ids,
+   .attach = container_device_attach,
+};
+
+void __init acpi_container_init(void)
+{
+   acpi_scan_add_handler(_handler);
+}
+#endif /* CONFIG_ACPI_CONTAINER */
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 3a12866..499908e 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -32,11 +32,7 @@ void acpi_processor_init(void);
 void acpi_platform_init(void);
 void acpi_pnp_init(void);
 int acpi_sysfs_init(void);
-#ifdef CONFIG_ACPI_CONTAINER
 void acpi_container_init(void);
-#else
-static inline void acpi_container_init(void) {}
-#endif
 #ifdef CONFIG_ACPI_DOCK
 void register_dock_dependent_device(struct acpi_device *adev,
acpi_handle dshandle);
-- 
1.8.3.2

--
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 V6 11/11] ACPI: introduce acpi platform exclude id list

[Zhang Rui]

For ACPI PIC (PNP), Timer (PNP0100) and DMA controller (PNP0200)
device objects, although they have _HID control method, but they
should not be enumerated to platform bus, because there will never be
any platform drivers for them.

Thus an exclude id list is introduced in this patch to prevent
those platform device nodes from being created.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_platform.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 33376a9..db89480 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -22,6 +22,18 @@
 
 ACPI_MODULE_NAME("platform");
 
+static const struct acpi_device_id excluded_id_list[] = {
+   {"PNP", 0}, /* PIC */
+   {"PNP0100", 0}, /* Timer */
+   {"PNP0200", 0}, /* AT DMA Controller */
+   {"", 0},
+};
+
+static bool is_exclusive_device(struct acpi_device *dev)
+{
+   return !acpi_match_device_ids(dev, excluded_id_list);
+}
+
 /**
  * acpi_create_platform_device - Create platform device for ACPI device node
  * @adev: ACPI device node to create a platform device for.
@@ -48,6 +60,9 @@ int acpi_create_platform_device(struct acpi_device *adev,
if (adev->physical_node_count)
return 0;
 
+   if (is_exclusive_device(adev))
+   return 0;
+
INIT_LIST_HEAD(_list);
count = acpi_dev_get_resources(adev, _list, NULL, NULL);
if (count < 0) {
-- 
1.8.3.2

--
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 V6 09/11] ACPI: introduce flag .is_master_device

[Zhang Rui]

For some ACPI device objects, they represent master devices,
and their children devices are enumerated by bus controller drivers
for the buses they are on.

In this case, we do not want to enumerate their children devices to
platform bus explicitly in acpi scan code.

Thus a new flag .is_master_device is introduced in this patch.

For devices with this flag set, we will not do default enumeration
for their children.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_lpss.c | 62 +---
 include/acpi/acpi_bus.h  |  3 ++-
 2 files changed, 45 insertions(+), 20 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 965428f..4ab0915 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -54,6 +54,7 @@ struct lpss_shared_clock {
 struct lpss_private_data;
 
 struct lpss_device_desc {
+   bool is_master_device;
bool clk_required;
const char *clkdev_name;
bool ltr_required;
@@ -91,6 +92,7 @@ static void lpss_uart_setup(struct lpss_private_data *pdata)
 }
 
 static struct lpss_device_desc lpt_dev_desc = {
+   .is_master_device = true,
.clk_required = true,
.prv_offset = 0x800,
.ltr_required = true,
@@ -98,6 +100,7 @@ static struct lpss_device_desc lpt_dev_desc = {
 };
 
 static struct lpss_device_desc lpt_uart_dev_desc = {
+   .is_master_device = true,
.clk_required = true,
.prv_offset = 0x800,
.ltr_required = true,
@@ -106,6 +109,7 @@ static struct lpss_device_desc lpt_uart_dev_desc = {
 };
 
 static struct lpss_device_desc lpt_sdio_dev_desc = {
+   .is_master_device = true,
.prv_offset = 0x1000,
.prv_size_override = 0x1018,
.ltr_required = true,
@@ -127,6 +131,7 @@ static struct lpss_shared_clock uart_clock = {
 };
 
 static struct lpss_device_desc byt_uart_dev_desc = {
+   .is_master_device = true,
.clk_required = true,
.prv_offset = 0x800,
.clk_gate = true,
@@ -140,6 +145,7 @@ static struct lpss_shared_clock spi_clock = {
 };
 
 static struct lpss_device_desc byt_spi_dev_desc = {
+   .is_master_device = true,
.clk_required = true,
.prv_offset = 0x400,
.clk_gate = true,
@@ -147,6 +153,7 @@ static struct lpss_device_desc byt_spi_dev_desc = {
 };
 
 static struct lpss_device_desc byt_sdio_dev_desc = {
+   .is_master_device = true,
.clk_required = true,
 };
 
@@ -156,16 +163,24 @@ static struct lpss_shared_clock i2c_clock = {
 };
 
 static struct lpss_device_desc byt_i2c_dev_desc = {
+   .is_master_device = true,
.clk_required = true,
.prv_offset = 0x800,
.shared_clock = _clock,
 };
 
 #define LPSS_PTR(desc) ((unsigned long))
+#define LPSS_MASTER_PTR(desc) LPSS_PTR(desc)
 
 #else
 
-#define LPSS_PTR(desc) 0
+static struct lpss_device_desc lpss_dummy_desc;
+static struct lpss_device_desc lpss_dummy_master_desc = {
+   .is_master_device = true,
+};
+
+#define LPSS_PTR(desc) (_dummy_desc)
+#define LPSS_MASTER_PTR(desc) (_dummy_master_desc)
 
 #endif
 
@@ -174,30 +189,30 @@ static const struct acpi_device_id acpi_lpss_device_ids[] 
= {
{ "INTL9C60", LPSS_PTR(lpss_dma_desc) },
 
/* Lynxpoint LPSS devices */
-   { "INT33C0", LPSS_PTR(lpt_dev_desc) },
-   { "INT33C1", LPSS_PTR(lpt_dev_desc) },
-   { "INT33C2", LPSS_PTR(lpt_dev_desc) },
-   { "INT33C3", LPSS_PTR(lpt_dev_desc) },
-   { "INT33C4", LPSS_PTR(lpt_uart_dev_desc) },
-   { "INT33C5", LPSS_PTR(lpt_uart_dev_desc) },
-   { "INT33C6", LPSS_PTR(lpt_sdio_dev_desc) },
+   { "INT33C0", LPSS_MASTER_PTR(lpt_dev_desc) },
+   { "INT33C1", LPSS_MASTER_PTR(lpt_dev_desc) },
+   { "INT33C2", LPSS_MASTER_PTR(lpt_dev_desc) },
+   { "INT33C3", LPSS_MASTER_PTR(lpt_dev_desc) },
+   { "INT33C4", LPSS_MASTER_PTR(lpt_uart_dev_desc) },
+   { "INT33C5", LPSS_MASTER_PTR(lpt_uart_dev_desc) },
+   { "INT33C6", LPSS_MASTER_PTR(lpt_sdio_dev_desc) },
{ "INT33C7", },
 
/* BayTrail LPSS devices */
{ "80860F09", LPSS_PTR(byt_pwm_dev_desc) },
-   { "80860F0A", LPSS_PTR(byt_uart_dev_desc) },
-   { "80860F0E", LPSS_PTR(byt_spi_dev_desc) },
-   { "80860F14", LPSS_PTR(byt_sdio_dev_desc) },
-   { "80860F41", LPSS_PTR(byt_i2c_dev_desc) },
+   { "80860F0A", LPSS_MASTER_PTR(byt_uart_dev_desc) },
+   { "80860F0E", LPSS_MASTER_PTR(byt_spi_dev_desc) },
+   { "80860F14", LPSS_MASTER_PTR(byt_sdio_dev_desc) },
+   { "80860F41", LPSS_MASTER_PTR(byt_i2c_dev_desc) },
{ "INT33B2", },
 
-   { "INT3430", LPSS_PTR(lpt_dev_desc) },
-   { "INT3431", LPSS_PTR(lpt_dev_desc) },
-   { "INT

[PATCH V6 01/11] ACPI: introduce .match() callback for ACPI scan handler

[Zhang Rui]

Currently, ACPI scan handler uses strcmp() to match device ids
and scan handler ids.

When converting PNPACPI enumeration into a scan handler, which I will do
later in this patch set, the current code becomes not flexible enough
because ACPI pnp scan handler requires wildcase and case insensitive support.

Thus a per scan handler .match() callback is introduced in this patch,
so that specified scan handler can have more flexible matching mechanism
by introduce its own .match() callback.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/scan.c | 17 +++--
 include/acpi/acpi_bus.h |  1 +
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 7efe546..e46e51c 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1974,14 +1974,19 @@ static bool acpi_scan_handler_matching(struct 
acpi_scan_handler *handler,
const struct acpi_device_id *devid;
 
for (devid = handler->ids; devid->id[0]; devid++)
-   if (!strcmp((char *)devid->id, idstr)) {
-   if (matchid)
-   *matchid = devid;
-
-   return true;
-   }
+   if (handler->match) {
+   if (handler->match(idstr, (char *)devid->id))
+   goto success;
+   } else
+   if (!strcmp((char *)devid->id, idstr))
+   goto success;
 
return false;
+
+success:
+   if (matchid)
+   *matchid = devid;
+   return true;
 }
 
 static struct acpi_scan_handler *acpi_scan_match_handler(char *idstr,
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 84a2e29..ba679af 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -131,6 +131,7 @@ static inline struct acpi_hotplug_profile 
*to_acpi_hotplug_profile(
 struct acpi_scan_handler {
const struct acpi_device_id *ids;
struct list_head list_node;
+   int (*match)(char *devid, char *handler_id);
int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
void (*detach)(struct acpi_device *dev);
void (*bind)(struct device *phys_dev);
-- 
1.8.3.2

--
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 V6 02/11] PNPACPI: use whilte list for pnpacpi device enumeration

[Zhang Rui]

ACPI can be used to enumerate PNP devices, but the code does not
handle this in a good manner.

Currently, if an ACPI device
1. has _CRS method,
2. has an identifications of
   "three capital charactors followed by four hex numbers",
3. is not in the excluded id list,
it is enumerated to PNP bus.

So actually, PNP bus is used as the default bus for enumerating _HID devices.

But, nowadays, more and more _HID devices are needed to be enumerate to
platform bus instead. And a white list is used for those devices to avoid
overlapping with PNP bus.
The problem is that this list is continuously growing.

So, a solution that uses platform bus as the default bus for _HID enumeration
is preferred.
In order to do this, this patch changes the way of enumerating PNP devices.
As the first step, we use a white list (scan handler) to create PNP devices
instead. This white list contains all the pnp_device_id strings in all the pnp
drivers, thus this change is transparent to PNP core and all the PNP drivers.

Note: I just grep all the id strings in all pnp_device_id instances and
  copy them to the new white list, with a few changes to the comments
  only, to follow the format of:

  /* driver name, or file name if not a PNP driver */
  {"id-string"}, /* optional comments for the id-string */
  ...

Note: the PNPACPI devices are created in two step,
  1. mark the PNPACPI devices by the acpi pnp scan handler.
  2. create the PNPACPI devices in PNPACPI code in a fs_initcall()
  In this case, if PNP/PNPACPI is not set or "pnpacpi=off" kernel option
  is used, the acpi pnp scan handler is still there, to prevent those
  PNPACPI devices from being created to platform bus.

Note: For CMOS RTC devices, the acpi pnp scan handler does not work because
  there is already a cmos rtc scan handler installed, thus we need to
  check those devices and enumerate them to PNP bus explicitly.
  Plus, the cmos rtc scan handler needs to return 1 so that it will not
  be enumerated to platform bus.

TODO: Reduce this PNPACPI white list by
  1. remove the ids for the devices that are never enumerated via ACPI
  2. remove the ids and convert the drivers to platform bus drivers
 for the devices that are not PNP devices in nature.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/Makefile|   1 +
 drivers/acpi/acpi_cmos_rtc.c |   2 +-
 drivers/acpi/acpi_pnp.c  | 388 +++
 drivers/acpi/internal.h  |   1 +
 drivers/acpi/scan.c  |   1 +
 drivers/pnp/pnpacpi/core.c   |  28 +---
 include/linux/acpi.h |   2 +
 7 files changed, 398 insertions(+), 25 deletions(-)
 create mode 100644 drivers/acpi/acpi_pnp.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..9a43893 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,6 +41,7 @@ acpi-$(CONFIG_ACPI_DOCK)  += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
 acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
 acpi-y += acpi_platform.o
+acpi-y += acpi_pnp.o
 acpi-y += power.o
 acpi-y += event.o
 acpi-y += sysfs.o
diff --git a/drivers/acpi/acpi_cmos_rtc.c b/drivers/acpi/acpi_cmos_rtc.c
index 961b45d..2da8660 100644
--- a/drivers/acpi/acpi_cmos_rtc.c
+++ b/drivers/acpi/acpi_cmos_rtc.c
@@ -68,7 +68,7 @@ static int acpi_install_cmos_rtc_space_handler(struct 
acpi_device *adev,
return -ENODEV;
}
 
-   return 0;
+   return 1;
 }
 
 static void acpi_remove_cmos_rtc_space_handler(struct acpi_device *adev)
diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
new file mode 100644
index 000..57d14ed
--- /dev/null
+++ b/drivers/acpi/acpi_pnp.c
@@ -0,0 +1,388 @@
+/*
+ * ACPI support for PNP bus type
+ *
+ * Copyright (C) 2014, Intel Corporation
+ * Authors: Zhang Rui 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+static const struct acpi_device_id acpi_pnp_device_ids[] = {
+   /* pata_isapnp */
+   {"PNP0600"},/* Generic ESDI/IDE/ATA compatible hard disk 
controller */
+   /* floppy */
+   {"PNP0700"},
+   /* ipmi_si */
+   {"IPI0001"},
+   /* tpm_inf_pnp */
+   {"IFX0101"},/* Infineon TPMs */
+   {"IFX0102"},/* Infineon TPMs */
+   /*tpm_tis */
+   {"PNP0C31"},/* TPM */
+   {"ATM1200"},/* Atmel */
+   {"IFX0102"},/* Infineon */
+   {"BCM0101"},/* Broadcom */
+   {"BCM0102"},/* Broadcom *

[PATCH V6 07/11] ACPI: introduce dummy lpss scan handler

[Zhang Rui]

The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.

Fix this problem for lpss devices by introducing a dummy
lpss scan handler in this patch.

Plus, if lpt_clk_init() fails, we need this dummy scan handler as well.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/Makefile|  2 +-
 drivers/acpi/acpi_lpss.c | 69 ++--
 drivers/acpi/internal.h  |  4 ---
 3 files changed, 50 insertions(+), 25 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 171efc2..605eff7 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -39,7 +39,7 @@ acpi-y+= processor_core.o
 acpi-y += ec.o
 acpi-$(CONFIG_ACPI_DOCK)   += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
-acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
+acpi-y += acpi_lpss.o
 acpi-y += acpi_platform.o
 acpi-y += acpi_pnp.o
 acpi-y += power.o
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 69e29f4..965428f 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -24,6 +24,8 @@
 
 ACPI_MODULE_NAME("acpi_lpss");
 
+#ifdef CONFIG_X86_INTEL_LPSS
+
 #define LPSS_CLK_SIZE  0x04
 #define LPSS_LTR_SIZE  0x18
 
@@ -159,40 +161,50 @@ static struct lpss_device_desc byt_i2c_dev_desc = {
.shared_clock = _clock,
 };
 
+#define LPSS_PTR(desc) ((unsigned long))
+
+#else
+
+#define LPSS_PTR(desc) 0
+
+#endif
+
 static const struct acpi_device_id acpi_lpss_device_ids[] = {
/* Generic LPSS devices */
-   { "INTL9C60", (unsigned long)_dma_desc },
+   { "INTL9C60", LPSS_PTR(lpss_dma_desc) },
 
/* Lynxpoint LPSS devices */
-   { "INT33C0", (unsigned long)_dev_desc },
-   { "INT33C1", (unsigned long)_dev_desc },
-   { "INT33C2", (unsigned long)_dev_desc },
-   { "INT33C3", (unsigned long)_dev_desc },
-   { "INT33C4", (unsigned long)_uart_dev_desc },
-   { "INT33C5", (unsigned long)_uart_dev_desc },
-   { "INT33C6", (unsigned long)_sdio_dev_desc },
+   { "INT33C0", LPSS_PTR(lpt_dev_desc) },
+   { "INT33C1", LPSS_PTR(lpt_dev_desc) },
+   { "INT33C2", LPSS_PTR(lpt_dev_desc) },
+   { "INT33C3", LPSS_PTR(lpt_dev_desc) },
+   { "INT33C4", LPSS_PTR(lpt_uart_dev_desc) },
+   { "INT33C5", LPSS_PTR(lpt_uart_dev_desc) },
+   { "INT33C6", LPSS_PTR(lpt_sdio_dev_desc) },
{ "INT33C7", },
 
/* BayTrail LPSS devices */
-   { "80860F09", (unsigned long)_pwm_dev_desc },
-   { "80860F0A", (unsigned long)_uart_dev_desc },
-   { "80860F0E", (unsigned long)_spi_dev_desc },
-   { "80860F14", (unsigned long)_sdio_dev_desc },
-   { "80860F41", (unsigned long)_i2c_dev_desc },
+   { "80860F09", LPSS_PTR(byt_pwm_dev_desc) },
+   { "80860F0A", LPSS_PTR(byt_uart_dev_desc) },
+   { "80860F0E", LPSS_PTR(byt_spi_dev_desc) },
+   { "80860F14", LPSS_PTR(byt_sdio_dev_desc) },
+   { "80860F41", LPSS_PTR(byt_i2c_dev_desc) },
{ "INT33B2", },
 
-   { "INT3430", (unsigned long)_dev_desc },
-   { "INT3431", (unsigned long)_dev_desc },
-   { "INT3432", (unsigned long)_dev_desc },
-   { "INT3433", (unsigned long)_dev_desc },
-   { "INT3434", (unsigned long)_uart_dev_desc },
-   { "INT3435", (unsigned long)_uart_dev_desc },
-   { "INT3436", (unsigned long)_sdio_dev_desc },
+   { "INT3430", LPSS_PTR(lpt_dev_desc) },
+   { "INT3431", LPSS_PTR(lpt_dev_desc) },
+   { "INT3432", LPSS_PTR(lpt_dev_desc) },
+   { "INT3433", LPSS_PTR(lpt_dev_desc) },
+   { "INT3434", LPSS_PTR(lpt_uart_dev_desc) },
+   { "INT3435", LPSS_PTR(lpt_uart_dev_desc) },
+   { "INT3436", LPSS_PTR(lpt_sdio_dev_desc) },
{ "INT3437", },
 
{ }
 };
 
+#ifdef CONFIG_X86_INTEL_LPSS
+
 static int is_memory(struct acpi_resource *res, void *not_used)
 {
struct resource r;
@@ -511,10 +523,27 @@ static struct acpi_scan_handler lpss_handler = {
.unbind = acpi_lpss_unbind,
 };
 
+#endif /* CONFIG_X86_INTEL_LPSS */
+
+static int acpi_lpss_dummy_attach(struct acpi_device *adev,
+   const st

[PATCH V6 07/11] ACPI: introduce dummy lpss scan handler

[Zhang Rui]

The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.

Fix this problem for lpss devices by introducing a dummy
lpss scan handler in this patch.

Plus, if lpt_clk_init() fails, we need this dummy scan handler as well.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/Makefile|  2 +-
 drivers/acpi/acpi_lpss.c | 69 ++--
 drivers/acpi/internal.h  |  4 ---
 3 files changed, 50 insertions(+), 25 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 171efc2..605eff7 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -39,7 +39,7 @@ acpi-y+= processor_core.o
 acpi-y += ec.o
 acpi-$(CONFIG_ACPI_DOCK)   += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
-acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
+acpi-y += acpi_lpss.o
 acpi-y += acpi_platform.o
 acpi-y += acpi_pnp.o
 acpi-y += power.o
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 69e29f4..965428f 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -24,6 +24,8 @@
 
 ACPI_MODULE_NAME(acpi_lpss);
 
+#ifdef CONFIG_X86_INTEL_LPSS
+
 #define LPSS_CLK_SIZE  0x04
 #define LPSS_LTR_SIZE  0x18
 
@@ -159,40 +161,50 @@ static struct lpss_device_desc byt_i2c_dev_desc = {
.shared_clock = i2c_clock,
 };
 
+#define LPSS_PTR(desc) ((unsigned long)desc)
+
+#else
+
+#define LPSS_PTR(desc) 0
+
+#endif
+
 static const struct acpi_device_id acpi_lpss_device_ids[] = {
/* Generic LPSS devices */
-   { INTL9C60, (unsigned long)lpss_dma_desc },
+   { INTL9C60, LPSS_PTR(lpss_dma_desc) },
 
/* Lynxpoint LPSS devices */
-   { INT33C0, (unsigned long)lpt_dev_desc },
-   { INT33C1, (unsigned long)lpt_dev_desc },
-   { INT33C2, (unsigned long)lpt_dev_desc },
-   { INT33C3, (unsigned long)lpt_dev_desc },
-   { INT33C4, (unsigned long)lpt_uart_dev_desc },
-   { INT33C5, (unsigned long)lpt_uart_dev_desc },
-   { INT33C6, (unsigned long)lpt_sdio_dev_desc },
+   { INT33C0, LPSS_PTR(lpt_dev_desc) },
+   { INT33C1, LPSS_PTR(lpt_dev_desc) },
+   { INT33C2, LPSS_PTR(lpt_dev_desc) },
+   { INT33C3, LPSS_PTR(lpt_dev_desc) },
+   { INT33C4, LPSS_PTR(lpt_uart_dev_desc) },
+   { INT33C5, LPSS_PTR(lpt_uart_dev_desc) },
+   { INT33C6, LPSS_PTR(lpt_sdio_dev_desc) },
{ INT33C7, },
 
/* BayTrail LPSS devices */
-   { 80860F09, (unsigned long)byt_pwm_dev_desc },
-   { 80860F0A, (unsigned long)byt_uart_dev_desc },
-   { 80860F0E, (unsigned long)byt_spi_dev_desc },
-   { 80860F14, (unsigned long)byt_sdio_dev_desc },
-   { 80860F41, (unsigned long)byt_i2c_dev_desc },
+   { 80860F09, LPSS_PTR(byt_pwm_dev_desc) },
+   { 80860F0A, LPSS_PTR(byt_uart_dev_desc) },
+   { 80860F0E, LPSS_PTR(byt_spi_dev_desc) },
+   { 80860F14, LPSS_PTR(byt_sdio_dev_desc) },
+   { 80860F41, LPSS_PTR(byt_i2c_dev_desc) },
{ INT33B2, },
 
-   { INT3430, (unsigned long)lpt_dev_desc },
-   { INT3431, (unsigned long)lpt_dev_desc },
-   { INT3432, (unsigned long)lpt_dev_desc },
-   { INT3433, (unsigned long)lpt_dev_desc },
-   { INT3434, (unsigned long)lpt_uart_dev_desc },
-   { INT3435, (unsigned long)lpt_uart_dev_desc },
-   { INT3436, (unsigned long)lpt_sdio_dev_desc },
+   { INT3430, LPSS_PTR(lpt_dev_desc) },
+   { INT3431, LPSS_PTR(lpt_dev_desc) },
+   { INT3432, LPSS_PTR(lpt_dev_desc) },
+   { INT3433, LPSS_PTR(lpt_dev_desc) },
+   { INT3434, LPSS_PTR(lpt_uart_dev_desc) },
+   { INT3435, LPSS_PTR(lpt_uart_dev_desc) },
+   { INT3436, LPSS_PTR(lpt_sdio_dev_desc) },
{ INT3437, },
 
{ }
 };
 
+#ifdef CONFIG_X86_INTEL_LPSS
+
 static int is_memory(struct acpi_resource *res, void *not_used)
 {
struct resource r;
@@ -511,10 +523,27 @@ static struct acpi_scan_handler lpss_handler = {
.unbind = acpi_lpss_unbind,
 };
 
+#endif /* CONFIG_X86_INTEL_LPSS */
+
+static int acpi_lpss_dummy_attach(struct acpi_device *adev,
+   const struct acpi_device_id *id)
+{
+   return 1;
+}
+
+static struct acpi_scan_handler lpss_dummy_handler = {
+   .ids = acpi_lpss_device_ids,
+   .attach = acpi_lpss_dummy_attach,
+};
+
 void __init acpi_lpss_init(void)
 {
+#ifdef CONFIG_X86_INTEL_LPSS
if (!lpt_clk_init()) {
bus_register_notifier(platform_bus_type, acpi_lpss_nb);
acpi_scan_add_handler(lpss_handler);
+   return

[PATCH V6 01/11] ACPI: introduce .match() callback for ACPI scan handler

[Zhang Rui]

Currently, ACPI scan handler uses strcmp() to match device ids
and scan handler ids.

When converting PNPACPI enumeration into a scan handler, which I will do
later in this patch set, the current code becomes not flexible enough
because ACPI pnp scan handler requires wildcase and case insensitive support.

Thus a per scan handler .match() callback is introduced in this patch,
so that specified scan handler can have more flexible matching mechanism
by introduce its own .match() callback.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/scan.c | 17 +++--
 include/acpi/acpi_bus.h |  1 +
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 7efe546..e46e51c 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1974,14 +1974,19 @@ static bool acpi_scan_handler_matching(struct 
acpi_scan_handler *handler,
const struct acpi_device_id *devid;
 
for (devid = handler-ids; devid-id[0]; devid++)
-   if (!strcmp((char *)devid-id, idstr)) {
-   if (matchid)
-   *matchid = devid;
-
-   return true;
-   }
+   if (handler-match) {
+   if (handler-match(idstr, (char *)devid-id))
+   goto success;
+   } else
+   if (!strcmp((char *)devid-id, idstr))
+   goto success;
 
return false;
+
+success:
+   if (matchid)
+   *matchid = devid;
+   return true;
 }
 
 static struct acpi_scan_handler *acpi_scan_match_handler(char *idstr,
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 84a2e29..ba679af 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -131,6 +131,7 @@ static inline struct acpi_hotplug_profile 
*to_acpi_hotplug_profile(
 struct acpi_scan_handler {
const struct acpi_device_id *ids;
struct list_head list_node;
+   int (*match)(char *devid, char *handler_id);
int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
void (*detach)(struct acpi_device *dev);
void (*bind)(struct device *phys_dev);
-- 
1.8.3.2

--
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 V6 02/11] PNPACPI: use whilte list for pnpacpi device enumeration

[Zhang Rui]

ACPI can be used to enumerate PNP devices, but the code does not
handle this in a good manner.

Currently, if an ACPI device
1. has _CRS method,
2. has an identifications of
   three capital charactors followed by four hex numbers,
3. is not in the excluded id list,
it is enumerated to PNP bus.

So actually, PNP bus is used as the default bus for enumerating _HID devices.

But, nowadays, more and more _HID devices are needed to be enumerate to
platform bus instead. And a white list is used for those devices to avoid
overlapping with PNP bus.
The problem is that this list is continuously growing.

So, a solution that uses platform bus as the default bus for _HID enumeration
is preferred.
In order to do this, this patch changes the way of enumerating PNP devices.
As the first step, we use a white list (scan handler) to create PNP devices
instead. This white list contains all the pnp_device_id strings in all the pnp
drivers, thus this change is transparent to PNP core and all the PNP drivers.

Note: I just grep all the id strings in all pnp_device_id instances and
  copy them to the new white list, with a few changes to the comments
  only, to follow the format of:

  /* driver name, or file name if not a PNP driver */
  {id-string}, /* optional comments for the id-string */
  ...

Note: the PNPACPI devices are created in two step,
  1. mark the PNPACPI devices by the acpi pnp scan handler.
  2. create the PNPACPI devices in PNPACPI code in a fs_initcall()
  In this case, if PNP/PNPACPI is not set or pnpacpi=off kernel option
  is used, the acpi pnp scan handler is still there, to prevent those
  PNPACPI devices from being created to platform bus.

Note: For CMOS RTC devices, the acpi pnp scan handler does not work because
  there is already a cmos rtc scan handler installed, thus we need to
  check those devices and enumerate them to PNP bus explicitly.
  Plus, the cmos rtc scan handler needs to return 1 so that it will not
  be enumerated to platform bus.

TODO: Reduce this PNPACPI white list by
  1. remove the ids for the devices that are never enumerated via ACPI
  2. remove the ids and convert the drivers to platform bus drivers
 for the devices that are not PNP devices in nature.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/Makefile|   1 +
 drivers/acpi/acpi_cmos_rtc.c |   2 +-
 drivers/acpi/acpi_pnp.c  | 388 +++
 drivers/acpi/internal.h  |   1 +
 drivers/acpi/scan.c  |   1 +
 drivers/pnp/pnpacpi/core.c   |  28 +---
 include/linux/acpi.h |   2 +
 7 files changed, 398 insertions(+), 25 deletions(-)
 create mode 100644 drivers/acpi/acpi_pnp.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..9a43893 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,6 +41,7 @@ acpi-$(CONFIG_ACPI_DOCK)  += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
 acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
 acpi-y += acpi_platform.o
+acpi-y += acpi_pnp.o
 acpi-y += power.o
 acpi-y += event.o
 acpi-y += sysfs.o
diff --git a/drivers/acpi/acpi_cmos_rtc.c b/drivers/acpi/acpi_cmos_rtc.c
index 961b45d..2da8660 100644
--- a/drivers/acpi/acpi_cmos_rtc.c
+++ b/drivers/acpi/acpi_cmos_rtc.c
@@ -68,7 +68,7 @@ static int acpi_install_cmos_rtc_space_handler(struct 
acpi_device *adev,
return -ENODEV;
}
 
-   return 0;
+   return 1;
 }
 
 static void acpi_remove_cmos_rtc_space_handler(struct acpi_device *adev)
diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
new file mode 100644
index 000..57d14ed
--- /dev/null
+++ b/drivers/acpi/acpi_pnp.c
@@ -0,0 +1,388 @@
+/*
+ * ACPI support for PNP bus type
+ *
+ * Copyright (C) 2014, Intel Corporation
+ * Authors: Zhang Rui rui.zh...@intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/acpi.h
+#include linux/module.h
+
+static const struct acpi_device_id acpi_pnp_device_ids[] = {
+   /* pata_isapnp */
+   {PNP0600},/* Generic ESDI/IDE/ATA compatible hard disk 
controller */
+   /* floppy */
+   {PNP0700},
+   /* ipmi_si */
+   {IPI0001},
+   /* tpm_inf_pnp */
+   {IFX0101},/* Infineon TPMs */
+   {IFX0102},/* Infineon TPMs */
+   /*tpm_tis */
+   {PNP0C31},/* TPM */
+   {ATM1200},/* Atmel */
+   {IFX0102},/* Infineon */
+   {BCM0101},/* Broadcom */
+   {BCM0102},/* Broadcom */
+   {NSC1200},/* National */
+   {ICO0102},/* Intel */
+   /* ide

[PATCH V6 11/11] ACPI: introduce acpi platform exclude id list

[Zhang Rui]

For ACPI PIC (PNP), Timer (PNP0100) and DMA controller (PNP0200)
device objects, although they have _HID control method, but they
should not be enumerated to platform bus, because there will never be
any platform drivers for them.

Thus an exclude id list is introduced in this patch to prevent
those platform device nodes from being created.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/acpi_platform.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 33376a9..db89480 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -22,6 +22,18 @@
 
 ACPI_MODULE_NAME(platform);
 
+static const struct acpi_device_id excluded_id_list[] = {
+   {PNP, 0}, /* PIC */
+   {PNP0100, 0}, /* Timer */
+   {PNP0200, 0}, /* AT DMA Controller */
+   {, 0},
+};
+
+static bool is_exclusive_device(struct acpi_device *dev)
+{
+   return !acpi_match_device_ids(dev, excluded_id_list);
+}
+
 /**
  * acpi_create_platform_device - Create platform device for ACPI device node
  * @adev: ACPI device node to create a platform device for.
@@ -48,6 +60,9 @@ int acpi_create_platform_device(struct acpi_device *adev,
if (adev-physical_node_count)
return 0;
 
+   if (is_exclusive_device(adev))
+   return 0;
+
INIT_LIST_HEAD(resource_list);
count = acpi_dev_get_resources(adev, resource_list, NULL, NULL);
if (count  0) {
-- 
1.8.3.2

--
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 V6 09/11] ACPI: introduce flag .is_master_device

[Zhang Rui]

For some ACPI device objects, they represent master devices,
and their children devices are enumerated by bus controller drivers
for the buses they are on.

In this case, we do not want to enumerate their children devices to
platform bus explicitly in acpi scan code.

Thus a new flag .is_master_device is introduced in this patch.

For devices with this flag set, we will not do default enumeration
for their children.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/acpi_lpss.c | 62 +---
 include/acpi/acpi_bus.h  |  3 ++-
 2 files changed, 45 insertions(+), 20 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 965428f..4ab0915 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -54,6 +54,7 @@ struct lpss_shared_clock {
 struct lpss_private_data;
 
 struct lpss_device_desc {
+   bool is_master_device;
bool clk_required;
const char *clkdev_name;
bool ltr_required;
@@ -91,6 +92,7 @@ static void lpss_uart_setup(struct lpss_private_data *pdata)
 }
 
 static struct lpss_device_desc lpt_dev_desc = {
+   .is_master_device = true,
.clk_required = true,
.prv_offset = 0x800,
.ltr_required = true,
@@ -98,6 +100,7 @@ static struct lpss_device_desc lpt_dev_desc = {
 };
 
 static struct lpss_device_desc lpt_uart_dev_desc = {
+   .is_master_device = true,
.clk_required = true,
.prv_offset = 0x800,
.ltr_required = true,
@@ -106,6 +109,7 @@ static struct lpss_device_desc lpt_uart_dev_desc = {
 };
 
 static struct lpss_device_desc lpt_sdio_dev_desc = {
+   .is_master_device = true,
.prv_offset = 0x1000,
.prv_size_override = 0x1018,
.ltr_required = true,
@@ -127,6 +131,7 @@ static struct lpss_shared_clock uart_clock = {
 };
 
 static struct lpss_device_desc byt_uart_dev_desc = {
+   .is_master_device = true,
.clk_required = true,
.prv_offset = 0x800,
.clk_gate = true,
@@ -140,6 +145,7 @@ static struct lpss_shared_clock spi_clock = {
 };
 
 static struct lpss_device_desc byt_spi_dev_desc = {
+   .is_master_device = true,
.clk_required = true,
.prv_offset = 0x400,
.clk_gate = true,
@@ -147,6 +153,7 @@ static struct lpss_device_desc byt_spi_dev_desc = {
 };
 
 static struct lpss_device_desc byt_sdio_dev_desc = {
+   .is_master_device = true,
.clk_required = true,
 };
 
@@ -156,16 +163,24 @@ static struct lpss_shared_clock i2c_clock = {
 };
 
 static struct lpss_device_desc byt_i2c_dev_desc = {
+   .is_master_device = true,
.clk_required = true,
.prv_offset = 0x800,
.shared_clock = i2c_clock,
 };
 
 #define LPSS_PTR(desc) ((unsigned long)desc)
+#define LPSS_MASTER_PTR(desc) LPSS_PTR(desc)
 
 #else
 
-#define LPSS_PTR(desc) 0
+static struct lpss_device_desc lpss_dummy_desc;
+static struct lpss_device_desc lpss_dummy_master_desc = {
+   .is_master_device = true,
+};
+
+#define LPSS_PTR(desc) (lpss_dummy_desc)
+#define LPSS_MASTER_PTR(desc) (lpss_dummy_master_desc)
 
 #endif
 
@@ -174,30 +189,30 @@ static const struct acpi_device_id acpi_lpss_device_ids[] 
= {
{ INTL9C60, LPSS_PTR(lpss_dma_desc) },
 
/* Lynxpoint LPSS devices */
-   { INT33C0, LPSS_PTR(lpt_dev_desc) },
-   { INT33C1, LPSS_PTR(lpt_dev_desc) },
-   { INT33C2, LPSS_PTR(lpt_dev_desc) },
-   { INT33C3, LPSS_PTR(lpt_dev_desc) },
-   { INT33C4, LPSS_PTR(lpt_uart_dev_desc) },
-   { INT33C5, LPSS_PTR(lpt_uart_dev_desc) },
-   { INT33C6, LPSS_PTR(lpt_sdio_dev_desc) },
+   { INT33C0, LPSS_MASTER_PTR(lpt_dev_desc) },
+   { INT33C1, LPSS_MASTER_PTR(lpt_dev_desc) },
+   { INT33C2, LPSS_MASTER_PTR(lpt_dev_desc) },
+   { INT33C3, LPSS_MASTER_PTR(lpt_dev_desc) },
+   { INT33C4, LPSS_MASTER_PTR(lpt_uart_dev_desc) },
+   { INT33C5, LPSS_MASTER_PTR(lpt_uart_dev_desc) },
+   { INT33C6, LPSS_MASTER_PTR(lpt_sdio_dev_desc) },
{ INT33C7, },
 
/* BayTrail LPSS devices */
{ 80860F09, LPSS_PTR(byt_pwm_dev_desc) },
-   { 80860F0A, LPSS_PTR(byt_uart_dev_desc) },
-   { 80860F0E, LPSS_PTR(byt_spi_dev_desc) },
-   { 80860F14, LPSS_PTR(byt_sdio_dev_desc) },
-   { 80860F41, LPSS_PTR(byt_i2c_dev_desc) },
+   { 80860F0A, LPSS_MASTER_PTR(byt_uart_dev_desc) },
+   { 80860F0E, LPSS_MASTER_PTR(byt_spi_dev_desc) },
+   { 80860F14, LPSS_MASTER_PTR(byt_sdio_dev_desc) },
+   { 80860F41, LPSS_MASTER_PTR(byt_i2c_dev_desc) },
{ INT33B2, },
 
-   { INT3430, LPSS_PTR(lpt_dev_desc) },
-   { INT3431, LPSS_PTR(lpt_dev_desc) },
-   { INT3432, LPSS_PTR(lpt_dev_desc) },
-   { INT3433, LPSS_PTR(lpt_dev_desc) },
-   { INT3434, LPSS_PTR(lpt_uart_dev_desc) },
-   { INT3435, LPSS_PTR(lpt_uart_dev_desc) },
-   { INT3436, LPSS_PTR(lpt_sdio_dev_desc) },
+   { INT3430, LPSS_MASTER_PTR(lpt_dev_desc) },
+   { INT3431, LPSS_MASTER_PTR

[PATCH V6 04/11] ACPI: remove unsupported serial PNP ids from acpi pnp scan handler id lsit

[Zhang Rui]

The serial pnp driver supports some unknown PNP modems (PNPCXXX/PNPDXXX)
by matching magic strings in the pnp device name or the pnp device card name.

ACPI enumerated PNP device neither supports pnp card, nor supports those magic
strings in its device name, which means this mechamism never works for ACPI
enumerated PNPCXXX/PNPDXXX devices.
So it is safe to remove those two ids from the ACPI pnp scan handler id list.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/acpi_pnp.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
index d206616..a563a27 100644
--- a/drivers/acpi/acpi_pnp.c
+++ b/drivers/acpi/acpi_pnp.c
@@ -300,8 +300,6 @@ static const struct acpi_device_id acpi_pnp_device_ids[] = {
{LTS0001},/* LG C1 EXPRESS DUAL (C1-PB11A3) touch screen 
(actually a FUJ02E6 in disguise) */
{WCI0003},/* Rockwell's (PORALiNK) 33600 INT PNP */
{WEC1022},/* Winbond CIR port, should not be probed. We 
should keep track of it to prevent the legacy serial driver from probing it */
-   {PNPCXXX},/* Unknown PnP modems */
-   {PNPDXXX},/* More unknown PnP modems */
/* scl200wdt */
{NSC0800},/* National Semiconductor PC87307/PC97307 
watchdog component */
/* mpu401 */
-- 
1.8.3.2

--
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 V6 08/11] ACPI: introduce platform_id flag

[Zhang Rui]

Only certain kind of ACPI device objects can be enumerated to platform bus.
These ACPI device objects include
1. ACPI device objects that have _HID control method.
2. some ACPI device objects that have Linux specified HID strings.

In order to distinguish those device objects from the others, a new flag
platform_id and a new function acpi_add_platform_id() are introduced
in this patch.

Currently, only devices with _HID method have this flag set.
If you want platform devices to be created for device objects without _HID,
use acpi_add_platform_id() when adding artificial Linux-specific ID strings
to them.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/scan.c | 9 -
 include/acpi/acpi_bus.h | 3 ++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index c82ab73..451e7d9 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1730,6 +1730,13 @@ static void acpi_add_id(struct acpi_device_pnp *pnp, 
const char *dev_id)
pnp-type.hardware_id = 1;
 }
 
+static void acpi_add_platform_id(struct acpi_device_pnp *pnp,
+const char *dev_id)
+{
+   acpi_add_id(pnp, dev_id);
+   pnp-type.platform_id = 1;
+}
+
 /*
  * Old IBM workstations have a DSDT bug wherein the SMBus object
  * lacks the SMBUS01 HID and the methods do not have the necessary _
@@ -1794,7 +1801,7 @@ static void acpi_set_pnp_ids(acpi_handle handle, struct 
acpi_device_pnp *pnp,
}
 
if (info-valid  ACPI_VALID_HID)
-   acpi_add_id(pnp, info-hardware_id.string);
+   acpi_add_platform_id(pnp, info-hardware_id.string);
if (info-valid  ACPI_VALID_CID) {
cid_list = info-compatible_id_list;
for (i = 0; i  cid_list-count; i++)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index ba679af..ec92ad3 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -233,7 +233,8 @@ struct acpi_hardware_id {
 struct acpi_pnp_type {
u32 hardware_id:1;
u32 bus_address:1;
-   u32 reserved:30;
+   u32 platform_id:1;
+   u32 reserved:29;
 };
 
 struct acpi_device_pnp {
-- 
1.8.3.2

--
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 V6 05/11] ACPI: introduce dummy container scan handler

[Zhang Rui]

The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.

Fix this problem for container devices by introducing a dummy
container scan handler in this patch.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/Makefile|  2 +-
 drivers/acpi/container.c | 21 +
 drivers/acpi/internal.h  |  4 
 3 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9a43893..5611a07 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -63,7 +63,7 @@ obj-$(CONFIG_ACPI_FAN)+= fan.o
 obj-$(CONFIG_ACPI_VIDEO)   += video.o
 obj-$(CONFIG_ACPI_PCI_SLOT)+= pci_slot.o
 obj-$(CONFIG_ACPI_PROCESSOR)   += processor.o
-obj-$(CONFIG_ACPI_CONTAINER)   += container.o
+obj-y  += container.o
 obj-$(CONFIG_ACPI_THERMAL) += thermal.o
 obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
 obj-$(CONFIG_ACPI_BATTERY) += battery.o
diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
index 63119d0..9100db7 100644
--- a/drivers/acpi/container.c
+++ b/drivers/acpi/container.c
@@ -41,6 +41,8 @@ static const struct acpi_device_id container_device_ids[] = {
{, 0},
 };
 
+#ifdef CONFIG_ACPI_CONTAINER
+
 static int acpi_container_offline(struct container_dev *cdev)
 {
struct acpi_device *adev = ACPI_COMPANION(cdev-dev);
@@ -111,3 +113,22 @@ void __init acpi_container_init(void)
 {
acpi_scan_add_handler_with_hotplug(container_handler, container);
 }
+
+#else
+
+static inline int container_device_attach(struct acpi_device *adev,
+   const struct acpi_device_id *not_used)
+{
+   return 1;
+}
+
+static struct acpi_scan_handler container_handler = {
+   .ids = container_device_ids,
+   .attach = container_device_attach,
+};
+
+void __init acpi_container_init(void)
+{
+   acpi_scan_add_handler(container_handler);
+}
+#endif /* CONFIG_ACPI_CONTAINER */
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 3a12866..499908e 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -32,11 +32,7 @@ void acpi_processor_init(void);
 void acpi_platform_init(void);
 void acpi_pnp_init(void);
 int acpi_sysfs_init(void);
-#ifdef CONFIG_ACPI_CONTAINER
 void acpi_container_init(void);
-#else
-static inline void acpi_container_init(void) {}
-#endif
 #ifdef CONFIG_ACPI_DOCK
 void register_dock_dependent_device(struct acpi_device *adev,
acpi_handle dshandle);
-- 
1.8.3.2

--
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 V6 06/11] ACPI: introduce dummy memory hotplug scan handler

[Zhang Rui]

The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.

Fix this problem for memory hotplug devuces by introducing a dummy
memory hotplug scan handler in this patch.

Plus, the dummy memory hotplug scan handler is also needed when
kernel parameter acpi_no_memhotplug is used.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/Makefile  |  2 +-
 drivers/acpi/acpi_memhotplug.c | 45 ++
 drivers/acpi/internal.h|  6 +-
 3 files changed, 34 insertions(+), 19 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 5611a07..171efc2 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -65,7 +65,7 @@ obj-$(CONFIG_ACPI_PCI_SLOT)   += pci_slot.o
 obj-$(CONFIG_ACPI_PROCESSOR)   += processor.o
 obj-y  += container.o
 obj-$(CONFIG_ACPI_THERMAL) += thermal.o
-obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
+obj-y  += acpi_memhotplug.o
 obj-$(CONFIG_ACPI_BATTERY) += battery.o
 obj-$(CONFIG_ACPI_SBS) += sbshc.o
 obj-$(CONFIG_ACPI_SBS) += sbs.o
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index b67be85..ed2f6a7 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -44,6 +44,13 @@
 
 ACPI_MODULE_NAME(acpi_memhotplug);
 
+static const struct acpi_device_id memory_device_ids[] = {
+   {ACPI_MEMORY_DEVICE_HID, 0},
+   {, 0},
+};
+
+#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
+
 /* Memory Device States */
 #define MEMORY_INVALID_STATE   0
 #define MEMORY_POWER_ON_STATE  1
@@ -53,11 +60,6 @@ static int acpi_memory_device_add(struct acpi_device *device,
  const struct acpi_device_id *not_used);
 static void acpi_memory_device_remove(struct acpi_device *device);
 
-static const struct acpi_device_id memory_device_ids[] = {
-   {ACPI_MEMORY_DEVICE_HID, 0},
-   {, 0},
-};
-
 static struct acpi_scan_handler memory_device_handler = {
.ids = memory_device_ids,
.attach = acpi_memory_device_add,
@@ -362,17 +364,34 @@ static void acpi_memory_device_remove(struct acpi_device 
*device)
 
 static bool __initdata acpi_no_memhotplug;
 
-void __init acpi_memory_hotplug_init(void)
-{
-   if (acpi_no_memhotplug)
-   return;
-
-   acpi_scan_add_handler_with_hotplug(memory_device_handler, memory);
-}
-
 static int __init disable_acpi_memory_hotplug(char *str)
 {
acpi_no_memhotplug = true;
return 1;
 }
 __setup(acpi_no_memhotplug, disable_acpi_memory_hotplug);
+
+#endif
+
+static int acpi_memory_dummy_add(struct acpi_device *device,
+const struct acpi_device_id *not_used)
+{
+   return 1;
+}
+
+static struct acpi_scan_handler memory_dummy_handler = {
+   .ids = memory_device_ids,
+   .attach = acpi_memory_dummy_add,
+};
+
+void __init acpi_memory_hotplug_init(void)
+{
+#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
+   if (!acpi_no_memhotplug) {
+   acpi_scan_add_handler_with_hotplug(memory_device_handler,
+   memory);
+   return;
+   }
+#endif
+   acpi_scan_add_handler(memory_dummy_handler);
+}
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 499908e..4a9e999 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -33,6 +33,7 @@ void acpi_platform_init(void);
 void acpi_pnp_init(void);
 int acpi_sysfs_init(void);
 void acpi_container_init(void);
+void acpi_memory_hotplug_init(void);
 #ifdef CONFIG_ACPI_DOCK
 void register_dock_dependent_device(struct acpi_device *adev,
acpi_handle dshandle);
@@ -44,11 +45,6 @@ static inline void register_dock_dependent_device(struct 
acpi_device *adev,
 static inline int dock_notify(struct acpi_device *adev, u32 event) { return 
-ENODEV; }
 static inline void acpi_dock_add(struct acpi_device *adev) {}
 #endif
-#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
-void acpi_memory_hotplug_init(void);
-#else
-static inline void acpi_memory_hotplug_init(void) {}
-#endif
 #ifdef CONFIG_X86
 void acpi_cmos_rtc_init(void);
 #else
-- 
1.8.3.2

--
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 V6 10/11] ACPI: use platform bus as the default bus for _HID enumeration

[Zhang Rui]

Because of the growing demand for enumerating ACPI devices to
platform bus, this patch changes the code to enumerate ACPI
devices to platform bus by default, if the device
1. has _HID.
2. does not have a scan handler attached.
3. will not be enumerated by its parent.

Signed-off-by: Zhang Rui rui.zh...@intel.com
---
 drivers/acpi/acpi_platform.c | 28 
 drivers/acpi/scan.c  | 25 -
 2 files changed, 24 insertions(+), 29 deletions(-)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index dbfe49e..33376a9 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -22,24 +22,6 @@
 
 ACPI_MODULE_NAME(platform);
 
-/*
- * The following ACPI IDs are known to be suitable for representing as
- * platform devices.
- */
-static const struct acpi_device_id acpi_platform_device_ids[] = {
-
-   { PNP0D40 },
-   { ACPI0003 },
-   { VPC2004 },
-   { BCM4752 },
-
-   /* Intel Smart Sound Technology */
-   { INT33C8 },
-   { 80860F28 },
-
-   { }
-};
-
 /**
  * acpi_create_platform_device - Create platform device for ACPI device node
  * @adev: ACPI device node to create a platform device for.
@@ -125,13 +107,3 @@ int acpi_create_platform_device(struct acpi_device *adev,
kfree(resources);
return 1;
 }
-
-static struct acpi_scan_handler platform_handler = {
-   .ids = acpi_platform_device_ids,
-   .attach = acpi_create_platform_device,
-};
-
-void __init acpi_platform_init(void)
-{
-   acpi_scan_add_handler(platform_handler);
-}
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 451e7d9..756977e 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2073,6 +2073,27 @@ static acpi_status acpi_bus_check_add(acpi_handle 
handle, u32 lvl_not_used,
return AE_OK;
 }
 
+static void acpi_do_default_enumeration(struct acpi_device *device)
+{
+   /*
+* Do not do enumeration for device object that has been/will be
+* enumerated by its parent.
+*/
+   if (device-parent  device-parent-flags.is_master_device)
+   return;
+
+   /* Do not do enumeration for device object with scan handler attached */
+   if (device-handler)
+   return;
+
+   /* Do not do enumeration for device object w/o platform_id */
+   if (!device-pnp.type.platform_id)
+   return;
+
+   acpi_create_platform_device(device, NULL);
+}
+
+
 static int acpi_scan_attach_handler(struct acpi_device *device)
 {
struct acpi_hardware_id *hwid;
@@ -2094,6 +2115,9 @@ static int acpi_scan_attach_handler(struct acpi_device 
*device)
break;
}
}
+
+   acpi_do_default_enumeration(device);
+
return ret;
 }
 
@@ -2253,7 +2277,6 @@ int __init acpi_scan_init(void)
acpi_pci_root_init();
acpi_pci_link_init();
acpi_processor_init();
-   acpi_platform_init();
acpi_lpss_init();
acpi_cmos_rtc_init();
acpi_container_init();
-- 
1.8.3.2

--
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/