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. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
