Re: Backlight and LCD module patches [2]

[Andrew Zabolotny]

On Thu, 29 Jul 2004 19:49:50 -0500
John Lenz <jelenz@xxxxxxxxxxxxxxxxx> wrote:

> 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.
Right now it happens in a different way. The patch I've published earlier uses
notifier objects (linux/notifier.h) so that if framebuffer can't find the
matched lcd device, it registers to be notified when new lcd devices appear in
the system; when it does it proceeds like usual (e.g. calls lcd_device_find).
Until it finds the LCD device framebuffer device cannot even initialize
(without powering on the LCD controller in some circumstances it's impossible
to do anything useful).

> 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).
These lists are anyway maintained by the class.c core. You just need a pointer
to the 'struct class' variable for classes you are interested in, and locking
also comes for free - everything is already implemented. Look in class.c for
list_for_each_entry macros - they all are traveling along these lists.

I personally don't like to make this device matching too generalized - if we
need it for b/l, that's fine, we'll have to implement it for b/l.
But it doesn't look too sane, so I'd rather leave it l/b specific.

--
Greetings,
   Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/