[Q] reprobe deferred-probing drivers

[Q] reprobe deferred-probing drivers

[Guennadi Liakhovetski]

Hi

I've got a situation, for which I currently don't have a (good) solution.

Let's say device A depends on device B and as long as B hasn't probed, A 
requests deferred probing. Now B probes, which causes A to also succeed 
its probing. Next we want to remove B, say, by unloading its driver. A has 
to go back into "deferred-probing" state. How do we do it? This can be 
achieved by unloading B's driver and loading again. Essentially, we have 
to use the sysfs "unbind" and then the "bind" attributes. But how do we do 
this from the kernel? Shall we export driver_bind() and driver_unbind()?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [Q] reprobe deferred-probing drivers

[Guennadi Liakhovetski]

On Wed, 17 Oct 2012, Guennadi Liakhovetski wrote:

> Hi
> 
> I've got a situation, for which I currently don't have a (good) solution.

Ok, right, would it be acceptable to just do something like

		if (dev->parent)
			device_lock(dev->parent);
		device_release_driver(dev);
		device_attach(dev);

?

Thanks
Guennadi

> Let's say device A depends on device B and as long as B hasn't probed, A 
> requests deferred probing. Now B probes, which causes A to also succeed 
> its probing. Next we want to remove B, say, by unloading its driver. A has 
> to go back into "deferred-probing" state. How do we do it? This can be 
> achieved by unloading B's driver and loading again. Essentially, we have 
> to use the sysfs "unbind" and then the "bind" attributes. But how do we do 
> this from the kernel? Shall we export driver_bind() and driver_unbind()?

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [Q] reprobe deferred-probing drivers

[Ming Lei]

On Wed, Oct 17, 2012 at 4:43 PM, Guennadi Liakhovetski
<g.liakhovetski@gmx.de> wrote:
> On Wed, 17 Oct 2012, Guennadi Liakhovetski wrote:
>
>> Hi
>>
>> I've got a situation, for which I currently don't have a (good) solution.
>
> Ok, right, would it be acceptable to just do something like
>
>                 if (dev->parent)
>                         device_lock(dev->parent);
>                 device_release_driver(dev);
>                 device_attach(dev);

The above should be OK for your purpose, and looks some other
deferred-probe devices may need this handling too.

But I am wondering how you could get the pointer of device A for
releasing driver in device B's remove()?

Thanks,
-- 
Ming Lei

Re: [Q] reprobe deferred-probing drivers

[Greg Kroah-Hartman]

On Wed, Oct 17, 2012 at 10:27:36AM +0200, Guennadi Liakhovetski wrote:
> Hi
> 
> I've got a situation, for which I currently don't have a (good) solution.
> 
> Let's say device A depends on device B and as long as B hasn't probed, A 
> requests deferred probing. Now B probes, which causes A to also succeed 
> its probing. Next we want to remove B, say, by unloading its driver. A has 
> to go back into "deferred-probing" state. How do we do it? This can be 
> achieved by unloading B's driver and loading again. Essentially, we have 
> to use the sysfs "unbind" and then the "bind" attributes. But how do we do 
> this from the kernel? Shall we export driver_bind() and driver_unbind()?

No, no driver should ever have to mess with that at all, it is up to the
bus to do this.  Do you have a pointer to the code you are concerned
about?

greg k-h

Re: [Q] reprobe deferred-probing drivers

[Guennadi Liakhovetski]

On Wed, 17 Oct 2012, Greg Kroah-Hartman wrote:

> On Wed, Oct 17, 2012 at 10:27:36AM +0200, Guennadi Liakhovetski wrote:
> > Hi
> > 
> > I've got a situation, for which I currently don't have a (good) solution.
> > 
> > Let's say device A depends on device B and as long as B hasn't probed, A 
> > requests deferred probing. Now B probes, which causes A to also succeed 
> > its probing. Next we want to remove B, say, by unloading its driver. A has 
> > to go back into "deferred-probing" state. How do we do it? This can be 
> > achieved by unloading B's driver and loading again. Essentially, we have 
> > to use the sysfs "unbind" and then the "bind" attributes. But how do we do 
> > this from the kernel? Shall we export driver_bind() and driver_unbind()?
> 
> No, no driver should ever have to mess with that at all, it is up to the
> bus to do this.  Do you have a pointer to the code you are concerned
> about?

No, not yet. I'm currently working on it. I'll do it using the

		device_release_driver(sd->dev);
		device_attach(sd->dev);

trick and post to linux-media. I'll (try to remember to) add you to cc, 
then we can see how to properly implement it.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/