[PATCH] ACPI_IBM_BAY can not coexist with ACPI_BAY

[PATCH] ACPI_IBM_BAY can not coexist with ACPI_BAY

[Chris Wedgwood]

ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI
code to fail to initialize so all the IBM ACPI functionality is
missing.  The simplest fix is to just make sure the Kconfig magic
disallows ACPI_IBM_BAY when ACPI_BAY is enabled.

Signed-off-by: Chris Wedgwood <cw@f00f.org>

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index e2ce4a9..1a83fc6 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -246,7 +246,7 @@ config ACPI_IBM_DOCK
 
 config ACPI_IBM_BAY
 	bool "Legacy Removable Bay Support"
-	depends on ACPI_IBM
+	depends on ACPI_IBM && !ACPI_BAY
 	default y
 	---help---
 	  Allows the ibm_acpi driver to handle removable bays.  It will allow

Re: [PATCH] ACPI_IBM_BAY can not coexist with ACPI_BAY

[Henrique de Moraes Holschuh]

On Thu, 15 Mar 2007, Chris Wedgwood wrote:
> ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI
> code to fail to initialize so all the IBM ACPI functionality is
> missing.  The simplest fix is to just make sure the Kconfig magic
> disallows ACPI_IBM_BAY when ACPI_BAY is enabled.
> 
> Signed-off-by: Chris Wedgwood <cw@f00f.org>

I'd really like to know why the two can't coexist, first.  And I'd really
prefer a patch that make the two load and run with bay functionality
concurrently.  ACPI_BAY doesn't work right with bay batteries, and I didn't
find a way to fix that yet (or I'd have sent in patches).

Otherwise, please change the patch to a "depends on ACPI_BAY=n ||
ACPI_BAY=m".

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH] ACPI_IBM_BAY can not coexist with ACPI_BAY

[Henrique de Moraes Holschuh]

On Thu, 15 Mar 2007, Chris Wedgwood wrote:
> ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI
> code to fail to initialize so all the IBM ACPI functionality is
> missing.  The simplest fix is to just make sure the Kconfig magic
> disallows ACPI_IBM_BAY when ACPI_BAY is enabled.
> 
> Signed-off-by: Chris Wedgwood <cw@f00f.org>

NAK.

I have looked into this issue, and I am working on a better fix to ibm-acpi
that allows it to coexist somewhat with ACPI_BAY (by disabling ibm-acpi bay
functionality at runtime if ACPI_BAY is loaded).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[PATCH] ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set

[Henrique de Moraes Holschuh]

This patch allows for ibm-acpi to coexist (with diminished functionality) with
other drivers like ACPI_BAY.  ibm-acpi will simply disable the functions it is
not able to register ACPI notifiers for.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Chris Wedgwood <cw@f00f.org>
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
---

 Len, you can pull this patch from:
 git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
 branch for-upstream/acpi-release

 Please send it to Linus for merge in 2.6.21.

 It will clash with the patches in acpi-test that are waiting for 2.6.22.
 I will rediff those, and send you a pull request when this patch
 gets accepted in mainline.

 drivers/acpi/ibm_acpi.c |   17 ++++++++++++++---
 1 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 3690136..f9f36f9 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -2507,7 +2507,7 @@ static int __init setup_notify(struct ibm_struct *ibm)
 	ret = acpi_bus_get_device(*ibm->handle, &ibm->device);
 	if (ret < 0) {
 		printk(IBM_ERR "%s device not present\n", ibm->name);
-		return 0;
+		return -ENODEV;
 	}
 
 	acpi_driver_data(ibm->device) = ibm;
@@ -2516,8 +2516,13 @@ static int __init setup_notify(struct ibm_struct *ibm)
 	status = acpi_install_notify_handler(*ibm->handle, ibm->type,
 					     dispatch_notify, ibm);
 	if (ACPI_FAILURE(status)) {
-		printk(IBM_ERR "acpi_install_notify_handler(%s) failed: %d\n",
-		       ibm->name, status);
+		if (status == AE_ALREADY_EXISTS) {
+			printk(IBM_NOTICE "another device driver is already handling %s events\n",
+				ibm->name);
+		} else {
+			printk(IBM_ERR "acpi_install_notify_handler(%s) failed: %d\n",
+				ibm->name, status);
+		}
 		return -ENODEV;
 	}
 	ibm->notify_installed = 1;
@@ -2594,6 +2599,12 @@ static int __init ibm_init(struct ibm_struct *ibm)
 
 	if (ibm->notify) {
 		ret = setup_notify(ibm);
+		if (ret == -ENODEV) {
+			printk(IBM_NOTICE "disabling subdriver %s\n",
+				ibm->name);
+			ibm_exit(ibm);
+			return 0;
+		}
 		if (ret < 0)
 			return ret;
 	}
-- 
1.5.0.3


-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[PATCH] ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set (v2)

[Henrique de Moraes Holschuh]

This patch allows for ibm-acpi to coexist (with diminished functionality) with
other drivers like ACPI_BAY.  ibm-acpi will simply disable the functions it is
not able to register ACPI notifiers for.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Chris Wedgwood <cw@f00f.org>
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
---

 There was a minor problem in the first version of the patch, which I didn't
 notice when backporting from acpi-test.  This is a fixed version.  Sorry
 about this.

 Len, you can pull this patch from:
 git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
 branch for-upstream/acpi-release
 
 Please send it to Linus for merge in 2.6.21.
 
 It will clash with the patches in acpi-test that are waiting for 2.6.22.
 I will rediff those, and send you a pull request when this patch
 gets accepted in mainline.

 drivers/acpi/ibm_acpi.c |   19 ++++++++++++++++---
 1 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 3690136..dc10966 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -2507,7 +2507,7 @@ static int __init setup_notify(struct ibm_struct *ibm)
 	ret = acpi_bus_get_device(*ibm->handle, &ibm->device);
 	if (ret < 0) {
 		printk(IBM_ERR "%s device not present\n", ibm->name);
-		return 0;
+		return -ENODEV;
 	}
 
 	acpi_driver_data(ibm->device) = ibm;
@@ -2516,8 +2516,13 @@ static int __init setup_notify(struct ibm_struct *ibm)
 	status = acpi_install_notify_handler(*ibm->handle, ibm->type,
 					     dispatch_notify, ibm);
 	if (ACPI_FAILURE(status)) {
-		printk(IBM_ERR "acpi_install_notify_handler(%s) failed: %d\n",
-		       ibm->name, status);
+		if (status == AE_ALREADY_EXISTS) {
+			printk(IBM_NOTICE "another device driver is already handling %s events\n",
+				ibm->name);
+		} else {
+			printk(IBM_ERR "acpi_install_notify_handler(%s) failed: %d\n",
+				ibm->name, status);
+		}
 		return -ENODEV;
 	}
 	ibm->notify_installed = 1;
@@ -2553,6 +2558,8 @@ static int __init register_driver(struct ibm_struct *ibm)
 	return ret;
 }
 
+static void ibm_exit(struct ibm_struct *ibm);
+
 static int __init ibm_init(struct ibm_struct *ibm)
 {
 	int ret;
@@ -2594,6 +2601,12 @@ static int __init ibm_init(struct ibm_struct *ibm)
 
 	if (ibm->notify) {
 		ret = setup_notify(ibm);
+		if (ret == -ENODEV) {
+			printk(IBM_NOTICE "disabling subdriver %s\n",
+				ibm->name);
+			ibm_exit(ibm);
+			return 0;
+		}
 		if (ret < 0)
 			return ret;
 	}
-- 
1.5.0.3

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH] ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set (v2)

[Len Brown]

Applied.


On Thursday 15 March 2007 15:15, Henrique de Moraes Holschuh wrote:
> This patch allows for ibm-acpi to coexist (with diminished functionality) with
> other drivers like ACPI_BAY.  ibm-acpi will simply disable the functions it is
> not able to register ACPI notifiers for.
> 
> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Cc: Chris Wedgwood <cw@f00f.org>
> Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
> ---
> 
>  There was a minor problem in the first version of the patch, which I didn't
>  notice when backporting from acpi-test.  This is a fixed version.  Sorry
>  about this.
> 
>  Len, you can pull this patch from:
>  git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
>  branch for-upstream/acpi-release
>  
>  Please send it to Linus for merge in 2.6.21.
>  
>  It will clash with the patches in acpi-test that are waiting for 2.6.22.
>  I will rediff those, and send you a pull request when this patch
>  gets accepted in mainline.

ok

thanks Henrique,
-Len


>  drivers/acpi/ibm_acpi.c |   19 ++++++++++++++++---
>  1 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
> index 3690136..dc10966 100644
> --- a/drivers/acpi/ibm_acpi.c
> +++ b/drivers/acpi/ibm_acpi.c
> @@ -2507,7 +2507,7 @@ static int __init setup_notify(struct ibm_struct *ibm)
>  	ret = acpi_bus_get_device(*ibm->handle, &ibm->device);
>  	if (ret < 0) {
>  		printk(IBM_ERR "%s device not present\n", ibm->name);
> -		return 0;
> +		return -ENODEV;
>  	}
>  
>  	acpi_driver_data(ibm->device) = ibm;
> @@ -2516,8 +2516,13 @@ static int __init setup_notify(struct ibm_struct *ibm)
>  	status = acpi_install_notify_handler(*ibm->handle, ibm->type,
>  					     dispatch_notify, ibm);
>  	if (ACPI_FAILURE(status)) {
> -		printk(IBM_ERR "acpi_install_notify_handler(%s) failed: %d\n",
> -		       ibm->name, status);
> +		if (status == AE_ALREADY_EXISTS) {
> +			printk(IBM_NOTICE "another device driver is already handling %s events\n",
> +				ibm->name);
> +		} else {
> +			printk(IBM_ERR "acpi_install_notify_handler(%s) failed: %d\n",
> +				ibm->name, status);
> +		}
>  		return -ENODEV;
>  	}
>  	ibm->notify_installed = 1;
> @@ -2553,6 +2558,8 @@ static int __init register_driver(struct ibm_struct *ibm)
>  	return ret;
>  }
>  
> +static void ibm_exit(struct ibm_struct *ibm);
> +
>  static int __init ibm_init(struct ibm_struct *ibm)
>  {
>  	int ret;
> @@ -2594,6 +2601,12 @@ static int __init ibm_init(struct ibm_struct *ibm)
>  
>  	if (ibm->notify) {
>  		ret = setup_notify(ibm);
> +		if (ret == -ENODEV) {
> +			printk(IBM_NOTICE "disabling subdriver %s\n",
> +				ibm->name);
> +			ibm_exit(ibm);
> +			return 0;
> +		}
>  		if (ret < 0)
>  			return ret;
>  	}
> -- 
> 1.5.0.3
> 

Re: [PATCH] ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set

[Chris Wedgwood]

On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote:

> This patch allows for ibm-acpi to coexist (with diminished
> functionality) with other drivers like ACPI_BAY.

Given the ACP_IBM_BAY implementation is more complete (or seems to be,
please comment if that isn't the case) we should probably actually
make sure that is the *preferred* code used (on suitable hardware) at
run time surely?

That way distributions can build both options and on IBM/Lenovo
hardware it will use the IBM ACPI code and otherwise will use the
generic ACPI BAY code?

Perhaps the IBM_ACPI_BAY code should go away and any missing
functionality provided there should be merged into ACPI_BAY?

Re: [PATCH] ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set

[Kristen Carlson Accardi]

On Thu, 15 Mar 2007 12:17:21 -0700
Chris Wedgwood <cw@f00f.org> wrote:

> On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote:
> 
> > This patch allows for ibm-acpi to coexist (with diminished
> > functionality) with other drivers like ACPI_BAY.
> 
> Given the ACP_IBM_BAY implementation is more complete (or seems to be,
> please comment if that isn't the case) we should probably actually
> make sure that is the *preferred* code used (on suitable hardware) at
> run time surely?

I haven't followed the ibm_acpi development lately, but when I first
wrote the bay driver, it had a couple features that ibm_acpi didn't have,
and then of course, is missing some it does have.  What used to be the
case is that if bay was inserted after the laptop was booted, the ibm_acpi
driver would not capture the events because it would only install it's 
notifier at driver load time on bay devices that existed.  The second
case is that if you are using the generic dock driver (which is more
funtional than the ibm_acpi dock feature), for certain ibm laptops such
as the X60, you need to have undock events sent to the bay device so that
it can alert user space to unmount cd's etc (since the bay is on the ultrabase).

> 
> That way distributions can build both options and on IBM/Lenovo
> hardware it will use the IBM ACPI code and otherwise will use the
> generic ACPI BAY code?

I think for now this is a good idea - the ibm_acpi solution should be
preferred over the generic bay driver till it is more fully developed.
I don't know how to ensure this is done wrt load order though.

> 
> Perhaps the IBM_ACPI_BAY code should go away and any missing
> functionality provided there should be merged into ACPI_BAY?
> 

I think this is a good idea.  It would certainly be less confusing for users.
too late for this release though, perhaps this can be targetted at 2.6.22/23?

Re: [ibm-acpi-devel] [PATCH] ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set

[Henrique de Moraes Holschuh]

On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote:
> I haven't followed the ibm_acpi development lately, but when I first
> wrote the bay driver, it had a couple features that ibm_acpi didn't have,
> and then of course, is missing some it does have.  What used to be the
> case is that if bay was inserted after the laptop was booted, the ibm_acpi
> driver would not capture the events because it would only install it's 
> notifier at driver load time on bay devices that existed.  The second

This is still true, I didn't bother fixing it because I'd rather expend "bay
time" trying to get the generic driver to work OK in thinkpads, but I have
been otherwise distracted with other ibm-acpi things, like a sysfs
conversion.

> as the X60, you need to have undock events sent to the bay device so that
> it can alert user space to unmount cd's etc (since the bay is on the ultrabase).

This is also still true.

BTW, currently the bay driver seems to have lost a lot of functionality, I
remember older incarnations of it (before it went platform-driver) caused
unplugs to be clean instead of driving libata nuts...  Am I recalling this
incorrectly?

> I think for now this is a good idea - the ibm_acpi solution should be
> preferred over the generic bay driver till it is more fully developed.
> I don't know how to ensure this is done wrt load order though.

Nor do I, and sincerely, if one is doing what some rpm distros are and
loading every ACPI module in a for loop at boot time, I don't want to know.
It is their mess to fix.  I just have ibm-acpi in my /etc/modules, and
arranged it to be loaded BEFORE any such distro crap (not that Debian has
it, but still...).

What we *can* do is to have DMI-based coldplug capabilities added, and work
from there to get udev to autoload devices.  And that still won't be 100%
failure-proof, but nothing is.

> I think this is a good idea.  It would certainly be less confusing for users.
> too late for this release though, perhaps this can be targetted at 2.6.22/23?

That's something I'd like to happen.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH] ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set

[Holger Macht]

On Thu 15. Mar - 12:37:32, Kristen Carlson Accardi wrote:
> On Thu, 15 Mar 2007 12:17:21 -0700
> Chris Wedgwood <cw@f00f.org> wrote:
> 
> > On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote:
> > 
> > > This patch allows for ibm-acpi to coexist (with diminished
> > > functionality) with other drivers like ACPI_BAY.
> > 
> > Given the ACP_IBM_BAY implementation is more complete (or seems to be,
> > please comment if that isn't the case) we should probably actually
> > make sure that is the *preferred* code used (on suitable hardware) at
> > run time surely?
> 
> I haven't followed the ibm_acpi development lately, but when I first
> wrote the bay driver, it had a couple features that ibm_acpi didn't have,
> and then of course, is missing some it does have.  What used to be the
> case is that if bay was inserted after the laptop was booted, the ibm_acpi
> driver would not capture the events because it would only install it's 
> notifier at driver load time on bay devices that existed.  The second
> case is that if you are using the generic dock driver (which is more
> funtional than the ibm_acpi dock feature), for certain ibm laptops such
> as the X60, you need to have undock events sent to the bay device so that
> it can alert user space to unmount cd's etc (since the bay is on the ultrabase).

But there's currently an issue with the second case you're talking
about. The dock driver doesn't generate any event in the bay driver on
undock. And due to the fact that the dock driver automatically issues a
ACPI undock, the hardware indication on the dock station signals
"everything alright" to the user so there's no way to tell the user that
he is not allowed to pull away the docking station because there's still
some file system mounted inside the cdrom. Userspace would need some time
to handle that IMHO.

Just a note,
  Holger

> 
> > 
> > That way distributions can build both options and on IBM/Lenovo
> > hardware it will use the IBM ACPI code and otherwise will use the
> > generic ACPI BAY code?
> 
> I think for now this is a good idea - the ibm_acpi solution should be
> preferred over the generic bay driver till it is more fully developed.
> I don't know how to ensure this is done wrt load order though.
> 
> > 
> > Perhaps the IBM_ACPI_BAY code should go away and any missing
> > functionality provided there should be merged into ACPI_BAY?
> > 
> 
> I think this is a good idea.  It would certainly be less confusing for users.
> too late for this release though, perhaps this can be targetted at 2.6.22/23?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@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] ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set

[Henrique de Moraes Holschuh]

On Thu, 15 Mar 2007, Chris Wedgwood wrote:
> On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote:
> > This patch allows for ibm-acpi to coexist (with diminished
> > functionality) with other drivers like ACPI_BAY.
> 
> Given the ACP_IBM_BAY implementation is more complete (or seems to be,
> please comment if that isn't the case) we should probably actually
> make sure that is the *preferred* code used (on suitable hardware) at
> run time surely?

ACPI_BAY is experimental, ibm-acpi bay handling is not.  In fact, ACPI_BAY
will debut in mainline in 2.6.21, ibm-acpi bay handling sort of works since
2.6.10.

I hope to have something much better than this stopgap patch for 2.6.22, and
to deprecate ibm-acpi bay (or have it working in *cooperation* with
ACPI_BAY) for 2.6.23.

> Perhaps the IBM_ACPI_BAY code should go away and any missing
> functionality provided there should be merged into ACPI_BAY?

That's the plan, yes.  Failing that, we shall attempt to make both drivers
cooperate (not only load together, but actually work together).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH] ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set

[Kristen Carlson Accardi]

On Thu, 15 Mar 2007 14:51:14 -0300
Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:

> This patch allows for ibm-acpi to coexist (with diminished functionality) with
> other drivers like ACPI_BAY.  ibm-acpi will simply disable the functions it is
> not able to register ACPI notifiers for.


this patch gives me the following compile error:

drivers/acpi/ibm_acpi.c: In function ‘ibm_init’:
drivers/acpi/ibm_acpi.c:2605: warning: implicit declaration of function ‘ibm_exit’
drivers/acpi/ibm_acpi.c: At top level:
drivers/acpi/ibm_acpi.c:2616: warning: conflicting types for ‘ibm_exit’
drivers/acpi/ibm_acpi.c:2616: error: static declaration of ‘ibm_exit’ follows non-static declaration
drivers/acpi/ibm_acpi.c:2605: error: previous implicit declaration of ‘ibm_exit’ was here



> 
> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Cc: Chris Wedgwood <cw@f00f.org>
> Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
> ---
> 
>  Len, you can pull this patch from:
>  git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
>  branch for-upstream/acpi-release
> 
>  Please send it to Linus for merge in 2.6.21.
> 
>  It will clash with the patches in acpi-test that are waiting for 2.6.22.
>  I will rediff those, and send you a pull request when this patch
>  gets accepted in mainline.
> 
>  drivers/acpi/ibm_acpi.c |   17 ++++++++++++++---
>  1 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
> index 3690136..f9f36f9 100644
> --- a/drivers/acpi/ibm_acpi.c
> +++ b/drivers/acpi/ibm_acpi.c
> @@ -2507,7 +2507,7 @@ static int __init setup_notify(struct ibm_struct *ibm)
>  	ret = acpi_bus_get_device(*ibm->handle, &ibm->device);
>  	if (ret < 0) {
>  		printk(IBM_ERR "%s device not present\n", ibm->name);
> -		return 0;
> +		return -ENODEV;
>  	}
>  
>  	acpi_driver_data(ibm->device) = ibm;
> @@ -2516,8 +2516,13 @@ static int __init setup_notify(struct ibm_struct *ibm)
>  	status = acpi_install_notify_handler(*ibm->handle, ibm->type,
>  					     dispatch_notify, ibm);
>  	if (ACPI_FAILURE(status)) {
> -		printk(IBM_ERR "acpi_install_notify_handler(%s) failed: %d\n",
> -		       ibm->name, status);
> +		if (status == AE_ALREADY_EXISTS) {
> +			printk(IBM_NOTICE "another device driver is already handling %s events\n",
> +				ibm->name);
> +		} else {
> +			printk(IBM_ERR "acpi_install_notify_handler(%s) failed: %d\n",
> +				ibm->name, status);
> +		}
>  		return -ENODEV;
>  	}
>  	ibm->notify_installed = 1;
> @@ -2594,6 +2599,12 @@ static int __init ibm_init(struct ibm_struct *ibm)
>  
>  	if (ibm->notify) {
>  		ret = setup_notify(ibm);
> +		if (ret == -ENODEV) {
> +			printk(IBM_NOTICE "disabling subdriver %s\n",
> +				ibm->name);
> +			ibm_exit(ibm);
> +			return 0;
> +		}
>  		if (ret < 0)
>  			return ret;
>  	}
> -- 
> 1.5.0.3
> 
> 
> -- 
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh
> 

Re: [ibm-acpi-devel] [PATCH] ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set

[Henrique de Moraes Holschuh]

On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote:
> this patch gives me the following compile error:
> 
> drivers/acpi/ibm_acpi.c: In function ???ibm_init???:
> drivers/acpi/ibm_acpi.c:2605: warning: implicit declaration of function ???ibm_exit???
> drivers/acpi/ibm_acpi.c: At top level:
> drivers/acpi/ibm_acpi.c:2616: warning: conflicting types for ???ibm_exit???
> drivers/acpi/ibm_acpi.c:2616: error: static declaration of ???ibm_exit??? follows non-static declaration
> drivers/acpi/ibm_acpi.c:2605: error: previous implicit declaration of ???ibm_exit??? was here

Fixed in v2.  I developed it against acpi-test, which has a header file that
prototypes ibm_exit, and sent it before it finished compiling on 2.6.21.
Drat, that teaches me about not waiting for these things...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh