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.red...@gmail.com>
> 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
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
