On Fri, May 04, 2018 at 01:58:20PM +0200, Boris Brezillon wrote: > On Fri, 4 May 2018 12:18:52 +0200 Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > On Thu, May 03, 2018 at 06:40:05PM +0200, Boris Brezillon wrote: [...] > > > return mdp4_lvds_connector->panel ? > > > connector_status_connected : > > > diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c > > > index 7a03a9489708..fffc80b73966 100644 > > > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c > > > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c > > > @@ -1881,7 +1881,7 @@ int msm_dsi_host_register(struct mipi_dsi_host *host, bool check_defer) > > > * output > > > */ > > > if (check_defer && msm_host->device_node) { > > > - if (!of_drm_find_panel(msm_host->device_node)) > > > + if (IS_ERR(of_drm_find_panel(msm_host->device_node))) > > > if (!of_drm_find_bridge(msm_host->device_node)) > > > return -EPROBE_DEFER; > > > } > > > > Again, pretty weird stuff going on here, prior to the patch. But I think > > this needs to be changed to take the -ENODEV into account in the next > > patch. As it is, this will continue to defer probe even if the panel > > node is disabled. > > Not sure this is a problem. I mean, the code was working before, and we > had no way to differentiate the -ENODEV vs -EPROBE_DEFER, which in turn > means that, any driver that assumed that the device would appear at some > point were just as broken as they are after this patch when the node > they're pointing to has its status set to "disabled". > > I'm not trying to patch all drivers to take the return code into > account, just those that might take advantage of it. Okay, fair enough. Thierry
Attachment:
signature.asc
Description: PGP signature