On Wed, Apr 13, 2022 at 11:01:23AM +0000, Linyu Yuan (QUIC) wrote:
> > From: Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>
> > Sent: Wednesday, April 13, 2022 6:24 PM
> > > > No, you don't check that, you just return that.
> > > Yes, I do like it.
> > > >
> > > > So you don't need that crazy polling mechanism where you queue a work
> > > > until you get the resource. Just let the driver core handle the
> > > > situation.
> > > The issue is when a UCSI implementation driver probe, it call ucsi_register(),
> > > But this function will not return -EPROBE_DEFER,
> > > It just queue a work to start connector discovery.
> >
> > Ah, right right. This is a library. But we should be able use
> > wait_for_device_probe().
> >
> > So if fwnode_usb_role_switch_get() returns -EPROBE_DEFER, you call
> > wait_for_device_probe() and try again.
> Do you mean do as below,
>
> find_role_switch:
> con->usb_role_sw = fwnode_usb_role_switch_get(cap->fwnode);
> if (IS_ERR(con->usb_role_sw)) {
> dev_err(ucsi->dev, "con%d: failed to get usb role switch\n",
> con->num);
> if (con->usb_role_sw == -EPROBE_DEFER) {
> wait_for_device_probe();
> goto find_role_switch;
> }
>
> return PTR_ERR(con->usb_role_sw);
> }
Yes, something like that. Perhaps you could just do that in a loop,
and you should have a delay there.
> Seem wait_for_device_probe() will wait all drivers probe,
> Can we accept it ?
That part is not a problem, but I'm not sure if it appropriate to call
the function from drivers. Let me check if there is something else
that we can do...
thanks,
--
heikki
