Re: [PATCH][RFC] drivers/firmware/dcdbas: rework to get uevents
On Dienstag, 20. November 2007, Michael E Brown wrote: > On Fri, Nov 16, 2007 at 11:53:53AM +0100, Frank Seidel wrote: > > On Mittwoch 14 November 2007 19:32:01, you (Frank Seidel) wrote: > > > Hi, > > > > > > this is a small trivial rework of the dcdbas driver so > > > HAL can get uevents when platform devices are added or removed. > > > > Sorry for the noise! In the meantime i realized (thanks to a nice > > colleague) this isn't really necessary anymore since patch > > 43cc71eed1250755986da4c0f9898f9a635cb3bf is in mainline. > > > > If you'd anyway to add this patch i gues this is a better version > > of it. > > Frank, Danny, > > Can you possibly explain a bit why this patch is necessary? Danny, does > this fix the module load problems that you had detailed in your earlier > email? > > If this is still necessary, then either Doug or Matt can queue it up for > next kernel release. AFAIK the patch Frank posted isn't needed anymore since this is commited to mainline: 43cc71eed1250755986da4c0f9898f9a635cb3bf Danny -- Danny Kukawka [EMAIL PROTECTED] Mobile Devices SUSE LINUX a Novell Business Maxfeldstr. 5, D-90409 Nuernberg, Germany SUSE LINUX Products GmbH, Nuernberg; GF: Markus Rex, HRB 16746 (AG Nuernberg) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] drivers/firmware/dcdbas: rework to get uevents
On Dienstag, 20. November 2007, Michael E Brown wrote: On Fri, Nov 16, 2007 at 11:53:53AM +0100, Frank Seidel wrote: On Mittwoch 14 November 2007 19:32:01, you (Frank Seidel) wrote: Hi, this is a small trivial rework of the dcdbas driver so HAL can get uevents when platform devices are added or removed. Sorry for the noise! In the meantime i realized (thanks to a nice colleague) this isn't really necessary anymore since patch 43cc71eed1250755986da4c0f9898f9a635cb3bf is in mainline. If you'd anyway to add this patch i gues this is a better version of it. Frank, Danny, Can you possibly explain a bit why this patch is necessary? Danny, does this fix the module load problems that you had detailed in your earlier email? If this is still necessary, then either Doug or Matt can queue it up for next kernel release. AFAIK the patch Frank posted isn't needed anymore since this is commited to mainline: 43cc71eed1250755986da4c0f9898f9a635cb3bf Danny -- Danny Kukawka [EMAIL PROTECTED] Mobile Devices SUSE LINUX a Novell Business Maxfeldstr. 5, D-90409 Nuernberg, Germany SUSE LINUX Products GmbH, Nuernberg; GF: Markus Rex, HRB 16746 (AG Nuernberg) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI video: Don't export sysfs backlight interface if query _BCL fail
Hi,
currently the acpi video module export the backlight interface to sysfs also
if acpi_video_device_lcd_query_levels() fails to read _BLC method (e.g.
because the method is not available). In this case the userspace don't know
which brightness level are supported and can't set a brightness level (echo
return with: "write error: Invalid Argument"). This happend e.g. on a ASUS
RF1 (correct supported by the asus-laptop module).
The video module should not export the backlight interface if query _BLC fail,
because you can't set anything from userspace and this make it useless.
See also: http://bugzilla.kernel.org/show_bug.cgi?id=8375
Danny
From: Danny Kukawka <[EMAIL PROTECTED]>
Subject: ACPI video: Don't export sysfs backlight interface if query _BLC fail
if qeuery _BCL fail (e.g. because the method is missing in BIOS) don't
export the backlight interface to sysfs.
Signed-off-by: Danny Kukawka <[EMAIL PROTECTED]>
---
video.c | 78 --
1 file changed, 41 insertions(+), 37 deletions(-)
--- linux-2.6.21/drivers/acpi/video.c 2007-04-26 13:50:51.0 +0200
+++ linux-2.6.21/drivers/acpi/video.c 2007-04-26 13:50:53.0 +0200
@@ -531,7 +531,6 @@
static void acpi_video_device_find_cap(struct acpi_video_device *device)
{
- acpi_integer status;
acpi_handle h_dummy1;
int i;
u32 max_level = 0;
@@ -565,50 +564,55 @@
device->cap._DSS = 1;
}
- status = acpi_video_device_lcd_query_levels(device, );
+ if (ACPI_SUCCESS(acpi_video_device_lcd_query_levels(device, ))) {
- if (obj && obj->type == ACPI_TYPE_PACKAGE && obj->package.count >= 2) {
- int count = 0;
- union acpi_object *o;
-
- br = kzalloc(sizeof(*br), GFP_KERNEL);
- if (!br) {
- printk(KERN_ERR "can't allocate memory\n");
- } else {
- br->levels = kmalloc(obj->package.count *
-sizeof *(br->levels), GFP_KERNEL);
- if (!br->levels)
- goto out;
-
- for (i = 0; i < obj->package.count; i++) {
- o = (union acpi_object *)>package.
- elements[i];
- if (o->type != ACPI_TYPE_INTEGER) {
- printk(KERN_ERR PREFIX "Invalid
data\n");
- continue;
- }
- br->levels[count] = (u32) o->integer.value;
- if (br->levels[count] > max_level)
- max_level = br->levels[count];
- count++;
- }
- out:
- if (count < 2) {
- kfree(br->levels);
- kfree(br);
+ if (obj->package.count >= 2) {
+ int count = 0;
+ union acpi_object *o;
+
+ br = kzalloc(sizeof(*br), GFP_KERNEL);
+ if (!br) {
+ printk(KERN_ERR "can't allocate memory\n");
} else {
- br->count = count;
- device->brightness = br;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "found %d brightness
levels\n",
- count));
+ br->levels = kmalloc(obj->package.count *
+sizeof *(br->levels),
GFP_KERNEL);
+ if (!br->levels)
+ goto out;
+
+ for (i = 0; i < obj->package.count; i++) {
+ o = (union acpi_object *)>package.
+ elements[i];
+ if (o->type != ACPI_TYPE_INTEGER) {
+ printk(KERN_ERR PREFIX "Invalid
data\n");
+ continue;
+ }
+ br->levels[count] = (u32)
o->integer.value;
+
+ if (br->levels[count] > max_level)
+ max_level = br->levels[count];
+ count++;
+ }
+ out:
+
[PATCH] ACPI video: Don't export sysfs backlight interface if query _BCL fail
Hi,
currently the acpi video module export the backlight interface to sysfs also
if acpi_video_device_lcd_query_levels() fails to read _BLC method (e.g.
because the method is not available). In this case the userspace don't know
which brightness level are supported and can't set a brightness level (echo
return with: write error: Invalid Argument). This happend e.g. on a ASUS
RF1 (correct supported by the asus-laptop module).
The video module should not export the backlight interface if query _BLC fail,
because you can't set anything from userspace and this make it useless.
See also: http://bugzilla.kernel.org/show_bug.cgi?id=8375
Danny
From: Danny Kukawka [EMAIL PROTECTED]
Subject: ACPI video: Don't export sysfs backlight interface if query _BLC fail
if qeuery _BCL fail (e.g. because the method is missing in BIOS) don't
export the backlight interface to sysfs.
Signed-off-by: Danny Kukawka [EMAIL PROTECTED]
---
video.c | 78 --
1 file changed, 41 insertions(+), 37 deletions(-)
--- linux-2.6.21/drivers/acpi/video.c 2007-04-26 13:50:51.0 +0200
+++ linux-2.6.21/drivers/acpi/video.c 2007-04-26 13:50:53.0 +0200
@@ -531,7 +531,6 @@
static void acpi_video_device_find_cap(struct acpi_video_device *device)
{
- acpi_integer status;
acpi_handle h_dummy1;
int i;
u32 max_level = 0;
@@ -565,50 +564,55 @@
device-cap._DSS = 1;
}
- status = acpi_video_device_lcd_query_levels(device, obj);
+ if (ACPI_SUCCESS(acpi_video_device_lcd_query_levels(device, obj))) {
- if (obj obj-type == ACPI_TYPE_PACKAGE obj-package.count = 2) {
- int count = 0;
- union acpi_object *o;
-
- br = kzalloc(sizeof(*br), GFP_KERNEL);
- if (!br) {
- printk(KERN_ERR can't allocate memory\n);
- } else {
- br-levels = kmalloc(obj-package.count *
-sizeof *(br-levels), GFP_KERNEL);
- if (!br-levels)
- goto out;
-
- for (i = 0; i obj-package.count; i++) {
- o = (union acpi_object *)obj-package.
- elements[i];
- if (o-type != ACPI_TYPE_INTEGER) {
- printk(KERN_ERR PREFIX Invalid
data\n);
- continue;
- }
- br-levels[count] = (u32) o-integer.value;
- if (br-levels[count] max_level)
- max_level = br-levels[count];
- count++;
- }
- out:
- if (count 2) {
- kfree(br-levels);
- kfree(br);
+ if (obj-package.count = 2) {
+ int count = 0;
+ union acpi_object *o;
+
+ br = kzalloc(sizeof(*br), GFP_KERNEL);
+ if (!br) {
+ printk(KERN_ERR can't allocate memory\n);
} else {
- br-count = count;
- device-brightness = br;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- found %d brightness
levels\n,
- count));
+ br-levels = kmalloc(obj-package.count *
+sizeof *(br-levels),
GFP_KERNEL);
+ if (!br-levels)
+ goto out;
+
+ for (i = 0; i obj-package.count; i++) {
+ o = (union acpi_object *)obj-package.
+ elements[i];
+ if (o-type != ACPI_TYPE_INTEGER) {
+ printk(KERN_ERR PREFIX Invalid
data\n);
+ continue;
+ }
+ br-levels[count] = (u32)
o-integer.value;
+
+ if (br-levels[count] max_level)
+ max_level = br-levels[count];
+ count++;
+ }
+ out:
+ if (count 2) {
+ kfree(br-levels);
+ kfree(br);
+ } else {
+ br
Re: [PATCH] ACPI: more verbose thermal zone shutdown message
On Sonntag, 15. April 2007, Pavel Machek wrote: > Hi! > > > while debug some strange termal shutdowns I wrote this patch to get more > > information in /var/log/messages about the reason for the shutdown. I > > think this would be useful in general. > > > > Danny > > > > From: Danny Kukawka <[EMAIL PROTECTED]> > > Subject: ACPI: more verbose thermal zone shutdown message > > > > add more information to acpi thermal zone shutdown message for easier > > debugging > > > > Signed-off-by: Danny Kukawka <[EMAIL PROTECTED]> > > Yes, please. [..] > Why two printks with same info, and why is one of them WARNING and > second EMERG? I think this is what happen and why there are currently two messages: * if the temperature is really critical you get (now) this: kernel: Critical trip point (102 C) reached on Thermalzone [THM] kernel: Critical temperature reached (150 C on [THM] with trip point set to: 102 C), shutting down. * and if something send a critical temp event to the thermal zone you get: kernel: Critical temperature reached (42 C on [THM] with trip point set to: 102 C), shutting down. Maybe we can delete the first one, since you get now also from second message the information if the temperature was really critical or if there was an other reason for the shutdown, but in the past this was IMO needed to differ. Danny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: more verbose thermal zone shutdown message
On Sonntag, 15. April 2007, Pavel Machek wrote: Hi! while debug some strange termal shutdowns I wrote this patch to get more information in /var/log/messages about the reason for the shutdown. I think this would be useful in general. Danny From: Danny Kukawka [EMAIL PROTECTED] Subject: ACPI: more verbose thermal zone shutdown message add more information to acpi thermal zone shutdown message for easier debugging Signed-off-by: Danny Kukawka [EMAIL PROTECTED] Yes, please. [..] Why two printks with same info, and why is one of them WARNING and second EMERG? I think this is what happen and why there are currently two messages: * if the temperature is really critical you get (now) this: kernel: Critical trip point (102 C) reached on Thermalzone [THM] kernel: Critical temperature reached (150 C on [THM] with trip point set to: 102 C), shutting down. * and if something send a critical temp event to the thermal zone you get: kernel: Critical temperature reached (42 C on [THM] with trip point set to: 102 C), shutting down. Maybe we can delete the first one, since you get now also from second message the information if the temperature was really critical or if there was an other reason for the shutdown, but in the past this was IMO needed to differ. Danny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ACPI: asus_acpi, support F2JE model
On Mittwoch, 11. April 2007, Jiri Slaby wrote: > Danny Kukawka napsal(a): > > Btw. looks as if a new version of the driver (v0.41) is already in the > > mm-tree. > > Good to hear, I've got a look only to .21-rc6-mm1, where are no changes like > this (there is 0.30). found in the latest mm snapshot under drivers/misc/ Danny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ACPI: asus_acpi, support F2JE model
On Mittwoch, 11. April 2007, Danny Kukawka wrote: > Jiri Slaby wrote: > > Corentin CHARY napsal(a): > >> Le Wednesday 11 April 2007 11:33:48 Jiri Slaby, vous avez écrit : > >>> asus_acpi, support F2JE model > >> Just use the new asus-laptop driver =) > >> (see acpi4asus-0.40) > > > > code seems good, but this is not so good: > > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20) > > #warning "This module does not support 2.6.20 yet, wait for a new release > > #=)" endif > > > > When do you plan to support latest kernels and merge it to mainline? > > This patch fixes acpi4asus-0.40 for me at least with 2.6.20 on a ASUS R1F. Btw. looks as if a new version of the driver (v0.41) is already in the mm-tree. Danny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ACPI: asus_acpi, support F2JE model
Jiri Slaby wrote:
> Corentin CHARY napsal(a):
>> Le Wednesday 11 April 2007 11:33:48 Jiri Slaby, vous avez écrit :
>>> asus_acpi, support F2JE model
>> Just use the new asus-laptop driver =)
>> (see acpi4asus-0.40)
>
> code seems good, but this is not so good:
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20)
> #warning "This module does not support 2.6.20 yet, wait for a new release
> #=)" endif
>
> When do you plan to support latest kernels and merge it to mainline?
This patch fixes acpi4asus-0.40 for me at least with 2.6.20 on a ASUS R1F.
Danny
Signed-off-by: Danny Kukawka <[EMAIL PROTECTED]>
---
asus-laptop.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
--- acpi4asus-0.40/driver/asus-laptop.c 2007-02-13 17:42:51.0 +0100
+++ acpi4asus-0.40/driver/asus-laptop.c 2007-04-11 20:12:49.0 +0200
@@ -41,8 +41,8 @@
# include
#endif
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20)
-#warning "This module does not support 2.6.20 yet, wait for a new release =)"
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,21)
+#warning "This module does not support 2.6.21 yet, wait for a new release =)"
#endif
#include
@@ -226,8 +226,8 @@
static void object##_led_set(struct led_classdev *led_cdev, \
enum led_brightness value);\
static int object##_led_wk; \
- static void object##_led_update(void *data);\
-DECLARE_WORK(object##_led_work, object##_led_update, NULL);\
+ static void object##_led_update(struct work_struct *dummy); \
+DECLARE_WORK(object##_led_work, object##_led_update); \
static struct led_classdev object##_led = { \
.name = "asus:" ledname, \
.brightness_set = object##_led_set, \
@@ -329,7 +329,7 @@
object##_led_wk = value;\
queue_work(led_workqueue, ##_led_work); \
} \
- static void object##_led_update(void * data)\
+ static void object##_led_update(struct work_struct *dummy) \
{ \
int value = object##_led_wk;\
write_status(object##_set_handle, value, (mask)); \
@@ -1053,8 +1053,7 @@
struct backlight_device *bd;
if(brightness_set_handle && lcd_switch_handle) {
- bd = backlight_device_register (ASUS_HOTK_FILE, NULL,
- _data);
+ bd = backlight_device_register (ASUS_HOTK_FILE, NULL, NULL,
_data);
if (IS_ERR (bd)) {
printk(ASUS_ERR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ACPI: asus_acpi, support F2JE model
Jiri Slaby wrote:
Corentin CHARY napsal(a):
Le Wednesday 11 April 2007 11:33:48 Jiri Slaby, vous avez écrit :
asus_acpi, support F2JE model
Just use the new asus-laptop driver =)
(see acpi4asus-0.40)
code seems good, but this is not so good:
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,20)
#warning This module does not support 2.6.20 yet, wait for a new release
#=) endif
When do you plan to support latest kernels and merge it to mainline?
This patch fixes acpi4asus-0.40 for me at least with 2.6.20 on a ASUS R1F.
Danny
Signed-off-by: Danny Kukawka [EMAIL PROTECTED]
---
asus-laptop.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
--- acpi4asus-0.40/driver/asus-laptop.c 2007-02-13 17:42:51.0 +0100
+++ acpi4asus-0.40/driver/asus-laptop.c 2007-04-11 20:12:49.0 +0200
@@ -41,8 +41,8 @@
# include linux/autoconf.h
#endif
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,20)
-#warning This module does not support 2.6.20 yet, wait for a new release =)
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,21)
+#warning This module does not support 2.6.21 yet, wait for a new release =)
#endif
#include linux/kernel.h
@@ -226,8 +226,8 @@
static void object##_led_set(struct led_classdev *led_cdev, \
enum led_brightness value);\
static int object##_led_wk; \
- static void object##_led_update(void *data);\
-DECLARE_WORK(object##_led_work, object##_led_update, NULL);\
+ static void object##_led_update(struct work_struct *dummy); \
+DECLARE_WORK(object##_led_work, object##_led_update); \
static struct led_classdev object##_led = { \
.name = asus: ledname, \
.brightness_set = object##_led_set, \
@@ -329,7 +329,7 @@
object##_led_wk = value;\
queue_work(led_workqueue, object##_led_work); \
} \
- static void object##_led_update(void * data)\
+ static void object##_led_update(struct work_struct *dummy) \
{ \
int value = object##_led_wk;\
write_status(object##_set_handle, value, (mask)); \
@@ -1053,8 +1053,7 @@
struct backlight_device *bd;
if(brightness_set_handle lcd_switch_handle) {
- bd = backlight_device_register (ASUS_HOTK_FILE, NULL,
- asusbl_data);
+ bd = backlight_device_register (ASUS_HOTK_FILE, NULL, NULL,
asusbl_data);
if (IS_ERR (bd)) {
printk(ASUS_ERR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ACPI: asus_acpi, support F2JE model
On Mittwoch, 11. April 2007, Danny Kukawka wrote: Jiri Slaby wrote: Corentin CHARY napsal(a): Le Wednesday 11 April 2007 11:33:48 Jiri Slaby, vous avez écrit : asus_acpi, support F2JE model Just use the new asus-laptop driver =) (see acpi4asus-0.40) code seems good, but this is not so good: #if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,20) #warning This module does not support 2.6.20 yet, wait for a new release #=) endif When do you plan to support latest kernels and merge it to mainline? This patch fixes acpi4asus-0.40 for me at least with 2.6.20 on a ASUS R1F. Btw. looks as if a new version of the driver (v0.41) is already in the mm-tree. Danny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ACPI: asus_acpi, support F2JE model
On Mittwoch, 11. April 2007, Jiri Slaby wrote: Danny Kukawka napsal(a): Btw. looks as if a new version of the driver (v0.41) is already in the mm-tree. Good to hear, I've got a look only to .21-rc6-mm1, where are no changes like this (there is 0.30). found in the latest mm snapshot under drivers/misc/ Danny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI: more verbose thermal zone shutdown message
Hi,
while debug some strange termal shutdowns I wrote this patch to get more
information in /var/log/messages about the reason for the shutdown. I
think this would be useful in general.
Danny
From: Danny Kukawka <[EMAIL PROTECTED]>
Subject: ACPI: more verbose thermal zone shutdown message
add more information to acpi thermal zone shutdown message for easier
debugging
Signed-off-by: Danny Kukawka <[EMAIL PROTECTED]>
---
thermal.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
--- linux-2.6.21-rc5/drivers/acpi/thermal.c 2007-04-05 13:37:07.0
+0200
+++ linux-2.6.21-rc5/drivers/acpi/thermal.c 2007-04-05 16:02:03.0
+0200
@@ -457,14 +457,20 @@
return -EINVAL;
if (tz->temperature >= tz->trips.critical.temperature) {
- printk(KERN_WARNING PREFIX "Critical trip point\n");
+ printk(KERN_WARNING PREFIX
+ "Critical trip point (%ld C) reached on thermal zone
[%s]\n",
+ KELVIN_TO_CELSIUS(tz->trips.critical.temperature),
+ acpi_device_bid(tz->device));
tz->trips.critical.flags.enabled = 1;
} else if (tz->trips.critical.flags.enabled)
tz->trips.critical.flags.enabled = 0;
printk(KERN_EMERG
- "Critical temperature reached (%ld C), shutting down.\n",
- KELVIN_TO_CELSIUS(tz->temperature));
+ "Critical temperature reached (%ld C on [%s] with trip point set
to: %ld C), shutting down.\n",
+ KELVIN_TO_CELSIUS(tz->temperature),
+ acpi_device_bid(tz->device),
+ KELVIN_TO_CELSIUS(tz->trips.critical.temperature));
+
acpi_bus_generate_event(tz->device, ACPI_THERMAL_NOTIFY_CRITICAL,
tz->trips.critical.flags.enabled);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI: more verbose thermal zone shutdown message
Hi,
while debug some strange termal shutdowns I wrote this patch to get more
information in /var/log/messages about the reason for the shutdown. I
think this would be useful in general.
Danny
From: Danny Kukawka [EMAIL PROTECTED]
Subject: ACPI: more verbose thermal zone shutdown message
add more information to acpi thermal zone shutdown message for easier
debugging
Signed-off-by: Danny Kukawka [EMAIL PROTECTED]
---
thermal.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
--- linux-2.6.21-rc5/drivers/acpi/thermal.c 2007-04-05 13:37:07.0
+0200
+++ linux-2.6.21-rc5/drivers/acpi/thermal.c 2007-04-05 16:02:03.0
+0200
@@ -457,14 +457,20 @@
return -EINVAL;
if (tz-temperature = tz-trips.critical.temperature) {
- printk(KERN_WARNING PREFIX Critical trip point\n);
+ printk(KERN_WARNING PREFIX
+ Critical trip point (%ld C) reached on thermal zone
[%s]\n,
+ KELVIN_TO_CELSIUS(tz-trips.critical.temperature),
+ acpi_device_bid(tz-device));
tz-trips.critical.flags.enabled = 1;
} else if (tz-trips.critical.flags.enabled)
tz-trips.critical.flags.enabled = 0;
printk(KERN_EMERG
- Critical temperature reached (%ld C), shutting down.\n,
- KELVIN_TO_CELSIUS(tz-temperature));
+ Critical temperature reached (%ld C on [%s] with trip point set
to: %ld C), shutting down.\n,
+ KELVIN_TO_CELSIUS(tz-temperature),
+ acpi_device_bid(tz-device),
+ KELVIN_TO_CELSIUS(tz-trips.critical.temperature));
+
acpi_bus_generate_event(tz-device, ACPI_THERMAL_NOTIFY_CRITICAL,
tz-trips.critical.flags.enabled);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ide: add "optical" to sysfs "media" attribute
From: Danny Kukawka <[EMAIL PROTECTED]> Subject: ide: add "optical" to sysfs "media" attribute Add "optical" to sysfs "media" attribute as already in /proc Signed-off-by: Danny Kukawka <[EMAIL PROTECTED]> --- linux-2.6.21-rc1/drivers/ide/ide.c 2007-03-21 14:07:18.0 +0100 +++ linux-2.6.21-rc1/drivers/ide/ide.c 2007-03-21 14:09:39.0 +0100 @@ -1952,6 +1952,8 @@ return "tape"; case ide_floppy: return "floppy"; + case ide_optical: + return "optical"; default: return "UNKNOWN"; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ide: add optical to sysfs media attribute
From: Danny Kukawka [EMAIL PROTECTED] Subject: ide: add optical to sysfs media attribute Add optical to sysfs media attribute as already in /proc Signed-off-by: Danny Kukawka [EMAIL PROTECTED] --- linux-2.6.21-rc1/drivers/ide/ide.c 2007-03-21 14:07:18.0 +0100 +++ linux-2.6.21-rc1/drivers/ide/ide.c 2007-03-21 14:09:39.0 +0100 @@ -1952,6 +1952,8 @@ return tape; case ide_floppy: return floppy; + case ide_optical: + return optical; default: return UNKNOWN; } - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] add Fujitsu Siemens Tablet PC devices to 8250_pnp.c
adds device ids of two Fujitsu Siemens Tablet PCs to pnp_dev_table
Signed-off-by: Danny Kukawka <[EMAIL PROTECTED]>
--- linux-2.6.21-rc4/drivers/serial/8250_pnp.c 2007-03-19 21:42:43.0
+0100
+++ linux-2.6.21-rc5/drivers/serial/8250_pnp.c 2007-03-19 21:55:53.0
+0100
@@ -340,6 +340,9 @@ static const struct pnp_device_id pnp_de
{ "FUJ02B8", 0 },
{ "FUJ02B9", 0 },
{ "FUJ02BC", 0 },
+ /* Fujitsu Wacom Tablet PC devices */
+ { "FUJ02E5", 0 },
+ { "FUJ02E6", 0 },
/* Rockwell's (PORALiNK) 33600 INT PNP */
{ "WCI0003", 0 },
/* Unkown PnP modems */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] add Fujitsu Siemens Tablet PC devices to 8250_pnp.c
adds device ids of two Fujitsu Siemens Tablet PCs to pnp_dev_table
Signed-off-by: Danny Kukawka [EMAIL PROTECTED]
--- linux-2.6.21-rc4/drivers/serial/8250_pnp.c 2007-03-19 21:42:43.0
+0100
+++ linux-2.6.21-rc5/drivers/serial/8250_pnp.c 2007-03-19 21:55:53.0
+0100
@@ -340,6 +340,9 @@ static const struct pnp_device_id pnp_de
{ FUJ02B8, 0 },
{ FUJ02B9, 0 },
{ FUJ02BC, 0 },
+ /* Fujitsu Wacom Tablet PC devices */
+ { FUJ02E5, 0 },
+ { FUJ02E6, 0 },
/* Rockwell's (PORALiNK) 33600 INT PNP */
{ WCI0003, 0 },
/* Unkown PnP modems */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
