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: <20210823084723.1493908-1-maxime@cerno.tech>
Date:   Mon, 23 Aug 2021 10:47:15 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Jonas Karlman <jonas@...boo.se>, Sam Ravnborg <sam@...nborg.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Daniel Vetter <daniel.vetter@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Maxime Ripard <maxime@...no.tech>,
        Neil Armstrong <narmstrong@...libre.com>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Robert Foss <robert.foss@...aro.org>,
        Andrzej Hajda <a.hajda@...sung.com>
Cc:     linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: [PATCH v3 0/8] drm/bridge: Make panel and bridge probe order consistent

Hi,

We've encountered an issue with the RaspberryPi DSI panel that prevented the
whole display driver from probing.

The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:
Only register our component once a DSI device is attached"), but the basic idea
is that since the panel is probed through i2c, there's no synchronization
between its probe and the registration of the MIPI-DSI host it's attached to.

We initially moved the component framework registration to the MIPI-DSI Host
attach hook to make sure we register our component only when we have a DSI
device attached to our MIPI-DSI host, and then use lookup our DSI device in our
bind hook.

However, all the DSI bridges controlled through i2c are only registering their
associated DSI device in their bridge attach hook, meaning with our change
above, we never got that far, and therefore ended up in the same situation than
the one we were trying to fix for panels.

The best practice to avoid those issues is to register its functions only after
all its dependencies are live. We also shouldn't wait any longer than we should
to play nice with the other components that are waiting for us, so in our case
that would mean moving the DSI device registration to the bridge probe.

If the general approach is agreed upon, other bridge drivers will obviously be
converted.

Let me know what you think,
Maxime

---

Changes from v2:
  - Changed the approach as suggested by Andrzej, and aligned the bridge on the
    panel this time.
  - Fixed some typos

Changes from v1:
  - Change the name of drm_of_get_next function to drm_of_get_bridge
  - Mention the revert of 87154ff86bf6 and squash the two patches that were
    reverting that commit
  - Add some documentation
  - Make drm_panel_attach and _detach succeed when no callback is there

Maxime Ripard (8):
  drm/bridge: Add documentation sections
  drm/bridge: Document the probe issue with MIPI-DSI bridges
  drm/mipi-dsi: Create devm device registration
  drm/mipi-dsi: Create devm device attachment
  drm/bridge: ps8640: Switch to devm MIPI-DSI helpers
  drm/bridge: ps8640: Register and attach our DSI device at probe
  drm/bridge: sn65dsi83: Switch to devm MIPI-DSI helpers
  drm/bridge: sn65dsi83: Register and attach our DSI device at probe

 Documentation/gpu/drm-kms-helpers.rst  | 12 ++++
 drivers/gpu/drm/bridge/parade-ps8640.c | 97 ++++++++++++++------------
 drivers/gpu/drm/bridge/ti-sn65dsi83.c  | 82 +++++++++++-----------
 drivers/gpu/drm/drm_bridge.c           | 70 +++++++++++++++++--
 drivers/gpu/drm/drm_mipi_dsi.c         | 81 +++++++++++++++++++++
 include/drm/drm_mipi_dsi.h             |  4 ++
 6 files changed, 256 insertions(+), 90 deletions(-)

-- 
2.31.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ