On Fri, May 17, 2013 at 10:27 PM, Alan Stern <[email protected]> wrote:
> On Fri, 17 May 2013, Peter Chen wrote:
>
>> > I found out a couple more things about this.
>> >
>> > If I do "rmmod dwc3" first, and then do "rmmod dwc3-pci", it doesn't
>> > crash.
>> >
>>
>> dwc3-pci will release dwc3 and its resources at its removal.
>> So, dwc3 core must be released first, then glue layer.
>
> That makes no sense. Obviously dwc3 can't be removed until all its
> resources have been released. And you said that dwc3-pci doesn't
> release the dwc3 resources until dwc3-pci has been removed.
>
> Therefore dwc3 can't be removed until dwc3-pci has been removed. This
> is exactly the opposite of what you wrote above.
>
After checking the code more, the things should like below:
At dwc3 core's removal:
602 static int dwc3_remove(struct platform_device *pdev)
603 {
604 struct dwc3 *dwc = platform_get_drvdata(pdev);
605
606 usb_phy_set_suspend(dwc->usb2_phy, 1);
607 usb_phy_set_suspend(dwc->usb3_phy, 1);
608
609 pm_runtime_put(&pdev->dev);
610 pm_runtime_disable(&pdev->dev);
At dwc3-pci's removal:
195 static void dwc3_pci_remove(struct pci_dev *pci)
196 {
197 struct dwc3_pci *glue = pci_get_drvdata(pci);
198
199 platform_device_unregister(glue->usb2_phy);
200 platform_device_unregister(glue->usb3_phy);
201 platform_device_unregister(glue->dwc3);
202 pci_set_drvdata(pci, NULL);
203 pci_disable_device(pci);
204 }
I am afraid I did not mention "platform_device_unregister(glue->dwc3)"
will call dwc3 core's removal.
If dwc3 core is removed first, then dwc3-pci. It is ok.
If dwc3-pci is removed first, the PHY's device will be removed,
when "platform_device_unregister(glue->dwc3) ->dwc3_remove
->usb_phy_set_suspend", the oops will be occurred.
I think it was the problem Paul met.
>> Since there are no relationship between core and glue
>> layer, If user unload module in incorrect order, the oops
>> may occur, the phy driver is the same situation.
>>
>> For such kinds of case, do we need to fix at kernel layer?
>> or using user space method to fix?
>
> There _should_ be a relationship between the core and the glue layer.
> The glue layer uses the core's resources; therefore the glue layer
> should contain references to symbols that are defined in the core.
> This will cause the kernel to prevent the core from being removed
> before the glue layer.
>
Yes, that is the hcd/gadget driver do.
> PHY drivers will need different treatment. I suspect that the right
> approach is to increment the phy driver's module count each time an HCD
> claims a PHY.
>
I think it is ok, one more thing is we need to return -EPROBE_DEFER
if PHY driver does not load before the HCD.
--
BR,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
