RE: acpi=off & /proc entries

RE: acpi=off & /proc entries

[Yu, Luming]

Try latest patch please. If you still have problem, would you please file it on bugzilla.kernel.org  (Both 2.4 and 2.5) 

Thanks,
Luming

-----Original Message-----
From: Zden¨§k OGAR Skal¨˘k [mailto:skalak-Bh/+Xfn7orxQjibfaplwYw@public.gmane.org]
Sent: 2003?5?12? 23:19
To: Grover, Andrew
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: [ACPI] acpi=off & /proc entries


Hi,

	I'm using kernel 2.4.20 with ACPI version 20021205 (with additional patch as:
custom corrected DSDT, DSDT in initrd, \_OS override, .....). I find out a small
bug:
	if you boot with acpi=off argument, acpi isn't activated (as you would expect),
but proc-entries in /proc/acpi (as battery & so on), appears just below /proc
:-{

cat /var/log/dmesg:
...
ACPI: Subsystem revision 20021205
ACPI: Disabled via command line (acpi=off)
...
acpi_button-0466 [0001] [02] acpi_button_init      : ----Entry
acpi_bus-1247 [0001] [03] acpi_bus_register_driv: ----Entry
acpi_bus-1259 [0001] [03] acpi_bus_register_driv: ----Exit- 0000000000000000
acpi_button-0478 [0001] [02] acpi_button_init      : ----Exit- 0000000000000000
...

Reason:
	there's global struct proc_dir_entry *acpi_root_dir in bus.c 
	if you boot with acpi=off, it has it's implicit value of NULL
	all drivers (ex. button) has their init functions with this sequence:
		acpi_xxx_dir = proc_mkdir(ACPI_xxx_CLASS, acpi_root_dir); 
		// this success, (but acpi_root_dir==NULL :-{
		result = acpi_bus_register_driver(&acpi_xxx_driver);	
		// this returns 0, should it ?
		if (result<0){
			// we don't get here
			remove_proc_entry(ACPI_xxx_CLASS, acpi_root_dir);
			return_VALUE(-ENODEV);
		}
		return_VALUE(0);

	I think, we should (in each such driver) test the acpi_disabled variable & if
it's on, don't even bother with mkdir, register_bus_driver  .... Or don't allow
acpi_bus_register_driver to return success if acpi==off (test of acpi_disabled
there :-)

	Sorry, but don't have time (and even not the correct kernel tree & correct acpi
version) to make patch ...

	Bye
		Zdenek OGAR Skalak

-- 
Ing. Zdeněk OGAR Skalák
Monet+ a.s.
Zámecká 365
763 14 Zlín - Štípa, CZ
Tel: +420 / 577 110 411,  Fax: +420 / 577 914 557


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: acpi=off & /proc entries

[Zdeněk OGAR Skalák]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]


Hi,

	here is small simple patch :-) It's against acpi-20030512-2.4.21-rc2.

	It prevents ACPI modules (button, ...) to register itself & create /proc
entries, when acpi is disabled through acpi=off. 

	Because bus.c uses acpi_disabled variable set by acpi=off, it doesn't register
/proc/acpi directory & module later registers (in his __init) it's /proc entry
just in /proc (/proc/button, ...).

	This simply returns -ENODEV if acpi_disabled & when module tries to register
via acpi_bus_register_driver (in bus.c) & as a consequence, module removes his
/proc entry :-)

	Bye
		Zdenek OGAR Skalak
-- 
Ing. Zdeněk OGAR Skalák
Monet+ a.s.
Zámecká 365
763 14 Zlín - Štípa, CZ
Tel: +420 / 577 110 411,  Fax: +420 / 577 914 557

[-- Attachment #2: acpi_off.diff --]
[-- Type: text/plain, Size: 429 bytes --]

diff -r -c old/drivers/acpi/bus.c new/drivers/acpi/bus.c
*** old/drivers/acpi/bus.c	Fri May 16 09:55:19 2003
--- new/drivers/acpi/bus.c	Fri May 16 09:58:01 2003
***************
*** 1249,1254 ****
--- 1249,1257 ----
  	if (!driver)
  		return_VALUE(-EINVAL);
  
+ 	if (acpi_disabled)
+ 		return_VALUE(-ENODEV);
+ 
  	down(&acpi_bus_drivers_lock);
  	list_add_tail(&driver->node, &acpi_bus_drivers);
  	up(&acpi_bus_drivers_lock);

RE: acpi=off & /proc entries

[Grover, Andrew]

One more comment - looks like this bug is only in 2.4 - somebody say something if otherwise.

Regards -- Andy

> -----Original Message-----
> From: Zdenek OGAR Skalák [mailto:skalak-Bh/+Xfn7orxQjibfaplwYw@public.gmane.org] 
> Sent: Friday, May 16, 2003 2:19 AM
> Cc: Grover, Andrew; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: [ACPI] acpi=off & /proc entries
> 
> 
> 
> Hi,
> 
> 	here is small simple patch :-) It's against 
> acpi-20030512-2.4.21-rc2.
> 
> 	It prevents ACPI modules (button, ...) to register 
> itself & create /proc
> entries, when acpi is disabled through acpi=off. 
> 
> 	Because bus.c uses acpi_disabled variable set by 
> acpi=off, it doesn't register
> /proc/acpi directory & module later registers (in his __init) 
> it's /proc entry
> just in /proc (/proc/button, ...).
> 
> 	This simply returns -ENODEV if acpi_disabled & when 
> module tries to register
> via acpi_bus_register_driver (in bus.c) & as a consequence, 
> module removes his
> /proc entry :-)
> 
> 	Bye
> 		Zdenek OGAR Skalak
> -- 
> Ing. Zdeněk OGAR Skalák
> Monet+ a.s.
> Zámecká 365
> 763 14 Zlín - Štípa, CZ
> Tel: +420 / 577 110 411,  Fax: +420 / 577 914 557
> 


-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful,
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge

RE: acpi=off & /proc entries

[Grover, Andrew]

Looks good. Thanks, Zdenek.

> -----Original Message-----
> From: Zdenek OGAR Skalák [mailto:skalak-Bh/+Xfn7orxQjibfaplwYw@public.gmane.org] 
> Sent: Friday, May 16, 2003 2:19 AM
> Cc: Grover, Andrew; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: [ACPI] acpi=off & /proc entries
> 
> 
> 
> Hi,
> 
> 	here is small simple patch :-) It's against 
> acpi-20030512-2.4.21-rc2.
> 
> 	It prevents ACPI modules (button, ...) to register 
> itself & create /proc
> entries, when acpi is disabled through acpi=off. 
> 
> 	Because bus.c uses acpi_disabled variable set by 
> acpi=off, it doesn't register
> /proc/acpi directory & module later registers (in his __init) 
> it's /proc entry
> just in /proc (/proc/button, ...).
> 
> 	This simply returns -ENODEV if acpi_disabled & when 
> module tries to register
> via acpi_bus_register_driver (in bus.c) & as a consequence, 
> module removes his
> /proc entry :-)
> 
> 	Bye
> 		Zdenek OGAR Skalak
> -- 
> Ing. Zdeněk OGAR Skalák
> Monet+ a.s.
> Zámecká 365
> 763 14 Zlín - Štípa, CZ
> Tel: +420 / 577 110 411,  Fax: +420 / 577 914 557
> 


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

FW: kernel 2.4 and bugzilla

[Grover, Andrew]

This is the email I received after emailing bugme-admin-3NddpPZAyC3hvxM+mQhndA@public.gmane.org

Regards -- Andy

-----Original Message-----
From: Martin J. Bligh [mailto:mbligh-/CzTsIfkJEdBDgjK7y7TUQ@public.gmane.org] 
Sent: Thursday, March 20, 2003 7:52 AM
To: Grover, Andrew; bugme-admin-3NddpPZAyC0@public.gmane.org
Subject: Re: kernel 2.4 and bugzilla


> I would like to be able to use one bugzilla to keep track of all bugs
> against the kernel for code I am maintaining (ACPI). I'd like to use
> this bugzilla (it's nice and non-distribution-specific) but I would
like
> to also have bugs filed against the 2.4 version of this driver.
> 
> Would it be a big deal if I kept 2.4 bugs here, too?

Go ahead ... we're looking at a more general opening up of Bugzilla.

M.


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

acpi=off & /proc entries

[Zdeněk OGAR Skalák]

Hi,

	I'm using kernel 2.4.20 with ACPI version 20021205 (with additional patch as:
custom corrected DSDT, DSDT in initrd, \_OS override, .....). I find out a small
bug:
	if you boot with acpi=off argument, acpi isn't activated (as you would expect),
but proc-entries in /proc/acpi (as battery & so on), appears just below /proc
:-{

cat /var/log/dmesg:
...
ACPI: Subsystem revision 20021205
ACPI: Disabled via command line (acpi=off)
...
acpi_button-0466 [0001] [02] acpi_button_init      : ----Entry
acpi_bus-1247 [0001] [03] acpi_bus_register_driv: ----Entry
acpi_bus-1259 [0001] [03] acpi_bus_register_driv: ----Exit- 0000000000000000
acpi_button-0478 [0001] [02] acpi_button_init      : ----Exit- 0000000000000000
...

Reason:
	there's global struct proc_dir_entry *acpi_root_dir in bus.c 
	if you boot with acpi=off, it has it's implicit value of NULL
	all drivers (ex. button) has their init functions with this sequence:
		acpi_xxx_dir = proc_mkdir(ACPI_xxx_CLASS, acpi_root_dir); 
		// this success, (but acpi_root_dir==NULL :-{
		result = acpi_bus_register_driver(&acpi_xxx_driver);	
		// this returns 0, should it ?
		if (result<0){
			// we don't get here
			remove_proc_entry(ACPI_xxx_CLASS, acpi_root_dir);
			return_VALUE(-ENODEV);
		}
		return_VALUE(0);

	I think, we should (in each such driver) test the acpi_disabled variable & if
it's on, don't even bother with mkdir, register_bus_driver  .... Or don't allow
acpi_bus_register_driver to return success if acpi==off (test of acpi_disabled
there :-)

	Sorry, but don't have time (and even not the correct kernel tree & correct acpi
version) to make patch ...

	Bye
		Zdenek OGAR Skalak

-- 
Ing. Zdeněk OGAR Skalák
Monet+ a.s.
Zámecká 365
763 14 Zlín - Štípa, CZ
Tel: +420 / 577 110 411,  Fax: +420 / 577 914 557


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com