On Fri, 11 Jan 2008 10:33:16 +0800,
Dave Young [EMAIL PROTECTED] wrote:
+struct device *class_find_device(struct class *class, void *data,
+int (*match)(struct device *, void *))
+{
+ struct device *dev;
+
+ if (!class)
+
On Jan 11, 2008 4:23 PM, Cornelia Huck [EMAIL PROTECTED] wrote:
On Fri, 11 Jan 2008 10:33:16 +0800,
Dave Young [EMAIL PROTECTED] wrote:
+struct device *class_find_device(struct class *class, void *data,
+int (*match)(struct device *, void *))
+{
On Wed, Jan 09, 2008 at 02:39:23PM +0800, Dave Young wrote:
On Jan 9, 2008 2:37 PM, Dave Young [EMAIL PROTECTED] wrote:
On Jan 9, 2008 2:13 PM, Dave Young [EMAIL PROTECTED] wrote:
On Wed, Jan 09, 2008 at 09:32:48AM +0800, Dave Young wrote:
On Jan 9, 2008 6:48 AM, Greg KH [EMAIL
Dave Young wrote:
This is the first one of the series about driver core changes.
Please always provide kerneldoc comments when you add new API elements;
here: exported functions.
It's unfortunate that the driver core's API isn't fully documented yet,
and you shouldn't make it worse.
That's
On Thu, 10 Jan 2008 17:48:43 +0800,
Dave Young [EMAIL PROTECTED] wrote:
Please add a kerneldoc comment for each of the new interfaces.
+int class_for_each_device(struct class *class, void *data,
+int (*fn)(struct device *, void *))
+{
+ struct device *dev;
+
On Thu, 10 Jan 2008, Dave Young wrote:
Hi,
The patches are done on my side, please help to check.
This is the first one of the series about driver core changes.
If this one is accepted and there's no other problem I will post the others
for maintainer's review (they need your comment
On Thu, Jan 10, 2008 at 05:48:43PM +0800, Dave Young wrote:
The patches are done on my side, please help to check.
Along with all of the other comments from people, I have a few.
This is the first one of the series about driver core changes.
If this one is accepted and there's no other
On Jan 10, 2008 8:34 PM, Stefan Richter [EMAIL PROTECTED] wrote:
Dave Young wrote:
This is the first one of the series about driver core changes.
Please always provide kerneldoc comments when you add new API elements;
here: exported functions.
It's unfortunate that the driver core's API
On Jan 10, 2008 9:23 PM, Cornelia Huck [EMAIL PROTECTED] wrote:
On Thu, 10 Jan 2008 17:48:43 +0800,
Dave Young [EMAIL PROTECTED] wrote:
Please add a kerneldoc comment for each of the new interfaces.
Will do.
+int class_for_each_device(struct class *class, void *data,
+
On Jan 10, 2008 11:41 PM, Alan Stern [EMAIL PROTECTED] wrote:
On Thu, 10 Jan 2008, Dave Young wrote:
Hi,
The patches are done on my side, please help to check.
This is the first one of the series about driver core changes.
If this one is accepted and there's no other problem I will
On Jan 11, 2008 2:39 AM, Greg KH [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 05:48:43PM +0800, Dave Young wrote:
The patches are done on my side, please help to check.
Along with all of the other comments from people, I have a few.
This is the first one of the series about driver core
On Tue, Jan 08, 2008 at 03:05:10PM +0800, Dave Young wrote:
On Jan 8, 2008 1:20 AM, Greg KH [EMAIL PROTECTED] wrote:
On Mon, Jan 07, 2008 at 06:13:37PM +0100, Stefan Richter wrote:
It's already in the driver core to the most part. It remains to be seen
what is less complicated in the
On Jan 9, 2008 6:48 AM, Greg KH [EMAIL PROTECTED] wrote:
On Tue, Jan 08, 2008 at 03:05:10PM +0800, Dave Young wrote:
On Jan 8, 2008 1:20 AM, Greg KH [EMAIL PROTECTED] wrote:
On Mon, Jan 07, 2008 at 06:13:37PM +0100, Stefan Richter wrote:
It's already in the driver core to the most part.
On Wed, Jan 09, 2008 at 09:32:48AM +0800, Dave Young wrote:
On Jan 9, 2008 6:48 AM, Greg KH [EMAIL PROTECTED] wrote:
On Tue, Jan 08, 2008 at 03:05:10PM +0800, Dave Young wrote:
On Jan 8, 2008 1:20 AM, Greg KH [EMAIL PROTECTED] wrote:
On Mon, Jan 07, 2008 at 06:13:37PM +0100, Stefan
On Jan 9, 2008 2:13 PM, Dave Young [EMAIL PROTECTED] wrote:
On Wed, Jan 09, 2008 at 09:32:48AM +0800, Dave Young wrote:
On Jan 9, 2008 6:48 AM, Greg KH [EMAIL PROTECTED] wrote:
On Tue, Jan 08, 2008 at 03:05:10PM +0800, Dave Young wrote:
On Jan 8, 2008 1:20 AM, Greg KH [EMAIL PROTECTED]
On Jan 9, 2008 2:37 PM, Dave Young [EMAIL PROTECTED] wrote:
On Jan 9, 2008 2:13 PM, Dave Young [EMAIL PROTECTED] wrote:
On Wed, Jan 09, 2008 at 09:32:48AM +0800, Dave Young wrote:
On Jan 9, 2008 6:48 AM, Greg KH [EMAIL PROTECTED] wrote:
On Tue, Jan 08, 2008 at 03:05:10PM +0800, Dave
On Monday 07 January 2008, Greg KH wrote:
Most of the non-driver core code should be converted to not use the
lock in the class at all. They should use a local lock instead.
Or better yet, that yet-to-be-written class_for_each_instance()
iterator ... :)
-
To unsubscribe from this list: send
On Jan 7, 2008 4:45 PM, Greg KH [EMAIL PROTECTED] wrote:
On Mon, Jan 07, 2008 at 10:09:44AM +0800, Dave Young wrote:
Thanks for your comment, I rewrite it for 2.6.24-rc7 as a all-in-one
patch, please see following. Drop i2c maintainer and list in cc
because there's no changes about i2c in
David Brownell wrote:
On Monday 07 January 2008, Greg KH wrote:
Most of the non-driver core code should be converted to not use the
lock in the class at all. They should use a local lock instead.
Or better yet, that yet-to-be-written class_for_each_instance()
iterator ... :)
By far most
On Mon, Jan 07, 2008 at 02:23:33PM +0100, Stefan Richter wrote:
David Brownell wrote:
On Monday 07 January 2008, Greg KH wrote:
Most of the non-driver core code should be converted to not use the
lock in the class at all. They should use a local lock instead.
Or better yet, that
On Mon, Jan 07, 2008 at 02:23:33PM +0100, Stefan Richter wrote:
David Brownell wrote:
On Monday 07 January 2008, Greg KH wrote:
Most of the non-driver core code should be converted to not use the
lock in the class at all. They should use a local lock instead.
Or better yet, that
Jarek Poplawski wrote:
David Brownell wrote:
On Monday 07 January 2008, Greg KH wrote:
Most of the non-driver core code should be converted to not use the
lock in the class at all. They should use a local lock instead.
Or better yet, that yet-to-be-written class_for_each_instance()
Greg KH wrote:
On Mon, Jan 07, 2008 at 02:23:33PM +0100, Stefan Richter wrote:
David Brownell wrote:
On Monday 07 January 2008, Greg KH wrote:
Most of the non-driver core code should be converted to not use the
lock in the class at all. They should use a local lock instead.
Or better
On Mon, Jan 07, 2008 at 06:13:37PM +0100, Stefan Richter wrote:
It's already in the driver core to the most part. It remains to be seen
what is less complicated in the end: Transparent mutex-protected list
accesses provided by driver core (requires the iterator), or all the
necessary locking
On Mon, 7 Jan 2008, Stefan Richter wrote:
Semi off-topic: What about struct device.sem? Is there any chance to
rip this out of the driver core and let drivers serialize everything? I
suppose not...
There isn't. The core uses that lock.
Alan Stern
-
To unsubscribe from this list: send
On Sun, Jan 06, 2008 at 07:41:29PM +0100, Stefan Richter wrote:
Dave Young wrote:
Convert semaphore to mutex in struct class.
All the patches in this series should be applyed simultaneously
Therefore you eventually need to repost it as a single patch. It can't
go into one of the
On Thu, Jan 03, 2008 at 08:06:09AM +0100, Jarek Poplawski wrote:
On Thu, Jan 03, 2008 at 01:50:20PM +0800, Dave Young wrote:
Convert semaphore to mutex in struct class.
...
One lockdep warning detected as following, thus use mutex_lock_nested with
SINGLE_DEPTH_NESTING in class_device_add
On Jan 3, 2008 3:24 PM, Jarek Poplawski [EMAIL PROTECTED] wrote:
On Thu, Jan 03, 2008 at 08:06:09AM +0100, Jarek Poplawski wrote:
On Thu, Jan 03, 2008 at 01:50:20PM +0800, Dave Young wrote:
Convert semaphore to mutex in struct class.
...
One lockdep warning detected as following, thus
On Thu, Jan 03, 2008 at 03:21:36PM +0800, Dave Young wrote:
...
I don't know if there's other possible warning places with this mutex
or not, if you have any ideas about this, please tell me.
I think lockdep is just to tell such things. So, the question is, how
much it was tested already,
29 matches
Mail list logo
