lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0137b1b9-1eb1-cff6-0e0e-fed446ccca64@linaro.org>
Date:   Mon, 21 Aug 2017 17:13:28 +0300
From:   Stanimir Varbanov <stanimir.varbanov@...aro.org>
To:     Marek Szyprowski <m.szyprowski@...sung.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Hans Verkuil <hverkuil@...all.nl>
Cc:     Pawel Osciak <pawel@...iak.com>,
        Kyungmin Park <kyungmin.park@...sung.com>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 1/7 v3] media: vb2: add bidirectional flag in vb2_queue

Hi Marek,

On 08/21/2017 03:21 PM, Marek Szyprowski wrote:
> Hi Stanimir,
> 
> On 2017-08-21 13:34, Stanimir Varbanov wrote:
>> This change is intended to give to the v4l2 drivers a choice to
>> change the default behavior of the v4l2-core DMA mapping direction
>> from DMA_TO/FROM_DEVICE (depending on the buffer type CAPTURE or
>> OUTPUT) to DMA_BIDIRECTIONAL during queue_init time.
>>
>> Initially the issue with DMA mapping direction has been found in
>> Venus encoder driver where the hardware (firmware side) adds few
>> lines padding on bottom of the image buffer, and the consequence
>> is triggering of IOMMU protection faults.
>>
>> This will help supporting venus encoder (and probably other drivers
>> in the future) which wants to map output type of buffers as
>> read/write.
>>
>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@...aro.org>
> 
> Thanks for the patch.
> 
> Acked-by: Marek Szyprowski <m.szyprowski@...sung.com>

Thanks!

> 
> While touching this, I would love to unify set_page_dirty_lock()
> related code in videobuf2-dc, videobuf2-sg and videobuf2-vmalloc.
> 
> IMHO the pattern used in videobuf2-vmalloc should be copied to
> videobuf2-sg (currently checks for dma_dir for every single page)
> and videobuf2-dc (currently it lacks any checks and calls
> set_page_dirty_lock() unconditionally). If you have a little bit
> of spare time, please prepare a separate patch for the above
> mentioned fix.

Sure, I'll unify set_page_dirty_lock invocations in separate patch.

-- 
regards,
Stan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ