On Tue, Dec 17, 2013 at 11:51 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > On Tue, Dec 17, 2013 at 10:58:51PM +0100, Daniel Vetter wrote: >> On Tue, Dec 17, 2013 at 10:30 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: >> > So in the unlikely event that the fb helper code fails I don't want to >> > fall over. >> > >> > But that shouldn't happen in practice. I only have the checks in place >> > to catch when I failed to set the fbdev field in one path (which is now >> > fixed) >> >> Imo if a core piece of the driver fails to initialize we should just >> fail driver loading. We've had tons of crazy lore around contexts >> failing, ppgtt failing and other similar stuff, and I think it just >> makes the normal code more fragile with no real gain. >> >> If you think something slips through the cracks maybe just throw a >> BUG_ON in there instead. > > I tripped over it earlier when I was disabling parts of the driver. > I think allowing dev_priv->fbdev to be NULL fits nicely with your > crusade against fbcon. > (In fact it was quite fun to load the driver without modesetting as a > headless accelerator...) Well for fully disabled fbdev we nuke all those functions completely. If we want to go with this safety net here then I think at least a WARN_ON or something should be put in there, since this really shouldn't happen. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
