linux-kernel - Re: [PATCH v4 3/7] drm/tinydrm: Add MIPI DBI support

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:   Sun, 12 Mar 2017 20:02:15 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Noralf Trønnes <noralf@...nnes.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 3/7] drm/tinydrm: Add MIPI DBI support

On Sun, Mar 12, 2017 at 7:42 PM, Daniel Vetter <daniel@...ll.ch> wrote:
>
> The upshot of all this is two-fold:
>
> - You get rid of a tiny bit of book-keeping in each tinydrm driver (the
>   merge_clips above, plus the "is this the current fb on our hw" check).
>
> - There's lots more manual upload devices than just tinydrm, or
>   drm_simple_pipe, this would benefit any atomic driver.
>
> - Long-term we want to expose the dirty_clip as properties to userspace,
>   since the compositor already computes this anyway for each atomic update
>   (at least good compositors do this). Test-driving these new properties
>   within the kernel would help in catching issues.

- Correct locking: taking the ->dirty_lock only protects against
concurrent other ->dirty or simple_pipe->update operations, it doesn't
protect against concurrent modeset changes (i.e. someone could disable
the panel while you try to upload stuff). Moving the locking out of
panel drivers into this one single core helper removes the need for
any locking in drivers. And no need for locking == no way to screw it
up :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch