linux-kernel - [PATCH 0/3] drm/komeda: Support for drm

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

Message-ID: <20191004143418.53039-1-mihail.atanassov@arm.com>
Date:   Fri, 4 Oct 2019 14:34:34 +0000
From:   Mihail Atanassov <Mihail.Atanassov@....com>
To:     "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
CC:     Mihail Atanassov <Mihail.Atanassov@....com>, nd <nd@....com>,
        Liviu Dudau <Liviu.Dudau@....com>,
        Brian Starkey <Brian.Starkey@....com>,
        "james qian wang (Arm Technology China)" <james.qian.wang@....com>,
        Daniel Vetter <daniel@...ll.ch>,
        David Airlie <airlied@...ux.ie>,
        Maxime Ripard <mripard@...nel.org>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Sean Paul <sean@...rly.run>,
        Russell King <linux@...linux.org.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [PATCH 0/3] drm/komeda: Support for drm_bridge endpoints

Greetings,

This series attempts to add support for endpoints (in the DT sense)
whose drivers only have a drm_bridge interface, unlike the tda998x,
which uses the component framework and provides all of drm_encoder,
drm_bridge, drm_connector.

1 & 2 should be fairly non-contentious, and I believe are valuable
enough on their own as they remove some pointer chasing and a few
allocations at the top level of komeda.

3 is the meat of this series, where I add the drm_bridge endpoint code.
This was tested with ti_tfp410 on the back end of a D71. I've tagged it
with an RFC since I drew inspiration from tilcdc, which does similar
shenanigans to detect tda998x vs non-tda998x, and is hence a precedent
for including similar handling, but I wasn't sure if there's a more well
established pattern.

Note that I opted not to remove the previous way of doing things for
tda998x, even though it could work with the drm_bridge handling
directly, since AFAIUI, device links haven't been implemented for
drm_bridge (see [1] for an attempt at doing that that never landed, and
I'm not aware of any refcounting having been added since), and therefore
getting a drm_bridge driver rmmod'ed while in use would be Bad(tm).

[1] https://lore.kernel.org/lkml/20180426223139.16740-1-peda@axentia.se/

Cc: Liviu Dudau <liviu.dudau@....com>
Cc: Brian Starkey <brian.starkey@....com>
Cc: James (Qian) Wang <james.qian.wang@....com>
Cc: Daniel Vetter <daniel@...ll.ch>
Cc: David Airlie <airlied@...ux.ie>
Cc: Maxime Ripard <mripard@...nel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
Cc: Sean Paul <sean@...rly.run>

Mihail Atanassov (3):
  drm/komeda: Consolidate struct komeda_drv allocations
  drm/komeda: Memory manage struct komeda_drv in probe/remove
  drm/komeda: Allow non-component drm_bridge only endpoints

 .../gpu/drm/arm/display/komeda/komeda_dev.c   |  21 +--
 .../gpu/drm/arm/display/komeda/komeda_dev.h   |   9 +-
 .../gpu/drm/arm/display/komeda/komeda_drv.c   | 118 ++++++++-----
 .../gpu/drm/arm/display/komeda/komeda_kms.c   | 159 ++++++++++++++++--
 .../gpu/drm/arm/display/komeda/komeda_kms.h   |   9 +-
 5 files changed, 243 insertions(+), 73 deletions(-)

-- 
2.23.0