On Thu, Jun 15, 2017 at 01:41:24PM -0700, Eric Anholt wrote: > If the panel-bridge is being set up after the drm_mode_config_reset(), > then the connector's state would never get initialized, and we'd > dereference the NULL in the hotplug path. We also need to register > the connector, so that userspace can get at it. > > Signed-off-by: Eric Anholt <eric@xxxxxxxxxx> I've not read all the details of the discussion here, just a comment on what this implies if we go with this. > --- > drivers/gpu/drm/bridge/panel.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c > index 67fe19e5a9c6..8ed8a70799c7 100644 > --- a/drivers/gpu/drm/bridge/panel.c > +++ b/drivers/gpu/drm/bridge/panel.c > @@ -82,11 +82,14 @@ static int panel_bridge_attach(struct drm_bridge *bridge) > > drm_mode_connector_attach_encoder(&panel_bridge->connector, > bridge->encoder); > + drm_atomic_helper_connector_reset(&panel_bridge->connector); I'm not sure we want to tie the ->reset stuff in with other helpers. One of the design goals I had with all things atomic was to make helpers much more modular, and imo the reset is one such piece - a driver might want to instead reconstruct state from hw using something like i915's hw state readout/compare/verify framework. If we can solve this init ordering issue without adding a depency on the reset stuff that would be a bit neater imo. But that's just my 2 cents. Cheers, Daniel > > ret = drm_panel_attach(panel_bridge->panel, &panel_bridge->connector); > if (ret < 0) > return ret; > > + drm_connector_register(&panel_bridge->connector); > + > return 0; > } > > -- > 2.11.0 > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
