Re: Backlight and LCD module patches [2]

[Andrew Zabolotny]

On Sat, 31 Jul 2004 17:17:36 -0500
John Lenz <jelenz@xxxxxxxx> wrote:

> I could see it going either way I guess.  The other thing the class_match
> could do is create those symlinks from the two classes of devices.  What
> other way is there from userspace to see which lcd device is associated with
> fb device?
Ok, you convinced me that a thin layer would give something. However, I
still think it would be better to use the lists that are already present in
class core, and not create new lists that duplicate the main one. First, the
main list is the 'ultimate' source of information, second list could
occasionally get out of sync.

> Yea I see that, but I was trying to keep all the class related code
> contained in class.c  I feel kinda uncomfortable manipulating lists and
> locking locks in struct class from outside code.
Well, *if* class_match will be implemented, it will become a part of class
core. So there shouldn't be a problem with manipulating that list.

> The way I see it, we really need a policy decision here, and neither you nor
> I are "authorized" to make that decision :)  We have two completly seperate
> devices, both have a struct device and both have a struct device_driver. 
> They can sit on completly seperate buses and be mixed together in lots of
> different combinations. One of the devices "knows" if it matches with the
> other device.
You did a perfect summary of the problem. Greg, what's your answer?

--
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/