Re: [patch] [media] uvcvideo: freeing an error pointer

Am 25.11.2016 14:57, schrieb Laurent Pinchart: > Hi Dan, > > Thank you for the patch. > > On Friday 25 Nov 2016 13:28:35 Dan Carpenter wrote: >> A recent cleanup introduced a potential dereference of -EFAULT when we >> call kfree(map->menu_info). > > I should have caught that, my apologies

[PATCH 01/10] doc: DT: camss: Binding document for Qualcomm Camera subsystem driver

Add DT binding document for Qualcomm Camera subsystem driver. Signed-off-by: Todor Tomov --- .../devicetree/bindings/media/qcom,camss.txt | 196 + 1 file changed, 196 insertions(+) create mode 100644

[PATCH 3/6] drm: mali-dp: Rename malidp_input_format

We're going to use the same format list for output formats, so rename everything related to input formats to avoid confusion. Signed-off-by: Brian Starkey Reviewed-by: Liviu Dudau --- drivers/gpu/drm/arm/malidp_hw.c | 24

Re: Enabling peer to peer device transactions for PCIe devices

A white list may end up being rather complicated if it has to cover different CPU generations and system architectures. I feel this is a decision user space could easily make. Logan I agreed that it is better to leave up to user space to check what is working and what is not. I found that

[RFC PATCH v3 0/6] Introduce writeback connectors

Hi, This is v3 of my series introducing a new connector type: DRM_MODE_CONNECTOR_WRITEBACK See v1 and v2 here: [1] [2] Writeback connectors are used to expose the memory writeback engines found in some display controllers, which can write a CRTC's composition result to a memory buffer. This is

[PATCH 6/6] drm: mali-dp: Add writeback connector

Mali-DP has a memory writeback engine which can be used to write the composition result to a memory buffer. Expose this functionality as a DRM writeback connector on supported hardware. Changes since v1: Daniel Vetter: - Don't require a modeset when writeback routing changes - Make writeback

[PATCH 1/6] drm: Add writeback connector type

Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type and related support functions. Drivers should initialize a writeback connector with drm_writeback_connector_init() which takes care of setting up all the

[PATCH 2/6] drm: writeback: Add out-fences for writeback connectors

Add the OUT_FENCE_PTR property to writeback connectors, to enable userspace to get a fence which will signal once the writeback is complete. It is not allowed to request an out-fence without a framebuffer attached to the connector. A timeline is added to drm_writeback_connector for use by the

Re: [PATCH] Media: Platform: Omap3isp: Do not forget to call

Hi Shailendra, Thank you for the patch. On Friday 25 Nov 2016 10:14:32 Shailendra Verma wrote: > v4l2_fh_init is already done.So call the v4l2_fh_exit in error condition > before returing from the function. > > Signed-off-by: Shailendra Verma > --- >

[PATCH 00/10] Qualcomm 8x16 Camera Subsystem driver

This patchset adds basic support for the Qualcomm Camera Subsystem found on Qualcomm MSM8916 and APQ8016 processors. The driver implements V4L2, Media controller and V4L2 subdev interfaces. Camera sensor using V4L2 subdev interface in the kernel is supported. The driver is implemented using as a

[PATCH 10/10] media: camss: Add Makefiles and Kconfig files

Add Makefiles and Kconfig files to build the camss driver. Signed-off-by: Todor Tomov --- drivers/media/platform/qcom/Kconfig | 5 + drivers/media/platform/qcom/Makefile| 1 + drivers/media/platform/qcom/camss-8x16/Makefile | 12

Re: [patch] [media] uvcvideo: freeing an error pointer

Hi Walter, On Friday 25 Nov 2016 15:47:49 walter harms wrote: > Am 25.11.2016 14:57, schrieb Laurent Pinchart: > > On Friday 25 Nov 2016 13:28:35 Dan Carpenter wrote: > >> A recent cleanup introduced a potential dereference of -EFAULT when we > >> call kfree(map->menu_info). > > > > I should

Re: Enabling peer to peer device transactions for PCIe devices

On 25/11/16 06:06 AM, Christian König wrote: > Well Serguei send me a couple of documents about QPI when we started to > discuss this internally as well and that's exactly one of the cases I > had in mind when writing this. > > If I understood it correctly for such systems P2P is technical

[PATCH 04/10] media: camss: Add CSIPHY files

These files control the CSIPHY modules which are responsible for the physical layer of the CSI2 receivers. Signed-off-by: Todor Tomov --- drivers/media/platform/qcom/camss-8x16/csiphy.c | 685 drivers/media/platform/qcom/camss-8x16/csiphy.h | 77

[PATCH 02/10] MAINTAINERS: Add Qualcomm Camera subsystem driver

Add an entry for Qualcomm Camera subsystem driver. Signed-off-by: Todor Tomov --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 411e3b8..0740aee 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9971,6 +9971,14 @@ T:

[PATCH 5/6] drm: mali-dp: Add RGB writeback formats for DP550/DP650

Add a layer bit for the SE memory-write, and add it to the pixel format matrix for DP550/DP650. Signed-off-by: Brian Starkey --- drivers/gpu/drm/arm/malidp_hw.c | 28 ++-- drivers/gpu/drm/arm/malidp_hw.h |1 + 2 files changed, 15

[PATCH 09/10] media: camms: Add core files

These files implement the platform driver code. Signed-off-by: Todor Tomov --- drivers/media/platform/qcom/camss-8x16/camss.c | 603 + drivers/media/platform/qcom/camss-8x16/camss.h | 93 2 files changed, 696 insertions(+) create mode

[PATCH 05/10] media: camss: Add CSID files

These files control the CSID modules which handle the protocol and application layer of the CSI2 receivers. Signed-off-by: Todor Tomov --- drivers/media/platform/qcom/camss-8x16/csid.c | 1071 + drivers/media/platform/qcom/camss-8x16/csid.h | 82

[PATCH 06/10] media: camss: Add ISPIF files

These files control the ISPIF module which handles the routing of the data streams from the CSIDs to the inputs of the VFE. Signed-off-by: Todor Tomov --- drivers/media/platform/qcom/camss-8x16/ispif.c | 1105

[PATCH 03/10] doc: media/v4l-drivers: Add Qualcomm Camera Subsystem driver document

Add a document to describe Qualcomm Camera Subsystem driver. Signed-off-by: Todor Tomov --- Documentation/media/v4l-drivers/index.rst | 1 + Documentation/media/v4l-drivers/qcom_camss.rst | 124 + 2 files changed, 125 insertions(+) create

[PATCH 07/10] media: camss: Add VFE files

These files control the VFE module. The VFE has different input interfaces. The PIX input interface feeds the input data to an image processing pipeline. Three RDI input interfaces bypass the image processing pipeline. The VFE also contains the AXI bus interface which writes the output data to

[PATCH 08/10] media: camss: Add files which handle the video device nodes

These files handle the video device nodes of the camss driver. Signed-off-by: Todor Tomov --- drivers/media/platform/qcom/camss-8x16/video.c | 597 + drivers/media/platform/qcom/camss-8x16/video.h | 67 +++ 2 files changed, 664 insertions(+)

Re: Enabling peer to peer device transactions for PCIe devices

Well, I guess there's some consensus building to do. The existing options are: * Device DAX: which could work but the problem I see with it is that it only allows one application to do these transfers. Or there would have to be some user-space coordination to figure which application gets what

Re: Enabling peer to peer device transactions for PCIe devices

On 2016-11-25 08:22 AM, Christian König wrote: Serguei, what is your plan in GPU land for migration? Ie if I have a CPU mapped page and the GPU moves it to VRAM, it becomes non-cachable - do you still allow the CPU to access it? Or do you swap it back to cachable memory if the CPU touches it?

Re: Enabling peer to peer device transactions for PCIe devices

On Fri, Nov 25, 2016 at 02:22:17PM +0100, Christian König wrote: > >Like you say below we have to handle short lived in the usual way, and > >that covers basically every device except IB MRs, including the > >command queue on a NVMe drive. > > Well a problem which wasn't mentioned so far is that

[patch] [media] media: ti-vpe: vpdma: fix a timeout loop

The check assumes that we end on zero but actually we end on -1. Change the post-op to a pre-op so that we do end on zero. Techinically now we only loop 499 times instead of 500 but that's fine. Fixes: dc12b124353b ("[media] media: ti-vpe: vpdma: Add abort channel desc and cleanup APIs")

Re: [patch] [media] uvcvideo: freeing an error pointer

On Fri, Nov 25, 2016 at 03:57:51PM +0200, Laurent Pinchart wrote: > diff --git a/mm/slab.c b/mm/slab.c > index 0b0550ca85b4..a7eb830c6684 100644 > --- a/mm/slab.c > +++ b/mm/slab.c > @@ -3819,6 +3819,8 @@ void kfree(const void *objp) > > if (unlikely(ZERO_OR_NULL_PTR(objp))) >

Re: [patch] [media] uvcvideo: freeing an error pointer

On Fri, Nov 25, 2016 at 06:02:45PM +0200, Laurent Pinchart wrote: > Sakari Ailus (CC'ed) has expressed the opinion that we might want to go one > step further and treat error pointers the same way we treat NULL or ZERO > pointers today, by just returning without logging anything. The reasoning

Re: Enabling peer to peer device transactions for PCIe devices

On 2016-11-25 03:26 PM, Felix Kuehling wrote: On 16-11-25 12:20 PM, Serguei Sagalovitch wrote: A white list may end up being rather complicated if it has to cover different CPU generations and system architectures. I feel this is a decision user space could easily make. Logan I agreed that

Re: Enabling peer to peer device transactions for PCIe devices

On 16-11-25 12:20 PM, Serguei Sagalovitch wrote: > >> A white list may end up being rather complicated if it has to cover >> different CPU generations and system architectures. I feel this is a >> decision user space could easily make. >> >> Logan > I agreed that it is better to leave up to user

Re: Enabling peer to peer device transactions for PCIe devices

On Thu, Nov 24, 2016 at 11:58:17PM -0800, Christoph Hellwig wrote: > On Thu, Nov 24, 2016 at 11:11:34AM -0700, Logan Gunthorpe wrote: > > * Regular DAX in the FS doesn't work at this time because the FS can > > move the file you think your transfer to out from under you. Though I > > understand

Re: Enabling peer to peer device transactions for PCIe devices

On Fri, Nov 25, 2016 at 02:49:50PM -0500, Serguei Sagalovitch wrote: > GPU could perfectly access all VRAM. It is only issue for p2p without > special interconnect and CPU access. Strictly speaking as long as we > have "bus address" we could have RDMA but I agreed that for > RDMA we

Re: Enabling peer to peer device transactions for PCIe devices

On Fri, Nov 25, 2016 at 09:40:10PM +0100, Christian König wrote: > We call this "userptr" and it's just a combination of get_user_pages() on > command submission and making sure the returned list of pages stays valid > using a MMU notifier. Doesn't that still pin the page? > The "big" problem

Re: [PATCH 1/1] smiapp: Implement power-on and power-off sequences without runtime PM

Hi Alan, On Friday 25 Nov 2016 10:21:21 Alan Stern wrote: > On Fri, 25 Nov 2016, Sakari Ailus wrote: > > On Thu, Nov 24, 2016 at 09:15:39PM -0500, Alan Stern wrote: > >> On Fri, 25 Nov 2016, Laurent Pinchart wrote: > >>> Dear linux-pm developers, what's the suggested way to ensure that a > >>>

Re: Enabling peer to peer device transactions for PCIe devices

On 2016-11-25 02:34 PM, Jason Gunthorpe wrote: On Fri, Nov 25, 2016 at 12:16:30PM -0500, Serguei Sagalovitch wrote: b) Allocation may not have CPU address at all - only GPU one. But you don't expect RDMA to work in the case, right? GPU people need to stop doing this windowed memory stuff

Re: Enabling peer to peer device transactions for PCIe devices

Am 25.11.2016 um 20:32 schrieb Jason Gunthorpe: On Fri, Nov 25, 2016 at 02:22:17PM +0100, Christian König wrote: Like you say below we have to handle short lived in the usual way, and that covers basically every device except IB MRs, including the command queue on a NVMe drive. Well a problem

Re: Enabling peer to peer device transactions for PCIe devices

On 16-11-25 03:40 PM, Christian König wrote: > Am 25.11.2016 um 20:32 schrieb Jason Gunthorpe: >> This assumes the commands are fairly short lived of course, the >> expectation of the mmu notifiers is that a flush is reasonably prompt > > Correct, this is another problem. GFX command submissions

Re: Enabling peer to peer device transactions for PCIe devices

On Fri, Nov 25, 2016 at 2:34 PM, Jason Gunthorpe wrote: > On Fri, Nov 25, 2016 at 12:16:30PM -0500, Serguei Sagalovitch wrote: > >> b) Allocation may not have CPU address at all - only GPU one. > > But you don't expect RDMA to work in the case, right? > > GPU

cron job: media_tree daily build: ERRORS

This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Nov 26 05:00:20 CET 2016 media-tree git hash:d3d83ee20afda16ad0133ba00f63c11a8d842a35 media_build

[PATCH v4] media: video-i2c: add video-i2c driver

There are several thermal sensors that only have a low-speed bus interface but output valid video data. This patchset enables support for the AMG88xx "Grid-Eye" sensor family. Cc: Attila Kinali Cc: Marek Vasut Cc: Luca Barbato Cc: Laurent

Re: Enabling peer to peer device transactions for PCIe devices

On Fri, Nov 25, 2016 at 12:16:30PM -0500, Serguei Sagalovitch wrote: > b) Allocation may not have CPU address at all - only GPU one. But you don't expect RDMA to work in the case, right? GPU people need to stop doing this windowed memory stuff :) Jason -- To unsubscribe from this list: send

Re: [PATCH 1/1] smiapp: Implement power-on and power-off sequences without runtime PM

On Fri, 25 Nov 2016, Sakari Ailus wrote: > Hi Alan and others, > > On Thu, Nov 24, 2016 at 09:15:39PM -0500, Alan Stern wrote: > > On Fri, 25 Nov 2016, Laurent Pinchart wrote: > > > > > Dear linux-pm developers, what's the suggested way to ensure that a > > > runtime- > > > pm-enabled driver

[PATCHv2] cec: pass parent device in register(), not allocate()

The cec_allocate_adapter function doesn't need the parent device, only the cec_register_adapter function needs it. Drop the cec_devnode parent field, since devnode.dev.parent can be used instead. This change makes the framework consistent with other frameworks where the parent device is not used

Re: ir-keytable: infinite loops, segfaults

On 11/25/16, Sean Young wrote: > > So if I understand you correctly, if you change the keymap, like you > changed 0xfe47 to KEY_PAUSE, then "ir-keytable -s rc1 -t" show you the > correct (new) key? So as far as ir-keytable is concerned, everything > works? > > However when you try

Re: [PATCH v4 2/3] media: change au0828 to use Media Device Allocator API

Em Wed, 16 Nov 2016 07:29:10 -0700 Shuah Khan escreveu: > Change au0828 to use Media Device Allocator API to allocate media device > with the parent usb struct device as the key, so it can be shared with the > snd_usb_audio driver. > > Signed-off-by: Shuah Khan

Re: Enabling peer to peer device transactions for PCIe devices

On Thu, Nov 24, 2016 at 11:11:34AM -0700, Logan Gunthorpe wrote: > * Regular DAX in the FS doesn't work at this time because the FS can > move the file you think your transfer to out from under you. Though I > understand there's been some work with XFS to solve that issue. The file system will

Re: [PATCH] v4l: async: make v4l2 coexists with devicetree nodes in a dt overlay

Hi Javi, On Wed, Nov 23, 2016 at 04:15:11PM +, Javi Merino wrote: > On Wed, Nov 23, 2016 at 05:10:42PM +0200, Sakari Ailus wrote: > > Hi Javi, > > Hi Sakari, > > > On Wed, Nov 23, 2016 at 10:09:57AM +, Javi Merino wrote: > > > In asd's configured with V4L2_ASYNC_MATCH_OF, if the v4l2

Re: [PATCH 0/3] Avoid warnings about using unitialized dest_dir

Em Mon, 21 Nov 2016 17:35:42 +0100 Arnd Bergmann escreveu: > On Saturday, November 19, 2016 12:56:57 PM CET Mauro Carvalho Chehab wrote: > > As Arnd reported: > > > > With gcc-5 or higher on x86, we can get a bogus warning in the > > dvb-net code: > > > >

Re: [PATCH v5 1/3] media: Media Device Allocator API

Em Fri, 18 Nov 2016 14:45:10 -0700 Shuah Khan escreveu: > Media Device Allocator API to allows multiple drivers share a media device. > Using this API, drivers can allocate a media device with the shared struct > device as the key. Once the media device is allocated by a

Re: Problem with media_build install

Hi list, I sent a patch for this issue, could someone take a look? http://www.mail-archive.com/linux-media@vger.kernel.org/msg105340.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at

[patch] [media] uvcvideo: freeing an error pointer

A recent cleanup introduced a potential dereference of -EFAULT when we call kfree(map->menu_info). Fixes: 4cc5bed1caeb ("[media] uvcvideo: Use memdup_user() rather than duplicating its implementation") Signed-off-by: Dan Carpenter diff --git

[GIT PULL for v4.9] media fix for xc2028 driver

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.9-4 For a fix at the firmware load logic at the tuner-xc2028 driver. Regards, Mauro --- The following changes since commit 9c763584b7c8911106bb77af7e648bef09af9d80: Linux 4.9-rc6

Re: [PATCH v4 3/3] sound/usb: Use Media Controller API to share media resources

Em Wed, 16 Nov 2016 07:29:11 -0700 Shuah Khan escreveu: > Change ALSA driver to use Media Controller API to share media resources > with DVB, and V4L2 drivers on a AU0828 media device. > > Media Controller specific initialization is done after sound card is >

Re: Problem with media_build install

Em Fri, 25 Nov 2016 20:02:57 +1100 Vincent McIntyre escreveu: > Hi list, > > I sent a patch for this issue, could someone take a look? > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg105340.html Patch applied. Next time, please add your

[GIT PULL FOR v4.10] HSV fixes for 4.10

Two fixes to make vivid work correctly with HSV. Regards, Hans The following changes since commit d3d83ee20afda16ad0133ba00f63c11a8d842a35: [media] DaVinci-VPFE-Capture: fix error handling (2016-11-25 07:57:07 -0200) are available in the git repository at:

Re: [PATCH] media: rc: refactor raw handler kthread

On Tue, Aug 02, 2016 at 07:44:07AM +0200, Heiner Kallweit wrote: > I think we can get rid of the spinlock protecting the kthread from being > interrupted by a wakeup in certain parts. > Even with the current implementation of the kthread the only lost wakeup > scenario could happen if the wakeup

[GIT PULL FOR v4.10] cec: pass parent device in register(), not allocate()

Hi Mauro, It's just a single patch, but I'd like to get that into 4.10. Now that the cec framework moves out of staging I prefer to get this kernel API change in before more CEC drivers are added. Regards, Hans The following changes since commit

Re: Enabling peer to peer device transactions for PCIe devices

Am 24.11.2016 um 17:42 schrieb Jason Gunthorpe: On Wed, Nov 23, 2016 at 06:25:21PM -0700, Logan Gunthorpe wrote: On 23/11/16 02:55 PM, Jason Gunthorpe wrote: Only ODP hardware allows changing the DMA address on the fly, and it works at the page table level. We do not need special handling for

Re: Enabling peer to peer device transactions for PCIe devices

Am 24.11.2016 um 18:55 schrieb Logan Gunthorpe: Hey, On 24/11/16 02:45 AM, Christian König wrote: E.g. it can happen that PCI device A exports it's BAR using ZONE_DEVICE. Not PCI device B (a SATA device) can directly read/write to it because it is on the same bus segment, but PCI device C (a

Re: [PATCH] Media: platform: vsp1: - Do not forget to call

Hi Shailendra, Thank you for the patch. The subject line is missing something (and has an extra -), I would phrase it as "v4l: vsp1: Clean up file handle in open() error path" (Mauro's scripts will add the "[media]" prefix when applying, so there's no need to add it manually) The same

Re: [patch] [media] uvcvideo: freeing an error pointer

> A recent cleanup introduced a potential dereference of -EFAULT when we > call kfree(map->menu_info). > > Fixes: 4cc5bed1caeb ("[media] uvcvideo: Use memdup_user() rather than > duplicating its implementation") > Signed-off-by: Dan Carpenter Thanks for your

[PATCH 2/5] media: entity: Be vocal about failing sanity checks

Commit 3801bc7d1b8d ("[media] media: Media Controller fix to not let stream_count go negative") added a sanity check for negative stream_count, but a failure of the check remained silent. Make sure the failure is noticed. Signed-off-by: Sakari Ailus ---

[PATCH 3/5] media: Rename graph and pipeline structs and functions

The media_entity_pipeline_start() and media_entity_pipeline_stop() functions are renamed as media_pipeline_start() and media_pipeline_stop(), respectively. The reason is two-fold: the pipeline struct is, rightly, already called media_pipeline (rather than media_entity_pipeline) and what this

[PATCH 1/5] media: entity: Fix stream count check

There's a sanity check for the stream count remaining positive or zero on error path, but instead of performing the check on the traversed entity it is performed on the entity where traversal ends. Fix this. Fixes: commit 3801bc7d1b8d ("[media] media: Media Controller fix to not let stream_count

[PATCH 4/5] media: entity: Split graph walk iteration into two functions

With media_entity_graph_walk_next() getting more and more complicated (and especially so with has_routing() support added), split the function into two. Signed-off-by: Sakari Ailus --- drivers/media/media-entity.c | 56

[PATCH 0/5] Media pipeline and graph walk cleanups and fixes

Hi folks, This patchset contains a few cleanups and fixes for graph traversal and pipeline starting and stopping. The set prepares for further routing changes without still making any of them. I'll post further patches on routing in the near future. Niklas: these go on top of your two patches

[PATCH 5/5] media: entity: Add debug information to graph walk

Use dev_dbg() to tell about the progress of the graph traversal algorithm. This is intended to make debugging of the algorithm easier. Signed-off-by: Sakari Ailus --- drivers/media/media-entity.c | 19 ++- 1 file changed, 18 insertions(+), 1

Re: [patch] [media] uvcvideo: freeing an error pointer

Hi Dan, Thank you for the patch. On Friday 25 Nov 2016 13:28:35 Dan Carpenter wrote: > A recent cleanup introduced a potential dereference of -EFAULT when we > call kfree(map->menu_info). I should have caught that, my apologies :-( Thinking a bit more about this class of problems, would the