linux-kernel - [PATCH] drm/dp: For drm_panel_dp_aux_backlight(), init backlight as disabled

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]

Date:   Wed, 14 Jul 2021 10:17:46 -0700
From:   Douglas Anderson <dianders@...omium.org>
To:     Rajeev Nandan <rajeevny@...eaurora.org>,
        Lyude Paul <lyude@...hat.com>,
        Robert Foss <robert.foss@...aro.org>
Cc:     Daniel Thompson <daniel.thompson@...aro.org>,
        Lee Jones <lee.jones@...aro.org>,
        Jingoo Han <jingoohan1@...il.com>,
        Douglas Anderson <dianders@...omium.org>,
        Daniel Vetter <daniel@...ll.ch>,
        David Airlie <airlied@...ux.ie>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: [PATCH] drm/dp: For drm_panel_dp_aux_backlight(), init backlight as disabled

Even after the DP AUX backlight on my board worked OK after applying
the patch ("drm/panel-simple: Power the panel when probing DP AUX
backlight") [1], I still noticed some strange timeouts being reported
by ti_sn_aux_transfer(). Digging, I realized the problem was this:
* Even though `enabled` in `struct dp_aux_backlight` was false, the
  base backlight structure (`base` in that structure) thought that the
  backlight was powered on.
* If userspace wrote to sysfs in this state then we'd try to enable
  the backlight.
* Unfortunatley, enabling the backlight didn't work because the panel
  itself wasn't powered.

We can only use the backlight if the panel is on and the panel is not
officially on when we probe (it's temporarily just on enough for us to
talk to it).

The important thing we want here is to get `BL_CORE_FBBLANK` set since
userspace can't mess with that. This will keep us disabled until
drm_panel enables us, which means that the panel is enabled
first. Ideally we'd just set this in our `props` before calling
devm_backlight_device_register() but the comments in the header file
are pretty explicit that we're not supposed to much with the `state`
ourselves. Because of this, there may be a small window where the
backlight device is registered and someone could try to tweak with the
backlight. This isn't likely to happen and even if it did, I don't
believe this causes any huge problem.

[1] https://lore.kernel.org/lkml/20210714093334.1.Idb41f87e5abae4aee0705db7458b0097fc50e7ab@changeid/

Signed-off-by: Douglas Anderson <dianders@...omium.org>
---

 drivers/gpu/drm/drm_dp_helper.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index e8eec20ab364..b5f75ca05774 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3568,6 +3568,8 @@ int drm_panel_dp_aux_backlight(struct drm_panel *panel, struct drm_dp_aux *aux)
 	if (IS_ERR(bl->base))
 		return PTR_ERR(bl->base);

+	backlight_disable(bl->base);
+
 	panel->backlight = bl->base;

 	return 0;
-- 
2.32.0.93.g670b81a890-goog