linux-kernel - Re: [v4,1/3] drm/prime: use dma length macro when mapping sg

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 30 Mar 2020 10:39:41 +0100
From:   Shane Francis <bigbeeshane@...il.com>
To:     Marek Szyprowski <m.szyprowski@...sung.com>,
        Christian König <christian.koenig@....com>
Cc:     Maling list - DRI developers <dri-devel@...ts.freedesktop.org>,
        David Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
        amd-gfx-request@...ts.freedesktop.org,
        Alex Deucher <alexander.deucher@....com>
Subject: Re: [v4,1/3] drm/prime: use dma length macro when mapping sg

On Mon, Mar 30, 2020 at 9:18 AM Marek Szyprowski
<m.szyprowski@...sung.com> wrote:
> Today I've noticed that this patch went to final v5.6 without even a day
> of testing in linux-next, so v5.6 is broken on Exynos and probably a few
> other ARM archs, which rely on the drm_prime_sg_to_page_addr_arrays
> function.
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>

Not sure what the full merge pipeline is here, but my original patch
was not sent to the stable mailing list. So I would assume that it
went through the normal release gates / checks ? If there was a fault
on the way I uploaded the patches I do apologise however I did follow
the normal guidelines as far as I understood them.

Personally I did validate this patch on systems with Intel and AMD GFX,
unfortunately I do not have any ARM based dev kits that are able to run
mainline (was never able to get an Nvidia TK1 to boot outside of L4T)