On 07/29/04 19:06:45, Andrew Zabolotny wrote:
> On Thu, 29 Jul 2004 18:25:47 -0500
> John Lenz <jelenz@students.wisc.edu> wrote:
> 
> > Actually, now that I think about it a bit more, I think the  
> > lcd_properties->match function should take a device * as a paramater  
> > instead of a fb_info *.  Insead of passing the fb_info pointer to the  
> > match function, we really should be passing the actual device  
> > structure.  For example, in the pxafb driver, it would register the  
> > platform_device that it creates with either the class code (if  
> > class_match is used) or with the lcdbase code.  This way the lcd driver  
> > could examine the device * and look at for example which resources it  
> > used, which memory region it was using, etc. and make its decision.

> If you look here: http://lkml.org/lkml/2004/6/26/84 you can see that this is
> exactly what I was proposing minus your proposal for a more generic
> class device match function. I was imagining that it would happen this way:
> the framebuffer device during initialization calls lcd_find_device() and
> passes his own 'struct device' to it; then lcd_find_device calls the match
> function of every previously registered LCD device with this parameter. The
> first one that says 'match' is returned. Same about backlight.

The only problem is that what happens if the fb device is registered before
the lcd device?  So that means you still need to keep around a list of fb
devices that have been registered so that when a new lcd device is registered
it can check if it matches an old fb device.

> 
> I don't see many reasons for a generic class match function. Last but not
> least the lcd_find_device() function is very small, so it will be a negligible
> gain but a lot of hassle (as you said, framebuffer drivers will have to be
> rewritten to not use the simple_class device class).
> 

The only advantage is we let the core class code take care of managing the 2 lists
of devices for us (which it is doing anyway).  Then the driver doesn't need to
keep the fb list around, doesn't need to keep the lcd list around, doesn't need
to write all that locking code to make sure the lists aren't updated all at the
same time, etc.  The class code already has these lists, already provides locking
for them, etc.

The fb stuff doesn't have to be rewritten to use normal classes, the class_match
could still work with simple classes.  The only change would be we would need some way
to pass the device pointer to the class_simple_device_add() function in fbmem.c,
a pretty trivial change.  Notice in fbmem it calls class_simple_device_add with a
paramater of NULL.  We would just like the individual driver to optionally pass a
device * there instead of NULL.

Perhaps a patch would better explain the situation.  I haven't even tried to compile
this patch, but it should give you an idea of what I am thinking here.  The only
thing I didn't add to this was the actual implementation of class_match_register,
but I can write that as well.

John