Messages in this thread | | | Date | Fri, 30 Jul 2004 04:06:45 +0400 | From | Andrew Zabolotny <> | Subject | Re: Backlight and LCD module patches [2] |
| |
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.
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).
-- Greetings, Andrew - 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/
| |