recursive call to platform_device_register deadlocks

recursive call to platform_device_register deadlocks

[Jamey Hicks]

We wrote soc_device to handle ASICs that were structured as a number of 
subcomponents, some of which are reused from ASIC to ASIC.  This enables 
the drivers for the subcomponents to be in separate files, loaded as 
modules, and enhances code reuse.  We submitted soc_device, but it was 
pointed out that platform_device probably does what we want.

We've started working on replacing uses of soc_device in handhelds 
drivers by platform_device.   One of the things we ran into is that the 
platform_device driver for an ASIC was calling soc_device_register 
inside its probe function.  If this is converted to 
platform_device_register, then the process deadlocks because 
bus_add_device locks platform_bus_type.

We could restructure the toplevel driver so that it does not call 
platform_device inside its probe function.  An alternative would be to 
add a pointer to a vector of subdevices to platform_device and have it 
register the subdevices after it has probed the toplevel device.  Do you 
have any recommendations?

Thanks,
Jamey Hicks

Re: recursive call to platform_device_register deadlocks

[David Brownell]

> We could restructure the toplevel driver so that it does not call 
> platform_device inside its probe function.  An alternative would be to 
> add a pointer to a vector of subdevices to platform_device and have it 
> register the subdevices after it has probed the toplevel device.  Do you 
> have any recommendations?

Other busses have taken the former approach... the toplevel bit
being more like a bridge/hub than anything else, and the children
appearing later through some dynamic scan/hotplug.  That vector
could be used to implement such a "scan", triggered sometime after
the bridge/hub driver returns from probe(), avoiding both that
driver core deadlock and recursion during probe().

I think the SPI stack will have similar issues.  There it'll be
typical that configurations be static board-specific ones ... not
so dissimilar from configurations involving board-specific ASICs.
An SOC may have several SPI controllers, with their own chipselects,
and different boards will have different chips (like serial flash,
sensors, DAC/ADC, etc) on each chipselect.  Unlike busses designed
for hotplug, those chips won't always self-identify; a dynamic
scan won't generally behave.

Some model that makes it easy to declare static sections of the
device tree, and which is easily applied to other bus types, would
be a good thing.  Like maybe that "alternative" you sketched.

- Dave

Re: recursive call to platform_device_register deadlocks

[Greg KH]

On Sat, Jun 18, 2005 at 10:39:34AM -0400, Jamey Hicks wrote:
> 
> We could restructure the toplevel driver so that it does not call 
> platform_device inside its probe function.  An alternative would be to 
> add a pointer to a vector of subdevices to platform_device and have it 
> register the subdevices after it has probed the toplevel device.  Do you 
> have any recommendations?

Use the -mm kernel, this should be allowed in that release, due to a
rework of the driver core logic in this area.  Can you test this out and
verify this?

thanks,

greg k-h

Re: recursive call to platform_device_register deadlocks

[Jamey Hicks]

Greg KH wrote:

>On Sat, Jun 18, 2005 at 10:39:34AM -0400, Jamey Hicks wrote:
>  
>
>>We could restructure the toplevel driver so that it does not call 
>>platform_device inside its probe function.  An alternative would be to 
>>add a pointer to a vector of subdevices to platform_device and have it 
>>register the subdevices after it has probed the toplevel device.  Do you 
>>have any recommendations?
>>    
>>
>
>Use the -mm kernel, this should be allowed in that release, due to a
>rework of the driver core logic in this area.  Can you test this out and
>verify this?
>
>  
>
Sounds good.  I will test it out.

Jamey

Re: recursive call to platform_device_register deadlocks

[Russell King]

On Sat, Jun 18, 2005 at 10:39:34AM -0400, Jamey Hicks wrote:
> We've started working on replacing uses of soc_device in handhelds 
> drivers by platform_device.   One of the things we ran into is that the 
> platform_device driver for an ASIC was calling soc_device_register 
> inside its probe function.  If this is converted to 
> platform_device_register, then the process deadlocks because 
> bus_add_device locks platform_bus_type.

This should now be resolved as a result of Greg's recent patch driver
model patch set, as appeared on lkml last night.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: recursive call to platform_device_register deadlocks

[Jamey Hicks]

Greg KH wrote:

>On Sat, Jun 18, 2005 at 10:39:34AM -0400, Jamey Hicks wrote:
>  
>
>>We could restructure the toplevel driver so that it does not call 
>>platform_device inside its probe function.  An alternative would be to 
>>add a pointer to a vector of subdevices to platform_device and have it 
>>register the subdevices after it has probed the toplevel device.  Do you 
>>have any recommendations?
>>    
>>
>
>Use the -mm kernel, this should be allowed in that release, due to a
>rework of the driver core logic in this area.  Can you test this out and
>verify this?
>
>  
>
I tested 2.6.12-mm1 yesterday and verified that it allows recursive 
calls to platform_device.

Jamey