展讯android LEDS模块分析----各种关系

         言归正传，我想详细说一下这个函数，

bus = bus_get(drv->bus);退回去想一想，drv->bus是什么bus，是&sprd_kb_led_driver->driver->bus，是&platform_bus_type，

priv->driver = drv; drv->p = priv;建立起drv->p 和 drv之间的关系

priv->kobj.kset = bus->p->drivers_kset;   kset 出现了！用来连接上下层之间的关系，其实是把drv绑定到上一层的bus上，

kobject_init_and_add(&priv->kobj, &driver_ktype, NULL,"%s", drv->name)->kobject_add_varg->kobject_set_name_vargs，那么，这个函数就把“keyboard-backlight”这个sprd_kb_led_driver.name对应到sprd_kb_led_driver->p->kobj.name上，然后在通过kobject_add_internal->create_dir就把“keyboard-backlight”创建了个目录挂在了“platform”上。为什么是“platform”上了呢？不是传说中他的上一层目录会是kobject->parent么？如果没记错的话，我们还从未对drv->p->kobject->parent赋过值，那么他应该是NULL才对啊。

        说实话，年轻真好，我记得我高中的时候竟然能够背诵整片的课文，现在回想起来，崇拜自己五体投地。而现在让我想这些链表的对应关系，乱，一团麻！不知道当年写这些东西的大神的脑子是怎么想的。万份怀念谭爷爷！没办法，为生存还得记住他，回头瞅了一眼，的确drv->p->kobject->parent是空，从开天辟地开始。还好那群Linux疯子们没有忘记他，kobject_add_internal中有这么一句判断 parent = kobject_get(kobj->parent);

/* join kset if set, use it as parent if we do not already have one */

if (kobj->kset) {

if (!parent)

parent = kobject_get(&kobj->kset->kobj);

kobj_kset_join(kobj);

kobj->parent = parent;

}

这个时候kset的作用似乎体现了出来一点点。我们曾经对kobject->kset赋过值，您不记得吗？是啊，您依然是皇上，它还是大明湖畔的那个夏雨荷！

priv->kobj.kset = bus->p->drivers_kset;曾经不经意间的一次回眸，换回了今天不用光混。这样，bus->p->drivers_kset->kobject赋给了孤独的drv->p->kobject->parent，so，“platform”目录下面必然有一个叫做“keyboard-backlight”的目录了。