Thread (9 messages) 9 messages, 5 authors, 2009-10-26

[WARNING] pxamci: 'pxa2xx-mci.0' does not have a release() function.

From: Russell King - ARM Linux <hidden>
Date: 2009-10-23 10:18:06

On Fri, Oct 23, 2009 at 11:50:28AM +0200, Antonio Ospite wrote:
On Thu, 22 Oct 2009 23:57:58 +0100
Russell King - ARM Linux [off-list ref] wrote:
quoted
On Fri, Oct 23, 2009 at 12:36:31AM +0200, Antonio Ospite wrote:
quoted
Hi,

I get this warning on shutdown. How to fix it properly?

FYI, in my setup pxa2xx_spi is the parent for pxamci, set using
this patch:
http://git.openezx.org/openezx.git?a=commitdiff;h=0ffd85ad8faea3456d4ecf5f63ae65aca26fff21
This sounds like it's the cause of the problem - from the backtrace, it
looks like SPI expects the children of the SPI device to be its own
responsibility to maintain.

Hence, because you've made pxamci a child of SPI, SPI is trying to
unregister and release the pxamci device.
A little more background: we need pxamci to be a child of SPI because
our PMIC is connected via SPI, and a PMIC regulator is used for mmc
powering; enforcing this hierarchy is needed to make pxamci suspend and
resume properly.
I don't think this is the right solution - and I don't know what the
right solution would be given that the interfaces I suspect you need
aren't public.

I don't think you can reverse the order of SPI and MMC initialization
because that'd mean MMC could try to use SPI before it exists.

Maybe the right answer is for SPI to stop thinking it owns all child
devices, and only unregister devices which it owns (iow, are of some
SPI bus-type.)

Adding Greg for comment.
The board init does:
	spi_pd = platform_device_alloc("pxa2xx-spi", 1);
	spi_pd->dev.platform_data = &ezx_spi_masterinfo;
	platform_device_add(spi_pd);
	spi_register_board_info(ARRAY_AND_SIZE(a780_spi_boardinfo));

	pxa_set_mci_parent(&spi_pd->dev);
	pxa_set_mci_info(&ezx_mci_platform_data);

Now, do you suggest to adapt pxamci so it supports the case when
another driver wants to release it? I am not sure how to do that, tho.
Definitely not.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help