Re: Backlight and LCD module patches [2]

[John Lenz <lenz@cs.wisc.edu>]

On 09/05/04 10:00:32, Greg KH wrote:
> On Sat, Aug 21, 2004 at 02:51:33AM +0000, John Lenz wrote:
> >
> > Here.  A few notes on the implementation.  I have a global lock
> protecting
> > all match operations because otherwise we get a dining philosophers
> problem.
> > (Say the same class is in two class_match structures, class1 in the
> first
> > one and class2 in the second...)
> 
> You also have some duplicated code in one function, which implies that
> you didn't test this patch (it's in the updated patch you sent me too) :)

I didn't test it.  It was only to show what I was thinking of with  
class_match.

> 
> > The bigger question of how should we be linking these together in the
> first
> > place?
> 
> I thought you only wanted the ability to actually find the different
> class devices.  Then the code would take it from there.  Not this
> complex driver core linking logic that you implemented.
> 
> > Instead of using this class_match stuff, we could use class_interface.
> 
> Exactly.  Why don't you all use that instead?

The only benifit from class_match is the "object oriented approach".  I  
assume that the struct list_head children in struct class can be used from  
driver code?  It is the correct policy to use that directly than to call a  
function in class.c?  As well, the struct kobject in class_device (which we  
would use to create a symbolic link)?  And of course our driver code would  
have to acquire class->subsys.rwsem...

If we do it in lcdbase.c we can even solve the locking problem... that is,  
we can always acquire class->subsys.rwsem in the lcd class before the  
class->subsys.rwsem in fb_class.

John