device/driver binding notification

device/driver binding notification

[Jean Delvare]

Hi Greg, hi Kay,

In the course of finally making the i2c subsystem comply with the Linux
2.6 device driver model, I am facing an issue which affects many v4l
drivers. I'm curious if the core device driver code has something to
offer to solve it.

Basically, a v4l driver creates an i2c bus, instantiates i2c devices on
that bus, and needs i2c chip drivers for these devices. In the past, i2c
devices were always bound to a driver by the time the v4l driver knew
they existed, so they were directly usable. But now that we follow the
device driver model, this is no longer the case. The sequence of events
is as follows:

1* v4l driver creates i2c bus.

2* v4l driver declares i2c devices in that bus.
   At this point, the v4l driver can't be used yet.

3* Later on, the drivers for these devices in question are loaded
   (typically thanks to udev), and they bind to the i2c devices.

4* Now the v4l driver can complete its initialization and users can make
   use of the device.

For now, between steps 2 and 3, I made the v4l driver sleep and
repeatedly check whether i2c_client.driver is set or not. It works but
it's pretty ugly. I am curious if there's a way to be notified when a
driver is finally bound to a given device? That's what I would need.

This also raises another question on reference counting. Ideally, the
i2c chip drivers shouldn't be allowed to be removed before the v4l
driver itself is (without the i2c chip drivers, the v4l drivers cannot
work properly.) So I would like to increase the reference count to the
i2c chip drivers when they bind to my chips, and decrease it when I
quit. Should I just do a try_module_get(i2c_driver.driver.owner) at a
random time and just hope for the best? Or is there a cleaner way to
express that kind of dependency between drivers?

Thanks,
-- 
Jean Delvare

Re: device/driver binding notification

[Kay Sievers]

On Sat, 2008-07-05 at 20:54 +0200, Jean Delvare wrote:
> Hi Greg, hi Kay,
> 
> In the course of finally making the i2c subsystem comply with the Linux
> 2.6 device driver model, I am facing an issue which affects many v4l
> drivers. I'm curious if the core device driver code has something to
> offer to solve it.
> 
> Basically, a v4l driver creates an i2c bus, instantiates i2c devices on
> that bus, and needs i2c chip drivers for these devices. In the past, i2c
> devices were always bound to a driver by the time the v4l driver knew
> they existed, so they were directly usable. But now that we follow the
> device driver model, this is no longer the case. The sequence of events
> is as follows:
> 
> 1* v4l driver creates i2c bus.
> 
> 2* v4l driver declares i2c devices in that bus.
>    At this point, the v4l driver can't be used yet.
> 
> 3* Later on, the drivers for these devices in question are loaded
>    (typically thanks to udev), and they bind to the i2c devices.
> 
> 4* Now the v4l driver can complete its initialization and users can make
>    use of the device.
> 
> For now, between steps 2 and 3, I made the v4l driver sleep and
> repeatedly check whether i2c_client.driver is set or not. It works but
> it's pretty ugly. I am curious if there's a way to be notified when a
> driver is finally bound to a given device? That's what I would need.

Is this what you are looking for? BUS_NOTIFY_BOUND_DRIVER:
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=116af378201ef793424cd10508ccf18b06d8a021

> This also raises another question on reference counting. Ideally, the
> i2c chip drivers shouldn't be allowed to be removed before the v4l
> driver itself is (without the i2c chip drivers, the v4l drivers cannot
> work properly.) So I would like to increase the reference count to the
> i2c chip drivers when they bind to my chips, and decrease it when I
> quit. Should I just do a try_module_get(i2c_driver.driver.owner) at a
> random time and just hope for the best? Or is there a cleaner way to
> express that kind of dependency between drivers?

Shouldn't the v4l device take a reference on the i2c device which will
prevent the i2c device to go away?

Kay

Re: device/driver binding notification

[Jean Delvare]

Hi Kay,

Thanks for your quick reply.

On Mon, 07 Jul 2008 14:41:31 +0200, Kay Sievers wrote:
> On Sat, 2008-07-05 at 20:54 +0200, Jean Delvare wrote:
> > Hi Greg, hi Kay,
> > 
> > In the course of finally making the i2c subsystem comply with the Linux
> > 2.6 device driver model, I am facing an issue which affects many v4l
> > drivers. I'm curious if the core device driver code has something to
> > offer to solve it.
> > 
> > Basically, a v4l driver creates an i2c bus, instantiates i2c devices on
> > that bus, and needs i2c chip drivers for these devices. In the past, i2c
> > devices were always bound to a driver by the time the v4l driver knew
> > they existed, so they were directly usable. But now that we follow the
> > device driver model, this is no longer the case. The sequence of events
> > is as follows:
> > 
> > 1* v4l driver creates i2c bus.
> > 
> > 2* v4l driver declares i2c devices in that bus.
> >    At this point, the v4l driver can't be used yet.
> > 
> > 3* Later on, the drivers for these devices in question are loaded
> >    (typically thanks to udev), and they bind to the i2c devices.
> > 
> > 4* Now the v4l driver can complete its initialization and users can make
> >    use of the device.
> > 
> > For now, between steps 2 and 3, I made the v4l driver sleep and
> > repeatedly check whether i2c_client.driver is set or not. It works but
> > it's pretty ugly. I am curious if there's a way to be notified when a
> > driver is finally bound to a given device? That's what I would need.
> 
> Is this what you are looking for? BUS_NOTIFY_BOUND_DRIVER:
>   http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=116af378201ef793424cd10508ccf18b06d8a021

Looks really good :) Thanks for the pointer. I'll get back to you if
it doesn't work for me, but apparently it should.

> > This also raises another question on reference counting. Ideally, the
> > i2c chip drivers shouldn't be allowed to be removed before the v4l
> > driver itself is (without the i2c chip drivers, the v4l drivers cannot
> > work properly.) So I would like to increase the reference count to the
> > i2c chip drivers when they bind to my chips, and decrease it when I
> > quit. Should I just do a try_module_get(i2c_driver.driver.owner) at a
> > random time and just hope for the best? Or is there a cleaner way to
> > express that kind of dependency between drivers?
> 
> Shouldn't the v4l device take a reference on the i2c device which will
> prevent the i2c device to go away?

They do eventually take a reference to the i2c device, but that's not
really the point. They control the life cycle of the device anyway, so
it's not going away. What the v4l drivers want to protect themselves
against, is said i2c device being unbound from its driver, because they
just can't work properly if they can't delegate a part of the work to
the i2c drivers.

My hope was that we could take a reference to the modules that provide
the drivers in question at the time they bind, so that they simply
can't be removed until we say it's safe, but I guess it wouldn't
protect us against manual unbind from sysfs. Unless there is a way to
block manual unbind, too?

In theory I guess that the v4l drivers should expect the i2c device to
be unbound and they should put themselves on hold when this happens,
until the devices are bound again, at which point they would need to
resync or reinitialize everything. However in practice this seems to
add a lot of complexity to the drivers, to handle a case which should
never happen in practice, so I'm reluctant to go that way.

Thanks,
-- 
Jean Delvare