[PATCH v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early

Ezequiel García ezequiel at vanguardiasur.com.ar
Tue Apr 29 06:50:25 PDT 2014


On 29 April 2014 06:09, Sebastian Andrzej Siewior <bigeasy at linutronix.de> wrote:
> On 04/29/2014 10:27 AM, George Cherian wrote:
>> Hi Sebastian,
>
> Hi George,
>
>> On 4/29/2014 1:36 PM, Sebastian Andrzej Siewior wrote:
>>> On 04/29/2014 09:58 AM, George Cherian wrote:
>>>>>> This is easily fixed by moving the node at the beggining of the child
>>>>>> list,
>>>>>> so it's probed first.
>>>> This will give issues on module removal.
>>>> Since we use device_for_each_child in remove patch, it will try to
>>>> remove cppi dma controller, while the channel
>>>> is still in use by musb node.
>>> Isn't this currently disabled because it blew up in the phy code?
>> Yes. So how if the dt  looks like this
>
> No. I remember we talked about this and we decided not to duct tape the
> bug by moving the nodes around. Instead we wanted to disable the child
> removal part (one tiny module that can't be removed) until the PHY code
> does no longer blow up.
> If the same case is for the DMA driver then it should be fixed, too.
> The order of the nodes in .dts should not crash the kernel under any
> circumstances. If a different node order accelerates the probing then
> fine. But a crash is a no no.
>

I still don't see any reason to have the DMA controller node as a
child of the USB.
However, it seems we need it this way for now; at least until we get
rid of the hwmod
altogether.

That said, this DT-ordering to fix other issues is starting to seem a
very bad idea.
I'll prepare a v3 to leave the DT as it is, and instead force the
driver to probe and
remove the childs so the DMA is probed first and the removed last.

We can always get rid of such workaround, once we can remove the DMA controller
out of the USB - as it should be.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar



More information about the linux-arm-kernel mailing list