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 *, voi
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 (!clas
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 dr
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 probl
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 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
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 pr
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 comme
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;
>
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 onl
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, G
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:
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 <[EM
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,
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 th
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
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 end: Transparent mutex-protected list
> > accesses provided
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 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 lock
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.
>
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_
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
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
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
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 ab
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 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 this patch:
>
> Convert semaphore to mutex in struct cla
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 m
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 maintainer trees otherwise, because they only take
fully bijectable patches.
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, bec
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 follo
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_devi
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
>
> Jan 3 10:45:15 darkstar kernel: ==
Convert semaphore to mutex in struct class.
All the patches in this series should be applyed simultaneously
toc:
---
1-driver-core-struct-class-convert-semaphore-to-mutex.patch
2-i2c-struct-class-convert-semaphore-to-mutex.patch
3-ieee1394-struct-class-convert-semaphore-to-mutex.patch
4-power-stru
34 matches
Mail list logo
