On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote: > On Mon, Nov 27, 2017 at 08:52:19PM +0000, Sudip Mukherjee wrote: > > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote: > > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote: > > > > Almost all drivers using remove_conflicting_framebuffers() wrap it with > > > > the same code. Extract common part from PCI drivers into separate > > > > remove_conflicting_pci_framebuffers(). > > > > > > > > Signed-off-by: Michał Mirosław <mirq-li...@rere.qmqm.pl> > > > > > > Since the only driver that seems to use this is the staging one, which imo > > > is a DOA project, not sure it's worth to bother with this here. > > > > afaik, this device is used in production by few manufacturers and it is > > usefull for them to have it in the tree and the only reason it is still > > in staging is because Tomi announced he will not take any new drivers in > > fbdev. And, so I have not taken the initiative to properly move it out > > of staging. I think Bartlomiej will also not accept new drivers in fbdev. > > Imo, if no one cares about porting it to kms (which will give you an fbdev > driver for free), then we should throw it out. At least I thought staging > was only for stuff that had a reasonable chance to get mainlined. Not as a > dumping ground for drivers that people use, but don't bother to get ready > for mainline. > > Greg?
Yes, if no one is working to get it out of staging, that means no one cares about it, and it needs to be removed from the tree. thanks, greg k-h _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
