On Thu, Nov 22, 2012 at 09:23:22AM +0800, Ming Lei wrote:
> On Thu, Nov 22, 2012 at 12:51 AM, Sebastian Andrzej Siewior
> <sebastian@xxxxxxxxxxxxx> wrote:
> > On Wed, Nov 21, 2012 at 10:36:37PM +0800, Ming Lei wrote:
> >> On Wed, Nov 21, 2012 at 10:09 PM, Felipe Balbi <balbi@xxxxxx> wrote:
> >> >> status = musb_platform_init(musb);
> >> >> - if (status < 0)
> >> >> + if (status < 0) {
> >> >> + /* try to defer probe if trasceiver is not ready */
> >> >> + status = (status == -ENODEV ? -EPROBE_DEFER : status);
> >> >
> >> > still wrong, what you should do is that when you can't get the phy, you
> >> > set status to -EPROBE_DEFER, instead of -ENODEV.
> >>
> >> The above code does set status to to -EPROBE_DEFER when phy can't
> >> be got, doesn't it?
> >
> > What he meant was probably something like:
>
> In fact, there is not much side effect to defer probe for -ENODEV, and the
> other -ENODEV cases are seldom triggered.
of course there is. Maybe there won't be for current code (which isn't
the case provided we have another return of -ENODEV), but you can't
assume no other code will be added there.
> > @@ -1059,25 +1059,25 @@ static int tusb_musb_start(struct musb *musb)
> > }
> >
> > static int tusb_musb_init(struct musb *musb)
> > {
> > struct platform_device *pdev;
> > struct resource *mem;
> > void __iomem *sync = NULL;
> > int ret;
> >
> > usb_nop_xceiv_register();
> > musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
> > if (IS_ERR_OR_NULL(musb->xceiv))
> > return -ENODEV;
> > + return -EPROBE_DEFER;
> >
> > pdev = to_platform_device(musb->controller);
> >
> > /* dma address for async dma */
> > mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > musb->async = mem->start;
> >
> > /* dma address for sync dma */
> > mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > if (!mem) {
> > pr_debug("no sync dma resource?\n");
> > ret = -ENODEV;
>
> Also I am not sure if it is a proper error code for this case, maybe EINVAL
> is better.
-ENOMEM sounds more correct to me.
> > As you see there is a second ENODEV error code which has nothing to do with the
> > missing PHY. That is what I meant by a larger patch.
>
> As far as this problem concerned, I will prepare one larger patch to fix all
> glue driver.
tks
--
balbi
Attachment:
signature.asc
Description: Digital signature
