linux-kernel - Re: [PATCH v4 3/3] drm/mediatek: Implement OF graphs support for display paths

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]

Message-Id: <D1Q7OPR0TRFG.1WLSI7EBAPUWX@walle.cc>
Date: Mon, 03 Jun 2024 09:42:31 +0200
From: "Michael Walle" <michael@...le.cc>
To: "AngeloGioacchino Del Regno" <angelogioacchino.delregno@...labora.com>,
 <chunkuang.hu@...nel.org>
Cc: <robh@...nel.org>, <krzysztof.kozlowski+dt@...aro.org>,
 <conor+dt@...nel.org>, <p.zabel@...gutronix.de>, <airlied@...il.com>,
 <daniel@...ll.ch>, <maarten.lankhorst@...ux.intel.com>,
 <mripard@...nel.org>, <tzimmermann@...e.de>, <matthias.bgg@...il.com>,
 <shawn.sung@...iatek.com>, <yu-chang.lee@...iatek.com>,
 <ck.hu@...iatek.com>, <jitao.shi@...iatek.com>,
 <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <dri-devel@...ts.freedesktop.org>, <linux-mediatek@...ts.infradead.org>,
 <linux-arm-kernel@...ts.infradead.org>, <wenst@...omium.org>,
 <kernel@...labora.com>
Subject: Re: [PATCH v4 3/3] drm/mediatek: Implement OF graphs support for
 display paths

Hi Angelo,

> >> Implement OF graphs support to the mediatek-drm drivers, allowing to
> >> stop hardcoding the paths, and preventing this driver to get a huge
> >> amount of arrays for each board and SoC combination, also paving the
> >> way to share the same mtk_mmsys_driver_data between multiple SoCs,
> >> making it more straightforward to add support for new chips.
> > 
> > paths might be optional, see comment in mtk_drm_kms_init(). But with
> > this patch, you'll get an -EINVAL with a disabled path. See my
> > proposals how to fix that below.
>
> I might not be understanding the reason behind allowing that but, per my logic, if
> a board does have a path, then it's written in devicetree and enabled - otherwise,
> it should not be there at all, in principle.
>
>
> Can you explain a bit more extensively the reason(s) why we need to account
> for disabled paths?

Paths should be (and this was already supported before this patch
with the hardcoded paths) disabled with the status property. This
way you can have a common board configuration where all the paths
are already described but are disabled. An overlay (or maybe another
dts variant) can then just enable the pipeline/output port by
overwriting the status property.

Also, this is the usual DT usage, as a node with status = "disabled"
should just be skipped. Without handling this, the current code will
return -EINVAL during probe (IIRC, my vacation might have reset my
memory :o).

-michael

Download attachment "signature.asc" of type "application/pgp-signature" (298 bytes)