linux.kernel - 26 new messages in 15 topics - digest
linux.kernel
http://groups.google.com/group/linux.kernel?hl=en
Today's topics:
* R: Re: R: [Bug #14886] Asus P2B-DS not detected as SMP moterboard - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/a7ff0e996789f4ae?hl=en
* tsl2550: Move form i2c/chips to als and update interfaces - 2 messages, 1
author
http://groups.google.com/group/linux.kernel/t/3e3fbb748bf4dd03?hl=en
* linux-next: add utrace tree - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/67ebc22686b326f0?hl=en
* PM / i915: Skip kernel VT switch during suspend/resume if KMS is used - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/e208566420ffb479?hl=en
* usb: otg: add notifier support - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/dad470d391a03375?hl=en
* Locking Problem in 2.6.33-rc5 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7f74d53dc1d0bbdf?hl=en
* which fields in /proc/meminfo are orthogonal? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/01c4ea8ee5701c41?hl=en
* Use full path to dnsdomainname and domainname in scripts/mkcompile_h - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/e0aebdfb17688691?hl=en
* netdev: remove HAVE_ leftovers - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6ca1e9867f4201ee?hl=en
* reiserfs: truncate blocks not used by a write - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a5822c96e2204389?hl=en
* perf,hw_breakpoint: add lockless reservation for hw_breaks - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/9346e7852bd8475c?hl=en
* 2.6.27.45 review - 7 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a6559c6a78c8c9b0?hl=en
* BUG at mm/slab.c:2990 with 2.6.33-rc5-tuxonice - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fa2f4f9561a0a52a?hl=en
* perf report for .ko files - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f73df95337ab2b2b?hl=en
* cpufreq: ondemand: Refactor frequency increase code - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1bb2591fe18b3022?hl=en
==============================================================================
TOPIC: R: Re: R: [Bug #14886] Asus P2B-DS not detected as SMP moterboard
http://groups.google.com/group/linux.kernel/t/a7ff0e996789f4ae?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Jan 26 2010 10:50 am
From: "flinco@libero.it"
Hi Dmitry,
I will try current git as soon as possible and I will post the results.
Many thanks and Best Regards,
Lorenzo Buzzi
>----Messaggio originale----
>Da: mad_soft@inbox.ru
>Data: 26/01/2010 16.53
>A: "Linux Kernel Mailing List"<linux-kernel@vger.kernel.org>
>Cc: "flinco@libero.it"<flinco@libero.it>, "Rafael J. Wysocki"<rjw@sisk.pl>,
"Kernel Testers List"<kernel-testers@vger.kernel.org>, "Arkadiusz Miskiewicz"
<arekm@maven.pl>, "H. Peter Anvin"<hpa@zytor.com>, "Andrew Morton"<akpm@linux-
foundation.org>, "Feng Tang"<feng.tang@intel.com>, "Len Brown"<len.brown@intel.
com>
>Ogg: Re: R: [Bug #14886] Asus P2B-DS not detected as SMP moterboard
>
>On 20:40 Mon 11 Jan , Rafael J. Wysocki wrote:
>> On Monday 11 January 2010, flinco@libero.it wrote:
>> > Tried 2.6.32.3. The issue is still present.
>>
>> Thanks for the update.
>>
>> Rafael
>
>(I have some troubles with registering on kernel bugzilla, so posting here,
>adding people from bug to CC: list)
>
>Hi!
>I'm also using P2B-DS and can confirm that starting with kernel 2.6.32
>SMP stopped working (and don't work still - tested with current git
>v2.6.33-rc5-238-g158c168) The issue seems to have something to do with the
>fact that ACPI is blacklisted on P2B-DS. I used to workaround this bug
>on newer kernels (>=2.6.32) by passing "acpi=force" in kernel arguments.
>Finally, yesterday I found some time to write simple automated bisection
>script and leaved it to run on machine overnight. Here's result:
>---------------------------------------------------------------------------
>e5b8fc6ac158f65598f58dba2c0d52ba3b412f52 is the first bad commit
>commit e5b8fc6ac158f65598f58dba2c0d52ba3b412f52
>Author: Len Brown <len.brown@intel.com>
>Date: Tue Jul 7 23:22:58 2009 -0400
>
> ACPI: check acpi_disabled in acpi_table_parse() and
acpi_table_parse_entries()
>
> Allow consumers of the acpi_table_parse()/acpi_table_parse_entries() API
> to gracefully handle the acpi_disabled=1 case via return value
> rather than checking the global flag themselves.
>
> Signed-off-by: Feng Tang <feng.tang@intel.com>
> Signed-off-by: Len Brown <len.brown@intel.com>
>---------------------------------------------------------------------------
>
>I re-checked this result and yes - reverting this commit on both 2.6.32 and
>current git (v2.6.33-rc5-238-g158c168) makes problem go away.
>
>--
>Best regards,
>Dmitry "MAD" Artamonow
>
>
--
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/
==============================================================================
TOPIC: tsl2550: Move form i2c/chips to als and update interfaces
http://groups.google.com/group/linux.kernel/t/3e3fbb748bf4dd03?hl=en
==============================================================================
== 1 of 2 ==
Date: Tues, Jan 26 2010 10:50 am
From: Jonathan Cameron
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
---
Simple changes to meet all of Jean's comments.
Made formatting changes, removed the defined maximum lux value
and separated out the crushing of drivers/i2c/chips.
If Jean is happy with fixes I would propose taking this through the ALS tree.
Attached is a full patch without git move detection.
Documentation/ABI/testing/sysfs-class-als | 9 +++
drivers/als/Kconfig | 14 ++++
drivers/als/Makefile | 2 +
drivers/{i2c/chips => als}/tsl2550.c | 101 +++++++++++++++++-----------
drivers/i2c/Kconfig | 1 -
drivers/i2c/Makefile | 2 +-
drivers/i2c/chips/Kconfig | 10 ---
drivers/i2c/chips/Makefile | 2 -
8 files changed, 87 insertions(+), 54 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-als b/Documentation/ABI/testing/sysfs-class-als
index d3b33f3..732f449 100644
--- a/Documentation/ABI/testing/sysfs-class-als
+++ b/Documentation/ABI/testing/sysfs-class-als
@@ -7,3 +7,12 @@ Description: Current Ambient Light Illuminance reported by
Unit: lux (lumens per square meter)
RO
+What: /sys/class/als/.../exposure_time[n]
+Date: Dec. 2009
+KernelVersion: 2.6.32
+Contact: Jonathan Cameron <jic23@cam.ac.uk>
+Description: Sensor exposure time. In some devices this
+ corresponds to the combined time needed to
+ to internally read several different sensors.
+ Unit: microseconds
+ RW
diff --git a/drivers/als/Kconfig b/drivers/als/Kconfig
index 200c52b..1564ffc 100644
--- a/drivers/als/Kconfig
+++ b/drivers/als/Kconfig
@@ -8,3 +8,17 @@ menuconfig ALS
This framework provides a generic sysfs I/F for Ambient Light
Sensor devices.
If you want this support, you should say Y or M here.
+
+if ALS
+
+config ALS_TSL2550
+ tristate "Taos TSL2550 ambient light sensor"
+ depends on EXPERIMENTAL && I2C
+ help
+ If you say yes here you get support for the Taos TSL2550
+ ambient light sensor.
+
+ This driver can also be built as a module. If so, the module
+ will be called tsl2550.
+
+endif #ALS
diff --git a/drivers/als/Makefile b/drivers/als/Makefile
index a527197..7be5631 100644
--- a/drivers/als/Makefile
+++ b/drivers/als/Makefile
@@ -3,3 +3,5 @@
#
obj-$(CONFIG_ALS) += als_sys.o
+
+obj-$(CONFIG_ALS_TSL2550) += tsl2550.o
\ No newline at end of file
diff --git a/drivers/i2c/chips/tsl2550.c b/drivers/als/tsl2550.c
similarity index 81%
rename from drivers/i2c/chips/tsl2550.c
rename to drivers/als/tsl2550.c
index a0702f3..8d5f2a1 100644
--- a/drivers/i2c/chips/tsl2550.c
+++ b/drivers/als/tsl2550.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2007 Rodolfo Giometti <giometti@linux.it>
* Copyright (C) 2007 Eurotech S.p.A. <info@eurotech.it>
+ * Copyright (C) 2009 Jonathan Cameron <jic23@cam.ac.uk>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -24,9 +25,11 @@
#include <linux/slab.h>
#include <linux/i2c.h>
#include <linux/mutex.h>
+#include <linux/err.h>
+#include <linux/als_sys.h>
#define TSL2550_DRV_NAME "tsl2550"
-#define DRIVER_VERSION "1.2"
+#define DRIVER_VERSION "2.0"
/*
* Defines
@@ -44,11 +47,12 @@
*/
struct tsl2550_data {
+ struct device *classdev;
struct i2c_client *client;
struct mutex update_lock;
- unsigned int power_state : 1;
- unsigned int operating_mode : 1;
+ unsigned int power_state:1;
+ unsigned int operating_mode:1;
};
/*
@@ -102,15 +106,16 @@ static int tsl2550_get_adc_value(struct i2c_client *client, u8 cmd)
return ret;
if (!(ret & 0x80))
return -EAGAIN;
+ if (ret == 0x7f)
+ return -ERANGE;
return ret & 0x7f; /* remove the "valid" bit */
}
/*
- * LUX calculation
+ * LUX calculation - note the range is dependent on combination
+ * of infrared level and visible light levels.
*/
-#define TSL2550_MAX_LUX 1846
-
static const u8 ratio_lut[] = {
100, 100, 100, 100, 100, 100, 100, 100,
100, 100, 100, 100, 100, 100, 99, 99,
@@ -180,8 +185,7 @@ static int tsl2550_calculate_lux(u8 ch0, u8 ch1)
else
return -EAGAIN;
- /* LUX range check */
- return lux > TSL2550_MAX_LUX ? TSL2550_MAX_LUX : lux;
+ return lux;
}
/*
@@ -191,7 +195,8 @@ static int tsl2550_calculate_lux(u8 ch0, u8 ch1)
static ssize_t tsl2550_show_power_state(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct tsl2550_data *data = i2c_get_clientdata(to_i2c_client(dev));
+ struct i2c_client *client = to_i2c_client(dev->parent);
+ struct tsl2550_data *data = i2c_get_clientdata(client);
return sprintf(buf, "%u\n", data->power_state);
}
@@ -199,12 +204,12 @@ static ssize_t tsl2550_show_power_state(struct device *dev,
static ssize_t tsl2550_store_power_state(struct device *dev,
struct device_attribute *attr, const char *buf, size_t count)
{
- struct i2c_client *client = to_i2c_client(dev);
+ struct i2c_client *client = to_i2c_client(dev->parent);
struct tsl2550_data *data = i2c_get_clientdata(client);
- unsigned long val = simple_strtoul(buf, NULL, 10);
- int ret;
+ unsigned long val;
+ int ret = strict_strtoul(buf, 10, &val);
- if (val < 0 || val > 1)
+ if (val < 0 || val > 1 || ret)
return -EINVAL;
mutex_lock(&data->update_lock);
@@ -220,40 +225,45 @@ static ssize_t tsl2550_store_power_state(struct device *dev,
static DEVICE_ATTR(power_state, S_IWUSR | S_IRUGO,
tsl2550_show_power_state, tsl2550_store_power_state);
-static ssize_t tsl2550_show_operating_mode(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t tsl2550_show_exposure(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
- struct tsl2550_data *data = i2c_get_clientdata(to_i2c_client(dev));
-
- return sprintf(buf, "%u\n", data->operating_mode);
+ struct i2c_client *client = to_i2c_client(dev->parent);
+ struct tsl2550_data *data = i2c_get_clientdata(client);
+ if (data->operating_mode)
+ return sprintf(buf, "160000\n");
+ else
+ return sprintf(buf, "800000\n");
}
-static ssize_t tsl2550_store_operating_mode(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t count)
+static ssize_t tsl2550_store_exposure(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
{
- struct i2c_client *client = to_i2c_client(dev);
+ struct i2c_client *client = to_i2c_client(dev->parent);
struct tsl2550_data *data = i2c_get_clientdata(client);
- unsigned long val = simple_strtoul(buf, NULL, 10);
- int ret;
-
- if (val < 0 || val > 1)
- return -EINVAL;
+ unsigned long val;
- if (data->power_state == 0)
- return -EBUSY;
+ int ret = strict_strtoul(buf, 10, &val);
+ if (ret)
+ return -EINVAL;
mutex_lock(&data->update_lock);
- ret = tsl2550_set_operating_mode(client, val);
+ if (val >= 800000)
+ ret = tsl2550_set_operating_mode(client, 0);
+ else
+ ret = tsl2550_set_operating_mode(client, 1);
mutex_unlock(&data->update_lock);
-
if (ret < 0)
return ret;
return count;
}
-static DEVICE_ATTR(operating_mode, S_IWUSR | S_IRUGO,
- tsl2550_show_operating_mode, tsl2550_store_operating_mode);
+static DEVICE_ATTR(exposure_time0, S_IWUSR | S_IRUGO,
+ tsl2550_show_exposure, tsl2550_store_exposure);
static ssize_t __tsl2550_show_lux(struct i2c_client *client, char *buf)
{
@@ -284,7 +294,7 @@ static ssize_t __tsl2550_show_lux(struct i2c_client *client, char *buf)
static ssize_t tsl2550_show_lux1_input(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct i2c_client *client = to_i2c_client(dev);
+ struct i2c_client *client = to_i2c_client(dev->parent);
struct tsl2550_data *data = i2c_get_clientdata(client);
int ret;
@@ -299,13 +309,13 @@ static ssize_t tsl2550_show_lux1_input(struct device *dev,
return ret;
}
-static DEVICE_ATTR(lux1_input, S_IRUGO,
+static DEVICE_ATTR(illuminance0, S_IRUGO,
tsl2550_show_lux1_input, NULL);
static struct attribute *tsl2550_attributes[] = {
&dev_attr_power_state.attr,
- &dev_attr_operating_mode.attr,
- &dev_attr_lux1_input.attr,
+ &dev_attr_exposure_time0.attr,
+ &dev_attr_illuminance0.attr,
NULL
};
@@ -391,14 +401,22 @@ static int __devinit tsl2550_probe(struct i2c_client *client,
goto exit_kfree;
/* Register sysfs hooks */
- err = sysfs_create_group(&client->dev.kobj, &tsl2550_attr_group);
- if (err)
+ data->classdev = als_device_register(&client->dev);
+ if (IS_ERR(data->classdev)) {
+ err = PTR_ERR(data->classdev);
goto exit_kfree;
+ }
+
+ err = sysfs_create_group(&data->classdev->kobj, &tsl2550_attr_group);
+ if (err)
+ goto exit_unreg;
dev_info(&client->dev, "support ver. %s enabled\n", DRIVER_VERSION);
return 0;
+exit_unreg:
+ als_device_unregister(data->classdev);
exit_kfree:
kfree(data);
exit:
@@ -407,12 +425,15 @@ exit:
static int __devexit tsl2550_remove(struct i2c_client *client)
{
- sysfs_remove_group(&client->dev.kobj, &tsl2550_attr_group);
+ struct tsl2550_data *data = i2c_get_clientdata(client);
+
+ sysfs_remove_group(&data->classdev->kobj, &tsl2550_attr_group);
+ als_device_unregister(data->classdev);
/* Power down the device */
tsl2550_set_power_state(client, 0);
- kfree(i2c_get_clientdata(client));
+ kfree(data);
return 0;
}
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 8d8a00e..5c33a71 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -63,7 +63,6 @@ config I2C_HELPER_AUTO
source drivers/i2c/algos/Kconfig
source drivers/i2c/busses/Kconfig
-source drivers/i2c/chips/Kconfig
config I2C_DEBUG_CORE
bool "I2C Core debugging messages"
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index ba26e6c..ce5fd62 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -5,7 +5,7 @@
obj-$(CONFIG_I2C_BOARDINFO) += i2c-boardinfo.o
obj-$(CONFIG_I2C) += i2c-core.o
obj-$(CONFIG_I2C_CHARDEV) += i2c-dev.o
-obj-y += busses/ chips/ algos/
+obj-y += busses/ algos/
ifeq ($(CONFIG_I2C_DEBUG_CORE),y)
EXTRA_CFLAGS += -DDEBUG
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index ae4539d..c11f8d6 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -6,14 +6,4 @@
menu "Miscellaneous I2C Chip support"
-config SENSORS_TSL2550
- tristate "Taos TSL2550 ambient light sensor"
- depends on EXPERIMENTAL
- help
- If you say yes here you get support for the Taos TSL2550
- ambient light sensor.
-
- This driver can also be built as a module. If so, the module
- will be called tsl2550.
-
endmenu
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index fe0af0f..ffde18d 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -10,8 +10,6 @@
# * I/O expander drivers go to drivers/gpio
#
-obj-$(CONFIG_SENSORS_TSL2550) += tsl2550.o
-
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
endif
--
1.6.4.4
== 2 of 2 ==
Date: Tues, Jan 26 2010 11:00 am
From: Jonathan Cameron
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
---
Reverted incorrect removal of i2c/chips references in i2c/Kconfig etc.
Documentation/ABI/testing/sysfs-class-als | 9 +++
drivers/als/Kconfig | 14 ++++
drivers/als/Makefile | 2 +
drivers/{i2c/chips => als}/tsl2550.c | 101 +++++++++++++++++-----------
drivers/i2c/chips/Kconfig | 10 ---
drivers/i2c/chips/Makefile | 2 -
6 files changed, 86 insertions(+), 52 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-als b/Documentation/ABI/testing/sysfs-class-als
index d3b33f3..732f449 100644
--- a/Documentation/ABI/testing/sysfs-class-als
+++ b/Documentation/ABI/testing/sysfs-class-als
@@ -7,3 +7,12 @@ Description: Current Ambient Light Illuminance reported by
Unit: lux (lumens per square meter)
RO
+What: /sys/class/als/.../exposure_time[n]
+Date: Dec. 2009
+KernelVersion: 2.6.32
+Contact: Jonathan Cameron <jic23@cam.ac.uk>
+Description: Sensor exposure time. In some devices this
+ corresponds to the combined time needed to
+ to internally read several different sensors.
+ Unit: microseconds
+ RW
diff --git a/drivers/als/Kconfig b/drivers/als/Kconfig
index 200c52b..1564ffc 100644
--- a/drivers/als/Kconfig
+++ b/drivers/als/Kconfig
@@ -8,3 +8,17 @@ menuconfig ALS
This framework provides a generic sysfs I/F for Ambient Light
Sensor devices.
If you want this support, you should say Y or M here.
+
+if ALS
+
+config ALS_TSL2550
+ tristate "Taos TSL2550 ambient light sensor"
+ depends on EXPERIMENTAL && I2C
+ help
+ If you say yes here you get support for the Taos TSL2550
+ ambient light sensor.
+
+ This driver can also be built as a module. If so, the module
+ will be called tsl2550.
+
+endif #ALS
diff --git a/drivers/als/Makefile b/drivers/als/Makefile
index a527197..7be5631 100644
--- a/drivers/als/Makefile
+++ b/drivers/als/Makefile
@@ -3,3 +3,5 @@
#
obj-$(CONFIG_ALS) += als_sys.o
+
+obj-$(CONFIG_ALS_TSL2550) += tsl2550.o
\ No newline at end of file
diff --git a/drivers/i2c/chips/tsl2550.c b/drivers/als/tsl2550.c
similarity index 81%
rename from drivers/i2c/chips/tsl2550.c
rename to drivers/als/tsl2550.c
index a0702f3..8d5f2a1 100644
--- a/drivers/i2c/chips/tsl2550.c
+++ b/drivers/als/tsl2550.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2007 Rodolfo Giometti <giometti@linux.it>
* Copyright (C) 2007 Eurotech S.p.A. <info@eurotech.it>
+ * Copyright (C) 2009 Jonathan Cameron <jic23@cam.ac.uk>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -24,9 +25,11 @@
#include <linux/slab.h>
#include <linux/i2c.h>
#include <linux/mutex.h>
+#include <linux/err.h>
+#include <linux/als_sys.h>
#define TSL2550_DRV_NAME "tsl2550"
-#define DRIVER_VERSION "1.2"
+#define DRIVER_VERSION "2.0"
/*
* Defines
@@ -44,11 +47,12 @@
*/
struct tsl2550_data {
+ struct device *classdev;
struct i2c_client *client;
struct mutex update_lock;
- unsigned int power_state : 1;
- unsigned int operating_mode : 1;
+ unsigned int power_state:1;
+ unsigned int operating_mode:1;
};
/*
@@ -102,15 +106,16 @@ static int tsl2550_get_adc_value(struct i2c_client *client, u8 cmd)
return ret;
if (!(ret & 0x80))
return -EAGAIN;
+ if (ret == 0x7f)
+ return -ERANGE;
return ret & 0x7f; /* remove the "valid" bit */
}
/*
- * LUX calculation
+ * LUX calculation - note the range is dependent on combination
+ * of infrared level and visible light levels.
*/
-#define TSL2550_MAX_LUX 1846
-
static const u8 ratio_lut[] = {
100, 100, 100, 100, 100, 100, 100, 100,
100, 100, 100, 100, 100, 100, 99, 99,
@@ -180,8 +185,7 @@ static int tsl2550_calculate_lux(u8 ch0, u8 ch1)
else
return -EAGAIN;
- /* LUX range check */
- return lux > TSL2550_MAX_LUX ? TSL2550_MAX_LUX : lux;
+ return lux;
}
/*
@@ -191,7 +195,8 @@ static int tsl2550_calculate_lux(u8 ch0, u8 ch1)
static ssize_t tsl2550_show_power_state(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct tsl2550_data *data = i2c_get_clientdata(to_i2c_client(dev));
+ struct i2c_client *client = to_i2c_client(dev->parent);
+ struct tsl2550_data *data = i2c_get_clientdata(client);
return sprintf(buf, "%u\n", data->power_state);
}
@@ -199,12 +204,12 @@ static ssize_t tsl2550_show_power_state(struct device *dev,
static ssize_t tsl2550_store_power_state(struct device *dev,
struct device_attribute *attr, const char *buf, size_t count)
{
- struct i2c_client *client = to_i2c_client(dev);
+ struct i2c_client *client = to_i2c_client(dev->parent);
struct tsl2550_data *data = i2c_get_clientdata(client);
- unsigned long val = simple_strtoul(buf, NULL, 10);
- int ret;
+ unsigned long val;
+ int ret = strict_strtoul(buf, 10, &val);
- if (val < 0 || val > 1)
+ if (val < 0 || val > 1 || ret)
return -EINVAL;
mutex_lock(&data->update_lock);
@@ -220,40 +225,45 @@ static ssize_t tsl2550_store_power_state(struct device *dev,
static DEVICE_ATTR(power_state, S_IWUSR | S_IRUGO,
tsl2550_show_power_state, tsl2550_store_power_state);
-static ssize_t tsl2550_show_operating_mode(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t tsl2550_show_exposure(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
- struct tsl2550_data *data = i2c_get_clientdata(to_i2c_client(dev));
-
- return sprintf(buf, "%u\n", data->operating_mode);
+ struct i2c_client *client = to_i2c_client(dev->parent);
+ struct tsl2550_data *data = i2c_get_clientdata(client);
+ if (data->operating_mode)
+ return sprintf(buf, "160000\n");
+ else
+ return sprintf(buf, "800000\n");
}
-static ssize_t tsl2550_store_operating_mode(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t count)
+static ssize_t tsl2550_store_exposure(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
{
- struct i2c_client *client = to_i2c_client(dev);
+ struct i2c_client *client = to_i2c_client(dev->parent);
struct tsl2550_data *data = i2c_get_clientdata(client);
- unsigned long val = simple_strtoul(buf, NULL, 10);
- int ret;
-
- if (val < 0 || val > 1)
- return -EINVAL;
+ unsigned long val;
- if (data->power_state == 0)
- return -EBUSY;
+ int ret = strict_strtoul(buf, 10, &val);
+ if (ret)
+ return -EINVAL;
mutex_lock(&data->update_lock);
- ret = tsl2550_set_operating_mode(client, val);
+ if (val >= 800000)
+ ret = tsl2550_set_operating_mode(client, 0);
+ else
+ ret = tsl2550_set_operating_mode(client, 1);
mutex_unlock(&data->update_lock);
-
if (ret < 0)
return ret;
return count;
}
-static DEVICE_ATTR(operating_mode, S_IWUSR | S_IRUGO,
- tsl2550_show_operating_mode, tsl2550_store_operating_mode);
+static DEVICE_ATTR(exposure_time0, S_IWUSR | S_IRUGO,
+ tsl2550_show_exposure, tsl2550_store_exposure);
static ssize_t __tsl2550_show_lux(struct i2c_client *client, char *buf)
{
@@ -284,7 +294,7 @@ static ssize_t __tsl2550_show_lux(struct i2c_client *client, char *buf)
static ssize_t tsl2550_show_lux1_input(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct i2c_client *client = to_i2c_client(dev);
+ struct i2c_client *client = to_i2c_client(dev->parent);
struct tsl2550_data *data = i2c_get_clientdata(client);
int ret;
@@ -299,13 +309,13 @@ static ssize_t tsl2550_show_lux1_input(struct device *dev,
return ret;
}
-static DEVICE_ATTR(lux1_input, S_IRUGO,
+static DEVICE_ATTR(illuminance0, S_IRUGO,
tsl2550_show_lux1_input, NULL);
static struct attribute *tsl2550_attributes[] = {
&dev_attr_power_state.attr,
- &dev_attr_operating_mode.attr,
- &dev_attr_lux1_input.attr,
+ &dev_attr_exposure_time0.attr,
+ &dev_attr_illuminance0.attr,
NULL
};
@@ -391,14 +401,22 @@ static int __devinit tsl2550_probe(struct i2c_client *client,
goto exit_kfree;
/* Register sysfs hooks */
- err = sysfs_create_group(&client->dev.kobj, &tsl2550_attr_group);
- if (err)
+ data->classdev = als_device_register(&client->dev);
+ if (IS_ERR(data->classdev)) {
+ err = PTR_ERR(data->classdev);
goto exit_kfree;
+ }
+
+ err = sysfs_create_group(&data->classdev->kobj, &tsl2550_attr_group);
+ if (err)
+ goto exit_unreg;
dev_info(&client->dev, "support ver. %s enabled\n", DRIVER_VERSION);
return 0;
+exit_unreg:
+ als_device_unregister(data->classdev);
exit_kfree:
kfree(data);
exit:
@@ -407,12 +425,15 @@ exit:
static int __devexit tsl2550_remove(struct i2c_client *client)
{
- sysfs_remove_group(&client->dev.kobj, &tsl2550_attr_group);
+ struct tsl2550_data *data = i2c_get_clientdata(client);
+
+ sysfs_remove_group(&data->classdev->kobj, &tsl2550_attr_group);
+ als_device_unregister(data->classdev);
/* Power down the device */
tsl2550_set_power_state(client, 0);
- kfree(i2c_get_clientdata(client));
+ kfree(data);
return 0;
}
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index ae4539d..c11f8d6 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -6,14 +6,4 @@
menu "Miscellaneous I2C Chip support"
-config SENSORS_TSL2550
- tristate "Taos TSL2550 ambient light sensor"
- depends on EXPERIMENTAL
- help
- If you say yes here you get support for the Taos TSL2550
- ambient light sensor.
-
- This driver can also be built as a module. If so, the module
- will be called tsl2550.
-
endmenu
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index fe0af0f..ffde18d 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -10,8 +10,6 @@
# * I/O expander drivers go to drivers/gpio
#
-obj-$(CONFIG_SENSORS_TSL2550) += tsl2550.o
-
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
endif
--
1.6.4.4
--
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/
==============================================================================
TOPIC: linux-next: add utrace tree
http://groups.google.com/group/linux.kernel/t/67ebc22686b326f0?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Jan 26 2010 10:50 am
From: Linus Torvalds
On Tue, 26 Jan 2010, Andi Kleen wrote:
> Tom Tromey <tromey@redhat.com> writes:
>
> > * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb.
> > Internally we're already using a self-pipe to integrate this into
> > gdb's main loop. Relatedly, don't mess with the inferior's parentage.
>
> How would having a kernel based solution be better over your
> user space simulation?
Oh, the reason we should do something in the kernel is that you really
can't do certain things with the ptrace() interface.
For example, think about how Wine and UML use ptrace - and then realize
that that makes it impossible to attach a debugger from the outside.
That's a real deficiency in ptrace - much more so than the fact that there
are some odd details (ie the whole "read/write a word at a time" is just a
quirky detail in comparison - not a fundamental problem).
> BTW there's the new signalfd() system call that might do it
> (haven't checked if it works for SIGCHLD)
No, you miss the point.
The problem isn't that you want to turn signals into a file descriptor
just because you like file descriptors.
The problem is that anything that is based on reparenting and signals is
fundamentally a "one parent only" kind of interface. See?
So the reason I think using an fd is a good idea is _not_ because gdb
already uses an fd internally, but because it gives you a "connection"
between the debugger and debuggee that is not fundamentally limited to a
single controller.
(It doesn't have to be a file descriptor, of course, but could be any kind
of other model that allows multiple connections. It's just that in unix
terms, using a file descriptor as the "cookie" for the connection is a
very natural model. So the important part isn't the file descriptor
itself, it's the model you could build).
Linus
--
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/
==============================================================================
TOPIC: PM / i915: Skip kernel VT switch during suspend/resume if KMS is used
http://groups.google.com/group/linux.kernel/t/e208566420ffb479?hl=en
==============================================================================
== 1 of 2 ==
Date: Tues, Jan 26 2010 10:50 am
From: "Rafael J. Wysocki"
On Tuesday 26 January 2010, Pavel Machek wrote:
> On Mon 2010-01-25 22:54:37, Rafael J. Wysocki wrote:
> > On Monday 25 January 2010, Alan Cox wrote:
> > > > > But in that case we should be able to disable the VT switch disable
> > > > > path; we just have to check each driver as it's loaded.
> > > >
> > > > OK, what the right sequence of checks would be in that case and where to place
> > > > them?
> > >
> > > Why are we even driving a vt switch direct from the suspend/resume
> > > logic ? The problem starts there. If it was being handled off the device
> > > suspend/resume method then there wouldn't be a mess to start with ?
> > >
> > > Start at the beginning
> > >
> > > - Why do we switch to arbitarily chosen 'last vt'
> > > - Why isn't vt related suspend/resume handled by the device
> >
> > Well, that was added long ago as a workaround for some problems people
> > reported (presumably). I've never looked at that before, so I can't really
> > tell why someone did it this particular way.
>
> As X drives hardware, it is/was neccessary to get control out of X and
> console switch was convenient.
>
> Note that it needs to happen with userland still active -- before
> freezer.
Well, that's a bit cumbersome.
> And yes, it should be per-driver these days.
That would have to be done using suspend notifiers and should depend on what
driver actually controls the screen at the moment. And I guess the only case
in which we actually _need_ to do the kernel VT switch is when the hardware
is controlled by X and without KMS.
Is there a simple way to determine if that's the case?
Rafael
--
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/
== 2 of 2 ==
Date: Tues, Jan 26 2010 11:20 am
From: Pavel Machek
On Tue 2010-01-26 19:47:45, Rafael J. Wysocki wrote:
> On Tuesday 26 January 2010, Pavel Machek wrote:
> > On Mon 2010-01-25 22:54:37, Rafael J. Wysocki wrote:
> > > On Monday 25 January 2010, Alan Cox wrote:
> > > > > > But in that case we should be able to disable the VT switch disable
> > > > > > path; we just have to check each driver as it's loaded.
> > > > >
> > > > > OK, what the right sequence of checks would be in that case and where to place
> > > > > them?
> > > >
> > > > Why are we even driving a vt switch direct from the suspend/resume
> > > > logic ? The problem starts there. If it was being handled off the device
> > > > suspend/resume method then there wouldn't be a mess to start with ?
> > > >
> > > > Start at the beginning
> > > >
> > > > - Why do we switch to arbitarily chosen 'last vt'
> > > > - Why isn't vt related suspend/resume handled by the device
> > >
> > > Well, that was added long ago as a workaround for some problems people
> > > reported (presumably). I've never looked at that before, so I can't really
> > > tell why someone did it this particular way.
> >
> > As X drives hardware, it is/was neccessary to get control out of X and
> > console switch was convenient.
> >
> > Note that it needs to happen with userland still active -- before
> > freezer.
>
> Well, that's a bit cumbersome.
(which was one of reasons it got special casing).
> > And yes, it should be per-driver these days.
>
> That would have to be done using suspend notifiers and should depend on what
> driver actually controls the screen at the moment. And I guess the only case
> in which we actually _need_ to do the kernel VT switch is when the hardware
> is controlled by X and without KMS.
We need vt switch when display is controlled by userland app directly
accessing hw. It may or may not be X (svgalib anyone?,
gtk-on-framebuffer? qtopia?).
Ideally, userspace should explicitely tell us. KD_KERNEL_GRAPHICS
console mode?
Plus the switch is needed for any graphics app using fbcon -- I do not
think we actually save the framebuffer over suspend. (This one should
probably be fixed).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/
==============================================================================
TOPIC: usb: otg: add notifier support
http://groups.google.com/group/linux.kernel/t/dad470d391a03375?hl=en
==============================================================================
== 1 of 3 ==
Date: Tues, Jan 26 2010 11:00 am
From: Felipe Balbi
On Tue, Jan 26, 2010 at 04:21:28PM +0100, ext David Brownell wrote:
>On Tuesday 26 January 2010, Felipe Balbi wrote:
>> >
>> >Thing is, supplying current is a bit more involved. If the
>> >board can't supply 300 mA, the USB configuration selection
>> >mechanism has to know that, so it never selects peripheral
>> >configurations which require that much current.
>>
>> but that's done already by the usb core, no ? It rules out configuration
>> based on the hub->power_budget (can't remember if the field is that
>> exact name).
>
>Yes, it handles that ... but where does the power budget
>come from? That's what I meant by "more involved".
we set it from board-files (on ARM, at least). It's a board
characteristic, no ?
>As in, the host/supplying side of the power equation can't
>be event driven like the peripheral/consuming side can.
>
>And that's another reason I think it's best to fully solve
>the common (peripheral, recharge-that-batter) case first.
fair enough.
--
balbi
--
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/
== 2 of 3 ==
Date: Tues, Jan 26 2010 11:20 am
From: Felipe Balbi
On Tue, Jan 26, 2010 at 04:07:22PM +0100, ext David Brownell wrote:
>On Tuesday 26 January 2010, Felipe Balbi wrote:
>> >> +enum usb_xceiv_events {
>> >
>> >Let's keep charger events separate from anything else,
>> >like "enter host mode" or "enter peripheral mode" (or
>> >even "disconnect"). The audiences for any other types
>> >of event would be entirely different.
>>
>> the idea was to notify USB events to interested drivers, not only "usb
>> charger events".
>
>There are thousands of events that could be issued.
>I'd rather start with one specific problem, which
>can really benefit from being solved.
>
>If necessary, other events can be added later.
>
>
>> >Right now there's a mess in terms of charger hookup,
>> >so getting that straight is IMO a priority over any
>> >other type of event. Using events will decouple a
>> >bunch of drivers, and simplify driver configuration.
>>
>> well, if you consider that this transceiver isn't really otg specific,
>> then this is already wrong.
>
>It's the only transceiver interface we have; and it
>works for OTG transceivers in peripheral-only mode,
>as well as host-only and dual-role modes. So it's
>not especially wrong.
>
>
>However, "you can consume N milliAmperes now" doesn't
>need to be coupled to a transceiver at all. In fact,
>it works just fine with any pure peripheral interface.
>The gadget stack uses such calls ... and doesn't need
>to be coupled to any transceiver. (But obviously it
>can hook up to an OTG transceiver.)
>
>
>
>> >> + USB_EVENT_NONE, /* no events or cable disconnected */
>> >> + USB_EVENT_VBUS, /* vbus valid event */
>> >> + USB_EVENT_ID, /* id was grounded */
>> >> + USB_EVENT_CHARGER, /* usb dedicated charger */
>> >> + USB_EVENT_ENUMERATED, /* gadget driver enumerated */
>> >
>> >Those seem like the wrong events. The right events for a charger
>> >would be more along the lines of:
>> >
>> > - For peripheral: "you may use N milliAmperes now".
>> > - General: "Don't Charge" (a.k.a. "use 0 mA").
>>
>> I have to disagree, which information would you used to kick the usb
>> dedicated charger detection other than VBUS irq from transceiver ?
>
>That's why I said what I did about the separate charger spec (and
>you quoted it below): it's not going to be less than those two
>ops, which your events don't really capture.
>
>That's "bonus" functionality though ... among other reasons, it's
>not all that common yet. The basic "charge battery over USB"
>scenario needs to work without that stuff.
>
>
>> So we need at least that, and also need to notify when the charger
>> detection is finished, so we can enable data pullups on the link.
>> Remember we might be connected to a charging downstream port.
>
>So you're presuming some separate component will do charger
>detection by listening for events? If it's mucking with the
>pullups, that seems very much like what an OTG transciever
>needs to be managing. And thus, perhaps, transceiver code.
well, if you have access to twl5031 docs you'd understand what I'm
talking about, the charger detection involves at least 3 blocks on
twl5031 plus musb to enable/disable pullups. The sequence is pretty much
as below:
1. vbus irq
2. usb_gadget_disconnect()
3. disable usb ldos
4. switch usb3v1 supply from vbat to vbus (to let charger detection work
on low bat)
5. enable usb3v1 *only*
6. call the notifier chain
7. BCC module kicks charger detection
8. disable usb3v1
9. switch usb3v1 supply back to vbat
10. enable usb ldos
11. usb_gadget_connect() (necessary since we might be connected to
charging port)
vbus irq comes from transceiver (drivers/usb/otg/twl4030-usb.c),
notifier (currently) is also issued from there.
usb_gadget_connect/disconnect() is implemented in
drivers/usb/musb/musb_gadget.c, BCC module is a power_supply driver (not
in mainline yet, I guess).
And after all that, we still have bq2415x as the charger chip itself. On
that we configure input current and all the filters imposed by pse law.
There's also the battery monitoring part which will involve the MADC
part of twl4030/5030/5031/tpsxxxxx and some temperature sensor (maybe).
So the whole thing is quite complicated and should probably be moved to
some "core" code.
>If there's such a separate component, I'd like to see some
>detail about how it'd work. But ... at first glance, it'd
>have thought it'd be simplest inside a transceiver driver.
well, we could export some symbols to the transceiver to access the BCC
address space in twl, but why if we can let bcc do that by itself if we
just tell it "hey dude, vbus is alive".
>We could take a vote to see how many folk have even seen
>one, much less own one. They're not very common, and not
>part of the USB 2.0 spec. That's why I say "not basic".
ok, got it. But we already have plenty of devices on the market which
support them. Look at n900, for example, the only way to charge its
battery if via usb port ;-)
>> what about irqs running in thread, wouldn't we "BUG sleeping in irq
>> context" ?
>
>Iff the IRQ has a thread context, it can block.
ok, so what do you suggest in this case ?
we know that on omaps vbus will come from an i2c-connected transceiver
so its irq handler will be running in a thread and VBUS is the first
valuable information we have on usb point of view.
--
balbi
--
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/
== 3 of 3 ==
Date: Tues, Jan 26 2010 11:20 am
From: Felipe Balbi
Hi,
On Tue, Jan 26, 2010 at 08:09:34PM +0100, Balbi Felipe (Nokia-D/Helsinki) wrote:
>well, if you have access to twl5031 docs you'd understand what I'm
>talking about, the charger detection involves at least 3 blocks on
>twl5031 plus musb to enable/disable pullups. The sequence is pretty much
>as below:
there's more which I forgot:
>1. vbus irq
>2. usb_gadget_disconnect()
>3. disable usb ldos
3.1 put transceiver in non-drivig mode
>4. switch usb3v1 supply from vbat to vbus (to let charger detection work
>on low bat)
>5. enable usb3v1 *only*
>6. call the notifier chain
>7. BCC module kicks charger detection
>8. disable usb3v1
>9. switch usb3v1 supply back to vbat
9.1 put transceiver back to normal mode
>10. enable usb ldos
>11. usb_gadget_connect() (necessary since we might be connected to
>charging port)
now it should be all fine.
--
balbi
--
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/
==============================================================================
TOPIC: Locking Problem in 2.6.33-rc5
http://groups.google.com/group/linux.kernel/t/7f74d53dc1d0bbdf?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Jan 26 2010 11:00 am
From: Larry Finger
On 01/26/2010 12:25 PM, Rafael J. Wysocki wrote:
> On Tuesday 26 January 2010, Larry Finger wrote:
>> On suspend to RAM, I get the following recursive locking message:
>>
>> =============================================
>> [ INFO: possible recursive locking detected ]
>> 2.6.33-rc5-Linus-dirty #173
>> ---------------------------------------------
>> sh/3488 is trying to acquire lock:
>> (s_active){++++.+}, at: [<ffffffff81167413>] sysfs_addrm_finish+0x43/0x70
>>
>> but task is already holding lock:
>> (s_active){++++.+}, at: [<ffffffff8116771d>] sysfs_get_active_two+0x3d/0x60
>>
>> other info that might help us debug this:
>> 4 locks held by sh/3488:
>> #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff81165b7f>]
>> sysfs_write_file+0x3f/0x160
>> #1: (s_active){++++.+}, at: [<ffffffff8116771d>] sysfs_get_active_two+0x3d/0x60
>> #2: (s_active){++++.+}, at: [<ffffffff81167702>] sysfs_get_active_two+0x22/0x60
>> #3: (dbs_mutex){+.+.+.}, at: [<ffffffff81271517>]
>> cpufreq_governor_dbs+0xe7/0x480
>>
>> stack backtrace:
>> Pid: 3488, comm: sh Not tainted 2.6.33-rc5-Linus-dirty #173
>> Call Trace:
>> [<ffffffff8107c36b>] __lock_acquire+0xf6b/0x1d30
>> [<ffffffff81078e9f>] ? lockdep_init_map+0x5f/0x5d0
>> [<ffffffff8107d1cb>] lock_acquire+0x9b/0x120
>> [<ffffffff81167413>] ? sysfs_addrm_finish+0x43/0x70
>> [<ffffffff81166ba3>] sysfs_deactivate+0xc3/0x110
>> [<ffffffff81167413>] ? sysfs_addrm_finish+0x43/0x70
>> [<ffffffff81167413>] sysfs_addrm_finish+0x43/0x70
>> [<ffffffff81165206>] sysfs_hash_and_remove+0x56/0x80
>> [<ffffffff8116895f>] sysfs_remove_group+0x4f/0xf0
>> [<ffffffff8127152b>] cpufreq_governor_dbs+0xfb/0x480
>> [<ffffffff8107a8dd>] ? trace_hardirqs_on_caller+0x14d/0x190
>> [<ffffffff8107a92d>] ? trace_hardirqs_on+0xd/0x10
>> [<ffffffff8126e314>] __cpufreq_governor+0x94/0x160
>> [<ffffffff8126f84f>] __cpufreq_set_policy+0x11f/0x180
>> [<ffffffff8126fc66>] store_scaling_governor+0xc6/0x200
>> [<ffffffff81270530>] ? handle_update+0x0/0x10
>> [<ffffffff8126f702>] store+0x62/0x90
>> [<ffffffff81165c21>] sysfs_write_file+0xe1/0x160
>> [<ffffffff8110b0c8>] vfs_write+0xb8/0x180
>> [<ffffffff8110b26c>] sys_write+0x4c/0x80
>> [<ffffffff81002dab>] system_call_fastpath+0x16/0x1b
>
> Does the patch at http://patchwork.kernel.org/patch/70461/ fix it?
No, it does not. The traceback is identical except for the new kernel
compilation number.
Larry
--
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/
==============================================================================
TOPIC: which fields in /proc/meminfo are orthogonal?
http://groups.google.com/group/linux.kernel/t/01c4ea8ee5701c41?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Jan 26 2010 11:10 am
From: "Chris Friesen"
Hi,
We have a system (2.6.27 based) which seems to be increasing its memory
consumption by several MB an hour. Summing up Pss for all maps in all
processes doesn't seem to explain it, so I'm looking at the kernel.
I've backported the kmemleak functionality. It's self-test module shows
leaks so I know it's working, but it doesn't report any leaks that would
correspond to the memory increase.
I'm currently trying to figure out which of the entries in /proc/meminfo
are actually orthogonal to each other. Ideally I'd like to be able to
add up the suitable entries and have it work out to the total memory on
the system, so that I can then narrow down exactly where the memory is
going. Is this feasable?
I'll keep reading the code but if anyone happens to know this already
I'd appreciate some assistance.
Thanks,
Chris
--
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/
==============================================================================
TOPIC: Use full path to dnsdomainname and domainname in scripts/mkcompile_h
http://groups.google.com/group/linux.kernel/t/e0aebdfb17688691?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Jan 26 2010 11:20 am
From: Glenn Sommer
2010/1/26 Michal Marek <mmarek@suse.cz>:
> On 26.1.2010 04:55, Américo Wang wrote:
>> On Wed, Jan 20, 2010 at 11:06 PM, Glenn Sommer <glemsom@gmail.com> wrote:
>>> Alternatively, if we want it to be more flexible(and allow the above)
>>> - we should do something like:
>>>
>>> domainname_executable=`which domainname`
>>> if [ ! -z "$domainname_executable" ] && [ -x "$domainname_executable" ]; then
>>>
>
> (or 'if command -v domainname >/dev/null 2>&1; then domainname ...')
>
>
>> Yeah, this seems better for me.
>
> Me too. Glenn, could you send a complete patch doing this? I'll add it
> to the kbuild tree then.
>
> Thanks,
> Michal
>
Yeah, good idea with "command -v" ! :)
( note: `command -v` will return true if the executable is found -
else it will return false. )
mkcompile_h is changed slightly in 2.6.32. Here's my new proposed patch:
--- scripts/mkcompile_h.orig 2010-01-26 18:59:37.000000000 +0100
+++ scripts/mkcompile_h 2010-01-26 20:03:42.000000000 +0100
@@ -67,9 +67,9 @@
echo \#define LINUX_COMPILE_BY \"`whoami`\"
echo \#define LINUX_COMPILE_HOST \"`hostname | $UTS_TRUNCATE`\"
- if [ -x /bin/dnsdomainname ]; then
+ if [ `command -v dnsdomainname 2> /dev/null` ]; then
domain=`dnsdomainname 2> /dev/null`
- elif [ -x /bin/domainname ]; then
+ elif [ `command -v domainname 2> /dev/null` ]; then
domain=`domainname 2> /dev/null`
fi
Signed-off-by: Glenn Sommer <glemsom@gmail.com>
--
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/
==============================================================================
TOPIC: netdev: remove HAVE_ leftovers
http://groups.google.com/group/linux.kernel/t/6ca1e9867f4201ee?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Jan 26 2010 11:20 am
From: Alexey Dobriyan
On Tue, Jan 26, 2010 at 05:18:17AM -0800, David Miller wrote:
> Alexey, please go through at least drivers/net and look at the
> other stale references to these HAVE_* macros.
My apologies.
[PATCH] netdev: remove HAVE_ leftovers
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/net/cassini.c | 2 +-
drivers/net/meth.c | 3 ---
drivers/staging/wlags49_h2/wl_netdev.c | 6 ------
3 files changed, 1 insertion(+), 10 deletions(-)
--- a/drivers/net/cassini.c
+++ b/drivers/net/cassini.c
@@ -106,7 +106,7 @@
#define cas_page_unmap(x) kunmap_atomic((x), KM_SKB_DATA_SOFTIRQ)
#define CAS_NCPUS num_online_cpus()
-#if defined(CONFIG_CASSINI_NAPI) && defined(HAVE_NETDEV_POLL)
+#ifdef CONFIG_CASSINI_NAPI
#define USE_NAPI
#define cas_skb_release(x) netif_receive_skb(x)
#else
--- a/drivers/net/meth.c
+++ b/drivers/net/meth.c
@@ -51,14 +51,11 @@
static const char *meth_str="SGI O2 Fast Ethernet";
-#define HAVE_TX_TIMEOUT
/* The maximum time waited (in jiffies) before assuming a Tx failed. (400ms) */
#define TX_TIMEOUT (400*HZ/1000)
-#ifdef HAVE_TX_TIMEOUT
static int timeout = TX_TIMEOUT;
module_param(timeout, int, 0);
-
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home