Em Sun, 11 Oct 2020 08:27:41 +0200 Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> escreveu: > Em Sat, 10 Oct 2020 23:50:27 +0200 > Daniel Vetter <daniel.vetter@xxxxxxxx> escreveu: > > > On Sat, Oct 10, 2020 at 11:36 PM Laurent Pinchart > > <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > > > > > > > > We probably still have a few legacy drivers using videobuf (non-2), > > > > but IMHO those should be safe to put behind some disabled-by-default > > > > Kconfig symbol or even completely drop, as the legacy framework has > > > > been deprecated for many years already. > > > > > > There's 8 drivers left, and they support a very large number of devices. > > > I expect unhappy users distros stop shipping them. On the other hand, > > > videobuf has been deprecated for a loooooooong time, so there has been > > > plenty of time to convert the remaining drivers to videobuf2. If nobody > > > can do it, then we'll have to drop support for these devices given the > > > security issues. > > > > Again, the issue here is _only_ with follow_pfn. For videobuf1 this > > means videbuf-dma-contig.c userptr support is broken. Unlike videobuf2 > > it means it's broken for all usage (not just zero-copy userptr), > > because videbuf-dma-contig.c lacks the pin_user_pages path. > > Well, follow_pfn() is used only by videbuf-dma-contig.c. If this is > the only part of VB1 that will have userptr broken, then there's > just one driver that might be affected: davinci. > > Yet, taking a deeper look: > > $ git grep include drivers/media/platform/davinci/|grep -i videobuf > drivers/media/platform/davinci/vpif_capture.h:#include <media/videobuf2-dma-contig.h> > drivers/media/platform/davinci/vpif_display.h:#include <media/videobuf2-dma-contig.h> > > It sounds to me that it was already converted to VB2, but some VB1 > symbols were not converted at its Kconfig. > > It sounds to me that there are other drivers with some VB1 left overs > at Kconfig, as those are the only ones using VB1 those days: > > $ for i in $(git grep media/videobuf drivers |grep -v videobuf2 |grep -v v4l2-core|cut -d: -f1); do dirname $i; done|sort|uniq > drivers/media/pci/bt8xx > drivers/media/pci/cx18 > drivers/media/platform > drivers/media/usb/tm6000 > drivers/media/usb/zr364xx > drivers/staging/media/atomisp/pci This is incomplete. There are two drivers that include videobuf indirectly: include/media/davinci/vpfe_capture.h include/media/drv-intf/saa7146_vv.h I double-checked that DaVinci still uses VB1. There are actually two clients for videbuf-dma-contig.c: davinci and fsl-viu. Those two will be affected, if we don't add pin_user_pages_fast() support to VB1 or convert them to VB2. > > > But that > > would be easy to add if this poses a problem I think - we just need > > to carry over the pin_user_pages_fast logic from videbuf2, no driver > > changes required. But of course I don't think we should do that before > > someone reports the regression, since videobuf1 userptr is doubly > > deprecated :-) > > I think otherwise. Keeping a broken component at the Kernel is > a bad idea. > > Yet, from my quick search above, it sounds to me that it is time for > us to retire the VB1 DMA contig support as a hole, as there's no client > for it anymore. > > I'll work on some patches cleaning up the VB1 left overs at > Kconfig and removing videbuf-dma-contig.c for good, if there's > no hidden dependency on it. > > > Thanks, > Mauro Thanks, Mauro _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
